Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Get Unstuck on Hard Problems
Transcript
- Lucas: There is a moment every software engineer knows — you've been staring at the same bug for two hours, you've tried three different approaches, and the code still breaks in exactly the same place. Your brain feels like static. And the worst part is, the more you push, the worse it gets. Luna: I think everyone listening has been there. It's almost a rite of passage. But what do FAANG engineers actually do in that moment — because I suspect they don't just keep banging their head against the wall. Lucas: They don't. And that's what we're drilling into today — the specific techniques for getting unstuck. Not theory, but the actual playbook. And before we go deep, a quick note on something that keeps this show ad-free and available to everyone. Luna: Yeah, listener support is what makes that possible. If today's conversation gives you something you can use, you can support us at buy me a coffee dot com slash fexingo. Lucas: It genuinely makes a difference. Okay — let's talk about stuckness. I want to start with a concrete example from a senior engineer at Amazon I spoke with recently. He was leading a microservices migration, and one service kept failing under load in staging. Luna: Classic. And these are never simple failures — they're usually something like a race condition or a subtle timeout issue. Lucas: Exactly. He spent two full days chasing it. Tried different thread pool configurations, added more logging, even re-read the SDK documentation. Nothing. So on day three, he did something that sounds almost too simple to work. Luna: Let me guess — rubber duck debugging? Where you explain the problem out loud to an inanimate object? Lucas: That's exactly it. But with a twist. He didn't just talk to a rubber duck — he recorded himself explaining the system architecture and the failure mode on his phone. And while listening back, he heard himself say 'and then the connection pool closes' — and he realized, wait, I'm assuming the connection pool closes correctly, but I never actually verified that. Luna: That's fascinating. The act of speaking forces your brain to sequence the problem linearly, instead of the circular thinking you do when you're just staring at code. Lucas: Right. There's actually neuroscience behind it — verbalizing a problem activates different neural pathways than reading or typing. So that's technique number one: force a verbal explanation, ideally to a recording or a colleague. Luna: But what if you don't have a colleague available? Or you're worried about looking like you don't know what you're doing? Lucas: That's a real concern. And it brings up the second technique: the timeboxed spike. A spike — in agile terms — is a short, experimental coding session with a specific hypothesis. The key is the timebox. You set a timer for, say, thirty minutes, and you try one very specific fix. Luna: So instead of randomly tweaking things, you're running a mini experiment. Hypothesis: 'If I increase the timeout from two seconds to five, the error rate drops.' Then test it. Lucas: Exactly. And if it doesn't work, you don't keep iterating — you stop, document what you learned, and move to the next hypothesis. The engineer I spoke with said that after the rubber duck moment, he did a thirty-minute spike to add a connection pool health check. It worked. Total time from stuck to solution: about forty minutes. Luna: That's a huge productivity gain. But I want to push back on something. Isn't there a risk that engineers use these techniques to avoid asking for help? Because sometimes the fastest path to unstuck is just asking someone. Lucas: That's a fair point. And I think the best engineers know when they're in a productive struggle versus when they're just spinning. Productive struggle is when you're learning something new — you're making incremental progress, even if it's slow. Spinning is when you're trying the same things with no new insight. Luna: So how do you tell the difference? Is there a rule of thumb? Lucas: The rule I've heard from staff engineers is: if you can't articulate what you've learned in the last thirty minutes, you're spinning. If you can say 'I ruled out this hypothesis' or 'I narrowed the bug to this module', you're still in productive struggle. Luna: That's concrete. So the moment you can't say what you've learned, it's time to either spike or ask for help. Lucas: Exactly. And asking for help has its own etiquette. The FAANG engineers I've interviewed emphasize that you should never just say 'I'm stuck' — you should show what you've tried and what you've eliminated. That signals competence, not weakness. Luna: Right. It's the difference between 'help, this doesn't work' and 'I've tried A and B, they both failed because of X and Y, do you see something I'm missing?' The latter shows you've done your homework. Lucas: And that's exactly how the Amazon engineer handled his rubber duck moment — he had already done the homework, but he needed the verbalization to see the blind spot. So let's recap the three techniques: verbal explanation, timeboxed spike, and structured help request. Luna: But there's a fourth technique I've heard about — something called 'the pomodoro reset.' Where you take a five-minute break, literally do something unrelated, and then come back. Is that part of the FAANG playbook? Lucas: It absolutely is. And it's backed by research on attention residue — when you switch tasks, part of your brain is still stuck on the previous problem. A short break, especially physical movement, clears that residue. I've seen engineers at Google use a standing desk and just walk away for five minutes. Luna: I do that myself. Sometimes the best debugging happens when I'm not looking at the screen. Lucas: Exactly. The brain continues to process subconsciously. So technique four is: take a deliberate break. Not just scrolling Twitter — actually disengage. Go make tea, look out a window, do some stretches. Luna: Okay, so we've got four techniques. But I want to talk about the emotional side. Being stuck is frustrating. It can make you feel stupid, especially when you're surrounded by really smart people. How do FAANG engineers manage that? Lucas: That's a great question. And I think the answer is that they normalize it. At Amazon, there's a concept called 'disagree and commit' — but there's also a culture of 'it's okay to be stuck, as long as you're transparent about it.' I've heard senior engineers say 'I'm stuck on this, I need another pair of eyes' in standup meetings without any stigma. Luna: So it's about psychological safety. If the team culture punishes being stuck, people will hide it and waste hours. But if it's seen as normal, they'll ask for help earlier. Lucas: Exactly. And that's something managers can foster. But for the individual engineer, the key is to have a personal playbook. Know your go-to techniques so you don't panic when you hit a wall. Luna: I want to ask about one more scenario: what if you're stuck on a problem that's not a bug, but a design decision? Like, which architecture to use? The techniques seem more applicable to bugs. Lucas: They apply to design too. The verbal explanation technique works great for design — you explain the trade-offs out loud, and often you hear your own bias. The timeboxed spike works too: you prototype a minimal version of each option and compare. And the structured help request is even more important for design, because you want input from people with different perspectives. Luna: So really, these are general problem-solving techniques, not just debugging tricks. Lucas: Exactly. And that's the takeaway I want listeners to have. Being stuck is not a failure — it's a signal. A signal that you need a new approach. And having a playbook turns that signal into action. Luna: I think that's a great note to end on. Next episode, we'll talk about something I know a lot of engineers struggle with: how to say no to extra work without seeming uncooperative. Lucas: That's a good one — see you next time.