The Best Interview Advice You Never Got (from ex-Amazon Principal Engineer)

0:00 Tech interviews are broken. Every job opening is immediately jumped on by hundreds or thousands of people in the first hour. After months of no luck, you finally get a call back. We're interested in you. When are you free to do interviews? Things just got real. One thing stands in the way of getting that dream job, escaping your current reality, finally working on something interesting, getting paid way more, being in a place that you could actually thrive. You have to clear the interview. You only get one shot. My name is Steve Wyn and I conducted nearly a thousand technical interviews for Amazon where I used to be a principal engineer. I'm a former bar raiser and I trained thousands of people at Amazon on how to conduct interviews and assess talent

0:45 during my nearly 20-year career there. In this video, I'll reveal to you the five simple things that you can do to dramatically increase your chances of clearing tech interviews. Tech interviews are broken, but they're all broken in the same way. None of this stuff is rocket science. You just don't know about it yet. What if I told you that it's possible to get an offer even though you needed big hints to clear the coding and system design questions? Would you believe me? Well, it's true. And what if I told you that it's possible to be rejected, but you knew the optimal answers to the coding questions? Would you believe me then? Well, that's also true. There are three types of questions in a technical interview. Coding questions, system design questions if you're more senior,

1:30 and behavioral questions. For each type of question, there's the surface level question, and then there's the question behind the question. Once you understand what that is, you'll look at interviews in a completely different way. Let's start with the coding questions. The simplest coding question is called FSBuzz. The question isn't about writing a for loop and a couple of if statements. There's no FSB buzz task in the sprint. The question behind the question for FSBuzz is, "Has this person ever coded before? Everybody is scared to death of getting a coding question that they've never seen and barely understand even what the interviewer is asking for. They think that the way to prepare is to drill on every leak code problem there is. But that type of thinking completely misses the point."

2:16 What is the point? The question behind the question for coding is, is this person a good problem solver? Suppose I gave you elite code hard during the interview and you were silent, knocked out the optimal solution in 3 minutes, and then just stared back in the interviewer with dead eyes. All done. The only signal that tells an interviewer is that this person has overprepared and that their soul has left them after years in the tech industry. a higher fidelity signal. And the thing that allows you to pass a question even if you don't know the answer is that you are able to use your head to reason through the problem. If you know the answer to the question, then start reasoning through it. The brute force solution is to sort the

3:01 items in the list and then return the answer. But that approach is big O of and log in to sort by using a hashmap. The answer is linear, but it's still linear memory. The optimal solution is to loop through the input and to keep a running computation. But even if you don't know the answer to something immediately, thinking out loud, explaining what you do know, and being receptive to hints is the critical skill that you want to focus on. So don't just blindly grind through coding problems. Make sure to also have a good handle on the fundamental concepts and identifying coding patterns. This along with hints from the interviewer will allow you to synthesize solutions on the spot and clear the problem without knowing the solution going in. My next tip is related to being receptive to hints. Suppose you were in an on-site loop and you got what I call the anti-in. You

3:48 didn't vibe with any of the interviewers. They asked you questions you didn't prepare for at all. And so after you bombed all of your interviews, you're now on your last interview of the long day. And all of the nervousness washes away. Nothing matters because you don't care anymore. You're asked a coding question you've never prepared for, but for once you get lucky and the interviewer gives you a good hint. The conversation with the interviewer is flowing well because you literally aren't nervous. Something that you studied hits you and you're able to synthesize the optimal answer and so you code it up in no time at all. Why couldn't the other interviews be like this one? Is this a realistic story? Yeah, it is. It happens in other arenas, too. I might lose two balls into the woods while playing a hole of golf, but

4:34 then I'll sink a 50-ft putt. It's because I stop putting all of this pressure on myself to do well, and all of a sudden, I'm in a flow state. And that's my second point. Maximizing your interview performance is about being comfortable, calm, and letting the effort from your practice surface. Your worst performance comes from the opposite. You're uncomfortable, you're stressed, and you focus on outcomes. In that state, you might even bomb a question that you've prepared for. How do you do this? I believe that preparation has a crucial physical component. Physically, it's really important that you get a good night's sleep, to eat well so you don't crash, and that you're well hydrated. Getting proper sleep doesn't mean sleeping poorly until the night before the

5:19 interview, and then getting into bed at 9:00 p.m., and scrolling on your phone until 3:00 a.m. The same goes with eating and drinking. You can't eat poorly for weeks, shoving flaming hot Cheetos and chugging Mountain Dew into your gullet, and then on interview day, drink way too much coffee until you're shaking like you took way too much aderall. Better is to instill healthy habits as part of your interview prep. You're an athlete, but instead of optimizing for muscle performance or hand eye coordination, you're optimizing your brain, which is housed in your body and aided by things like healthy sleep and proper nutrition. Every dollar you make in life is going to come from in here. Before a big game, athletes don't train super hard and come out onto the field exhausted. They take it easy, get

6:05 in a good meal, and do some warm-ups. If you want to be a professional brain athlete, don't neglect your body. Breathing exercises are a great way to regulate your body and calm yourself down. Take a look at box breathing or the 478 technique. You can literally slow your heart rate down just by breathing intentionally. It's just a small thing to add to your practice routine that pays a huge dividend. The other way to get more comfortable is to introduce situations that spike nervousness as part of your preparation. You want to start small and increase stakes over time. By yourself, you can simulate an interview setting by recording yourself with your phone or with the camera and forcing yourself to watch the video afterwards. Doing a mock interview with your friends or colleagues is the way to take it to the

6:51 next level. And the level after that is paid mock interviews. You'll never completely eliminate the nervousness, but if you can get comfortable with the feeling, it won't get in the way of your interview performance. You don't want to process high anxiety for the first time during the interview. My next tip is related to doing mocks and practice. Tell me if this sounds like you or someone you know. You get an outreach from your dream company. They're working on a product that you vibe with. They've got the cache. They have free food for crying out loud. The compensation is mindblowing. You get this job and your life will change. You talk with the recruiter and they ask you when you can interview. You panic and say 2 weeks. The problem is that you're not prepared

7:37 and so you start cramming like crazy. You sign up for all of the interview prep. You start grinding leak code. The big day comes and you do well in some interviews and you do poorly in others. You've been rejected. It's a gut punch. They don't give you any feedback on why you didn't get in, but you have a good sense why. And so, you pick yourself up, brush yourself off, and address your weak spots. You try again with your second choice. You do better this time, but still you get another rejection. They don't give you feedback, but you know why. And so, you go down your list of companies, and eventually, eventually, you do get that job, but it's a company far down on your list. Do you see the problem here? You interviewed at companies in the wrong order. And that's my point. The best practice for interviews is interviews.

8:24 You can try to simulate all you want, but there's no substitute for the real thing. It's a numbers game. If you do five in-person interview loops, reflect on your performance, and address your weaknesses, you're going to get really good at interviewing. To optimize your chances of receiving offers at your dream job, you want to backload interviews there and practice with companies that aren't at the top of your list. But Steve, you might say, "The recruiter reached out to me for my dream job and I haven't heard back from anybody else. I can't schedule other interviews. I have to act now." What I would say is that think about recruiter reachouts as the top of their funnel. It's a numbers game for them, too. I'll run through the rough numbers. For every offer they extend, they've typically interviewed five candidates. Only 50% of

9:11 people make it past the initial screens or online assessments. And of the people that do the initial screens, maybe another 50% goes to recruiter completely. That's why most recruiters are machine gunning reachouts to fill the top of their funnel and try to persuade people to take interviews as soon as possible. If your dream job is a big tech company that's growing quickly, you can keep the relationship warm, get your act together, and do your best to interview at other companies first. Then when you actually peak, that's the moment to start going through your dream jobs, not the other way around. Tech interviews are challenging enough. The last thing you need is disorganization holding you back when you're juggling multiple applications, practice problems, and system design prep. Things

9:58 can get messy fast. The lack of structure can lead to missed opportunities, and mental fatigue when you need to be at your sharpest. Monday.com has been a gamecher for my coaching clients. It's a clean visual workspace where you can see your entire job search at a glance. You track application statuses, schedule mock interviews, and organize all of your prep materials in one place. What's powerful is creating custom dashboards that show you exactly where you stand. You can set up automations to remind you when to follow up with recruiters or specific algorithms before your next big interview. The collaborative features are killer, too. You can share boards with your coding buddies to give feedback on solutions or work together on system design challenges. Remember

10:43 what I said about interviewing at your practice companies first? You can create a priority pipeline in monday.com to schedule your interview strategically so you're at your peak performance for your dream roles. Stop treating your tech careers like a disorganized side project. Use the link below to try monday.com for free and give yourself that structured approach that turns interview preparation into job offers. For my next point, let's go back to the interview questions themselves. How do you do well on the system design interview? For these questions, there's a fundamental mindset shift that if you understand will make these questions so much easier. Let's talk about the concept of system design. First, let's dissect a question that you might receive. An interviewer may say, "Design

11:29 Amazon." But let's just take a step back. Amazon employs tens of thousands of software engineers. Their gigantic systems evolved over a long period of time. They didn't design the system in 45 minutes one-on-one with a rando. The fundamental difference between a coding interview and a system design interview is with code there's a right answer. Even if you didn't get the right answer right away, the hints are meant to guide you to that answer. But with the system design interview, there's no right answer. I was a principal engineer at Amazon and spent nearly 20 years there. Design Amazon or Design Prime Video are meaningless prompts from the lens of actual system design. We don't design systems that way. These systems are way

12:15 too big, way too complicated, and have way too many constraints. So what's the real point? That's where the question behind the question comes into play. The point of the system design interview is to have a meaningful conversation on the topic of system design. The underlying question is, do I believe that this person could make a contribution to our systems design? That's a million miles away from actual system design. The operative word here is conversation. What I'm looking for is does this person clarify what I mean and gather both functional and non-functional requirements. If they don't, then I'll get a signal that they build solutions without thinking about the problems at hand. Does this person define core entities, develop sensible APIs, and

13:01 come up with a workable highle design? Great. That's a wonderful starting point. But again, let's back up to the word conversation again. What makes a good conversation? active listening, critical thinking, and bringing value to that conversation. After you've gotten a highle design, the interviewer is now trained to deep dive. Where are they going to go? That's up to the interviewer. One place they may go is scale. One place they may go is to a tricky use case. One place they may go is to build towards future extensibility. The critical mistake here is not taking the interviewer's lead. One interview question I like to ask is to design ticket master. I like this because I worked as the lead engineer

13:46 for Amazon's offering in this space and I designed a number of systems here before the business was spun down. I filed a ton of patents in this area and we built one of the fastest and most robust ticket selling platforms in the entire world. So after I asked this question, people would come up with core entities like customer, ticket, and event, and they would sketch out a highle design that would allow for basic search and transacting. At this point, I like to dive deep into places that were a bit stickier. Not to get a sense of whether they could solve the problem exactly like we did. That's not the point, and also impossible to do, but to see if we could actually have a useful discussion. One direction I like to take would be when people buy a ticket for an event with assigned seating, they want

14:32 the tickets to be next to each other. If you buy four tickets to a seated concert, you don't want to be on opposite sides of the venue. So, how do you represent this in the model? It's not straightforward and there are a number of interesting directions to go. If you have an idea of how to do this, leave your approach in the comments and I'll respond to it. The candidates that did the worst were the ones that tried to steer the conversation away to something that they had prepared for or they thought there was some sort of trick that they weren't seeing. But there's no right answer when it comes to system design questions. You want to ask for requirements, define core entities and APIs, and generate a highle design. Then follow the lead of the interviewer as they probe for depth in specific areas so that you can demonstrate critical thinking abilities to have that meaningful conversation. Which brings me

15:19 to my next point. I've said that with coding interviews, it's not about knowing the answer, but demonstrating that you're a problem solver. And with system design interviews, it's not about actually designing a system. It's about getting to a reasonable highle design and then demonstrating critical thinking skills within the context of a system design conversation. But how do you do that? Well, to answer that question, I'll bring in the final type of interview, the behavioral interview. Behavioral interview questions are usually in the form of tell me about a time when are meant to gauge how you've handled situations in the past. The idea is that prior behavior is a strong indicator of future behavior. The question behind the behavioral interview question is, "Do I want to work with this person?" If an

16:05 interviewer asked you to tell me about a time when you had to deal with a difficult co-orker, on the surface they may be asking you about a time you dealt with conflict. But what's the question behind the question? Well, it's are you the difficult coworker? At its core, behavioral questions are questions about the actions that you took in the past. But the truly interesting part is the motivation that drove your action. What were you thinking before you took that action? That's the truly differentiating factor that people always leave out. They think their stories are only about what they did and so leave out the most interesting part, which is what drove you to take that action. Let me give you an example. If I asked you to tell me

16:50 about a time you disagreed with the team decision, you might say something like, "My team wanted to launch a feature without proper testing, but I convinced them to delay the release until we fixed critical bugs." That's fine, but it lacks insight into your thinking. A more powerful response would be, "My team was pushing to launch our payment system update to meet a deadline. When I reviewed the test coverage, I noticed three critical edge cases weren't covered. So, I thought to myself, if we rush this, we risk data corruption issues that could affect thousands of customers and damage the trust that we spent years building." Rather than just opposing the launch, I documented these specific scenarios, created a quick demo showing potential failures, and proposed a modified timeline that addressed these risks while still hitting our goals. See

17:37 the difference? The second answer reveals your reasoning process. You weren't just being difficult. This gives the interviewer insight into how you actually think, not just what you did. And that's my point. The biggest way to do well in technical interviews is to always think out loud. This holds for the coding interview, the system design interview, and the behavioral interview. Add thinking out loud to your preparation. If you can think out loud, this maximizes your luck surface area. It maximizes the likelihood that they'll give you a small but crucial hint on the coding interview that will give you credit for the problem even if you don't know the answer. It'll allow you to have a meaningful conversation when it comes to system design, even if the interviewer starts probing deeply in areas that you aren't familiar with. And

18:24 it'll give insight to interviewers during the behavioral interview because at the end of the day, interviews are less like a test that if you pass, you get an offer, but more like a date where you're really trying to feel each other out. And the thing that you're really optimizing for is fit. The question behind the question isn't, "Did they get all the questions right, it's do I want to work with this person?" And the best answer to give them is a view into how you think when confronted with challenging problems. If you enjoyed this video, none of this matters unless you actually get a call back. Take a look at this video about how to stand out in an insanely competitive job market. Most people are trying to be outstanding in the same way as everybody else. So don't fall into that trap.