Hacker News Reader

Comment by birdymcbird | Hacker News Reader

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

View on HN

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.

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

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

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

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.

Reply on news.ycombinator.com