Hacker News Reader

> 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 must follow up with a chat about the code.

That’s actually a very valid point. Take-home assignments not only require a significant amount of effort from the person administering them but also from the interviewer (or rather, the hiring team). After investing the time and effort in reviewing a project, it’s reasonable to expect feedback/a response back if requested.

However, we must also acknowledge certain realities. If there are 20 solid candidates for a single open position, many capable individuals will be rejected. This doesn’t imply that they were inadequate or even “failed.” It’s simply a reality of life.

Now to be asked to justify why a hiring manager picked A and not B, legally speaking, cannot be that I had to pick one out of the amazing candidates, so I picked one. The legally correct response (unfortunately) is to get nit picky and find faults where none really exists. At least, that has been my observation in how corporate America likes to operate. And last time I checked, Kagi is based out of Palo Alto.

> if there are 20 excellent responses for a single open position, many capable individuals will be rejected.

I would never ask 20 people to do a take-home assignment. There are so many better ways to test team fit before asking someone to commit serious, unpaid, time to a project. Historically speaking a 30 minute chat with someone provides a surprisingly good amount of information to anyone experienced in hiring.

But if you want to commit 20 people to take-home assignments, then block off 20 hours next week for 1-on-1s to chat with them about those assignments. If that sounds like too much, then don't find a better way to filter down the number of people doing homework until it feels manageable.

to justify why a hiring manager picked A and not B, legally speaking, cannot be that I had to pick one out of the amazing candidates, so I picked one.

Why not? Does this phrasing implies any form of illegal discrimination?

> If there are 20 solid candidates for a single open position, many capable individuals will be rejected.

And yet, the role is still advertised 1.5 months after my rejection, which means they are still getting emails from new candidates applying for the role. Do you suppose they get so many competent candidates that they can't make a decision on whom to hire?

At this point we can only speculate about their intentions, because the intentions are definitely not transparent.

I agree. The company should have either published clear guidelines on how the project would be assessed or provided some feedback on what could have been done better. It's okay to fail an assignment, but it's not acceptable to waste someone's time without offering anything in return. There are many companies, including pop startups, that handle this well.

did they really deliver "exceptional solution" though?

Their solution seems to be nothing like "a minimal, terminal-inspired email client", and OP completely ignored the references to tools they were told to "take inspiration from"

When there is such bad misunderstanding of the requirements, I'd not waste time on the discussion either.

There was able opportunity for the hiring manager to point that out if that were the case. They specify questions where encouraged and then completely ignored the questions. If the HM doesn't have time to respond, then maybe take-home as first filter is not a good decision.

Were there? The question clearly said, "build a minimal, terminal-inspired email client" and "take inspiration from existing terminal email tools like aerc, mutt". Candidate completely ignored that part and built a tool which is nothing like terminal email at all.

Would any of their emails give a hiring manager idea that the candidate failed to understand the assignment in such a gross way?

Email 1, "What kind of extra feature do you value highly"

Interviewer thinks: "UX improvement could be VI-like megacommands, "pretty UI" must mean creative use of colors and font attributes, privacy-related must be encryption at rest... It's all good, we are happy to look at all of those!"

Email 2, "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."

Interviewer thinks: "OK, that's a lot of implementation details.. Not sure why candidate feels the need to confirm that, but nothing in the list above will be graded as a negative. The important things we care about are that it's inspired by terminal apps like mutt, and that "it should feel fast and intuitive" and one can totally do that using technologies above"

Without seeing the screenshots/mockups, how would one even guess that the candidate was so off?

> Interviewer thinks: "OK, that's a lot of implementation details.. Not sure why candidate feels the need to confirm that"

Really? My email states explicitly why I want to confirm that:

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

Are you forgetting that the entire transaction implies a lot of work for the candidate?

Are you forgetting that candidate is doing this to land a job?

Do you think the candidate is writing a design document just for fun?

Your subtext implies that I should have guessed the grading, which is quite mind-blowing.

Remember, the instructions mention a web app as an option, the role is for a web-based company, and if my design document did not meet any of the key aspects they could have brought it up and rejected my proposal.

If you read the assignment, you can see that the majority of tasks is about UI and user-facing features ("Should have basic email viewing + sending functionality", "Does not have to handle rich text messages, just plaintext", "take inspiration from existing terminal email tools like aerc, mutt, or even something like himalaya.", "It should feel fast and intuitive")

The assignment had exactly 1 line about actual back-endy stuff: "Can use a fake backend (DB, in-memory, etc) or real ..."

Now, what did your email asked for? There was a whole bunch of things about back-endy stuff, and exactly 1 (one) sentence about the user-visible things, the thing they cared about the most:

"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"

So maybe you intended this to be a complete design document, but it actually was not. This is because it did not actually did contain any parts the interviewer cared about. And that's one of the reasons why you got no feedback - you could do _anything_ for the backend and they would likely still accepted that, they simply did not care if you used Pulumi or terraform or "start.sh" or "docker compose up"

And no, you don't need to guess the grading, you just need to read the assignment carefully. What do they seem to want? What kinds of things do they mention a lot? What kind of things do they mention in passing?

The HM answered, it was just not what the author wanted:

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

It seems like the author wanted to hear something more like "ok, here’s a list of things we want you to implement, and here’s mock-ups for the UI, and here’s the API spec you can follow". How I’m reading the HM’s response is - I should spend a few minutes trying out the email clients they mentioned or watching videos on them, and come up with a list of their features. Apply my own judgement to say which ones are most important and roughly estimate the time it will take to implement a PoC for the assignment. At this point you could take that to the HM and say "hey, I think I can do X, Y, Z features within the timeframe. I’d like to have W, U, V, features in the client but I think they’re less important and I won’t have time. Since this is a backend position I will focus on the API and the client will be a thin wrapper around that. Does that sound good?". They will probably say yes and maybe throw in a "when you do X feature think about users that have 100k unread emails in their inbox", and you’ll get a gold star for "dealing with ambiguity". If I was the HM I would expect some amount of back and forth like this. Since the guidelines are so broad you can focus in on the areas you are most familiar with and keep the rest super simple. As far as we know the author sent the one email on March 18 including a lot of details about what dependencies they were going to use but no product or clarifying questions after that, which the HM might have happily answered. They also both went past the deadline set by the company AND their own self-imposed later deadline from their own proposal.

At the end of the day this is a startup and so it makes sense that what they’re looking for is someone who can work independently. They won’t have a PM to come up with the spec and list of requirements for you every time, and an architect who hands you the perfect software design, and they need you to be able to apply your own judgement and look ahead so that if you are designing their backend and 6 months down the line users ask for drafts support, you don’t come back with "sorry I didn’t account for drafts in my data model because no one told me, we can’t support that without redoing the whole thing".

It sounds like this actually worked fine as a filter for both the author and the company, just that the author realized too late in the process that this was not the work environment they were looking for. A phone screen or whatever else would've just been additional time spent for both the company and the author. I also don't think it's the company's fault that the author put in a "full work week" of hours, as far as we can tell that was never the expectation.