Pull requests, merge requests, and code reviews. You’ve probably heard these terms before. A code review is the moment developers ask each other for feedback. A bugfix or new feature is finished, and before it can go live, someone else takes a look. Even if the change works functionally, there’s often room to improve it technically. At the same time, it’s the moment where developers show their choices to the team, so everyone stays up-to-date on what’s happening in the codebase.
For you as a junior, a code review is even more than that. It’s your chance to be coached. A colleague walks through your code and asks why you made certain decisions. Sometimes you’ll get tips, sometimes you’ll be shown what’s missing or could be done differently. In short: for your learning process, this might be the most valuable step.
And don’t forget: a code review is not a one-way street. You can give feedback to your senior colleagues too. The beauty of this is that you get to read someone else’s code, try to understand it, and form your own opinion. A win-win situation. In this article, I’ll walk you through how to approach a code review in the right way.
Code review mindset
Before you start a code review, it’s important to understand why you’re doing it. Many developers see it as a stage in the process where you just look for mistakes in a colleague’s code. A better mindset is: I want to learn. You want to understand what another developer has built and see if you would have made the same choices. If a choice is different, you want to know whether one of you missed something, or if it could genuinely be done another way.
With the right mindset, you focus more on collaboration and understanding the context of the new code, and less on spotting errors. When you truly understand the context, potential mistakes will stand out naturally.
What to look for during a code review
usually approach a code review systematically. In my head, I tick off imaginary boxes, once everything is checked, the review is done. As a junior, you can follow the same approach, but I’d suggest fewer boxes. Instead of reviewing the content like a senior might, you can focus on code style. That’s your strength and where you can add real value.
- Readability & naming: Pay attention to how readable the code is. You can judge this without deep knowledge of the code itself. Are variable names clear and following the agreed-upon rules? When you scan the code, can you roughly understand what’s happening, or is it a black box? Readability is crucial when collaborating, everyone on the team should be able to understand the code. If you find the code hard to read, that’s something to point out in a review.
- Consistency: Consistency isn’t about the content, it’s about style. Does the new code fit with the existing codebase? Are different techniques used in other components? Does something feel out of place? Is the indentation different? All these points are fair game for a review, especially if you feel hesitant giving in-depth technical feedback.
- Unnecessary complexity: Take a slightly deeper look. Is the code more complex than it needs to be? You might notice this through deeply nested if statements. If something feels overly complex, let your colleague know that breaking it into smaller statements could improve readability. If you’re nervous about making recommendations, simply point it out without suggesting a solution.
- Duplicated code: Again, this isn’t about the content, but about styling and best practices. Does the new code repeat itself unnecessarily? DRY (Don’t Repeat Yourself) is a core principle. Mention duplicated code when you spot it.
- Documentation & comments: Is there documentation or comments, and are they clear? Read through them and share your thoughts. Code comments exist to show everyone what the code does, so if you don’t understand a comment, it’s likely not helpful or accurate.
With these five points, you can already add a lot of value to any code review. You may not be evaluating the content deeply yet, which is okay, but focusing on readability and style already makes a difference.
Don't worry about everything yet
It’s completely normal that you’re not focusing on everything yet, and nobody expects you to. Here are a few areas you don’t need to be strict about in your first few code reviews:
- Performance optimizations: You don’t need to judge whether a piece of code is “fast enough” or the most efficient solution. Micro-optimizations, like rewriting a loop or changing a data structure, usually only matter when there’s a real performance problem. As a junior, it’s perfectly fine to ask, “Is this efficient enough for our use case?” but don’t feel pressured to come up with the perfect solution yourself.
- Architecture and design patterns: Whether code belongs in a particular design pattern or layer of the application is often a matter of experience and context. You don’t need to decide if this is the perfect place for a function or module. What you can do is notice when something deviates from the rest of the project and ask a question about it. That’s just as valuable as suggesting a change.
- Business Logic and domain decisions: Sometimes you simply won’t understand why code is written a certain way, and that’s fine. You don’t know the full business context yet. Instead of criticizing, use it as a chance to learn. Ask questions like, “Why are we doing this this way?” or “What would happen if we approached it differently?” This shows that you’re thinking along, without pretending you have all the answers.
But if something about these areas does not feel right, just ask. Questions are part of learning and always welcome.
How to give feedback
Giving feedback during a code review isn’t about being right, it’s about collaborating. The way you deliver your feedback makes all the difference. Treat it as a conversation rather than a judgment. Instead of saying, “This is wrong,”you could ask, “Why did you solve it this way?” This opens up space for explanation, and often you learn something yourself in the process.
How you phrase suggestions also matters. A comment like, “You have to do it like this” feels like an order and can create resistance. A better approach is: “Maybe this could be done in a separate function, what do you think?” This invites your colleague to think along with you rather than feeling corrected.
Don’t forget to point out what’s good as well. If something is clever or neatly written, acknowledge it. Even a small note like, “Nice solution!” balances your feedback and ensures it doesn’t come across as only criticism.
Conclusion
A code review isn’t just a task to tick off, it’s an opportunity. As a junior, you don’t need to know everything. By focusing on readability, consistency, and simplicity, you already add value. Ask questions, give feedback, and embrace the chance to learn. Every review helps the code improve, and helps you grow as a developer.