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 se

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.