[birdymcbird]

until recently i was a principal engineer at amazon. so maybe my opinion has some weight.

system design interview is more about interviewee asking questions..taking time to understand the problem..ask about product feature or SLA..understand functional and non functional requirement.

then its about candidate showing some knowledge set showing they can think and reason behind some immediate coding task. Demonstrate ability to make judgment..simplify where possible..discuss costs and trade offs.

this interview not about candidate building some system at scale themself. building and supporting has trials and lessons you only learn by doing and failing, not through interview prep or YouTube videos

[CharlieDigital]

Candidates can't read minds.

The best technical interviews I've been on as a interviewee have been those where the expectations are clear. In your example:

    "We're not expecting you to create Twitter in 15 minutes, but we want to understand how you think about the challenges and key considerations of building a large system like Twitter"

Many interviewers fail to provide enough context and that leaves the interpretation of the prompt too wide open. At that point, the interview has failed since whether a candidate can provide an answer that is aligned with the expectations of the interviewer has an element of chance to it.

[birdymcbird]

>>>> Many interviewers fail to provide enough context and that leaves the interpretation of the prompt too wide open.

yes but this not a defect as youre viewing it.

in real world at amazon, your job to deal with ambiguity. the hand holding phase where youre given or told exactly what to do is maybe 1-2 year for college level hire. you work with ambiguity or you move out.

if you do not want ambiguity challenge then amazon not best fit for you. its not for everyone and amazon certainly has big problems in its culture. not defending any of it but saying to you what it is.

[mrleinad]

> Many interviewers fail to provide enough context and that leaves the interpretation of the prompt too wide open

So do clients/customers. What's your point? That an interview to assess whether a developer can elicit requirements should be less hard than dealing with an actual customer?