Avoid These Junior Engineer Mistakes With Code Review

In this video segment, we reflect on common mistakes and best practices around code submissions, especially relevant to early-career engineers. The discussion centers around how to be thoughtful and intentional in code reviews to earn trust and increase velocity over time.

• We don’t treat code review as a speed game. Moving fast at the cost of quality—like deferring fixes or separating tests from the initial diff—often backfires. We strive to bundle fully thought-out changes with tests as one atomic, reviewable unit.
• We use RFC diffs to gather early feedback. When we're unsure of direction, we create “Request for Comment” diffs clearly labeled as such. This helps reviewers give high-level input without getting stuck on minor details.
• We always show proof of testing, even for small changes. Even if our change is minimal (e.g., a refactor or doc update), we still confirm it compiles and passes existing tests to signal due diligence.
• We think like reviewers. Providing context, test signals, and clarity up front not only earns trust but speeds up the feedback loop and helps us land code more efficiently.