Code Review Basics

The Hook (The "Byte-Sized" Intro)

Google's engineering team found that every hour of code review saves 33 hours of debugging later. That's not a typo. A single review comment — "this loop doesn't handle empty arrays" — can prevent a production outage that costs days. Code review isn't overhead; it's the highest-ROI activity in software development.

📖 What is Code Review?

Code review is the practice of having another developer examine your code changes before they're merged. It's conducted through pull requests, focusing on correctness, clarity, security, and maintainability.

Conceptual Clarity

What reviewers look for:

Category	What to Check
Correctness	Does the code do what it claims? Edge cases handled?
Clarity	Is the code easy to read and understand?
Security	Any hardcoded secrets? SQL injection? XSS?
Performance	Unnecessary loops? N+1 queries? Large allocations?
Tests	Are there tests? Do they cover edge cases?
Style	Does it match the team's coding standards?
Scope	Is the PR focused? Does it mix unrelated changes?

Review etiquette:

Critique the code, not the person
Ask questions instead of making demands: "Would it be clearer to...?" vs "Change this."
Acknowledge good code: "Nice approach here 👍"
Be timely — don't let PRs sit for days

Real-Life Analogy

Code review is like a flight co-pilot checking the captain's work. The captain is skilled, but a second pair of eyes catches fatigue-induced mistakes. Neither pilot feels insulted — both understand that review is about safety, not trust.

Visual Architecture

flowchart TD PR["📋 PR Opened"] --> ASSIGN["👥 Reviewers Assigned"] ASSIGN --> READ["📖 Read Code"] READ --> COMMENT["💬 Leave Comments"] COMMENT --> DECISION{"Decision"} DECISION -->|"Approve"| MERGE["✅ Ready to Merge"] DECISION -->|"Request Changes"| REVISE["🔄 Author Fixes"] REVISE --> PUSH["Push Updates"] PUSH --> READ style PR fill:#0f3460,stroke:#53d8fb,color:#53d8fb style MERGE fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb style REVISE fill:#1a1a2e,stroke:#ffd700,color:#ffd700

Why It Matters

Bug prevention: Reviews catch bugs before they reach users.
Knowledge sharing: Reviewing code teaches you how other parts of the system work.
Mentorship: Senior devs teach juniors through review feedback, and vice versa.
Consistency: Reviews enforce shared patterns, preventing the codebase from becoming a patchwork.

Code

bash

# ─── As an author: request review ───
gh pr create --reviewer senior-dev,teammate

# ─── As a reviewer: check out the PR locally ───
gh pr checkout 42
# OR
git fetch origin pull/42/head:pr-42
git switch pr-42

# ─── Run the code locally to verify ───
npm test
npm run dev   # Check the UI manually

# ─── Leave feedback on GitHub ───
# - Line comments: click the "+" on any line in the diff
# - General comment: write in the conversation tab
# - Approve/Request Changes: submit review with verdict

# ─── As an author: address feedback ───
git add .
git commit -m "Fix edge case per review feedback"
git push
# The PR updates automatically

The Reviewer's Checklist

✅ Check	Question to Ask
Logic	Does this handle null/empty/edge cases?
Naming	Can I understand the variable/function names without context?
Duplication	Is similar code already in the codebase?
Tests	Are the tests meaningful (not just happy-path)?
Security	Any inputs unsanitized? Secrets exposed?
Performance	Any O(n²) where O(n) would work?
Documentation	Are complex parts commented?

Key Takeaways

Code review catches bugs early and spreads knowledge across the team.
Focus on correctness, clarity, security, and tests — not just style nitpicks.
Critique code, not people. Ask questions instead of demanding changes.
Review promptly — stale PRs slow down the entire team.

Interview Prep

Q: What is the purpose of code review? A: To improve code quality by catching bugs, security issues, and design problems before they reach production. It also serves as a knowledge-sharing mechanism, ensuring multiple team members understand different parts of the codebase.
Q: What makes a good code review comment? A: A good comment is specific, actionable, and kind. It explains why something should change (not just that it should), proposes alternatives when possible, and distinguishes between blocking issues and suggestions.
Q: How do you handle receiving critical review feedback? A: Treat feedback as a learning opportunity. The comments are about the code, not about you. Read them carefully, ask clarifying questions if needed, implement the changes, and thank the reviewer for catching issues.