I recently wrote about job hunting in today's tech landscape (mainly development) and shared my experiences, tips and tricks. Following on from that article and several discussions with ex-colleagues and other friends who are now in a job hunting position, the topic always drifts back to one stage in the hiring process in particular: the dreaded technical tests...*queue the foreboding music*.
This got me to thinking: 'how relevant are tech tests in today's market, and are they still a useful tool to make a hiring decision?'
Photo by Helloquence / Unsplash
The problem with tech tests
At some point, someone decided that technical tests should be slid into the developer hiring process as a good measure of the candidate in question's ability to write some code in a relevant language - to gauge their technical knowledge.
The problem is, most tech tests don't seem quite thought through and can suffer from a number of problems:
- They're used as a sole (or very large bias) measure in the hiring decision
- They don't have good skills coverage or highlight language depth
- They're cursory at best
- They're too big of an ask
- They don't recognise nor measure other vital skills, such as empathy, communication or (sometimes) even logic and problem solving.
- They are unforgivingly strict and don't represent how it works in the real-world
When good tech tests go bad
There are other problems, of course, as with any process or its parts. But there are a couple of points in the previous list that I'd like to highlight as I believe they fundamentally undermine the very goal that tech tests seek to achieve.
Cursory technical tests
I've seen tests that were used in a full-stack development role and the test was to add some properties to a C# class, hook them up to a couple of text boxes on the front-end and have them submit to a form of some nature.
This particular test was limited to about 40 mins. More than enough time. But, more than enough time for what? To shove buttons on a form in .Net, POST the value and stuff it into some class properties?!
With such a simple, lightweight test on offer, you could argue that there's no point in having it. It barely scapes the surface of any level of skill beyond beginner C# tutorials and it takes up 40 minutes that you could have spent showing the candidate around, chatting about their approach to solving big problems or working in a team.
If you're going to have a test, make it relevant to the job's application and substantial enough to provide data that you're looking for.
Large-scale, unpaid projects
On the flip side to being too superficial come those tests that are so monolithic that they're practically projects in their own right. But if a bigger, meatier project-style test can eliminate the problems of a superficial one, that's got to be better, right?
Well, yes and no...
Yes, you should be able to see a lot more scope of what the candidate is capable of, but the problem with these test types isn't their size. The problem is that it is quite common to expect an applicant to spend many hours of their time for free to do them.
Yes, they're applying to you, for a job with your company, but the process is still a two-way street. Plus, they might be applying to several different positions and multiples of five or six hours of tests soon add up - especially when you're asking them to basically write a mini app for you for nothing.
Designers have often been placed in this position by prospective clients who are (however unwittingly) quick to undervalue their skills and time by demanding copious amounts of spec-work; work undertaken on a speculative basis that they might 'win the tender', 'get the job', 'nail the pitch'.
The design industry pushed back at this and the No!Spec website encapsulates this movement perfectly.
There's nothing wrong in seeing how someone works, but don't ask them to provide too much of their time for naught, just for the prospect of a final interview.
Focus placed on raw technical skills alone
Again, whilst the literal goal of a technical test is to solve a given problem, the underlying objective should always be to see how someone approaches a challenge, how do they work when solving a problem.
This knowledge should be gained largely from discussions around those very topics: projects they've worked on, scenarios they've found themselves in, and so on. The technical test is then free to back up and reinforce those discoveries, in additional to showing off some level of competence at the thing in question.
The hiring decision, for me, has everything to do with the following two qualities:
- How well will this person fit within our company - can we all work together?
- Can this person learn, develop and grow?
This can't apply to all industries, obviously. I wouldn't expect someone to be hired as a heart surgeon based solely on a plucky attitude and can-do spirit. But a seasoned developer with an analytical mind shouldn't be passed over, just because she doesn't know ReactJS.
This great (paraphrased) quote I found on Twitter sums it up:
'You can learn a new language/framework/whatever,
but you can't un-dick a person'
Strict test conditions exclude real-world practices
I've also seen (and experienced) tests with very strict rules to follow. These ranged from 'no internet access', to time limits not paired to the level of work required for the test, to crippling, prescriptive coding standards.
Yes, you need some sort of limits - time-boxing the test, for example - but by placing unrealistic restrictions on tests that otherwise wouldn't (or shouldn't) exist in the real-world, we narrow our view of that applicant in a real-world scenario.
I mean, who hasn't looked for help on Stack Overflow or referred back to a set of docs because they can't possibly keep the entire JestJS api in their head?
Where tech tests can help
Where they can help immensely is giving an overview, an objective assessment of a candidate's approach to problem solving and task management beyond literal attributes of their code skills - how they comment their code, or how efficient they are in writing functions, their coding style, etc.
They can highlight strengths and weaknesses in a language or a framework, or even an approach to a design pattern (SOLID, DRY), but the results of a technical test shouldn't determine the lone success of a candidate.
Good tech tests should be:
- Deep enough to gather the relevant data for which they exist
- Reimbursing the candidate for their time and expenses (for larger tests)
- Taken as a part-measure of a candidate's profile - not the final word
- Given fair boundaries within which to work, not confined to unrealistic rules
- Not viewed as the only indicator of a particular level of skill
Tech tests still have a place, but...
Technical tests have their place and can work well to round out the overall picture of a person , but they're a delicate balance to get right: big enough to be worth the effort; small enough to not consume the hiring process; designed to work well as part of the bigger picture.
And don't forget there are a bevy of other means to assess technical skill these days, whether it's a GitHub portfolio, NPM contributions, or websites worked on that can be talked through to highlight the decision making and development process.
Top comments (0)