I failed a take-home assignment from Kagi Search

2025, May 13

---

• A “take-home assignment” in the world of Software Developer interviews, is a challenge sent to candidates for them to implement a code solution that solves the challenge.
• In this blog post I describe my experience doing a “take-home assignment” for a company that I deemed reputable, and I hope to shine some light on the absurdity of this practice. I will show you what kind of requirements are asked of candidates, for free, without any remorse towards wasting their time.

I sent my CV for a role at Kagi Search, the description of the role can be found here:

The summary in that link would be:

Requirements

- Proven experience in building backend systems
- Proficiency in Go
- Strong understanding of scaling and maintaining backend systems
- Ability to collaborate effectively with SREs and other team members.
- Solid understanding of containerization technologies like Docker

So I got an email, saying that I was selected for a take-home assignment. Something like this:

Thank you for your interest in working at Kagi. We were impressed by your application and would like to move forward with the next stage of our selection process.

As part of our evaluation, we’d like you to complete the Kagi Developer Assessment that will showcase your skills and approach to problem-solving. 

It can be found in the following URL:  https://hackmd.io/@antonios/SkeEpQeh1l
Once you complete it, please reach out and we’ll review it and, if successful, invite you for a follow-up interview where we’ll discuss your approach and solution in detail.

The URL for the take-home is archived here: https://archive.md/A95Ju. I copy-pasted the requirements into the next paragraph so you don’t have to open the link.

The take-home

The project is to build a minimal, terminal-inspired email client, with the following requirements:

• Email client can either be in the terminal (i.e. a TUI) or a web app
• Should have basic email viewing + sending functionality
• Can use a fake backend (DB, in-memory, etc) or real IMAP/POP/JMAP/etc backend
• Does not have to handle rich text messages, just plaintext

This project tests your ability not only to code, but to deal with ambiguity and open-endedness, which is essential in R&D projects like Kagi Labs.

• Do the project in a way that shows off your skills as a developer
• Deliverable is the completed project, in a GitHub repo and deployed anywhere so we can easily test it.
• Create a README file with setup instructions

And don’t hesitate to tell us if you have any questions!

These instructions are extremely broad, and the size of the project is quite large too.

Usually I turn down these kind of unpaid homework, but I had heard about Kagi Search as a reputable company, so I got rid of my inhibitions and bit the bullet.

Because the instructions are so broad, I proceeded to deliver some questions over email to the Hiring Manager. I got answers such as:

We always have a lot of candidates, some they do the basic, some provide a lot of extra features, great documentation and decision making explanations, deployment for demoing, and future thoughts on what would be next. From hiring point of view, we prefer stronger assessments.

to which I asked:

Q: What kind of extra feature do you value highly? ‘kind‘ meaning something like ‘UX improvement‘, or ‘pretty UI‘, or ‘privacy related‘, or ‘something that showcases a lot of complexity‘.

to which he replied:

That is part of the assessment itself, see what kind of extra features you can come up if any.

…. that’s very little information to work with, so I came up with a strategy. I would write an implementation plan detailing the entire deliverable before actually writing the code, if my proposal is accepted that means it should be good enough to get a phone interview, maybe even an offer, right? Nope. Despite my efforts to agree on all these terms on email before investing an entire week of full-time effort, it seems none of my efforts meant anything to the Hiring Manager.

A summary of my proposal is as follows:

A webapp with golang accessible online, deployed through AWS using ECS Fargate, with SSL (https), integrated with an email sender provider, with authentication through a login screen, with the ability to send emails through a form, and displaying incoming emails in the user interface.

Below I include the email that I sent to the manager with the detailed proposal, this is a long one, so scroll down to the next header if you prefer:

---

Hi Antonio De Dios,

It is me again 🙂

I hope it is ok that I keep sending you emails, it’s just that I am taking the assessment very seriously.

I have done a little research and I want to offer a proposal of features for the deliverable. I also want to ask for a bit more time, as this is the first day in which I found time for the project, and this weekend I will not be available to work on it.

So here is my proposal:

Delivery date: Sunday EOD March 30,

This is two business days later than the two-week mark since you sent me your first email.

Deliverable:

Email client, deployed to “the cloud” (AWS), sends and receives emails through an email provider such as Postmark, written in Golang with a web UI, leveraging APIs and libraries to work efficiently.

Reasoning:

• Even though this is a backend role, adding a web frontend displays a breadth of knowledge about web technology that remains relevant for backend development. The solution will also include a database, a classic piece of backend roles.
• Deploying to AWS with Infra-as-Code tooling, not part of the assessment requirements, but most definitely relevant to the job description due to: IaC tooling, Docker tooling, networking concepts, resiliency. Additionally, this makes it much easier to look at the final result, as opposed to locally building some code. And the infra implementation makes for good interview conversation.
• Using an email service such as Postmark simplifies the stack without sacrificing functionality. This kind of implementation remains relevant for many real-world applications for various reasons, such as protecting senders from bounced emails. It is also relevant in the sense that integrating APIs is the bread-and-butter of backend development.
• While writing the solution in Golang makes it relevant to the job, I will also pick a combination of Golang libraries and frameworks to deliver the result in an efficient manner.

Specs:

These are the implementation details that I have settled on using for this given solution:

• For the Golang backend I will be using the following libraries:

  • Pocketbase, a backend framework that leverages SQLite as the database.
  • TEMPL, an HTML templating library for golang. This keeps the work on the backend, which helps with speed and avoids going into too much frontend, which would be more relevant for a frontend role (avoids SPA/JavaScript).

• For the Infra-as-code I will use Pulumi. For Pulumi I will use the TypeScript SDK because it offers the most brevity in configuration.

• For the Email Service Provider, I will use Postmark, this allows me to manage email easily with the usage of Postmark’s API and my own database. This circumvents the usage of IMAP/POP, whilst useful standard protocols, a lot of complexity is involved in integrating them properly.

• The UI will be kept simple, showing pagination for sent and received emails. In addition to the requirements of the assessment, there will be a login screen and two accounts will be provided for the demo.

Stretch goals:
These are goals which I would like to meet, but I cannot promise due to the time constraint:

• Backups and resiliency:
  • In the scenario of the service going offline for whatever reason, it would be great if the service is restarted without losing data.

CONCLUSION

This is my proposal for the assessment. Coming up with the proposal has taken me some time and I would like to know what kind of response I could expect from Kagi if I drive it to completion. Looking forward to your answer!

Kind regards,

Jose

---

That is where my email ends.

The answer was so low effort, that it should have given me a clue as to the lack of seriousness from the manager, but I tried to view it in a positive light. I realize now, I am naive. So this was the reply I got:

Hi Jose, 
This is all very exciting. Looking forward to receiving your submission.
Thanks for keeping me updated.

You will notice that my question went completely ignored. I asked:

• “I would like to know what kind of response I could expect from Kagi if I drive it to completion.”

All I got was:

• “This is all very exciting”

Still, this is somewhat of a positive answer, correct? Well, I would have much rather preferred if my proposal had been rejected right there, and my time had been respected.

After all, this is plenty of information to determine whether the solution will be good enough to move me forward into a role.

I delivered on all promises. It took me an entire week of full-time effort. This is an extreme commitment from my side, but I assumed that nailing the take-home would put me very close to a good job.

If you want to look at a demo of the web application, use this youtube link:

If you want to look at the code for the solution, with very extensive documentation, use this GitHub link:

After getting an automated rejection email, I asked for feedback, to which I got this email:

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. 
We receive a lot of interest and applications for each position at Kagi which makes selection processes is extremely competitive.
We value you as a user and as job candidate and would like to invite you to keep an eye on future positions and continue applying.

Really?

1. If he wanted a simpler solution, he could have told me on March 18, when I submit my proposal.
2. If my solution was weak for the role, he could have told me on March 18, also when I submit my proposal. There is no way the judgement changed between the proposal submission and March 31, when I submitted the deliverable deployed for demoing.
3. It is May 13 right now, a month and a half after I got rejected and the job advertisement is still up. I understand that companies are using the same advertisement to fill multiple roles, but clearly this isn’t some kind of competition where the winner seats are taken, they are still advertising the seats and it is anyone’s guess how many people have gone through the same trick for an imaginary prize.
4. The original project instructions mentioned that deploying the project for demoing would be nice, but not a required step. After I made my submission, the instructions changed to make it a strict requirement for the project to be deployed. So it is funny that my project is so weak, yet it made them update the guidelines to something stricter. Go figure.

This is sad for all applicants as a whole, many whom are unemployed and are on a timer towards bankruptcy. Imagine if you were unemployed, your savings are only going to last you so long, and companies demand that you spend the little time you have left on unpaid work. But what choice do we have once we are in a desperate position? Perhaps next time I am asked for one of these unpaid assignments I will link them to this blog, although you have to understand that if someone is going hungry or facing eviction, they don’t have much choice in the matter.

I definitely believe that we can. I also dislike leetcode-style interviews, the programming puzzles that require the candidate to solve a problem during a video-call. This week I failed a “coin change” problem, well I passed about half of the tests in less than 50 minutes, but I did not have enough time to implement the backtracking part of the solution with Clojure, a programming language that I learned as a hobby and also spent an entire week practicing for this Clojure-based role.

Are there no other options? Of course there are. 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. As opposed to the leetcode-style interviews which select for people that memorized some canned leetcode problem well enough to be really efficient at writing the exact code to solve it.

I am not completely against live coding, it is a tool to determine basic coding literacy, but does it make someone a better programmer if they can solve knapsack in 50 minutes instead of 2 hours? Heck, I don’t think it matters if someone takes longer solving it. Solving these code puzzles under a timer is far removed from the day-to-day responsibilities of an engineer working on an old or new software product.

Lets do better, and please, unless you are in a desperate position, start rejecting roles that ask for this kind of unpaid work. Make it so that they lose all the top talent.

Thanks.

---

---

Go back to the top

---