You are starting or run a high tech company and need to build software.
You read that the majority of software projects fail.
You are at ease with technology and maybe you wrote some code yourself, but the idea of doing it with others gives you the creeps.
In this article I'll tell you about a part of the recruitment process, not all of it. I'll focus on technical tests you can use to vet candidates and I'll show you which ones to prefer and which ones to avoid.
What a good test should accomplish
Good technical tests should create an experience that is as much as possible similar to real job tasks.
Bad ones resemble school exams and tests, and are unrelated to actual work.
The best tests give a candidate a feeling of what it is like to work in your company.
Tests should be as little stressful as possible. It's a way to tell candidates that you know that stress reduces productivity and quality, and hinders problem solving.
Tests to prefer
Work with us for one day
Have the candidate come to your office and write a piece of code you will actually use. They may do it with the help of a developer of yours or maybe the latter just shows around and lets the candidate drive. Possibly a mix of the two approaches is best. It's the candidate who should decide how much he wants to work autonomously and when he wants to ask for help instead.
In a real working environment you want people to find the mix of autonomy and cooperation they feel is more useful in a given situation.
The candidate is allowed to use internet, possibly their favourite IDE.
Candidates should be encouraged to ask as many questions as they want. The quality of their questions is one of the best indicators that they are good developers.
The piece of code to produce may implement a new function or it may solve an existing issue.
It's not important to build working code. You want to see how your future team member works and thinks.
Project assignment
It's about assigning a small project that may take 1-2 days to do. It has to be something found in a real working situation. It may be the implementation of a React component that can be used in a real project. Candidates work on their own, where they want.
Don't assign anything academic or algorithms actual developers will never write because they find them in software libraries.
Remember the rule of thumb to use here: it has to be as similar as possible to what developers do in your company.
If you won't use the produced code, assign a project the developer can add to her on-line portfolio.
If you want to give a longer assignment lasting 4-5 days, you should pay for it.
Interactive project assignment
This is a project lasting 1-2 days or a longer one lasting 4-5 days. It's about creating an application or a prototype you will actually use.
Your would-be co-workers will enjoy the flexibility of working when and where they want, but they will interact remotely with your team to get help and guidance.
Tests to avoid
Don't use psychometric tests. They are not work related and have nothing to do with the ability of a developer to solve coding problems.
You need to know that they can interact and cooperate.
There are introverts and extroverts. Introverts need to think before they can talk. Extroverts need to talk before they can deliver anything meaningful.
This is wonderful. They have completely different ways to approach problems. This makes for better collective problem solving.
You just need to make sure that you don't have to extract words from an introvert with a tooth extractor and that an extrovert doesn't need to babble for hours before talking sense. No need for any psychometric test for this. Just plain common sense.
To soothe your worries that a potential employee may not be able to interact, prefer to have her talk about times when she worked in a team, any type of team.
Never use a psychometric test or any test, for that matter, as a pass-or-fail gate to the next steps of the hiring process.
If ever a psychometric test is useful, its usefulness melts away as soon as it's used to get rid of as many candidates as possible. You need to find alternative ways to contain a flood of candidatures.
Don't use tests that assess numerical ability or similar ones. The school system is broken, but if a developer can code, she can count to 10 as well.
You need to carefully assess tests to be sure that they don't make people feel insulted. You want to convey the image of a company that respects employees because respect is motivating and motivation makes people productive and smart.
Timed quizzes
The candidate has to answer theoretical questions about programming languages.
No developer answers theoretical questions when doing actual work and not necessarily they need to know or remember the theory to be able to solve problems.
Problem solving ability in software is language agnostic. Good developers forget details about a specific programming language. They can easily find them when needed. They do so to make space in their mind to focus on problem solving.
This type of quizzes is timed. Developers have to answer questions in a very short time. Often it's 20-40 minutes. They are not allowed to seek for help or use the internet and they wouldn't have time to do so.
The difference with a real working environment strikes.
These tests make developers run. The running developer is one of the major predictors of failure in software projects.
Timed writing of small pieces of code
There is a small function to write and the applicant has to remember instruction syntax by heart. The function may be unrelated to actual problems or may be easily found in a software library.
A developer doesn't do this when actually working.
They use tools that remember and check syntax for them. If they learned syntax by heart, they would be very unprofessional.
When actually working, the most important activity a developer performs is not to quickly write a function, but to compare many solutions to find the one that is easier to maintain and less likely to cause problems later. Something a developer can't do when they have to churn out some code faster than a rocket.
Whiteboard coding
Forget the whiteboard. Nobody writes code on a whiteboard when actually working. The whiteboard can be useful to illustrate a solution or an architecture.
Puzzles
Google "interview puzzles" and you will be able to feed the candidate an endless list of them.
Nobody solves puzzles on the job.
What not to do
Don't assign any test before having talked to the candidate. Tests shouldn't be used to eliminate candidates before having seen them.
Never test someone you think has little chances, you would waste their time.
Never assign a test your employees wouldn't feel comfortable taking. You may even assign a test to one of your employees. If she doesn't pass it, you may not want to use it when hiring.
What to do
Always test and interview candidates as if they were already on board.
Try to use many tests, not just one, and ignore the worst results.
Use a mix of tests for candidates who are working or have a family, and a different one for those who have more time available.
Always let people know about the outcome.