Learnings from conducting ~1,000 interviews at Amazon
Steve Huynh, formerly Principal Engineer at Amazon, shares observations from Bar Raiser, and an excerpt from his new book, Technical Behavioral Interview Tech interviews have two parts: the technical interview â with a focus on things like coding, software architecture, problem solving â and the behavioral part â with a focus on past experience, and the situations that show youâd be a good fit at the company youâre interviewing with, along with things like attitude, motivation, culture fit. Technical interviews are going through a big change, thanks to AI tools: some companies are bringing in new, AI-assisted types of interviews, while others are trying to make âpre-AIâ type interviews work. What doesnât seem to be changing is the second type of interviews: the behavioral ones. Iâve found the topic of behavioral interviews from a software engineerâs perspective somewhat under-discussed â even though this interview carries huge weight in securing an offer and what level you come in at. No matter how strong your technical skills are, especially at mid-sized and larger companies, you are unlikely to get an offer if you are deemed to not be a fit for what the company is looking for. Steve Huynh was an engineer at Amazon for 17 years â I previously did a podcast episode with him on the reality of being a principal engineer at Amazon. During this time, Steve conducted nearly 1,000 interviews, of which around 600 were Bar Raiser ones. Bar Raiser interviews are unique to Amazon: itâs an interview conducted by someone outside of the hiring team, with the goal of ensuring that the new hire raises the companyâs talent bar. After leaving the e-commerce giant, Steve spent 2 years researching and writing the book Technical Behavioral Interview: An Insiderâs Guide. Today, we cover two topics on interviews and behavioral interviews: 1. Learnings from conducting ~1,000 behavioral interviews at Amazon. Steve reflects of major observations from his 17 years at Amazon, covering: Youâre over-prepared for one interview and unprepared for the other How you deliver the story matters as much as the story itself The interview is an audition for what itâs like to work with you 2. What companies are looking for during behavioral interviews. An excerpt from Steveâs new book, Technical Behavioral Interview, covering ~75% of a full chapter of the book (out of the 14 total chapters.) We get into: Understanding fit: role and company The four dimensions that determine your level What each level looks like Reading and calibrating your own level Researching what companies really value Longtime readers might remember Steve from my podcast with him a year back: What is a Principal Engineer at Amazon? With Steve Huynh My usual disclaimer: as with all my recommendations, I was not paid for this article, and none of the links are affiliates. See my ethics statement for more. With this, itâs over to Steve: A Bar Raiser is a specially trained interviewer whose job is to ensure that every hire raises the average talent level at Amazon. I had veto power over any candidate. I sat on nearly a thousand interview loops across every level from intern to Principal Engineer. After 50 or so interviews as a Bar Raiser, the patterns became impossible to miss. And this was the biggest one: The candidates who didnât get offers seldom failed because they lacked technical skill. They failed because of how they presented themselves. For sure, technical preparation is crucial, and Iâm not telling you to skip it. But most candidates have massive blind spots when it comes to non-technical matters, which is a big problem. Why? Because that blind spot is where most hiring decisions are made. The Bar Raiser who trained me put it this way: Technical skills are the ante. They get you into the game. But theyâre not what wins you the hand. I didnât fully appreciate what that meant until Iâd seen candidates who were technically very strong get rejected because of everything else. Think about it. By the time youâre sitting in a final round of interviews, youâve already passed at least one technical screen or take-home assignment. The company already knows you could probably do the job. They already know you want to work with them. But thatâs not what the final round is for. The final round is when the team figures out whether they want to work with you. Being technically proficient is part of it, but itâs not all of it. Can you explain your thinking clearly when youâre stumped? How do you handle it when things go wrong? Can they picture you in a design review or in a tough conversation with a partner team? Fit. Fit is what decides most hiring outcomes, yet itâs the thing most candidates spend the least time preparing for. After nearly a thousand interviews, I can tell you exactly where the gap is and how you can close it. The average candidate preparing for a tech interview probably spends 95% of their time on technical preparation and 5% on everything else. Some spend literally zero on everything else. I get why. Technical preparation feels concrete. You can grind coding problems and measure your progress. You can study system design patterns and feel yourself getting sharper. Thereâs a clear input/output relationship. Do more problems, get better at problems. For most technical interviews, even if you havenât seen the exact problem before, you can still do a decent job. Itâs simply not possible to prepare for every problem, so itâs expected that you can reason through an unfamiliar coding question and pick up on hints the interviewer gives you. You can work through a system design problem by applying fundamentals you already know. Itâs expected that you will encounter new questions during an interview, so it isnât fatal if youâre a competent engineer who can think on your feet. However, the non-technical rounds are the opposite. You cannot wing them and expect to do well. When an interviewer says, âTell me about a time something went wrong on a project and how you handled itâ and you havenât thought about that question before, there is no hint they can give you. Thereâs no reasoning your way through it in real time. You either have a prepared story ready to go, or youâre going to mumble your way through a word salad while the interviewer watches. Iâve seen this play out hundreds of times. A candidate would crush the coding round, then I would ask them about a difficult decision they made, and they would fall apart. They would pick a half-remembered example, start rambling, backtrack to add context they forgot, in the process losing track of the question. Then, five minutes later, they would land on something like, âSo, yeah, it worked out in the end.â These candidates were often strong coders, but that didnât matter. At the debriefs, the feedback was always some version of âI couldnât get a concrete answer about their experience. Every story was vague and unconvincing.â We couldnât extend an offer when a candidate couldnât articulate how they worked. The technical bar was met, but the hiring decision was made in the behavioral round. Hereâs whatâs frustrating about this. Non-technical preparation takes a fraction of the time for technical. If youâre going to spend 80 to 100 hours preparing for an interview cycle, spending a single weekend on your stories might be the highest-leverage investment you make. Ten hours of story prep can completely change the outcome of your behavioral rounds. Meanwhile, your 80th hour of LeetCode will give you almost nothing you didnât already have at 60. The returns on technical prep diminish rapidly. The returns on story prep are exponential because almost nobody does it at all. What to do: How are you currently splitting your interview prep time? If itâs 99% technical and 1% everything else, youâre over-indexed on the part with diminishing returns and under-indexed on the part where hiring decisions get made. You donât need to cut your technical prep dramatically. Just reallocate. If yâŠ
Send this story to anyone â or drop the embed into a blog post, Substack, Notion page. Every play sends rev-share back to The Pragmatic Engineer.