One of the most important but still ignored aspects of hiring a software developer is verifying how candidate is dealing with the code and whether is able to express their thoughts with particular programming language. Usually in IT recruitment we do it by asking candidate to write some code solving particular problem. Candidate can do it alone or as a pair programming with the recruiter (Hit the bull’s eye with coding tests in natural environment [case study]). We do it because writing code is one of the most important things developers do on a daily basis. However we should also remember that developers much more often read than write the source code. So we should not forget about verifying if candidate is able to quickly analyse and understand some code snippets. We can simply show some code printouts or (even better) give IDE with some project and ask questions related to what is happening here. That’s where code review challenge is really helpful.
How to verify candidates programming skills during technical interview?
Regarding what is said above we see that most of the time during technical interview/ assessment we spend on verifying if the candidate is able to solve some programming challenges or problems. Candidate is focusing on understanding and analyzing the problem and then finding a proper solution. However, we can realize that candidate is forced to think more about “what to do” than “how to do”. When we ask candidate to write a code which will be able to reserve a seat for a flight in some conditions, the goal is to ship the correct functionality, and mostly due to stress and time limitation it’s all the candidate is able to do. Is there any option to reverse this situation and let the candidate focus on “how”? Yes! For the many years when I was actively involved in IT sourcing and hiring developers or architects I was using code reviews.
What is code review?
Code review is a process when programmers verify each other code to find any potential problems, errors or deviations from best practices (if you want to learn more go to Wikipedia). For the last few years code review is a must-have element of the software delivery process. It gives us great auditability and better code quality but it also enables awesome knowledge sharing – people can now teach and learn at the same time, by sharing experiences. But I don’t want to convince you to enforce code-reviews in your development process (which by the way you should rethink if you’re not using it yet) but show you why and how to use code reviews during technical interview.
How can you use code review in IT recruitment process?
By showing the candidate code which is already written and works (mostly) as expected we let them focus on the quality of the solution. By asking simple question “So, what do you think about this code” we change candidate into read-only mode. What is important to mention is that some developers are used to such tasks which they take during exam certifications, etc. and they are looking up for some silly, intentional errors like missing semicolons, incorrect parameters, wrong classes, etc. In my opinion we should use different approach. I always used working code that compiles correctly. I emphasize at the beginning that there are no “certification-like” errors and candidate should focus on best practices, some common problems that are hard to be noticed by automatic tools and can cause serious problems of production.
Example of code review challenge
For example in Java that could be invoking thread.run() instead of thread.start() which compiles correctly, tests are passing but we’re not starting new thread which can degradate final performance. We can also check if candidate will notice that some transactional method is invoked outside of the transactional aspect, which can cause serious consistency problems in a database.
How to assess programming skills based on code review?
Based on the first candidate impression we can assess his/her approach to the quality. If for us the code is really ugly and full of issues and candidate says something like “looks good to me” we can assume he won’t help in improving code quality in our company and even will degradate it. It’s also pretty easy to assess the candidate experience. For example in some 60 lines source code junior developers were able to find around 4-5 issues. Developers with 8+ years of experience were able to find 10. And the best candidates were around 15-20 issues. The best candidate pointed me 2 issues I was not aware of, and when I was writing the code there were included over 30 problems.
What should we expect candidates to comment? The most important things are the issues mentioned above – problems that are common for particular technology and are not visible from the first sight. The next thing is the readability. The code has to be clean, well-structured and well-named so any other developers (not only the author) will be able to understand it and change it. So names of methods or variables – are they meaningful, not too long, etc. Are methods not too big and not containing too much logic. Are technologies used in the snippet good choice for solving particular problem (for example if our code is using string operations to build an XML we can expect candidate pointing out that there are many libraries which were created to do it in a better way).
Code review in DevSkiller assessment campaigns
At DevSkiller we believe that code review should be included in assessing programming skills. That’s why most of our assessment campaigns contain that kind of problem to solve. We also encourage companies to build their own coding tests that will include code review challenge. It’s pretty convenient for most companies as you can use your old code base to prepare such a task. Just talk to your IT department about this and include it in your recruitment process.
