Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Self-Assess Before Performance Reviews
Transcript
- Lucas: So we're deep into mid-year review season across most of the big tech companies right now — late June 2026, which means managers at Google, Meta, Amazon are all finalizing their calibration packets for the first half of the year. Luna: And if you're an engineer, this is usually the moment where you realize you should have started preparing three months ago. Lucas: Exactly. And that's what I want to talk about today — not the review process itself, but the self-assessment that precedes it. Because a lot of engineers treat the self-assessment as this last-minute homework assignment, and they miss the fact that it's actually a strategic document. Luna: Strategic how? I mean, doesn't your manager already know what you worked on? Lucas: They know some of it. But here's the thing — at FAANG scale, your manager might have a dozen direct reports or more. They see your code reviews, your commits, your sprint demos. But they don't see the full picture of your impact, especially the cross-team coordination or the architectural decisions you made that prevented future tech debt. Luna: So the self-assessment is your chance to connect the dots for them. Lucas: Right. And the engineers who get promoted fastest are usually the ones who treat the self-assessment as a narrative-building exercise, not a checklist. I was talking to a staff engineer at Google who said she starts drafting her self-assessment about six weeks before the review deadline. She adds bullet points as she ships things, and by the time review season comes, she's not scrambling — she's editing. Luna: Six weeks. That's a serious lead time. What does she actually write? Lucas: She structures it around three dimensions that map directly to the promotion criteria at most companies: scope of impact, technical leadership, and business influence. Scope of impact is about how many users or systems your work touched. Technical leadership is about the design decisions you drove. Business influence is about how your work moved a metric — revenue, latency, retention, something concrete. Luna: I love that. It forces you to translate technical work into business outcomes. A lot of engineers write 'I built a new caching layer' — but that's just a task. The business outcome is 'caching reduced page load time by 30 percent, which increased conversion by 2 percent.' Lucas: Exactly. And that transformation — from task to outcome — is the core skill of a senior engineer. I remember a story from Amazon. There was an SDE II who was frustrated that she wasn't getting promoted to SDE III. She had worked on a critical service migration, but her self-assessment listed all the technical steps — 'migrated database from DynamoDB to Aurora, updated connection pooling, fixed five bugs.' Luna: Effort oriented, not impact oriented. Lucas: Yeah. So she rewrote it. Framed it as: 'Led the migration of our primary customer database, reducing query latency by 40 percent and saving the team roughly 200 engineering hours per quarter in maintenance. The migration enabled a new feature that increased customer retention by 3 percent.' That got her the promotion. Luna: And she had to gather that data — the latency numbers, the retention lift — she probably had to pull that from dashboards and talk to the product team. Lucas: Right. And she started doing that six weeks out. That's the pattern. Now, let me pause there because this is actually a good moment to mention something. If you're listening and thinking, 'I need a system for this, this is exactly the kind of concrete advice I was hoping for' — that's the whole reason this show exists. And we keep the episodes ad-free so you get straight value. If today was actually useful to you, the way these stay ad-free is listener support — buy me a coffee dot com slash fexingo. It's a small way to say 'keep making these' and it genuinely lets us keep talking about the specifics, not selling you something. Luna: Yeah, and we mean that. Even a couple of coffees a month helps. So if you've gotten something from the show, consider it. Lucas: Alright, back to self-assessment. So you've got your three dimensions. Now the next mistake I see is that engineers rate their own work by effort — 'I spent three months on this, it was really hard' — but the review committee doesn't care about effort. They care about demonstrable impact relative to your level. Luna: How do you calibrate what 'impact at your level' even means? I know a lot of engineers struggle with that. Lucas: Great question. At Meta, they have these public leveling guidelines that describe what impact looks like at each level. For example, an E5 is expected to have impact that spans a quarter and affects their team. An E6 should have impact that spans a half and affects multiple teams. So you need to be honest about the scope of your work. Luna: And if you're not sure, you can look at recent promotions in your org to see what kinds of projects they worked on. Lucas: Exactly. But there's also a calibration technique I learned from a senior manager at Apple. He told me to write my self-assessment, then give it to a peer — not your manager, a peer — and ask them two questions: 'Does this sound true?' and 'Does this sound like the next level?' If the peer says it sounds like you're already operating at that level, great. If they say it sounds like you're describing your current job, you need to reframe or you might not be ready. Luna: That's a smart sanity check. And it also builds your case — because if a peer can verify your impact, that's powerful in calibration. Lucas: Right. Calibration is where your manager goes to bat for you in a room full of other managers. If your self-assessment has concrete numbers and peer validation, it gives your manager ammunition. Without that, your manager might have to say 'I think they did good work' — and that's weak. Luna: So the self-assessment is really a document for your manager's manager, not just your manager. Lucas: Exactly. It's part of the promotion packet. And the strongest packets I've seen have three things: a crisp narrative, specific metrics, and at least two peer quotes or endorsements. Some engineers even ask peers to write a brief paragraph about their collaboration — not a surprise, but a planned request. Luna: That's forward-thinking. I think a lot of engineers feel uncomfortable asking for endorsements because it feels like bragging. But if you frame it as 'I want to make sure my review is accurate, can you share what you saw in our project?', people are usually happy to help. Lucas: Yeah, and the timing matters. If you ask three weeks after the project ended, the details are fresh. If you ask during review season, everyone is busy and it feels transactional. So start six weeks out, ask for feedback on your self-assessment, gather peer quotes, and by the time the review window opens, you're just polishing. Luna: One thing I've heard from engineers is that they're afraid of overselling — that if they frame their impact too strongly, they'll look arrogant or get called out. Lucas: That's a real fear. But the antidote is specificity. If you say 'I improved performance by 40 percent,' and you can point to the dashboard showing the before and after, that's not arrogance — it's evidence. The problem is when people say 'I was the key driver of success' without any proof. So stick to the formula: I did X, which led to Y measurable outcome. Luna: And if you can't measure the outcome directly, you can still frame it as enabling others. Like 'I built a tool that saved the team 10 hours per week' — that's measurable. Lucas: Exactly. And that brings us to one more trap: the 'busy' trap. Some engineers list 15 different projects in their self-assessment, trying to show volume. But review committees weight depth over breadth. They'd rather see two projects with deep impact than ten shallow ones. So edit ruthlessly. Luna: Pick the two or three that best demonstrate growth toward the next level. Lucas: Right. And if you have smaller projects, you can group them under a theme — 'I improved our monitoring infrastructure across three services, reducing incident response time by 50 percent.' That's one bullet, not three. Luna: I want to go back to something you said earlier — starting six weeks out. What does the week-by-week timeline look like? Lucas: Sure. Week one: review the promotion criteria for your target level and the current level. Note the gaps. Week two: list all projects from the last six months, assign each to one of the three dimensions — scope, leadership, influence. Week three: pull metrics for the top three projects. Week four: write a first draft and send it to a trusted peer for feedback. Week five: incorporate feedback and ask for peer quotes. Week six: final review with your manager, ideally one-on-one. Then submit. Luna: That's a concrete plan. And you're not cramming the night before. Lucas: Exactly. And I think the biggest takeaway is this: your self-assessment is not a report of what you did — it's an argument for what you're capable of. Treat it like a pitch. And if you're not sure where to start, just pick one project and write the before and after story. That one exercise will teach you more about self-assessment than any template. Luna: Great advice. And with mid-year reviews wrapping up, this is the perfect time to start building the habit for the end-of-year cycle. Lucas: Exactly. Alright, that's our show for today. We'll be back next week with another deep dive on navigating the engineering career ladder at big tech companies.