You asked, we’re answering!
In this episode, we dive into the most frequently asked questions about assessments!
5. Why use a technical assessment solution at all?
Believe it or not, most organizations don’t use a standardized technical assessment solution. A majority of organizations still rely on proxies for skill, like resumes or pedigree. Even worse, others rely on gut feelings.
The primary reason to use technical assessments in your hiring process is to create a more objective process for all candidates. You want to be fair to candidates and create an organization that focuses on skills and abilities.
If nothing else, implementing standardized, certified technical assessments also ensures compliance with the EEOC. If you’re not objectively measuring abilities, you’re relying on gut feelings and this could get you in trouble for creating a biased hiring process.
Other types of employment like CPAs, lawyers, and even hairdressers have to undergo some sort of official certification or licensing. Even though engineering is a highly technical job, this is not the standard. Here at CodeSignal, we hope to change that!
4. Why can’t I just use multiple choice questions in my assessment?
Usually, this question comes from non-technical folks looking to design a technical assessment.
We like to joke and say ask if you can measure someone’s ability to ride a bike through multiple choice questions? Sure it might seem like they know how to ride a bike because it’s easy to theoretically describe how to ride a bike, but that doesn’t necessarily mean they can ride a bike in practice.
Another example is a driving test. To get a permit, you simply have to pass a written test. To actually get your license, you have to take a real driving test behind the wheel and demonstrate that it’s not only in your head but you actually have the skills you can implement in practice. Same thing with technical assessments!
3. Will senior candidates actually take an assessment?
Many tend to think that highly experienced candidates might not like taking a test. BUT, this is a huge perception in the industry.
The culprit?
Terribly designed tests!
A lot of senior candidates have been handed tests that have nothing to do with the job. If you’re measuring basic skills that even a junior developer should have, yes, senior candidates are going to hate it!
You want to create tests that are relevant to the position and the actual skills needed for the job. This takes a little extra work but pays off in dividends! And more, the senior candidates will gain a lot of respect for your team and company for having a brilliant and effective way to find the right talent.
2. How should I build my test?
Who should build my test?
Should I have an internal committee that builds every single test?
Should I ask an engineer to come up with questions?
Whichever way the question is asked, the answer is the same. You should never build your own tests.
Test design is a real discipline that takes years of experience and expertise to develop. Expecting that internal engineers can create high-quality, non-biased tests will result in poor results. Think about it. Your ability to create a valid reading comprehension test is not related to your ability to read.
It also can put you in danger of compliance issues because they aren’t adequately trained on how to build unbiased, certified tests.
Test design is not Ikea furniture, it’s more like an airplane. You don’t want to assemble your own!
1. What should I look for when evaluating different technical assessment solutions?
Buying a technical assessment solution is not an everyday thing.
Understanding what matters and doesn’t matter can be complicated.
We believe there are three key fundamentals everyone should focus on when evaluating technical assessment solutions:
- Design
- Delivery
- Analysis
When it comes to design, you want to make sure your platform comes with professionally-designed assessments or expert consultation service. Simply providing a list of technical questions is not enough.
Delivery is about delivering a great candidate experience. You want to ensure that the tool you’re choosing can handle various types of technical skill measurement – UI, algorithm, SQL, DevOps, etc. It also needs to utilize the modern IDE (integrated development environment).
Finally, analysis is all about being able to put the candidate results into context. At the end of the day, you’re trying to understand a candidate’s abilities not just in comparison to the other candidates who applied, but to the holistic population. Evaluating candidates in your own bubble will always lead to subpar results.
This blog post is based on the twenty-fifth episode of the data-driven recruiting podcast hosted by CodeSignal co-founders Sophia Baik and Tigran Sloyan. You can find and listen to this specific episode here or check out the video version embedded above.