And yet the over engineered solution that somehow took a week to complete fell completely flat. I'd guarantee that Kagi has hired developers through this process who only spent a couple hours on it. If I was working on this, I wouldn't have gone beyond three hours. It would have actually been a console app and I would have done something like integrate your unread mail count in your terminal prompt as some "bonus" demonstrating additional thought in the space.
I've worked with IMAP and POP libraries before so am familiar with the fundamentals for building a client and libraries in many languages make this part of the integration very straightforward. Couple that with a "modern" CLI library this should come together very quickly. And I would not have included half a dozen cloud services for a terminal like email client. The project submitted completely missed the mark and they still have no idea why.
If I wanted to create something by meticulously planning out every detail and spoon feeding them to a code monkey with no creative input I'd just use an LLM or outsource to India where you've got to spell out every little detail and still get questionable results back. I've had to do that plenty of times and I don't want to work like that. I want to work with other professionals who can run with a concept and deliver good results without constant oversight and micromanagement. That's clearly not the author of the blog post.
I think you might be missing the point of the blog post. The author is frustrated that he followed standard engineering practices (by submitting a proposal for approval). This proposal was perceived to be as accepted and then when they delivered.
The issue isn't his solution is incorrect. The issue is the company's said his solution was correct and then they rejected him anyways.
This is the equivalent of the interviewer telling you the brute force solution on a leetcode is good enough, but then rejecting you after the interview.
no, the company did not say that his solution was correct, that's just what the author thought.
The company said that _the parts he wrote in the doc_ would not negatively affect his scoring. But his doc did not contain many parts that the company cared about - read it yourself, and try to answer the questions like: Will there be a per-email indicator? Is there a "sent mail" folder? How will user be notified of incoming email?
I've worked with IMAP and POP libraries before so am familiar with the fundamentals for building a client and libraries in many languages make this part of the integration very straightforward. Couple that with a "modern" CLI library this should come together very quickly. And I would not have included half a dozen cloud services for a terminal like email client. The project submitted completely missed the mark and they still have no idea why.
If I wanted to create something by meticulously planning out every detail and spoon feeding them to a code monkey with no creative input I'd just use an LLM or outsource to India where you've got to spell out every little detail and still get questionable results back. I've had to do that plenty of times and I don't want to work like that. I want to work with other professionals who can run with a concept and deliver good results without constant oversight and micromanagement. That's clearly not the author of the blog post.