[exeldapp]

Yes, software is full of ambiguities but there are methods we use to handle them. OP emailed an outline wanting feedback, as any team player would do to iron out ambiguities, and received a meaningless reply. I think it's safe to say companies don't want their engineers going into a corner never to be seen again for 2 weeks, which is what this interview process recreates.

[theamk]

OP's proposal was only describing irrelevant stuff (the backend technologies) and was completely silent on on stuff that mattered (demonstrating how actual RFC822 email works, mutt-inspired UI). It was therefore accepted without comments, as there were no "substance" to comment on.

That is often a problem with proposals/design docs in general. In the real job, if proposal is actually required, it would be sent it back with "please add details on UX and how you are going to store email headers". In this case, the proposal was explicitly _not_ required though, so interviewers did not want to ask for more details on the optional document. They checked what was written there, found no problems, and approved it.

[Yizahi]

That position is called Email BACKEND Specialist. "We’re looking for a Backend Engineer to help build and maintain our brand new email service. "(c) https://kagi.peopleforce.io/careers/v/108008-email-backend-e...

No wonder he focused on backend part.

[theamk]

I think what has happened is the author has no idea what "email backend" was, so he just decided to ignore that part and build the only backend he knew, web-app backend. And those terms are pretty different. The "email backend" is the service which actually stores and transfers email, in the author's case it was turso + postman.

So from the interviewer's standpoint, author was asking about few details of implementation, like "can I use third-party service for email storage?"; and the response was of course "yes, you can" (because assignment was pretty clear that backend does not need to be advanced or even present, and that it's UI that matters)

I guess the question worked as intended, and filtered out candidate who cannot even read the simple requirements.

(The amount of effort was disproportional though, but I am not sure how to solve this in take-home context without discriminating against people who have busy schedules and/or work slowly)

[Yizahi]

Yeah, that's likely what happened.

[edfletcher_t137]

OP didn't take into account the (great) asymmetry between themselves and the hiring manager, then built an entire lament on that. Dealing with this job req is likely just one of many day-to-day responsibilities the HM has and frankly I'm impressed they responded with three whole sentences. One method we can use to handle such ambiguity is to "make your best judgement" based on your skills, knowledge and experience (things that are tested for in the hiring process, incidentally), because often you may not get the answer you want or expect if any at all.