For certain jobs, especially technical positions, replace pre-screening based on education and experience with a take-home test. This saves significant time and energy and allows you to engage with promising candidates faster.
But the most important reason not to pre-screen is that it removes a huge source of initial bias. Many incredibly talented candidates won’t have the education or experience recruiters are trained to look for. This not only means you lose out on great candidates, but you’re also going to be competing furiously for those few candidates that look good on paper — everyone else wants them too.
A take-home test becomes the first line of defense in filtering out candidates and requires the most work from your team given the volume of potential submissions. It’s also the first time candidates will get a sense of what your team does.
This stage is not only a critical hurdle to prevent you from wasting time on unqualified candidates, but also an extremely important part of selling candidates on the role. For all these reasons, you should continuously evolve this stage of your process as you gather data on candidate performance and interest through your funnel.
A sound take-home test should have the following attributes:
- Self-explanatory – You want to minimize the chances that a candidate will have questions or need clarification.
- Bounded – It should take no more than 2 hours for a skilled candidate to complete.
- Desensitized – It will be distributed widely, so don’t include any proprietary or sensitive data.
- Relevant – Match the problems to the top challenges you actually face in your job.
- Direct – Be clear about exactly how you want the test answered and how you will evaluate the performance of candidates.
- Gradated – Ask increasingly difficult questions so you can easily tell the candidate’s real skill level.
Finally, establish a clear framework for evaluating submissions. Consider these criteria:
- Correctness – Did they get the correct final answers?
- Logic – Was the logic in their answer sound?
- Assumptions – Did they make any assumptions clear?
- Code quality – Is the code executable, tested, functional, documented?
- Efficiency – Is the code concise and reasonably performant?
- Technology used – Are they using modern tools and libraries appropriately?
- Communication – Were answers clear and presented in a reasonable way?
Click to Add the First »