Job preparationCode review
Code review interview questions and answers
What a review looks for, what makes a good reviewer, and how you fix bugs — the questions about working in a team.
Code review comes up even for junior roles now, because a company wants to know whether you will work alone or in a team.
What is really being measured here is attitude rather than knowledge: can you take criticism, and can you talk about someone else's code without being rude about it.
The questions
What is code review and why does it matter?
What to coverCode review raises the quality of the code and cuts down defects. It also builds collaboration across the team and creates a chance to learn.
How is the code review process carried out?
What to coverIt usually starts with a code submission — a pull request. Team members then examine the code and leave their comments and suggestions. Once the necessary changes are made, the code is approved.
What should you pay particular attention to during a code review?
What to coverThe quality of the code, whether it works, readability, security, and maintainability.
Talk about coding standards and best practices.
What to coverA coding standard is the set of rules a company or team agrees to follow. Best practices are the most effective established ways of writing code.
How do you become a good code reviewer?
What to coverIt takes close attention, detailed knowledge, critical thinking, and the ability to make constructive comments.
How do you analyse the performance of code?
What to coverWith profiling tools such as valgrind, gprof and perf.
What is your favourite programming language and why?
What to coverThis depends on your own preference and experience — but when you answer, name the concrete strengths of the language rather than only saying you like it.
Why do data structures and algorithms matter?
What to coverThey are central to how well and how efficiently a program runs. They give you different ways to approach a problem and to optimise it.
How do you go about solving a complex problem?
What to coverBy analysing the problem, gathering the data you need, choosing a suitable algorithm and data structure, then coding and testing it.
Talk about bugs and the bug-fixing process.
What to coverDebugging tools are used to track a bug down. Once identified, the code is corrected and then tested again.
If you were reviewing code, what would you consider?
What to coverAnswer with a list; it makes you sound organised. Does the code actually work? Do the names and structure read clearly? Is the same code repeated? Are inputs validated, and is there a security gap? Are there tests? And can someone else change this in six months? Most candidates never mention that last one, so keep it in mind.
How would you make code more readable and more efficient?
What to coverBreak the work into small pieces — one function, one job. Choose names that explain themselves so you do not need a comment. Cut nested ifs by returning early. If you have written the same code three times, make it a function. And for efficiency: measure where the time is actually going first, then work there — optimising on a guess costs readability and buys no speed.
Tips for this round
- Asked what you look for in a review, give at least five things — not just "whether there are bugs".
- Give an example of a constructive comment: what is wrong, why, and what could be done instead — all three together.
- Have a story ready about criticism you received on your own code. How you took it is the real answer.