Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Build Resilience Against Impostor Syndrome
Transcript
- Lucas: You've been at a FAANG company for maybe six months. The onboarding is done. You shipped your first real project. And yet, every morning you look around and think — I don't belong here. Everyone else seems to know things you don't. They type faster. They ask sharper questions in design reviews. You're convinced it's only a matter of time before someone figures you out. Luna: That feeling has a name — impostor syndrome. And it is remarkably common in big tech. I've been there myself. Lucas: Yeah. And the thing is, it's not just a vague emotional state. There are specific patterns that trigger it. And some really concrete tactics engineers use to push through. That's what I want to get into today. Luna: Good. Before we go deep — quick honest thing. A handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making this many of these episodes. No ads, no sponsors — just listener support. So if today's tech conversation gave you something usable, that's where it comes from. Lucas: It really is. And we're grateful. Anyway — let's anchor this in some numbers. A 2024 internal survey at Meta found that 67 percent of new hires reported impostor thoughts within their first six months. Not just junior engineers — senior staff and even managers. Luna: Wow. Two-thirds. So it's not about skill level. It's about the environment. Lucas: Exactly. At FAANG, you're surrounded by people who were the smartest person in their previous job. Suddenly, being average feels like failing. And the feedback loops are intense — code reviews, performance ratings, stack ranking. It's a petri dish for self-doubt. Luna: So what do people actually do about it? I remember a senior engineer at Amazon who kept what he called a 'competence log'. Every week he'd write down three things he did well — a bug he fixed, a design decision that worked, a mentoring moment. When impostor feelings hit, he'd read it back. Lucas: That's a great tactic. And it maps to something a Google engineering director told me about — the 'three data points rule'. When you feel like an impostor, your brain cherry-picks negative evidence. The rule says: force yourself to find three concrete, objective pieces of evidence that you're competent. A successful code review. A positive comment from a colleague. A project milestone you hit on time. Luna: It's like retraining your attention. Instead of fixating on the one time you made a mistake in a design review, you start noticing all the times you contributed. Lucas: Right. And there's a cognitive bias at work here — the Dunning-Kruger effect inverted. In a highly skilled environment, competent people underestimate their ability because they compare upward. The less competent ones overestimate. So feeling like an impostor is actually a sign you have enough self-awareness to see the gaps. That's not a weakness — it's a signal that you're growing. Luna: I like that reframe. But it's not just individual tactics. The culture matters too. At Meta, they have explicit programming on impostor syndrome during onboarding. They tell new hires: 'If you don't feel a little overwhelmed, you're not learning.' Lucas: That's smart normalization. And I've seen managers who actively build that into their one-on-ones. Instead of just reviewing output, they ask: 'What's something you're proud of this week?' and 'What's something that felt hard?' That creates space for the honest conversation. Luna: Let me give another concrete example. A friend at Apple said she felt impostor syndrome most acutely during code reviews — especially when a more senior engineer would suggest a completely different approach. She started a practice: after each review, she'd note one thing she learned and one thing she already knew. That balance kept her from spiraling. Lucas: That's smart. Because code reviews can feel like a public judgment of your competence. But they're actually a collaboration tool. One study from Google — Project Aristotle follow-up work — found that teams with psychological safety outperformed others, even when individual skill levels were the same. So the environment matters a ton. Luna: What about the role of mentorship? I've seen engineers who pair with a mentor specifically to get grounded feedback on their performance — not just career advice. Lucas: Huge. A good mentor can give you an external reality check. They can say: 'Look, you shipped that service with zero downtime. That's not luck. That's skill.' And because they're outside your head, you trust it more than your own internal monologue. At Amazon, there's a formal mentorship program that pairs engineers with someone two levels up — and one of the explicit goals is combating isolation and impostor feelings. Luna: Yeah. Isolation is a big part of it. When you're remote or in a new team, you don't see the struggles of others. You only see their polished output. That exaggerated comparison is brutal. Lucas: That's why some teams at Google do 'postmortem sharing' — not just for outages, but for projects. Engineers present what went wrong and what they learned. It normalizes failure and shows that everyone hits rough patches. Luna: So we've talked about individual tactics, mentorship, and culture. Is there a structural change that helps? Like, are performance review processes part of the problem? Lucas: They can be. The old stack ranking systems — where you're forced into a distribution — that definitely amplifies impostor syndrome. Because you're literally ranked against peers, and someone has to be at the bottom. Most FAANGs have moved away from strict curves, but the competitive undercurrent remains. A better approach is what Microsoft did with their 'growth mindset' culture — focusing on learning and development rather than just ratings. Luna: I want to circle back to something you said earlier — about the three data points rule. Can you walk through how an engineer would actually apply that in a moment of doubt? Lucas: Sure. Let's say you just had a tough code review. Your change got a lot of comments. You feel your stomach drop. The impostor voice says: 'See, you don't know what you're doing.' The rule says: stop. Take out a notebook or a note app. Write down three things that went well this week. Maybe you debugged a tricky issue. Maybe a junior engineer said your explanation was helpful. Maybe your deployment went smoothly. The key is they have to be specific and objective. Not 'I'm smart' — but 'I fixed the caching bug that had been open for three days.' Luna: That's concrete. And it moves you from emotion to evidence. I've done that, and it really does reframe the moment. Lucas: Absolutely. And the competence log that you mentioned — that's the same idea but proactive. You build up evidence over time so when impostor hits, you have a pre-existing case file. One engineer at Facebook told me he kept a folder of 'kudos' emails and positive code review comments. He called it his 'brag file'. Luna: I love that. It's like a portfolio of proof. And it's not about arrogance — it's about balancing the cognitive scales. Lucas: Right. And I think the best engineers I've talked to treat impostor syndrome not as something to eliminate, but to manage. It's like a background process — it'll always be there to some extent. But you can reduce its priority. You can build systems that help you see reality more clearly. Luna: Final thought — is there a point where impostor syndrome actually becomes a problem? When it stops being a growth signal and starts hurting performance? Lucas: Definitely. If it leads to avoidance — you stop contributing in meetings, you decline stretch projects, you shy away from promotion — then it's costing you. That's when you need more than self-help. You need a mentor, maybe therapy, or a manager who can give you structured feedback. The goal isn't to never feel it. It's to not let it dictate your decisions. Luna: That's a good place to leave it. I think a lot of engineers listening will recognize themselves in this conversation. And hopefully some of those tactics stick. Lucas: Yeah. Next time we'll talk about something lighter — how FAANG engineers negotiate flexible hours without it looking like they're slacking. That's a whole other set of skills. Luna: Looking forward to it. Thanks, Lucas. Lucas: Thanks, Luna.