I stopped asking long ago about references, as they are totally irrelevant and there are other simple ways to find out if a candidate for a software development position would be a good fit in your team. Ask him to review first a short 20-lines code sequence, with different mistakes. Then ask him to write his own short code sequence, to implement some standard algorithm. And see how he reacts when he has his code reviewed by you or some other interviewer.
Table of Contents
1. Why this is Indeed an Ultimate Job Interview Test
- Unlike many other things, this is almost impossible to fake, or simply learn from books and pretend you experienced them for real at some previous job. Because this almost always comes up with a high emotional tag when we first have to deal with the process. It’s like your first date, or your first exam. It is always easy to detect in someone’s voice if he is emotionally involved in the process or not. All truly experienced people I know became soon enough emotionally detached.
- This is a very important step in someone’s life becoming truly professional. This tells you if your candidate already “grew up”, had the time to go through a “maturity” process, worked in a team with quality assurance standards at heart.
- Like extreme peer programming, peer code reviews are per se sensitive issues. A candidate already used to taking some distance from things that can be perceived as personal will surely fit great in your own group.
- Along with the overall process of creating a complex app in a team, with checkins and checkouts, the build phase and so on, testing your candidate on peer code reviews can prove for sure if he did this or not. And HOW he actually did it. But it doesn’t even matter at the end how much experience he had indeed doing this, as all you should care about is he does it well or not, if he demonstrates good practices and a positive constructive approach or not.
2. When Your Candidate is the Reviewer
Common mistakes a software developer may commit when reviewing someone else’s code:
- Spending way too much time on it. May look like he is trying too hard to find errors in someone else’s code. And you are also supposed to spend less time on other people’s code than on your own code.
- Trying to change someone’s coding style, when there are no such coding standards in the organization. Some people may call functions with each argument on a separate line. Others on a single line, when all fits nicely. Is there are no coding standards your company defined, doing it one way or another is just an acceptable preference.
- Making personal comments, even nice remarks such as “sorry I have to correct your mistake here”. It is verbose, not necessary (it must be understood this is your role as a reviewer, to try correct eventual mistakes) and may actually trigger a negative response.
- Making long comments, when corrections should be as short as possible, impersonal and straight to the point. Not nice for the reviewed person when he gets back a tone of comments. They may be just positive details, but they would rather appear as corrections. Try send rather a related email in this case, it looks better,
- Forcing the other person to actually implement your own alternative, which may bring no actual added value, it’s just a preference. You may just leave a neutral note in this case, but do not force or require a change of implementation unless you have serious justified reasons to do so.
- Getting emotionally involved. If you consider an issue important to you, better take the subject offline and discuss it separately. Code reviews are not a place for polemics.
- Making harsh insensitive comments. Always proceed in a diplomatic and detached way, never make fun if you discover a silly error and you are not a buddy to the other guy.
3. When You Review His Code
- Do this as last stage, and do it properly, to see how the candidate takes the analysis of his code and the eventual criticism. Keep it constructive and positive, and check his reactions. You can see from a mile a person already used to this, who does not take things personal and who demonstrates he cares for a good code, no matter how many people help create it.
- Later on, I always use to come up with a few traps. I will first try “correct” an issue which was right in the first place. To see if the candidate stands up for his own opinions, that he is not just a “yes man”, leaving bad code behind just to avoid confrontations.
- The second kind of trap is when you, as a reviewer, become at some point a bit too temperamental with an issue. Your candidate may have to deal at some point with peers not always keeping their cool. And it is important that your candidate be able to move past this, to not take it personal and actually help relax the tension, no matter who created it.