I failed a take-home assignment from Kagi Search

My honest feedback below from the perspective of a hirer. I&#x27;ll start by saying I hate takehome stuff, for exactly reasons like this. It wastes everyone&#x27;s time. They&#x27;re fine as a &#x27;last step before hire&#x27; thing, but not as a filter.<p>1 - Too much chatter. Part of the assignment is using judgment and working in ambiguity. I probably would have ran with what was given enough to knock out something small and local in an evening or two. Asking questions is usually fine, they even welcomed it, but seems counter to the original ask.<p>2 - Writing and sharing a proposal seemed like way overkill. You have to remember that these companies are now getting hundreds if not thousands if not tens of thousands of applicants, that is a lot to deal with if everyone does so. I think it&#x27;s a bit of a disconnect...you feel like you&#x27;re going above and beyond and being thorough, they feel like it&#x27;s being a bit long winded and wasting time. That probably explains the nonresponse.<p>3 - The finished product seemed functional, but seemed a bit overkill on the infra and polish. This is probably a good thing to work with you, but ended up wasting a lot of your time if not being selected, which was the case.<p>4 - Maybe I missed something, but the requirement asked for terminal inspired. I&#x27;m not quite sure precisely what they meant by that, but didn&#x27;t see any possible interpretation of that in the result.<p>Anyways, hope you don&#x27;t take it too negatively or personally - you obviously are a talented individual and moreso seem to really care about your work. Just wanted to play a little devil&#x27;s advocate with a different perspective.

My first though on looking at the code, and then on demo video was: wow, it took that person a solid week to write a web app with two pages.. all while missing the most basic email features, like an ability to opening a message (and not just show full text of mail bodies on one page).<p>Later on I read the requirements... This person applied to a position named &quot;Email Backend Engineer&quot; but they actually used a third-party product (postmark + turso) for email backend! They also clearly don&#x27;t think about email too much - the basic stuff, like plaintext email formatting, viewing, and folders (at least inbox + outbox) are simply missing; while there are optional features, like login screen, admin page and backend framework. And backend database does not even containing a email headers map!<p>That person might be a great engineer, but I don&#x27;t think they would be a good fit for that specific position. I&#x27;d reject them as well.<p>(A separate question is that hiring manager&#x27;s second response... We don&#x27;t do take-home interviews, but I imagine I&#x27;d be stumped by a proposal like that, it seems so irregular in a take-home assignment. Still, I can see how the candidate took that response for an approval... perhaps a next candidate would get an extra sentence perhaps something like &quot;actual problem grading would depend on the code quality, number of features implemented, and how close those are to requirements and job description&quot;)<p>Update: read original job description and not just the except from the blog. That person surely omitted some stuff in their blog! the original title was:<p>&quot;The project is to build a minimal, terminal-inspired email client&quot;<p>it gave examples:<p>&quot;Your implementation should take inspiration from existing terminal email tools like aerc, mutt, or even something like himalaya.&quot;<p>wow! that&#x27;s 100% no hire, serious inability to read the requirements.

Take home assessments can be a valuable part of an interview process but they absolutely need a time limit. I think 2-3 hours is going to give you all the information you need, unless what you&#x27;re selecting for is new grads with no dependents, hobbies, or responsibilities.<p>If this had been limited to 3 hours then the worst case is that the candidate would have lost 3 hours, but far more likely is that they would have come up with an entirely different proposal and&#x2F;or solution that was appropriate for that timeline, and that extra information would have made it clearer what the company was looking for.<p>The other point I&#x27;d always encourage applicants to confirm is: are you looking for <i>any answer</i>, or are you looking for <i>a good answer</i>. Some take-home tests are purely about passing a test suite and how you manage it doesn&#x27;t matter, some would prefer that you meet 80% of the requirements but write better code. I&#x27;ve seen applicants do the wrong thing on both sides of this.

I understand that their responses were very minimal and not helpful, but it clearly says in the requirements to make a &quot;terminal-inspired&quot; email client. However, in the video you shared [1] I see a somewhat generic email web app, with nothing particularly &quot;terminal-inspired&quot;. Considering the fact that they wanted either a real TUI or a webapp, I&#x27;m pretty sure that the web app should&#x27;ve also been &quot;terminal-inspired&quot;. Am I missing something? I&#x27;m not trying to necessarily criticize you, perhaps I just misunderstood the requirements.<p>Edit: I&#x27;ve actually checked the full requirements page, and they explicitly say this in &quot;Inspiration&quot;:<p>&gt; Your implementation should take inspiration from existing terminal email tools like aerc, mutt, or even something like himalaya.<p>[1] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=yY1sVXMkP_o" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=yY1sVXMkP_o</a>

I did a recent round of interviews and this experience closely mirrors mine (at multiple places). Delivered an exceptional solution to the problem only to be rejected <i>without</i> a discussion about the delivered project. I have been on the hiring end of take-homes multiple times and firmly believe that if you ask someone to do a take-home assignment you <i>must</i> follow up with a chat about the code. Apparently that&#x27;s not the case at most places.<p>If you&#x27;re asked to do a take home, I <i>highly</i> recommend confirming that there will be a follow up regardless of the assessment, and if they do not agree to this, do not do the &quot;home work&quot;. The honest truth is that most of the teams hiring are of pretty low quality and therefore implementing a good solution is a negative because the team hiring is not at your level (which is a frustrating reason for being rejected).<p>I&#x27;m an early adopter of Kagi and am now planning on cancelling my account over of this. Completely unacceptable. If you don&#x27;t have time to chat with a candidate about their work, don&#x27;t ask them to do the work in the first place.

This is a classic case of misreading the subtext. They want you to be independent and able to create your own work and goals. The ambiguity of the take home task is not there for you to interrogate over multiple emails, rather its an open palette for you to show how you take a relatively broad task and produce your own interrogation of the problem space.<p>As someone who works at a university this is very reminiscent of students who don&#x27;t understand the assignment then complain when they get an unexpected mark.

Since the author himself seems to have posted this, I figure I might as well try to help contextualize the response he got. I worked at Kagi (though not on their search product) and went through a similar take-home test. Obviously, a lot of disclaimers: this was a while ago, I am obviously biased, I am not at Kagi anymore and this is my perspective. I&#x27;m not even sure how they would feel about this but they&#x27;re more than welcome to say hi if not reply to the actual content of this comment.<p>When I went through the process the company was very small and Vlad personally reviewed applicants, and he used take home projects like this one. It seems like the company has grown larger so now he isn&#x27;t looking at them himself anymore, but the essence seems the same. If you ever talk to him you&#x27;ll find that he&#x27;s basically the Hacker News commenter stereotype and his interview is really a vibe check to see if you seem cool. To him, submitting a long design doc where you go &quot;I am going to use Galactor. I will make sure the project is florp-ready. I will fleem.&quot; is the exact opposite of cool. When the assignment says &quot;I want a terminal-inspired email client&quot; the project that passes with flying colors has keyboard shortcuts for everything and comes with a paragraph explaining how it never takes more than 2ms to draw a frame. I suspect the interviewer thinks you are too &quot;enterprise-brained&quot; to work at Kagi.<p>Now, is this actually a good way to screen people? A bunch of other people here have opinions on it, so I won&#x27;t rehash it too much. There are obvious problems with it. Vlad basically wants people who think like him. This kind of interview has a lot of problems that have been discussed and studied at length. But if you understand that and are privileged enough to go through that process, the task will actually make sense to you. I think Kagi could do a better job at communicating this. It&#x27;s unfortunate that you had to waste a bunch of your time to get to this point but I hope you can find something else that matches your working style better.

I took a look at the code, to see how I would react as a reviewer.<p>In the first file I opened, I got as far as here: <a href="https:&#x2F;&#x2F;github.com&#x2F;Sleepful&#x2F;mymail&#x2F;blob&#x2F;main&#x2F;app&#x2F;router&#x2F;pageGroup.go#L40">https:&#x2F;&#x2F;github.com&#x2F;Sleepful&#x2F;mymail&#x2F;blob&#x2F;main&#x2F;app&#x2F;router&#x2F;page...</a><p><pre><code> &#x2F;&#x2F; Create a context variable that inherits from a parent, and sets the value &quot;test&quot;. &#x2F;&#x2F; Create a context key for the theme. ctx, err := getEmails(pb, e) </code></pre> First line is very weird, unrelated to the task. Maybe copy-paste from a sample in a blog post? Anyway not paying attention to leave it in.<p>Wording in the second line is not consistent with third.<p>I’d stop my review there. Lack of attention to detail. Author does not demonstrate an ability to think clearly.

I had a similar experience with DuckDuckGo several years ago, but the difference was that I got paid as I progressed through the various stages.<p>I had to submit a short written design proposal and was told to cap it at a few hours and was paid for it. It was accepted and then I spent time implementing a solution. The pay again was capped at a certain amount of hours, but I ended up going past the recommendation because I was actually having fun trying to figure it out.<p>I submitted the solution and after a while I got a response with basically, &quot;it was a difficult decision, but sorry we&#x27;re going to pass&quot; and they wouldn&#x27;t provide additional detail. It&#x27;s been over 5 years, but I still wonder why they passed.<p>I can only assume they had a lot of candidates and they may have had other very strong submissions that were better than mine. However, it took a lot out of me emotionally and affected me for quite some time... more than any other interview in my ~20 year career. I feel for the OP.

As an engineering interviewer I feel the urge to comment. I like neither leet code, nor home assignments. They are both time consuming and provide you with a little information.<p>But having said this I would have likely rejected the author too. Kagi Search is a startup, these folks are typically looking for fast moving, pragmatic optimists who can strike the breadth - depth balance.<p>We used to have a colleague. They would collect the inputs, close themselves for a few days, come up with a solution only to learn that reqs changed in the meantime. It was not pleasant experience for anyone.

Man, I hate take-homes.<p>When I see instructions that say “This project tests your ability not only to code, but to deal with ambiguity and open-endedness”, it actually means either a) this exercise has been so poorly conceived that we didn’t bother with a rubric or b) the work environment is so chaotic, we never clearly define specs or requirements for anything.<p>That, and the instruction to simultaneously “show off your skills” and deliver a pragmatic functional solution are completely at odds. Good simple solutions aren’t flashy.

I worked with a lot of engineers in my 40+ year engineering career. One thing that most engineers don&#x27;t like is ambiguity. I didn&#x27;t like it either, until mid career when I was thrown into an environment where the customers didn&#x27;t really know what they wanted, and it was impossible to explore all of the solution space within time and budget constraints. I ended up thriving in this environment, but I watched as many qualified and experienced engineers floundered and over-stressed themselves. The attrition rate in this environment was about 80%. To survive, I had to use intuition, speculation, and innovation -- things I had not used much in my previous engineering roles. I sadly watched while a lot of really good engineers chose to move on, or were assigned to less relevant roles.<p>In this case, I perceive that the author (Jose) was looking for firm requirements, and did what he could to elicit them, but the Kagi folks were just looking for innovation and a demonstration of competency. They didn&#x27;t care as much about the details of the submittal as they did about seeing what the candidate would do without specific requirements.

I just read half of the article and this is painful to read. They’re asking for something relative simple as a take home, that just requires a little bit of imagination to fill the gaps. Why does the candidate have to be so fussy about details? Do the best you can, fast, and don’t announce you’re gonna be 2 days late for a take home!<p>To work in a startup you have to embrace the &quot;just do it&quot; mindset, you have a brain to fill the gaps, and you can always iterate later. I’d be more interested in getting the result of the take home quickly, obviously in a working state, but with a documentation explaining trade offs because of lack of time, ideas for future improvements, design choices, stuff not included (ie. a pretty UI) etc.<p>My take: they’re literally asking for a CRUD (if you decouple well, you can easily replace the DB with SMTP&#x2F;IMAP later) with basic email features: send (to, cc, bcc), fetch, reply, reply all, transfer. That’s it, you can do it in 2 hours. Add folders, signatures, &quot;send later&quot;, authentication, or whatever if you want to show off.<p>--<p>Additionally as an experimented Go developer (8 years working with Go as my main language), the code is not great and tbh I would have rejected it if I received this technical test where I work.<p>In 5 minutes of reading the code:<p>- lots of commented out test stuff, don&#x27;t leave that in a take home or I&#x27;m gonna assume you&#x27;ll do the same in your commits<p>- lots of println but no logging<p>- relative imports (eg &quot;mymail&#x2F;app&#x2F;router&quot;), don&#x27;t do this<p>- weird choice of relatively big dependencies (turso? pocketbase? negroni?)<p>- no architecture or decoupling, everything is in the router<p>- bad use of the context (getEmails)<p>- no tests (no need to test everything for a take home but at least some things can be tested)<p>People say languages are interchangeable and you&#x27;re never a &quot;xxx&quot; dev, but that&#x27;s not true. They asked for &quot;Proficiency in Go&quot; and the candidate is not proficient in Go, that would be the number 1 reason for rejection.

Building a concrete, working, <i>minimum-viable</i> solution from ambiguous requirements: that&#x27;s the point of the exercise. That&#x27;s what hiring managers want in candidates because those candidates end up being good at building a concrete, working solutions from ambiguous requirements. Which is <i>every software project ever</i>. Although the AI Age has unquestionably changed the efficacy of this kind of candidate screening, that is orthogonal to this discussion. For many years it has been one of the most-effective ways to screen for the ability to build concrete, working solutions from ambiguous requirements. Which is <i>every software project ever</i>. So it&#x27;s no surprise it persists.

Man this sounds rough. I had a somewhat similar experience a while back but instead of going back and forth trying to nail down requirements, I went down this spiral of wondering if the lack of clarity wwas part of some kind of meta-test.<p>&quot;Do they want to see if I can build something with as little guidance as possible?&quot;<p>&quot;Do they want me to push for more requirements like I would on a real project?&quot;<p>&quot;If I build something cool but totally off from what they expected will that make me look better or worse?&quot;<p>&quot;Or are they just trying to weed out the people that can&#x27;t code at all?&quot;<p>In the end I didn&#x27;t get a follow-up interview and they refused to give me any feedback on how I could have done better on the take-home assessment.<p>Back to the OP: <i>One such example would be to do a live code review. This could be done asynchronously or synchronously. It could allow actually talking through topics and issues that relate to the challenges in a real software project. This would allow to surface much more of the knowledge in an experienced software engineer.</i><p>I like this idea a lot.

I have done this dance a few times. My learning about interview assignments is review the written grading rubric before reading anything else. If the grading criteria lacks specificity then don’t do the assignment. If there is no provided grading rubric in advance then don’t do the assessment.

I was sick of working with this guy halfway through his blog post. To me it was pretty clear what they wanted, it was a &quot;show us what you can do&quot; kind of assignment while he wanted handholding and constant validation, already making excuses for being late and avoiding IMAP&#x2F;POP due to &quot;complexity&quot; when applying for a backend email engineer position.<p>Yes, they should&#x27;ve told you not to bother after you sent that proposal. But they were completely right to ultimately reject you. You&#x27;re a lot of work.

I just can’t get past the fact that he didn’t even deliver on the core deliverable of “ The project is to build a minimal, terminal-inspired email client”. Nothing about the demo I watched on YouTube looked “terminal-inspired”

I feel like Kagi was just asking &quot;Impress us&quot; and OP misunderstood the assignment by actually building a solid project and handling edge cases that no one cared about.<p>Anyways thanks for writing this up OP, it was an interesting read and I am a Kagi customer so I liked learning about them.

I understand the frustration here. I assume Kagi has a lot of candidates and is trying to identify the best ones for handling ambiguity. While I can appreciate the interviewee’s desire for more information or a rubric, it might potentially hurt the effectiveness of the take-home assignment.<p>During my college days, I had an on-campus interview with Microsoft that served as an assessment for whether I would be eligible for more in-person interviews in Seattle. The interview question was open-ended: “I would like you to design an alarm clock.” It seemed like an unusual open-ended question that prompted me to consider several critical factors, such as the intended audience, physicality, visibility, and audibility. By considering these factors and not immediately presenting a solution, the interview team informed me that I had passed the test. If they had provided me with more specific instructions or guidelines before the interview, they might have missed a signal that was important to them.<p>Unfortunately, I did not advance to the subsequent rounds at Microsoft. I interviewed during the fall semester. While I made it thru the full process, I was informed that I lacked confidence, but wasn’t a no. I was encouraged to reapply in the spring. The initial experience had left me drained and disheartened, so I decided not to pursue a second attempt. I now deeply regret this decision and wish I had given it another chance. If anyone is in a similar situation during their college years, I strongly advise them to avoid making my mistake. Working at a FAANG company could have changed my entire life and career trajectory.

This article perfectly highlights the perils of <i>unbounded</i> take home tests.<p>A timeboxed test for a small group (say, no more than 10) of final candidates can be an excellent differentiator.<p>The problem here is Kagi have omitted the timebox, so less confident and&#x2F;or experienced candidates go to the ends of the earth to deliver something that was never going to meet the mark.<p>Had Kagi said “spend no more than 4 hours on this” - and arguably reduced some of the requirements accordingly - then your man here wouldn’t have wasted a week (!) of his time and Kagi’s.<p>It’s a real shame that so much time was wasted by the candidate, but the requirements are very clear that “This project tests your ability … to deal with ambiguity and open-endedness”. He’d already dug a hole for himself before he’d started, unfortunately.

Feels harsh to jump on them for it, but it seems like they forgot the job spec when doing the take home. From that list Kagi wants to confirm:<p>- Proficiency in Go - Strong understanding of scaling and maintaining backend systems - Solid understanding of containerization technologies like Docker<p>Nailing the take home would require a project that demonstrates all three. Of those I think they maybe do okay on the second one, though offloading to paid services is maybe cheating a little there. I don&#x27;t think they do well at either of the other two though.<p>From the detailed spec, one might expect the project to demonstrate those things, but the code as submitted just doesn&#x27;t.

I don&#x27;t mind take home assignments per se, but it seems like there should be a reasonable &quot;this should take this long&quot; time boxing of the thing so people don&#x27;t waste a ton of time. I&#x27;ve done take-home things a couple of times and they always had &quot;this should take 12 hours&quot; or whatever time amount.<p>The &quot;simpler&quot; solution part stood out to me though. Given that Kagi was putting little effort into the thing, I wonder if his verbosity&#x2F;try-hardness might have been a turnoff? Afterall, part of the thing is determining if you <i>want</i> to work with a person, my impression reading his blog post was.. mildly turned off? There was just a bit of desperation to it (which might be from real factors!) but still. That sounds mean and I don&#x27;t like saying it, that&#x27;s just kind of the vibe that hit me.

It&#x27;s a tough lesson, but a good one to learn early: never waste time with interview take home assignments. This is especially true for broad and ambiguous assignments that you will need to sink lots of time into.<p>What if there are 300 other applicants? What&#x27;s to disincentivize giving all of them the assignment even when there&#x27;s only one open position? There is no guarantee that anybody will even clone your repository.<p>In a live coding interview, the company is committing valuable engineering resources to evaluate you. You have some assurances that they actually want to hire someone and not just get free labor or waste your time.

It sounds like Kagi asked for something simple but creative, and the author overengineered it.

Failing an assignment might cost you one job opportunity, but complaining about it publicly can harm your reputation and limit your chances with a lot of employers.<p>In the long run, venting online can be far more damaging than the initial setback - and a huge waste of time!

Probably Kagi is using candidates as &quot;chatgpt&quot; answers on what they want to further work on for free. I have already suspect this kind of shenigans 2 years ago and stopped my Kagi subscription. As for adverts on positions, ghost jobs likely. That is the current trends. As for Jose, don&#x27;t be surprised say 3 years from now they contact you. Some companies pool potential candidates like backup boyfriends. I usually just flat out ban this kind of companies and actively spread these companies to my circle to avoid. The lost is really on these companies without further access to specific job pool (and even customers) and of course bad evangelism on their part for decades to come even if they have changed.

I feel Kagi&#x27;s entire point of the take home assignment is to see how people handled assignments if left to their own devices with little instructions to go off.<p>When good companies are trying to hire engineers, they don&#x27;t hire based on skill alone. They also try to hire based on how a person performs given certain constraints like time and ambiguity.<p>Sharing a proposal and asking for more time was probably the polar opposite what they were looking for<p>I think a lot of product managers prefer to see simple, fast solutions to a take home assignment. Understandable and turned in on time.

While I would never do a take-home assignment for a job, I think your expectations are out of line with the current buyers market that has hundreds or thousands of applications for every position.<p>Your solution is the same old thing thousands of others could produce. They want more than a programmer that knows some languages, tools and libraries.<p>I think they might give you 10 more minutes of their consideration if you simply produced a command-line program in Go that used sockets to talk protocols to servers.

Seems ultimately the applicant and company weren&#x27;t going to be a good fit. An interview is a process where both parties evaluate each other. This applicant set the bar too low for this company and wasted time when the signals were there from the start.

Although I agree with you regarding leetcode and the lack of feedback on rejections, I honestly don&#x27;t understand the dislike for take-home assignments. If you truly enjoy coding, you could see them as an excuse to work on a new hobby project.

The author didn&#x27;t really ask for a code review, though a lot of people imagining themselves in the position of technical hiring manager are already taking care of that.<p>Anyway: I don&#x27;t think homework assignments are a valuable mechanism for filtering out candidates. Setting aside shoulds and shouldnots and the ethics of it and everything else, it simply provides a really poor signal for the value of a potential candidate.<p><i>Especially</i> today, when something like this particular assignment could just be pasted into any of the popular LLMs and returned as completed within a couple hours.<p>If an organization wants to hire developers that can take vague project descriptions and convert them into code that may or may not do whatever was in the heads of the people that wrote the project description, then (a) that&#x27;s a bad practice, but (b) it would be better for everyone involved if you handled this over a video call. If your staff are too busy to do a small pile of video calls with potential candidates over a couple of weeks, then they are too busy to properly onboard a new candidate and you should probably just pack it in. (i.e., they are <i>not</i> too busy to do this.)<p>If the goal is to hire somebody that knows IMAP, SMTP, POP, etc. inside-and-out and can crank out RFC-compliant code without using any of the third-party libraries that already exist for this sort of thing, then the assignment description should have asked for that.<p>Homework assignments are an unfortunately common practice, but worst of all, most of them are carelessly designed.

I forgot my own rule: if the test is to filter out candidates that is ok, if it is to filter in, then it is nok. Filter out: small app with bugs, find the bug or add a small feature.

You had the right idea to begin with - never do take home assignments.<p>Second - this is the wrong approach. Nothing wrong with writing a small doc. Write it, then implement the necessary features (terminal inspired client that can read and send email), and test it. Literally a cli for read and send, tack on curses or use imgui. Do IMAP&#x2F;POP&#x2F;SMTP or emulate it. The job position is for a backend role in the email team.<p>Tack on bells and whistles later.

I went through something very similar — spent several days on a take-home assignment, took it seriously, carefully followed all the instructions and delivered everything.<p>Then I waited for two weeks, and all I got was a clearly templated response.<p>The worst part isn’t even the rejection — it’s the vague replies, or no reply at all.It just makes you feel like your time doesn’t matter.<p>Thank you for writing this. We really do need more people to speak up about these things.

I read so many responses (the replies here to this post and to so many other similar posts) of the form<p>&quot;Oh, I simply refuse to do interviews [of format xyz]. It&#x27;s just not worth my time...&quot;<p>I feel like such a worthless piece of crap when I read these. I apply to hundreds of places, and when someone comes along that even wants to talk to me or a miracle happens and I get to any sort of technical round, I simply DON&#x27;T HAVE THE OPTION to be turning them away for <i>any</i> reason.<p>Like, these companies have <i>all</i> the leverage right now, and lots of us have none. Responses like &quot;just tell them no&quot; seem so tone deaf. I guess some of you must be seriously baller, but it seems otherworldly to me.<p>This is close to how I feel when I read posts on Linkedin &quot;demanding&quot; that companies dispense with some unethical hiring practice (e.g. keeping up job postings for which they are not hiring, rejecting candidates without feedback, endless interview rounds, etc). I&#x27;m like, &quot;Dude! The people who are doing this do not give a rat&#x27;s ass about your preachy Linkedin post. We have no leverage here. Spare me your clickbait.&quot;<p>End of rant.

You probably triggered LLM blindness with your proposal. Never use formal style speech in markdown with bullet points.

Without wanting to be unkind, this author misunderstands the purpose of the exercise, which is to demonstrate to another human being that you can write code that meets the company&#x27;s standards (as in, would pass PR review), not to ship a fully-functional product solo. The initial email makes it explicit that they don&#x27;t care if the product even works (&quot;Can use a fake backend&quot;) and that the specifications are deliberately open-ended. A little intuition and empathy can tell you that they probably are not going to spend many hours reviewing a complex submission, so the project should optimize for demonstrability of code quality, not completeness.<p>&quot;I would like to know what kind of response I could expect...&quot; - This is also established from the beginning: you can expect either a &quot;Looks good, let&#x27;s do some interviews&quot; or a &quot;Sorry, not interested,&quot; based on the code you submit. They can&#x27;t narrow down the choices prior to your submission, because they&#x27;re grading your submission, not your proposal document with an extensive list of details that they already told you they&#x27;re mostly ambivalent to.<p>&quot;So it is funny that my project is so weak, yet it made them update the guidelines to something stricter.&quot; - Main character syndrome. As someone who has been on the other side of these kinds of reviews, the far more likely explanation is that they kept getting submissions where the build instructions didn&#x27;t work (which is not disqualifying by itself; the authors may not be on the same OS as the reviewers) and they got tired of spending time dealing with it.<p>Ultimately, the failure here was not a technical one but a social one. The author tried very hard to do the thing that it seemed like they were asking for, not the thing they actually wanted. The hiring manager&#x27;s unwillingness to engage with the proposal doc was itself a form of communication that they were not interested in this level of detail, it was just an implicit one.<p>It&#x27;s common for engineer types to want all that kind of communication to be explicit, and I have a lot of sympathy for those folks, but the reality is that teamwork is a skill, and the ability to suss out what a stakeholder actually wants, but isn&#x27;t saying due to incomplete information and&#x2F;or office politics, is a reasonable thing to select for. The ambiguity of the prompt is a feature, not a bug: it&#x27;s kept the author away from a company whose communication style they&#x27;re not compatible with.<p>(that said, this project does sound excessively complex for a take-home)

From this post, it seems like the hiring manager is either not the real hiring manager (maybe just an HR agent with this lofty title) or was himself hired without any screening or on the job evaluation for reading and responding to emails (which is a big part, IMO, of any manager) or has multiple roles to play and has no time to devote to hiring.<p>I feel sorry for the author to have spent more time on actually doing the assignment after that reply.

Assuming the recruiting manager is non technical, he should have referred to the team in need when he received the &quot;specification&quot; email, something like &quot;what should I do with this candidate?&quot;. A 5min chat with engineers would have clarified the situation and 5min to send an answer to the candidate. Same for the feedback request.<p>Seems like he did none of it, and in this company people do not talk and everyone is left guessing what is work consists in, which resonates strangely with the take home assignment directives. What an horrible workplace it would be.

Very insightful idea here. If you work in software, requirements engineering is a key task. Figuring out “would this deliver for you?” is a key question you hash out with clients.<p>But the absurdity of take home work like this is the company feels obliged to keep their requirements secret. Thus, by doing the task not knowing if it will be up to spec, you compromise on your most important skill!

I did one once for Barclays for a Haskell role in London. A whole evening of work and they never even sent me a rejection email.

Honestly, you lost it with your first email asking for more direction, and every email after that just made it worse.<p>This was part of the assignment:<p>&gt; This project tests your ability not only to code, but to deal with ambiguity and open-endedness, which is essential in R&amp;D projects like Kagi Labs.<p>It was vague on purpose, they wanted to see how your decision making process goes with what you fill in the blanks with, without needing hand holding. You seemed to ignore this critical piece and went further and further against it with each message.

if you are asking candidates to complete a take home you should provide at least a partial rubric of how the project will be evaluated.<p>if you can&#x27;t provide that then i think you haven&#x27;t created one, and if you haven&#x27;t created one i&#x27;m guaranteed to be wasting my time because you&#x27;re just doing vibe interviewing.

As someone who struggles with whiteboard and leet-code style interviews, I&#x27;m not against take-home assignments.<p>Just two things:<p>- If the candidate already has a portfolio, whether personal projects on GitHub, open source contributions, or projects they&#x27;re willing to share directly, why do you need to make them implement some specific project? The whole point of a take-home assignment is the discussion that follows it where you talk about the code, which trade-offs they made and why, and you try to get a general feel for their understanding and enthusiasm for the domain. Whether they implemented something specific is irrelevant.<p>I get that this is often done to make lives easier for the interviewer, and to be able to relatively compare implementations between candidates, but every candidate is different, and since you want to judge their thinking the project should be relatively open-ended as well. So just spend some time to review their portfolio instead of asking them to implement the same cookie-cutter project.<p>- All take-home assignments should be paid. Period. Don&#x27;t ask candidates to work for free. Agree on a time estimate, and pay them a fair hourly rate. The initial offer can be some average rate for the specific role, but if the candidate has a higher rate, then negotiate based on that. It&#x27;s disrespectful to expect them to work for free, only to reject them afterwards. This way at least it wouldn&#x27;t be a complete waste of their time.<p>I&#x27;m disappointed that Kagi&#x27;s process doesn&#x27;t take these two points into consideration.<p>That said, my favorite interview style for programmers is the code review. Show them a piece of intentionally buggy and incomplete code, ask them to mention any issues they find, and to fix them. This could be open ended and include performance issues, testing, etc. Then you work on it together, the interviewer almost taking a co-driver seat in a pair programming session, and the discussion is almost always relaxed and informative. I&#x27;ve been on both sides of this type of interview and it&#x27;s always been a positive experience, and most candidates enjoy it as well. It&#x27;s much better than a stressful &quot;here&#x27;s a blank whiteboard, implement this from scratch&quot;, a leet-code style puzzle, and much less of a time-investment than a take-home assignment.

The requirements for even senior software engineers now are absurd (to say nothing of entry&#x2F;mid level, which I think may not even exist anymore at most shops).<p>Companies are abusing their position and we should remember the most egregious of them and avoid them in the future.

Take home assignments I feel have the second worst signal for any hiring workflow (behind automated leetcode), you give someone free reign to spend too much time working on something useless without seeing how they actually think or approach problems, you only get a solution at the end, and the solution, especially in open ended problems like these has very loose objective measures. If you want a long term hiring process, I&#x27;d just stick to a contract project, though personally just do monitored interviews; I know it takes up more of the hiring managers time, but the amount of signal you get from actually talking and interfacing with a dev is pretty useful

Same thing happened to me at Zipline, they give you a basic problem to solve in a take home assignment and then ask you to do something you’re “proud of” or to really show off your skills for the rest of it.<p>Never heard back after submitting, spent probably 10 hours on it

Is it just me or he missed the point completely?<p>Look at all the third party services he uses! Nobody sane would pick that solution. That would be a completely maintainment nightmare.<p>He did not write an email client, he wrote a wrapper to some email client, which handles all the heavy lifting.<p>At the very least, write something that interact with a real (or fake) SMTP server. Other things are just cherry on top.

This is the same thing that happened to me with an Expensify interview back in 2011. After that, I decided to only do interviews in person, or where the person was on a call with me. Take home tests are not worth the risk of this crap.

Wow you got a lot of responses! I was given a take-home assignment from Kagi to build a RSS scraper where Vlad responded to only one of my four questions. I asked how long I should spend on it, and he responded with a single sentence saying as long as I thought necessary. After four days of work to get an MVP complete, I submitted the project. I received a single sentence rejection a week later.<p>Love the service. Very disappointed in the process. Four days for a take-home with absolutely minimal feedback is really bad. I decided to jump through the hoops because it seemed like a really cool company to work for.

No offense but even the readme is way too long and complicated. And the project itself seems like too much.<p>I often see people applying make this same mistake with their CV. They&#x27;ll have a 5 page long incredibly overfilled CV with whatever they ever worked on. Instead, just make it one single clear and concise page so that the recruiter can quickly assess your selling point relevant to the position. They don&#x27;t have time for all this so why would you?

A bit OT, but I&#x27;m wondering how any fresh grad is supposed to pass today&#x27;s hiring bar.<p>And, with the market flooded with experienced devs, why should any employer take a chance on a 100% green dev, when they can pick and choose from among 5+ YoE SWEs, who are desperate for jobs? As Shawn&#x27;s post from yesterday showed, many of us are willing to work at much lower salaries, so even financially, it does not make sense to hire a fresher.<p>Anyone care to engage with this topic?

It&#x27;s totally unreasonable to ask somebody to do so much free work, and the outputs are hard to judge, and likely not the candidate&#x27;s own work anyhow, so almost entirely pointless.<p>Remember kids &quot;just say no&quot;

You asked way too many questions.<p>The instructions seemed clear. They deliberately set an open ended task, and they want to see how well you independently add valuable features (to a well known format).<p>I agree that this is an obscene amount of unpaid work but if you&#x27;re going to do it, you can&#x27;t ask your hiring contact how to do it. It demonstrates a lack of independence, and that&#x27;s something they told you they wanted for this role.

&gt; We receive a lot of interest and applications for each position at Kagi which makes selection processes is extremely competitive.<p>This is the real take away. Don&#x27;t put in outsized effort at companies that are highly subscribed. Everyone prides themselves on being &quot;extremely competitive&quot; and unless it&#x27;s a FAANG (or well known quiet money fountain like Valve), it&#x27;s probably not actually worth the effort.<p>If it&#x27;s hot on HN, it&#x27;s highly subscribed -- you just can&#x27;t expect effort to be valued the same way when there are 10 applicants.<p>&gt; We normally don’t provide feedback at this stage. We have had other submissions that were simpler and stronger, so we decided to continue forward with these candidates.<p>This would have been a great place to push and ask for a little more feedback (while being nice as possible since they have nearly no incentive to share more)... How could the other solutions have been simpler <i>and</i> &quot;stronger&quot; (whatever that means? more robust?) -- a few details on what you missed that they were looking for (tests? documentation? CI?) could at least add some value.<p>All that said -- finding a job is really hard right now. Wish you the best.

Both are wrong. OP should have just done the assignment and not send proposals, deploy it all on server less deployments etc. Kagi should not have implied that the more the better

This (and other terrible interviewing processes) seem like the epitome of a problem being tackled from the wrong end: Trying to filter things coming OUT of the hiring funnel instead of filtering the things going IN to the hiring funnel.<p>Case-in-point: Modern job sites (<i>cough</i> LinkedIn). Every job listing has HUNDREDS of applicants within an hour of the job being posted. It&#x27;s ridiculous. It should not be _that_ easy to apply for a job.<p>The outcome is what we are seeing today: A company posts a job, is inundated with 100s&#x2F;1,000s of applications. In order to filter out the 80% of applicants who aren&#x27;t deeply interested in the role, the company deliberately assigns busywork&#x2F;road blocks to slow down the process.<p>The other 20% of applicants will then spend days&#x2F;weeks&#x2F;months in the hiring process on intro videos, take home challenges, etc. Basically anything that can be throw at the applicant that isn&#x27;t time with a human.<p>The takeaway for each can be broken down into:<p>- 80% of applicants: didn&#x27;t spend anything, didn&#x27;t get anything, don&#x27;t care<p>- 19% of applicants: spent time doing some&#x2F;all of the busywork, _aren&#x27;t_ hired, end up very frustrated at the amount of time&#x2F;energy&#x2F;resources that was spent only to be discarded<p>- The 1%: spent time doing some&#x2F;all of the busywork, _are_ hired, feel great!<p>I&#x27;m not sure what the exact solution is, but I know that:<p>a) it&#x27;s a race to the bottom (with the bottom being full automation on BOTH sides of the hiring process),<p>b) I&#x27;d much rather spend a fair bit of time putting together applications for 5 jobs and be seriously considered than spend very little time on 50 jobs only to be immediately rejected or handed an assignment before I even talk to a real human being<p>c) hiring teams hate the status quo, too.

I think this is a classic case of over delivering.<p>The requirements to spin up and obtain live services (postmark, torso), is a bit much, especially for a take home assignment.<p>Personally, If your app can’t be spun up and tested with a simple &quot;docker compose up —build&quot;, then you are doing something wrong.<p>My rule of thumb for take home assignments: if I spend more than a few hours on it. Then I am probably over delivering and need to rethink approach and remove shit I don’t need. There’s no way in hell I’m spending a full working day, let alone a _week_ of free labor for these assignments.<p>Note: also not a fan of &quot;take home assignments&quot; either. Of the few companies that ask for these, I consequently ask to be compensated for my time. Only 1 company agreed to compensation, but others declined and I moved on.

It’s pretty disrespectful in my opinion. It would be better if they took 90% of their applications and secretly threw them in the garbage than to waste applicants’ time evaluating them on vague criteria.<p>I have been lucky enough to be able to reject take homes. Next time, I might offer to do them for a flat rate of $200&#x2F;hour but working for free is something I will avoid.<p>If it’s going to be used as a screening process, at least give clear guidelines and evaluate it pass&#x2F;fail.

“but to deal with ambiguity and open-endedness, which is essential in R&amp;D projects like Kagi Labs”…. Also based on the nonsense responses by the hiring manager, it sounds like one of 2 things<p>Either someone had a vision and is saying ‘Read my mind’<p>The alternative explanation seems to be, there is no vision, and the interviewee needs to define it.<p>In either scenario, the amount of communication, feedback, specificity, lack of respect for the power dynamics is appalling.

So, as someone who has applied to a lot of jobs and has had a lot of jobs, I&#x27;m going to be a bit more critical here. I think the amount of information they gave is sufficient for a take-home.<p>Make an email client, email view+send, fake backend or real imap, handle plaintext.<p>At this stage, for a take-home, I&#x27;d start working and write down assumptions I made as I went along. I&#x27;m probably the opposite of the author, as a take-home (unless it&#x27;s the last stage or something) is, in my view, a tester to see what a person can do within a few hours of work. I&#x27;ve had several take-home exercises during my time as a software engineer and they varied from &quot;we have provided all details that a stakeholder would provide&quot; to &quot;if you have any further clarifying questions, please get back to us&quot;.<p>The most recent one I took a couple of years ago came with an internal library the company used. They said, &quot;use this library to make a web app that takes advantage of these methods inside of it; create an app that simulates behavios using those methods. Do not spend more than 10 hours on the assignment.&quot;<p>I started coding, I threw something together that worked in about 6-7 hours and I was writing down assumptions as I worked as well as trade-offs from those assumptions. &quot;I assume the user would not be bothered by a failure here, if reliability would be important, what would we want to do in the case of a failure? Retry? Back off retries? etc etc&quot;. I then provided the code and provided a list of improvements &quot;Add unit tests to these 3 components, add integration test to ensure this functionality works end-to-end if its essential, improve UI, clean up code base, refactor these services, use a framework&#x2F;library for the UI instead of hard-coded JS to make these few calls. I wrapped it up because I think I was 70-80% there.&quot;<p>During the next interview with the architect of the company, he said that the solution I provided worked fine, we discussed some things I did and he asked why I did them, but specifically, and this is why I&#x27;m commenting here, he mentioned that he appreciated the assumptions document, the future improvements and the &quot;I stopped here because I&#x27;d rather get feedback on this and refine, as opposed to keep building something I imagine you want&quot;. He said that the ability to work up to a point where you hit the majority of the story and then get feedback on that incomplete project is better than having someone dissapear into a cave for a month to try and come back with the absolute finished product in their oppinion and then having to make changes to get it in line with what was actually wanted.<p>So I guess, become comfortable with uncertainty. If nothing else, ask only &quot;hey, I assume you want something along these lines that I can bang out in 5-6-10-20-40 hours. If you&#x27;re not happy with what you get for 5 hours, it might not be a good fit in general or if you think I prioritized the wrong thing in those 5 hours, then we can chat about that too&quot;. I am also saying this, because my current role is a lot more in line with what the author is looking for - they spend weeks refining requirements, they write documentation, they create mocks and they have meetings over meetings before I even know what I&#x27;m supposed to do and within a day or two they start realizing that what they described is about 10-20% off what they wanted or what is possible and the whole cycle of meetings starts again. Instead, and I&#x27;ve been pushing for this each sprint, I&#x27;m asking them to accept a certain level of unknown in a given story, we work on it, we see it behave and get used and refine it based off of that.<p>The author seems to want waterfall, but agile exists for a reason. Hell, let&#x27;s not even call it agile or whatever else, in a real situation, you start doing and you learn as you move along. You refine based on feedback, you refine based on new experiences and based on new requirements. You work in the murky areas of someone elses mind. Or not, I don&#x27;t know, but expecting a series of jira tickets with screenshots and deliverables from a company that just wants to see how you think, how you work with uncertainty and how you deal with unknowns feels... wrong.

This basically screens for desperation.

did the take home assignment precede a chat with the team?

I love Kagi as a product. I do not love Kagi as a company (based on reports of founder, posted here: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40011314">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40011314</a>)

&gt; kind&#x27; meaning something like &#x27;UX improvement&#x27;, or &#x27;pretty UI&#x27;,<p>They literally said they want a simple TUI email app<p>&gt; If he wanted a simpler solution, he could have told me on March 18, when I submit my proposal.<p>When he said your emails could be stored in a fake database or loaded in memory it was obvious they didn’t want something over complicated.<p>No one likes over engineering, it can come off as egotistical, indulgent and more importantly a sign of technical debt lurking ahead.<p>Your proposal is long winded, you’re not the only applicant these people are looking at my guy.<p>I’m not sure what Fargate is (nor care) or even why you suggested AWS and all that other jazz but you clearly went overboard. No one wants a developer where you ask them for A and they return A B and a half finished C.<p>Yes, you’re allowed to ask questions but the ones you asked showed signs of overthinking and lack of initiative.

I tell everyone up front (recruiters and companies) I absolutely don&#x27;t do homework assignments as part of a job interview. If they&#x27;re unable to judge my skill level from an interview, that speaks volumes about them, not me.<p>Furthermore, if they are even the kind of company that thinks they&#x27;re so special they can or should even ask for that, then it proves they&#x27;re the kind of people I want to avoid like the plague to begin with. So when I&#x27;m asked to do a homework assignment it&#x27;s actually a huge time saver for me, because it tells me right up front to avoid them.<p>All developers should refuse this. But there are always enough that are so desperate they&#x27;ll do pretty much anything.

just use cursor lol

Yikes, I love Kagi but if I&#x27;d applied for this position and they gave me this assignment, I&#x27;d have told them to take a hike. This isn&#x27;t an afternoon project, it&#x27;s a full weekend. Maybe two. And are you supposed to be writing tests and stuff for this?<p>Moreover, this exercise tells you so little about the candidate and their experience. Sure, you know they can code (or did they just use Cursor?) but you have no idea whether they are good and addressing prompts and not at making wise choices. Who cares if the program can send email? What matters is that the client doesn&#x27;t choke after 10k messages are received or that unicode is handled well: that&#x27;s the sort of <i>actual</i> challenges you&#x27;d be doing at a company like Kagi, not making enormous toy projects.<p>Edit: Despite that, it seems like a bold choice for the author to build a web app instead of a TUI like the instructions lay out. One could say &quot;terminal inspired&quot; could include web applications but I think that&#x27;s a stretch.

The (interview) game has changed and it will get worse because of more layoffs this year.<p>To standout, you have to be a bit creative and you must sustain yourself with your own company &#x2F; startup. (4 basic instructions here) [0]<p>Companies do not care about you or your take home solution(s) unless you&#x27;ve built something that threatens their existence with a competing product that makes money and steals their users.<p>Stop playing by their rules with these interview &#x27;games&#x27; unless you have lots of time. Spend your time elsewhere. You now have AI, and you should build a startup instead.<p>[0] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43212438">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43212438</a>

I will not be applying to Kagi!

Asking candidates to put in disproportionate amounts of time and effort is abusive. The hiring manager here seems to have taken all of 5 minutes to reject the candidate&#x27;s multiple hours of work.<p>edit: commenters here are also missing the forest for the trees. If the candidate had done X, Y, Z to make a more compelling entry then it would be some other poor guy staring at a two line rejection of tens of hours of work. The process is exploitative.