Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Handle Code Review Conflicts
Transcript
- Lucas: You submit a pull request. You've tested it, your logic is clean, the tests pass. Then a senior engineer comments: 'This should use a factory pattern instead.' And you think — but it's a two-method class. That's the code review conflict that derails careers, not because of the code, but because of how you handle it. Luna: I've seen that exact comment. It's almost always about style, not correctness. And the junior either fights back aggressively or just caves and rewrites it resentfully. Lucas: Right. And both of those hurt your reputation over time. So today we're going to talk about how FAANG engineers navigate these conflicts — not just the technical side, but the human side. Because code review is the most frequent high-stakes interaction you'll have with your peers. Luna: If today's tech conversation gave you something usable, the reason we can keep doing this without ads is listener support. You can buy us a coffee at buy me a coffee dot com slash fexingo. Low-key, no pressure — just if you found it useful. Lucas: Yeah, that's the only way this stays free and focused. Now, let's get into the specific scenario that a listener named Priya sent in. She's a mid-level engineer at Amazon, and she had a PR that got a 'nit: rename this variable to isAvailable' — which is fine, she did it. But then a different senior asked her to refactor an entire module because he preferred a different architecture. Luna: Ouch. That's where the stakes go from trivial to significant. How did she handle it? Lucas: She pushed back initially, citing the existing codebase conventions. But the senior was insistent. So she did something smart: she took the conversation offline. She asked for a quick sync, showed him the existing patterns, and they agreed to align on a new convention for future modules. Her PR went in as-is. Luna: That's a great move. The key phrase there is 'let's align on a convention.' It shifts the conversation from personal preference to team standard. Lucas: Exactly. And that's a pattern I see among engineers who get promoted. They know when to fight and when to fold. A study from Google's engineering productivity research — Project Aristotle, actually — found that psychological safety was the top predictor of effective teams. And code review is where psychological safety gets tested daily. Luna: So what's the concrete framework? If I'm a junior engineer and a senior drops a refactor bomb on my PR, what do I say? Lucas: First, separate objective from subjective feedback. Objective: 'This function has a bug when the input is null.' You fix that, no debate. Subjective: 'This should use an abstract base class.' That's style. For subjective feedback, you have three moves: explain, align, or concede. Luna: Explain — that's like 'I chose this pattern because it's consistent with the existing code.' Align — 'Let's discuss what the team standard should be going forward.' Concede — 'I see your point, I'll update it.' Lucas: Right. But here's the nuance: you don't always want to concede, even if it's easier. Because every time you concede on a subjective point, you're signaling that your judgment isn't worth defending. Over time, that hurts your technical credibility. Luna: But if you fight every subjective comment, you become known as difficult. There's a balance. Lucas: Exactly. The rule of thumb I use: if the change takes less than 15 minutes, just do it. Pick your battles. But if it's a significant refactor, that's worth a conversation. And always, always frame it around what's best for the codebase, not your ego. Luna: I've also seen people use data. Like, 'I benchmarked both approaches and the current version is 10 percent faster.' That's hard to argue with. Lucas: Yeah, data is the ultimate trump card. But not every situation has data. Sometimes it's genuinely ambiguous. In those cases, I look at who the reviewer is. If it's a staff engineer with context I don't have, I'm more likely to trust their judgment. If it's a peer, I'm more likely to push for consensus. Luna: That's a good heuristic. Another thing: how do you handle the reviewer who is just plain wrong? Like, they misunderstand the requirement and ask for something that breaks the feature. Lucas: You thank them for the review — always start with appreciation — then explain the requirement. Say 'That's a valid approach for a different use case, but this feature needs to handle X, which is why I went this direction.' And if they still push back, escalate to a third reviewer or your manager. That's not tattling; that's unblocking yourself. Luna: I want to talk about the emotional side too. Code review can feel like a personal attack, especially when comments pile up. I've seen engineers take a day to respond because they're too frustrated. Lucas: That's actually a good tactic — if you're angry, don't reply. Wait until you can be professional. But don't wait more than 24 hours. A slow response signals that you're avoiding the conflict. Better to reply with 'Thanks, let me think about this and get back to you tomorrow.' Luna: Yeah, clear communication about timing is underrated. So what about the reviewer's side? How should a senior engineer give feedback to avoid these conflicts? Lucas: Great question. The best reviewers I've seen use the 'nit' prefix for trivial things, and they always include a rationale for bigger asks. Instead of 'Use factory pattern,' they say 'A factory pattern would make this extensible for the new payment types we're adding next quarter.' That gives context. Luna: And they separate blocking comments from nice to haves. A lot of conflicts happen because the author thinks every comment must be addressed. Lucas: Right. So if you're the author, ask: 'Is this a blocker or a suggestion?' If the reviewer doesn't specify, you can ask. But by default, assume blocking unless stated otherwise. That's a common FAANG culture norm. Luna: Let's talk about async vs. sync. When should you take it offline? Lucas: If you've gone back and forth three times and you're still not aligned, stop typing. Schedule a 15-minute call. Async debate is inefficient and tends to escalate because tone is lost. On a call, you can hear the other person's intent, and you can reach a decision in minutes. Luna: And record the outcome in the PR. 'Discussed offline, agreed to proceed with current approach, will revisit when we add X feature.' That gives closure. Lucas: Exactly. Now, one more pattern I want to cover: the 'drive-by reviewer.' Someone who isn't assigned but drops in with a major comment. How do you handle that? Luna: Politely acknowledge, but weight their feedback based on their domain expertise. If they're from your team, take it seriously. If they're from a different team and the comment is about something they own, like API design, definitely consider it. But if it's about internal implementation detail, you can say 'Thanks, I'll keep that in mind for future iterations.' Lucas: That's perfect. The phrase 'I'll keep that in mind for future iterations' is a polite way to not adopt the feedback without being dismissive. And it's honest — you might use it later. Luna: So let's sum up. For the listener who's about to submit their next PR: what's your number one piece of advice? Lucas: Assume good intent. Most reviewers are trying to help. But also, trust your own judgment. You wrote the code; you understand the context. If a comment doesn't make sense, ask clarifying questions. And if you still disagree, escalate thoughtfully. Your goal isn't to win the argument — it's to ship the best code with a healthy team. Luna: And if you're the reviewer, remember that the author probably worked hard on that PR. Start with something positive, even if it's just 'Nice approach on the error handling.' It sets a collaborative tone. Lucas: Completely agree. Code review is the most common form of mentorship in tech. Do it well, and people will want to work with you. Do it poorly, and you become the person everyone dreads adding as a reviewer. Luna: Alright, that's a good note to end on. Next episode, we'll talk about something every engineer faces: how to say no to extra work without looking like you're not a team player. Lucas: Ooh, that's a good one. See you next time.