What your first code review at a software job looks like
On most teams, nothing reaches the main branch until another engineer approves it. Your first review can feel like a test, but it's a normal part of every change. This guide walks through what a reviewer looks for, using real review comments from Kadra sprints, and how to respond.
The pull request comes before the review
A reviewer reads your description before your code. A good one names the ticket and explains what was wrong. Here is the opening of a real commit message from Kadra's ECOM-114 ticket, where percent coupons were charged as flat dollar amounts:
“discountCents returned coupon.value * 100 for percent coupons, so a 10% coupon subtracted a flat $10 regardless of cart size”What the reviewer reads in the diff
The fix for ECOM-114 was one line. The reviewer checked that it fixed the root cause, that it left the fixed-amount coupon path alone, and that it matched how the rest of the file handles money:
if (coupon.type === "percent") {
- return coupon.value * 100;
+ return roundCents((subtotal * coupon.value) / 100);
}“Good catch reusingroundCentsto keep percent coupons consistent with howtaxCentsalready guards against fractional cents.”
- Correctness: does the change fix the cause, or only the symptom in the ticket?
- Scope: did you change only what the ticket needs? Reviewers notice unrelated edits.
- Consistency: does it follow the patterns already in the file?
- Tests: is there a test that would have caught the bug?
- Explanation: will the next person understand why the code looks like this?
Scope is part of the review
Small diffs are easier to approve because the reviewer can see everything that changed. On LEDG-208, where a payments helper converted dollars to cents with float math, the reviewer called out both the fix and its size:
“Minimal, targeted diff”
Blocking and non-blocking comments
Not every comment needs a change before merge. Reviewers often mark suggestions as optional. On LEDG-215, the reviewer approved the fix and left an idea for later:
“might be worth logging when a replayed transfer_id is short-circuited, just for observability into retry volume”
If a comment doesn't say whether it blocks, ask. "Is this blocking, or OK as a follow-up?" is a normal question on any team.
When the reviewer requests changes
Requested changes are routine, so treat them as part of the job. Reply to each comment, either with the change or a short reason you disagree. Push the fix as a new commit so the reviewer can see what changed since their last look, then ask for another review.
In Kadra, the reviewer also reads the grading check. While the hidden tests fail, it requests changes and points you at the failing tests. It only approves once they pass.
Review your own diff first
Before you ask anyone, read your pull request in the GitHub diff view as if someone else wrote it. Remove debug output, commented-out code and stray formatting changes. Most first-review comments are things the author could have caught in two minutes.
Questions people ask
How long should a code review take?
On many teams a reviewer responds within a working day. Smaller pull requests get reviewed faster, so splitting a large change helps both of you.
Is it bad if my first pull request gets changes requested?
No. Requested changes are a normal part of reviewing code, and senior engineers get them too. What reviewers remember is whether you responded clearly and fixed what they asked.
Can I practice code review before getting a job?
Yes. Open source projects review every outside pull request. Kadra gives you an AI reviewer on real GitHub pull requests, graded by hidden tests, so you can practice the full loop on your own schedule.
Try it on a real ticket
Pick a stack, fix a bug in a working codebase and get your pull request reviewed. Free during beta.