There have been a lot of article on why technical interviews don’t work lately. This problem is as wide as the variety of company recruiting developers.
The CTO of a startup has the skills to figure out if candidates are good enough but not much time to do so; a recruiter can spend more time with them but will needs an automated tool which for now narrows to multiple choice questions and small coding challenges.
Still, the technical interview is a primordial step for hiring the right person. Unlike other professions, you can’t rely on a resume to hire a software developer : doing so, you would risk missing out great self-taught developers and in this industry you cannot afford false negatives anymore.
Technical interview methods today
Written tests
This might concern a small part of the industry but I’ve seen it several times in big corporations. Those tests ask candidates to solve little coding problems on a sheet of paper, and are corrected by recruiters with no coding skills. No need to tell you why it is the worst method I’ve ever seen.
Multiple choices questions
This solution has the advantage that you can make a candidate take a test remotely.
Besides that, I don’t like it for a simple reason : most of the time you test only very theoretical knowledge, and this is useless.
Online coding challenges
As for the latter, those can be taken remotely and they provide with very clear scores, along with actual code written by the candidates.
The problem is in what you test the developers on : usually algorithmic problems that allows you to see if they have some logic sense, not if they actually execute and work well on real projects.
Whiteboard
The classic method which is interesting if well used. I don’t see the point in making a candidate code on a whiteboard when there is a computer around, but discuss on design patterns and other choices of development on a project makes sense.
Unfortunately, this method is heavily time-consuming for your engineers.
Code Pairing
As for whiteboarding, it can be useful depending on what you offer the candidates to work on. And as for whiteboarding, it is still time consuming.
Exchange on one of the candidate’s side project
This is the most common piece of advice we see nowadays; and indeed if your candidates can show you side projects, you will be able to discuss on both product and code, review the choices they made, and see how they act when they’re excited by a product.
I would definitely recommend it but to me it doesn’t substitute to a technical test, it is merely the logical transition between the technical interview and the step where you check if the candidate would fit in your team and company.
Work on a short term contract with the developer
Obviously this method works if you can afford it.
But there are a lot of limitations : the developer must not have a job already, agree to spend a few weeks working with you, and it probably only works for one applicant at a time.
What would the right product do ?
Being given that all the methods listed above have big flaws, that was for us the question to answer. We wanted to create a product that :
- could determine if the candidate can work on a project in a given language/framework (read existing code and documentation and write clean commented code)
- could determine if the candidate is good at problem solving
- would not be highly time consuming
- would be usable by someone without high technical skills
At this point, if you would have put any other bullet point in this list, I will welcome your suggestions with interest.
So we built Staffit
Work in real conditions
Our starting point was that the great majority of existing tests don’t analyze the developers’ performance on what they will really work on. As formulated in this recent article :
These problems are often stereotyped and dull. For example, an ‘easy’ problem might be to convert a string of Roman Numerals into an integer. The average team might solve this somewhere between 10 minutes to a half hour.
The problem using these questions is that they don’t correlate to what your company is doing. By answering these problems, I have only demonstrated that I understand the trick.
So that with Staffit, we allow you to see what developers are worth when they work on projects, on their machine and with access to their usual ressources (ie Stackoverflow, Google, pretty much anything…).
Corrections with peer assessment
It’s pretty easy to make a candidate work on a project but once it’s done, automate the correction is the hard part. Plus, you haven’t seen his ability to review code.
To solve this, we decided to try something unique : use peer assessment inside a recruitment process. Peer assessment is a system mainly used by MOOCs such as Coursera or OpenClassrooms that lets the students assess each other while still getting an objective score. Here is how it works :
- You work on a project with features to implement and bugs to fix
- Once done, you are facing with 3 work results on the same project. You have to grade them on different points, with a given marking scheme, and for each point 3 possibility (bad, ok, great).
- Your way to grade impact your score : you have to show your ability to review code and learn from it.
The amazing thing with peer correcting is that the score given this way can more objective than if a teacher had given it. If this subject interest you as much as us, here is an article of a research team at Stanford that explains this result in details.
Try it yourself !
The first tests on this system on staffit.co have started and we are eager to share with you our first results !
You can try it by yourself, our service is free for now, we already have dozens of tests and we could implement yours if you contact us.
We are currently building our product and your feedbacks are more than welcome, you can get in touch with us at christophe@staffit.co or via @staffitrh .
