The 2nd line of assignment, "The project is to build a minimal, terminal-inspired email client".
I agree that "inspiration" can be subjective, but in this particular case the solution was so much off that it'd be hard to argue otherwise. There is nothing terminal-like in it, and the tool is not usable as an email client either. Instead of doing login screens and user management, author should have made a page to view individual email or added folder (just 3, inbox/sent/trash, would already be a great improvement)
And if you want to ignore the requirements and work off position description... the position is titled "Email Backend Engineer", and the candidate's solution offloads actual email operations (storage, transfer) to third-party services. I suspect that even if candidate provided the same UX, but would have backed it with SMTP, IMAP, TCP/IP (not via http library), DNS MX lookup, resilient storage etc... then they might have passed.
But author failed to do either serious front-end work (required by question) or serious back-end work (required by job posting), so result was entirely predictable.
For every comment in this thread that says the author did too much, there is another saying the author clearly did not do enough.
Plenty of comments here have strong, but conflicting, opinions about which set of features are obviously in or out of scope. That alone indicates to me that this is a badly worded take home test.
Even ignoring that, the author told Kagi exactly what they were going to do in advance.
Applicant: I'm going to spend a week building X
Kagi: Sounds great!
Applicant: After a week, I have built X
Kagi: Not at all what we are looking for. Rejected.
I don't see any way to interpret this interaction positively.
I don't see much disagreement in the comments here? However there seems to be some people who only read the blogpost and did not actually follow the link to the original assignment [0].. you can tell their response by the lack of mention of "terminal inspired" features. Sadly this happens during discussions sometimes, especially when original author did not mention all the relevant facts in the post.
anyway, the exchange went like this:
Kagi: "please build terminal-inspired email client, you can choose which email flows you'd like to implement."
Applicant: I am going to spend a week building it, using golang, AWS, TMPL etc... I am also going to fit it onto 2 html pages.
Kagi: Sounds great!
Applicant: After a week, I have built something using golang, AWS, TMPL etc.. It has nothing to do with terminal, and does implement any of the email flows completely.
Kagi: Not at all what we are looking for. Rejected.
I don't see any way to blame Kagi for that exchange. Who would have thought the candidate decided to ignore half of the requirements?
I agree that "inspiration" can be subjective, but in this particular case the solution was so much off that it'd be hard to argue otherwise. There is nothing terminal-like in it, and the tool is not usable as an email client either. Instead of doing login screens and user management, author should have made a page to view individual email or added folder (just 3, inbox/sent/trash, would already be a great improvement)
And if you want to ignore the requirements and work off position description... the position is titled "Email Backend Engineer", and the candidate's solution offloads actual email operations (storage, transfer) to third-party services. I suspect that even if candidate provided the same UX, but would have backed it with SMTP, IMAP, TCP/IP (not via http library), DNS MX lookup, resilient storage etc... then they might have passed.
But author failed to do either serious front-end work (required by question) or serious back-end work (required by job posting), so result was entirely predictable.