Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Get Unstuck by Asking Better Questions
Transcript
- Lucas: There's this moment every engineer knows — you're staring at a bug or a design problem, you've been stuck for an hour, and you finally give up and message a teammate. Luna: And then you spend the next five minutes describing what you've tried, and they immediately point out something obvious you missed. Lucas: Exactly. That feeling of 'why didn't I see that?' usually isn't about smarts — it's about how you framed the question. Today I want to talk about a specific technique that FAANG engineers use to get unstuck faster: asking better questions. Luna: Isn't that just a soft skill? Like, be more articulate? Lucas: It sounds soft, but there's a structural problem underneath. In engineering culture, we reward the person who already knows the answer. Admitting you're stuck feels like a failure. So people either spin their wheels too long, or they dump a messy brain-dump on a colleague and hope for a save. Luna: And the brain-dump approach usually wastes everyone's time. Lucas: Right. The fix is something called the XY Problem. It's a classic logical fallacy where you focus on your attempted solution Y instead of the actual problem X. In engineering, it looks like this: you say 'I tried changing the cache expiry to 30 seconds, but now the data is stale.' And your teammate starts debugging cache configs with you. Luna: When really the underlying problem might be that you're fetching data too often, or that the data source itself is wrong. Lucas: Bingo. So the first rule of asking better questions: state the goal, not the attempted fix. If you say 'I need to show users the latest inventory count within two seconds of a purchase,' now your teammate can think about the real problem with you. Luna: That shifts it from 'help me fix this thing I broke' to 'help me solve this problem I'm trying to solve.' Lucas: Exactly. There's a corollary I've seen work well at places like Google and Stripe: the Three-Question Rule. Before you ping anyone, write down three things — what am I trying to achieve, what have I already ruled out, and what is the simplest next thing I could try? Luna: That forces you to clarify your own thinking first. Lucas: And often, by the time you've written the third question, you've already figured it out. I'd say maybe a third of the time, the exercise itself unblocks you without needing to ask anyone. Luna: That's a huge time saver. But what about when you genuinely need someone else's context? Like, you're stuck on a design review and you need a senior engineer's input on trade-offs. Lucas: That's where framing becomes even more important. Most junior engineers ask 'What do you think of this design?' which is too broad. A senior engineer might need 20 minutes to read and respond. Luna: And they're busy, so they might delay or give a shallow answer. Lucas: Right. Instead, ask a specific question like 'I'm choosing between an event-driven architecture and a batch job for this inventory sync. The batch job is simpler but adds 5 minutes of latency. Do you have experience with that trade-off at scale?' Luna: Now you've given them context and a clear decision point. They can answer in two minutes. Lucas: And they'll probably remember you as someone who respects their time. That builds social capital, which matters a lot at FAANG for promotions and getting your projects staffed. Luna: Let's talk about the debugging scenario specifically. Because that's where I see the most wheel-spinning. Lucas: Yeah, debugging is the classic XY Problem trap. I once saw an engineer spend two days trying to fix a memory leak in a microservice. He'd tried every GC tuning flag, every profiler. Finally, a senior engineer asked 'What's the actual symptom?' Turns out the service was just logging too much — the 'memory leak' was a logging buffer that never flushed. Luna: Wow. So the real problem was log configuration, not memory management. Lucas: Exactly. If he'd started with 'My service is crashing after running for four hours with an out-of-memory error. Here's the exact heap dump and the log volume,' the senior would have spotted it in five minutes. Luna: So the pattern is: describe the symptom, not your theory. Lucas: And include the minimal reproduction steps. The best bug reports I've seen at Netflix follow a template: expected behavior, actual behavior, steps to reproduce, and what you've already eliminated. That's it. Luna: That reminds me of something from Amazon's internal engineering culture — they have a concept called 'writing as thinking.' They encourage engineers to write a one-page document before asking for help on a complex problem. Lucas: That's huge. The discipline of writing forces you to organize your thoughts. I've had situations where writing the doc made me realize I was asking the wrong question entirely. Luna: Let's pivot a bit — how does this apply to career conversations? Like asking for a promotion or a project? Lucas: Huge. A lot of engineers ask 'How do I get promoted?' which is impossible to answer well. The better question is 'What's one project I could take on this quarter that would demonstrate impact at the next level?' Now your manager can point to a specific thing. Luna: And they can also tell you what metrics matter for that project. Lucas: Right. Similarly, when asking for mentorship, avoid 'Will you mentor me?' That puts a vague ongoing burden on someone. Instead, try 'I'm working on X and I'd love to get your feedback on Y. Could we do a 20-minute review next week?' Luna: That's respectful and bounded. You're much more likely to get a yes. Lucas: And you get better advice because the context is concrete. So the through-line here is: better questions earn better answers and respect your colleagues' time. It's a multiplicative skill — a small improvement in how you ask can save hours across your whole team. Luna: I want to push back a little. Doesn't this risk becoming yet another thing engineers feel they have to 'optimize'? Like, now you're stressed about phrasing the perfect question before you even ask? Lucas: That's a fair concern. The goal isn't perfection — it's avoiding the worst patterns. If you can just remember to state the goal instead of your attempted fix, you're already ahead of 80 percent of questions. Luna: So a simple mental shortcut: start with 'I'm trying to...' instead of 'I tried...' Lucas: Exactly. 'I'm trying to reduce latency on this endpoint, and I've tried caching and query optimization. Can you think of other approaches?' That's a good question. Luna: And if that's all you take away from this episode, it'll still save you time. Lucas: Speaking of saving time, I want to mention something brief. If today's tech conversation gave you something usable, there's a simple way to support the show. A couple of dollars a month is genuinely what keeps these episodes ad-free — buy me a coffee dot com slash fexingo. It's a small thing, but it makes a real difference for us. Luna: Yeah, it really does. Every contribution helps us keep the content focused and independent. Lucas: Back to the topic — let's talk about one more scenario where asking better questions matters a lot: code reviews. Luna: Oh, this is a good one. How many times have you seen a comment like 'This code is hard to understand'? Lucas: Too many. That's a terrible question because it doesn't tell the author what to do. A better version is 'Could you add a comment explaining why we're using a hash map here instead of a list? I'm not following the lookup pattern.' Luna: Now the author knows exactly what's confusing and can fix it quickly. Lucas: And as the reviewer, you've modeled good questioning behavior. The author learns how to ask better questions in their own reviews. It's contagious. Luna: That's a nice side effect — you're not just unblocking yourself, you're improving the team's communication culture. Lucas: Right. And that's the deeper value of this skill. It's not just about getting unstuck faster. It's about building a reputation as someone who thinks clearly and respects others' time. That reputation is gold in a FAANG environment. Luna: So to wrap up — if you're stuck right now on something, try the Three-Question Rule. Write down your goal, what you've ruled out, and the next thing to try. Then if you still need help, start your message with 'I'm trying to...' Lucas: And if you want to see this in action, I'll put a template in the show notes that you can copy-paste. Thanks for listening, and we'll see you next time. Luna: Take care, everyone.