Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Recover From a Bad Performance Review
Transcript
- Lucas: You get a calendar invite from your manager that just says 'Performance Sync — 30 min' and your stomach drops. You open the document — and the rating is lower than you expected. Maybe you're at Amazon and you got a 'Meets Some' on the stack rank. Maybe it's Google and your calibration landed at 'Impact Not Yet Evident.' Whatever the label — it stings. Luna: It feels like a career earthquake. I've seen engineers go straight to 'I need to quit' mode within minutes. Lucas: Right — and that's exactly the instinct you have to resist. Because the data shows that engineers who get a bad review and stay — and execute a deliberate recovery plan — often end up promoted within eighteen months. The review is a signal about your impact in the last six months. It is not a verdict on your entire career. Luna: So what's the first move, minute one after that meeting? Lucas: Don't push back in the room. Your manager just delivered feedback that likely went through a calibration process with five other managers. If you argue in the moment, you sound defensive. You say: 'Thank you, I need some time to process this. Can we schedule a follow-up in two days to talk about concrete next steps?' That buys you time to plan. Luna: And in those two days — what are you actually doing? Lucas: First, read the review again — cold. Underline the specific projects and behaviors that got flagged. Then look for the pattern. At Amazon, a 'Meets Some' often means you delivered OK output but with too many escalations or rework. At Google, 'Impact Not Yet Evident' usually means your project scope was too narrow or you didn't influence cross-team results. Figure out which bucket you're in. Luna: Interesting — so you're diagnosing the root cause before you even talk to your manager. Lucas: Exactly. And then you write a one-page comeback plan. Bullet points: what I'll stop doing, what I'll start doing, and the specific deliverable I'll produce in the next quarter to demonstrate improvement. Show your manager you've already internalized the feedback and have a plan. That alone changes the tone of the follow-up conversation. Luna: I've heard that a big mistake engineers make is asking 'Who said this about me?' — trying to identify the peer who gave negative feedback. Lucas: Huge mistake. At FAANG, peer feedback is anonymous or aggregated. Asking that question makes you look like you're hunting for someone to blame. The better question is: 'What behavior do I need to change so that this feedback doesn't come up again?' That's forward-looking. That's what managers want to hear. Luna: And what about the classic 'I just need a new manager' response? Sometimes a bad review is actually a mismanagement issue. Lucas: It's real — but it's a dangerous card to play right after a bad review. If you blame your manager, you lose the ability to learn from whatever criticism was valid. My rule: do the comeback plan first for one quarter. If you execute it and the next review is still bad — then you have data that the environment is the problem, and you can move internally or externally with a clean story. Luna: So the comeback plan is like a structured experiment. You're testing whether the feedback was fair and whether you can address it. Lucas: Right. And you want to focus on visible impact. One of the most common patterns in bad reviews — especially at Amazon — is that the engineer did a lot of work, but the impact was invisible to the people calibrating. So in your comeback quarter, you pick one project with a clear metric — say, reduce pager duty alerts by 30 percent — and you make sure your manager and skip-level know what you're doing and why. Luna: And what if the review comes with a formal PIP — performance improvement plan? That's the nuclear option. Lucas: It is. But even then, you have options. At Amazon, the typical PIP is about 30 days. At Microsoft, it's often 60 to 90 days. The odds of surviving a PIP at Amazon are roughly 50 percent. But the smart play is to start interviewing immediately — externally — while you execute the PIP. That way, you have a fallback. And if you do survive, you've also gathered market data on your own value. Luna: That's actually empowering — you're not just sitting there hoping. You're taking control. Lucas: Exactly. And here's something most engineers don't realize: if you do get let go after a PIP, many FAANG companies will allow you to convert to a 'coached out' resignation if you ask. That lets you say you left voluntarily in future background checks — it avoids the termination flag. Luna: That's a pro-level move. I want to circle back to something you mentioned earlier — the one-page plan. Can you give listeners a concrete example of what that looks like? Lucas: Sure. Say you're a software engineer at Google, and your review says your code is solid but you're not having enough cross-team impact. Your plan might say: 'Stop: working on tasks that only benefit my immediate team. Start: joining the weekly infrastructure sync with the data engineering team. Deliverable: by end of Q3, propose a shared library that reduces duplicate work between my team and data engineering, with a target of saving 40 engineering hours per quarter.' That's specific and measurable. Luna: And you present that to your manager in the follow-up meeting? Lucas: Yes. And you ask: 'Does this address the feedback? What would you add or change?' That positions you as someone who takes ownership. Your manager becomes your coach instead of your judge. Luna: That's a really useful way to frame it. And I think this is a good moment to mention — if you're getting value from episodes like this, where we give specific actionable frameworks, there's a simple way to support the show. It's listener-supported, no ads, and if you want to help keep it going, you can do that at buy me a coffee dot com slash fexingo. Just a one-time thing, no pressure. Lucas: Yeah, it really helps. And back to the plan — another thing to watch out for: don't try to fix everything at once. Pick the top two criticisms. If your review says 'code quality needs improvement' and 'communication needs improvement,' focus on the one that will have the biggest multiplier. At most FAANGs, communication is actually the higher-leverage fix, because better communication makes your code impact more visible. Luna: So you're arguing that the 'soft' skill fix can actually be the faster route to a better review? Lucas: Absolutely. I've seen engineers double down on coding more hours after a bad review — and the next review still says 'impact not evident.' Because they were writing great code no one knew about. Meanwhile, an engineer who starts writing weekly status emails and presenting at the team demo gets noticed — and their next rating goes up even if their code output stayed the same. Luna: Visibility is part of the job description at that level. Lucas: Exactly. And one more thing: document everything. Keep a 'brag doc' of your wins each week. When the next review cycle comes, you have concrete evidence to point to. That's especially important if you're in a company with a lot of engineers and a forced distribution — your manager might want to fight for you in calibration, but they need ammunition. Luna: That brag doc idea is something we've talked about in other contexts, but it's especially critical after a bad review. Lucas: Right. The bad review is not the end of the story. It's the inciting incident. The real story is what you do next. And the engineers who treat it as a data point rather than a verdict — those are the ones who end up writing the narrative they want.