[theamk]

a wrong kind of backend though.. The position is "Email Backend Engineer" and the backend OP built was "web backend"

(OP outsourced the actual "email backend", that is the thing that stores and sends/receives emails, to a third-party products. Probably not the wisest solution if you are trying to get hired to work on email backends :) )

[pas]

I think rejecting a candidate for almost any reason that those making the decision feel as important is okay, but wasting people's time is not.

Just reading the thread is obvious that the requirements were sufficiently vague -- which, again, is not necessarily a problem -- but going about this in a very disrespectful way is not.

(And yes, of course, the hiring manager always can say that "oh I did not want to reject them before they sent the finished assignment, because they could have surprised us with their code!" -- which, while technically true, but I think simply showcases the absolute uncaring laziness that we see from many companies.)

[theamk]

Well, you are a hiring manager, and you get an email filled with irrelevant decisions (i.e. the parts which do not affect scoring much), and the only part relevant to assignment text [0] is:

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

How would you reply to that?

One option is to tell them that the document looks fine, but also add that it does not actually describe the parts they are going to grade on (such as: "which part of aerc/mutt is does author imitate?"). But this is a bad idea, because the likely reaction of candidate is to spend even more time on spec... and the assignment is not about writing specs, the specs are not in the rubric, and you don't want to waste candidate's time on asking for docs you don't care about.

Another option is to tell them: "This spec is so bad, I don't think you can possibly pass. Bye-bye!". This is even worse, as it can potentially reject good candidates who are just bad at writing documents - and there are plenty of them.

So I think responding: "Looking forward to receiving your submission." is the pretty OK answer.

(I suppose the in the non-interview settings, if this was a junior engineer, I'd might also add something like "And don't forget to make the pages you write be terminal-inspired, as the requirements say, see videos of people using [aerc], [mutt] and [himalaya]" - but I can see why this was not said in the interview. After all, testing that the candidate can read and comprehend a tiny requirements doc is a part of the interview)

[0] https://archive.md/A95Ju#selection-529.0-545.9

[pas]

Like I said, it's okay to reject the candidate for submitting something that's implies they are not a good fit.

In my interpretation the "righteous indignation" part is that the candidate tried to make sure that they are not ending up wasting their time and not chasing some pipe-dream (which is bad for both parties after all, leaves a sour taste in the candidate's mouth, and ... apparently does not further the good reputation of Kagi), yet ... that is exactly what ended up happening, because the fucking ~~money lenders in the temple~~ hiring mangers in the corposphere are not just useless individually, but are actively harmful as a cohort.

(Of course, the people deciding to hire hiring managers usually have good reasons to do so. And companies are not expected to babysit every candidate, but since almost always the power dynamics favors them they ought to be the more generous and proactive in the transaction. But at this point in the analysis we are just a few steps from declaring that it's cough late-stage capitalism's cough fault.)

[theamk]

I don't think you are hearing my arguments?

Imagine yourself in the hiring manager's place. Assume all you know nothing about the candidate, and all you have is this email he posted in the blog.. How would you respond to it? Keep in mind you have no idea that the candidate is going to ignore all the requirements, you have not seen the product yet.

[pas]

I do (and I'm very happy that I got one more insightful and detailed reply), but I think many people here dismiss how easy (and thus common) this kind of fuckup is.

And I expect more from professional hiring facilitators.

I would tell them to write more about the UI/UX, do a mockup whatever. Emphasize that the people doing the evaluation looove TUIs so anything web starts with a bit of a handicap, etc.

[theamk]

I think your response will select a different kind of people that Kagi wanted do.

"I would tell them to write more about the UI/UX, do a mockup whatever." is effectively changing the take-home task from "write code", to "write spec, including mockup, get it approved, and then write code". This can be a valid skill, depending on position - but it also means that applicants waste their time on the writing documents that are not part of grading rubric.

And this brings us to a second part: "Emphasize that the people doing the evaluation looove TUIs..." - this is giving a really big hint. It would be a valid response _if the goal was to get this particular candidate_, say because unethical recruiter is getting paid for each candidate placed, and does not care about Kagi's own needs. But does Kagi (or anyone else, really?) want the kind of candidates that could not even parse out the simple doc? Because they were not subtle about loving TUIs in the requirements, mentioning them multiple times and giving examples.

So I am pretty sure that these kinds of strong hints would be against the interview rules, and there is no "fuckup" in this regard.

If I were to write those replies... I don't actually know their policy about how much help can they give to candidate over email.

If reviewing intermediate docs is too much, I'd have to refuse the candidate firmly: "Reviewing documents mid-assignment is against a spirit of this question. Please write the code using the best understanding of the assignment, and I am looking forward to receiving your submission."

If reviewing those docs is OK, I'd say something mildly encouraging - as the document as sent is not wrong, it's just incomplete. "This document contains no glaring defects"? "I can imagine a passing submission that would follow the plan outlined in this document"? "The results will depend on quality of implementation and how well you've followed the assignment, but so far I see no blockers"? "I cannot promise anything until I see the code, but that can potentially lead to passing assignment"?

Some of those would be better than "This is all very exciting. Thanks for keeping me updated" -- but looking at the candidate, would this make a difference? Judging by the tone of the post, and how he decided to proceed because "this is somewhat of a positive answer", even those harsher responses would end up the same way.