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

[CharlieDigital]

The difference is that in an interview context, there's almost always a defined endpoint; a narrow path that defines success. A 30-60 minute interview isn't the same thing as a 6 month project where you get a chance to meet with multiple stakeholders, digest the inputs, ask followups and so on.

This is why we see the rise of the "never ending interviews[0]". If you want an effective interview -- as an interviewer -- then understand what output you are measuring (like any good experiment) and then see if your subject can arrive at that outcome when given the context and 30-60 minutes.

Don't waste your own time disqualifying perfectly good candidates by playing games with ambiguity when you already know what you are looking for.

[0] https://www.bbc.com/worklife/article/20210727-the-rise-of-ne...

[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?

[CharlieDigital]

An interview with a customer for requirements had a very clear context.

An interview for a technical position could focus on either high level design, specific technical aspects, or process and so approach to problem solving. Maybe a bit of each. An interviewer that more clearly defines the context can get better responses.