Someone added you as a reviewer, and your first instinct is probably that they made a mistake: you barely know this codebase, and the author has been here for years. This guide to how to do your first code review starts from a different premise. You were asked because your read matters, not because anyone expects you to know everything, and the habits you build in the first few reviews decide whether review becomes a skill or a performance.
The short answer: Your first code review is a reading exercise, not an exam. Pick a small PR, read the description before the diff, follow the logic, and ask genuine questions wherever it loses you. Say plainly what you checked and what you did not. An approval scoped that honestly is worth more than a confident rubber stamp, and every review teaches you the codebase faster than writing code does.
You were asked because your read matters
The author has been staring at this change for hours or days, and they physically cannot see it fresh anymore. You can. That is the asset a new reviewer brings, and it does not require seniority. If the change does not make sense to you, that is data about the code, not about you: code that confuses a careful reader today will confuse the on-call engineer at 3am next year. Your job is not to certify perfection. It is to report, accurately, what the change did to one attentive reader.
How to do your first code review: start small
Do not make your debut on the 900-line feature branch. Pick small PRs deliberately, because size is the strongest predictor of whether a review is real: a 40-line bug fix you understand end to end teaches you more than an 800-line diff you skim. There is a social bonus, too. Lou Franco’s writeup on getting reviewed faster observes that small PRs get picked up quickly because reviewers grab them as mini-breaks between tasks. Be that reviewer. Small, prompt reviews make you the teammate whose name people are glad to see in the reviewer box, and they build your calibration one digestible change at a time.
Read the description before the diff
Know what the change claims to do before you check whether it does it. The description, the linked ticket, and the test names tell you the intent; the diff only tells you the implementation, and you cannot judge an implementation against an intent you never read. If the description is empty, that is legitimately your first comment, not an obstacle to route around. And if you can run the change locally, do: five minutes of clicking through the actual behavior grounds everything else you will say.
Ask questions as questions
Microsoft’s research on modern code review found that understanding the change is the top challenge reviewers face, seniors included. So “why does this need a lock?” is a contribution, not an admission: either there is a reason, which now gets written down where the next reader will find it, or there is not, and you just caught something. Ask genuine questions plainly, without dressing them up as verdicts or dressing verdicts down as questions. The author answering “why” in a thread is documentation being written in real time.
Lean on a checklist, not on nerve
You do not yet hold the team’s review standards in your head, and you do not need to. A code review checklist removes the blank-page problem: does the error path do something sensible, do the tests assert behavior rather than implementation, do the names say what things do, does anything touch data it should not. Walking a checklist beats staring at a diff waiting for insight, and after a dozen reviews the checklist moves into your head where it belongs.
Know what your approval means
Approving is not politeness; it says “I read this, and I am willing for it to merge on my word.” The empty thumbs-up that skips the reading part is review theatre, and it is the one habit that will quietly zero out your value as a reviewer. The honest alternative is scoping: “I reviewed the logic and the tests; someone else should check the infra part” is a perfectly good review, and saying it out loud is a sign of care, not weakness. Do that consistently and something compounding happens: every change you trace, every “why” you get answered, every checklist pass builds your map of the system. Reviewing teaches you a codebase faster than writing code in it does, because you see every part of it change, with the reasons attached. Your first review is the slowest one you will ever do. Your tenth will feel routine, and by then the team will have learned what your approval is worth.
Frequently asked questions
What if I do not feel qualified to review the code?
You were asked for your read, not your omniscience. A reviewer who carefully follows the logic and says where it loses them adds value even with less context than the author. Scope your approval honestly: say what you checked and what you did not, and ask someone else to cover the parts outside your depth. That is professionalism, not weakness.
Is it okay to just ask questions in a code review?
Yes, and it is more useful than it feels. Research on code review at Microsoft found that understanding the change is the hardest part of review for everyone, not just newcomers. A question that makes the author explain a decision often surfaces the bug, and the written answer documents the code for the next reader. Questions are contributions.
How long should my first code reviews take?
Shorter than you think. Pick small pull requests, read the description first, and give the change one careful pass instead of three anxious ones. Reviewer attention degrades after about an hour of continuous reading, so timebox yourself. A focused thirty minutes on a small PR beats an afternoon of second-guessing on a large one you were not ready for.
