We’ve all been here. You’re looking for a new job, and you’ve aced a couple of interviews. They now ask you to do a take-home technical test, no worries you think, I’m a great developer.
Then you look at the test… It’s 10 hours worth of work. You cringe, you cry, you wonder if it’s worth your time.
It doesn’t have to be this way.
Now,
The first thing you have to ask, is why do programming tests exist?
Employers want to filter out those who present themselves well, but can’t live up to what they say. Understandably companies have things to do, they can’t risk hiring someone who can’t do the task they’ve been hired for.
Okay but, why do programming tests suck?
They can just be bad tests.
They may take too long to complete, or ask for skills or experience irrelevant to the job. Do you need to understand pointers as a JS developer? You may be the type of person whose blood pressure, and anxieties hit worrying levels when you walk into an interview.
How can we improve tests?
No test is perfect, infact, nothing is. But I’ve compiled four ideas which should guide you in the right direction if you’re ever tasked with having to administer a technical test.
In brief, the test should be as short as possible, it should be clear with what you’re aiming to figure out, it should be contextual to the role, and you should be willing to provide feedback to applicants who pass, or fail.
Tests should not take more than an hour
The longer a test is estimated to take, the bigger drop off you’re going to have from applicants. How many people would be happy to deliver a ten hour programming test, versus a thirty minute test?
Notably we’re adults, we have our own lives, and responsibilities outside of work. Not every person has so much time to spare, or is willing to sacrifice a Saturday just to prove their skill for a job they may not get.
Furthermore, a well designed test is a great indicator of your company’s engineering strength. Remember as an applicant, you’re interviewing the company as much as they’re interviewing you.
It should be clear what is being tested
When the applicant receives your test, that last question they should be asking is ‘why are they wanting me to do this’?
I’ve applied for a React web role, and been given a React-Native test before. Luckily i’m skilled across both domains, and at the very least it’s both React. But my knowledge of managing .plist, and .xml build schemes for debug, and release aren’t relevant to the web. So why am I being tested on that? It showed me that the company in question hadn’t put effort into their hiring process.
Your test doesn’t need to have ambiguous meaning which only you’re privy to. If you want to see the code quality this developer can produce, state that on the test. If you care more about someone who can just get things done rather than keep code quality high, state that. Honesty is the best policy.
Being on the same page around what is being tested for is only going to improve the results, and stop applicants from wasting time on details which you don’t care about.
What are you wanting from this applicant?
Do you want to see how reusable they can make their code? How well they can architect a codebase? If they can separate concerns between different problems? You should be testing clearly against that.
The test should be contextually relevant to the role
If you want someone who can knock out BAU work day-in, day-out, why would you give them a test where they need to create an application from scratch? They may have never been in that situation, and if it’s not relevant to the job they’ll be undertaking, why put them in that situation?
One size doesn’t fit all, one test doesn’t fit all.
If you need a BAU bug basher, provide them a test where that’s the aim. We’ve all heard stories of developers going into interviews having to traverse a doubly linked list, or some other obscure data structure. What does that really test?
If you think it’s testing how well someone will fix frontend bugs for example, you’re only lying to yourself.
You should receive clear feedback regardless of how well you did
You have asked an applicant to take time out of their day, night, or even weekend to complete this test, the least you could do is give them feedback on how they did. Not only does this pay it forward, and help the developer improve. It will leave them with a good impression of your company, and potentially have them retry in the future when they’ve improved.
Even better, taking feedback is a core part of our everyday life. Few PRs make it into development without at least one comment. If the applicant struggles with taking feedback that’s showing you that they may be difficult to work with. And the opposite is true, someone who takes that feedback well shows they could be great to work with.
You don’t have to have a programming test.
Not every company does, your company may not need to.
If you’ve come across a developer who culturally fits in with the team, and displays a massive passion for programming. What do you need to test? And what can’t you teach them, or they themselves?
Every passionate developer will be willing to try new things, or learn a different discipline. It’s what keeps programming interesting, and the developer passionate.
In my latest role, I wasn’t given a test to do. Even during the interviews I wasn’t quizzed extensively about my technical know-how. I just had the interviewer ask me about the project I was coming off, and walking through what it was, and how it worked. Easy, I’m staring at this project day-in, and day-out. Ask me anything, I could traverse this codebase with my eyes closed at this point.
And that was it, I was hired. From that they ascertained that I understood what I was doing, and why things were the way they were. They could tell I’m passionate about the craft, and that I’m hungry to learn more. Which is exactly what i’ve been doing in the role. My passion for development has even transcended it into writing short blog posts about my experiences, and technical know-how. From that they could figure I was someone they wanted to work with, and had the passion to do anything I set my mind to.
I’ll leave you with this question. Are you sure you need a test?
Conclusion
Did you have to do a technical test for your current job?
What do you think makes a good test?
What do you think about not having a technical test?
