|
I want to tell you about the Meta interview where I learned one of the most important lessons about technical interviewing, one that completely transformed how I teach and approach them. This was in 2019. I was still in college. I got a DM from a recruiter on LinkedIn asking if I was interested in interning for Meta (Facebook at the time). I had a call with the recruiter, crushed that screening and got matched with a software engineer for the technical screen. It was the standard stuff: phone call, shared coding platform, one problem to solve. When the interviewer pasted the question on the coding platform, I recognized it immediately and felt a surge of relief. It was a pretty standard problem that I had seen and done before, or so I thought. I started coding. I worked through the problem, hit a couple of bugs, debugged them and kept going. Forty-five minutes in, the code looked solid. Everything worked. I told the interviewer, "Hey, I'm done." There was a pause. He then responded, "You didn't solve the problem I gave you. What is this code doing?" Fifteen minutes left. No time to recover. I tried explaining my approach, but I could tell he had already made up his mind. We wrapped up with the obligatory "Do you have any questions for me?" I asked about the culture and the other standard stuff. But I already knew I wasn't getting a callback. Here's what I realized afterwards: Before I told the interviewer I was done, the only conversation we'd had was our initial pleasantries. As soon as I saw the question, I read it, I didn't ask for clarification. I didn't request more examples (he only gave me one). I didn't come up with my own examples. I didn't walk him through my approach before coding. I just... started writing code. That's a recipe for disaster. Now, maybe the interviewer should have followed along actively, asking clarifying questions. But here's the reality: I've been on the other side now, interviewing candidates for FAANG companies Most interviewers are overworked, tired engineers. For many, interviewing isn't something they want to or enjoy doing. It's an obligation. I can easily see why he let me go off on my own while he focused on his other work on the side. It's on you, the candidate, to steer the interview. You need to confirm you understand the problem by explaining it back to the interviewer. You need to think of your approach out loud and communicate it before you code. Because most of the time, the interviewer already has the solution in their head. They've probably asked this question hundreds of times. They know the exact edge cases and all the pitfalls candidates will encounter. The more you talk through how you see the problem and communicate as you're coding, the more they can guide you and give you hints to help course correct if you're going off the rails. The conversation is equally as important as the technical problem-solving. That's why I'm so focused on teaching the communication side of technical interviews, not just the coding part. Topics like these are exactly what we cover in The Code Room during the Technical Interview Tuesdays session. Real scenarios, real mistakes, real strategies that actually work. As someone who has coached dozens of software engineers and landed my Netflix role with just one week of interview prep (because I'd been staying ready), I can tell you from experience: waiting until you have an interview scheduled is not the best time to start prepping. Building this skill takes time. It's something you need to work on consistently, with intentional practice so you're ready when the opportunity arises. I've designed The Code Room to give you that structure and accountability. Coaching and feedback from me, a supportive community, and the consistent practice that turns interview prep from a stressful scramble into a skill you own. We're in launch week right now. New members get $50 off their subscription for life. Whatever price you lock in stays with you forever. Join The CodeRoom_ today. I'll see you inside. Uma |
Join my email list for updates, behind-the-scenes thoughts, and content I don’t post anywhere else.
I was recently speaking on a panel at an event for software engineers who recently got laid off. You could feel the tension in the room. Smart people. Solid experiences. But the same question kept coming up in different forms: How do you stand out when companies have hundreds of qualified candidates to choose from? My answer was simple. The narrative you can build around your career and how you convey it is what will make you stand out. Your narrative is more than what you’ve done or how many...
I used to think the most important career document was your resume. Turns out, I was wrong. There's a document that will quietly do more heavy lifting for your career than your resume ever will. It's called a brag sheet and once you start one, you're never going back. So what exactly is a brag sheet? It's a living document that tracks all the work you've done and the value you've delivered. Think of it as your resume's more detailed, always-up-to-date cousin. Here's Why You Should Have One A...
Before we dive in: Today is the final day for new members to get 25% off their subscription to The Code Room for life. Whatever price you lock in today stays with you forever. Join here. The CodeRoom_ Very early on in my career, I used to think mastering a programming language would set me apart as a software engineer. But here's what I've learned from my time at Microsoft and Netflix, and from all the interviews I've done with other companies: knowing a programming language isn't what makes...