I wrote a popular article about the Amazon Leadership Principles. It walked people through how to think about the principles, and the related questions they would be asked in the interview process. This article has helped dozens of people get jobs at Amazon.
That article had originated from my notes to friends and family to help them with pending interviews at Amazon. I also had notes on pending technical interviews, but I hadn’t gotten around to writing that up in article format until now.
While this article is written from the point of view of passing the Amazon technical interview, most major technology companies have similar interview processes. The discussion below should benefit anyone interviewing anywhere for a technical position.
As an upfront warning, I don’t plan to list specific questions asked in these interview processes, because they are all over the internet. You can use LeetCode for interview practice, and find plenty of sample questions on websites such as Glassdoor for any type of job. This article is about the approach to the technical interview, not the specific questions themselves.
Interview Loop Structure
Companies want to avoid hiring someone without the necessary leadership or skills to be successful. When organizing an interview loop, the interviewers are generally split between asking questions to evaluate the candidates leadership and their skills. Leadership evaluation at Amazon is oriented around the leadership principles. The technical skills evaluated will depend on the job position.
When I refer to specific technical skills, these are the functional abilities you’ve built up over the years through a combination of work experience and education. For a software engineer this would be things like coding, algorithms, or information architecture. Product managers, machine learning scientists, and marketing managers would all have their own questions to get at the core skills of the job.
Leadership related questions are usually related to your previous experience. Something like ‘Tell me about a time you had a conflict with a peer, and how you resolved it.’
Skills are usually evaluated differently, by directly asking questions about how to solve a question. Rather than reflecting on how you have used your skills in the past, they probe for specific knowledge you need to be successful in this job. Questions such as ‘Draw a diagram of how you would build a video streaming service from scratch.’
Why assess technical skills in this way?
There are constraints and limitations on the interview process.
The best way to interview would be to hire someone who claimed to have the skills you need, and then observe them over the next few months. This is occasionally done for internships, and some startups have experimented with try-out employment. In general though, this is expensive for the team to ramp up the new hire, and is a drain on resources.
We could ask candidates how they have solved real life complex problems in the problems. However, we can’t gauge the actual technical complexity of the problem, we would need to spend too much time understanding the context of the solution, and we have no way of telling if the candidate could solve similar problems in the future.
You could try to assess someone with real life problems. Perhaps something your team is actually struggling with. However, almost all real life have a massive amount of context associated with them. Getting the candidate ramped up on the situation and the tools involved would be a significant time investment for the team and the candidate. Additionally, this problem would not be easily repeatable, and it would be hard to compare the performances of other candidates.
The Technical Interview
Winston Churchill once said ”…it has been said that democracy is the worst form of Government except for all those other forms that have been tried from time to time…”
For those of us who have interviewed hundreds or thousands of candidates, the technical interview is the worst form of interview, except for all those other forms which have been tried from time to time.