I’m sure at some point you’ve googled things like “should I do test tasks for job applications?” You’ve likely found tons of posts where developers vent about how much they hate these tests. Yet despite the backlash, companies like mine still ask for them.
I’ve worked as a dev for 12+ years and hired many myself for 8+ years. So I get both perspectives here. Don’t hate me yet, developers — hear me out.
Why We Dislike Test Tasks
These tasks take up our precious time with no guaranteed payoff. A proper test could easily eat up a whole weekend — time you could spend with family or on hobbies. There was a candidate once who declined our test task because of a family issue. Family comes first, and I respected his choice even though we really wanted to see his skills.
And in a lot of cases candidates already have a full-time job they’re trying to leave. Some candidates are working long hours to meet a deadline before leaving their current role. The last thing they probably need is an intensive project in eating up all of the spare time!
Adding insult to injury, most companies won’t even review your work or give feedback afterwards. Why? Because properly reviewing a test task takes time too! Reviewing ten projects can be exhausting when it’s repetitive. Our tech lead once had to review twenty test tasks back-to-back to provide notes before interviews started next week. He was bleary-eyed and exhausted by the end!
And let’s not forget — you’re doing this for free. Spending days working with no reward and a faint chance of a job? Not exactly a fair deal. I heard from one candidate who spent 30+ hours on a complex test project, only for the company to ghost him after submission. What a waste of his time and skills!
Here’s a question: do these tasks even prove the skills? They’re so limited compared to real work. We asked a backend engineer to build a simple API — impressive, but nothing like architecting a complete system. And you can’t stop someone from cheating or outsourcing them. A colleague once found out a candidate live streaming the interview, right on call, so that others could help him pass it!
Why Companies Love Test Tasks
First off, I respect when someone invests their time on a test for us. It shows real interest in joining our team. That matters more to me than the quality of their work. One applicant spent an additional weekend refactoring the task he already completed to use best practices — while that wasn’t required by no means, that told me a lot about his passion.
These tests also demonstrate your work style. We look at time management, communication, attention to detail — all vital skills. I once interviewed a candidate who met every deadline and kept me constantly updated — that reliability was so valuable! Many candidates fail at the basics like keeping in touch. Those aren’t people we want to hire.
Of course, we also look at your code. Yes, you could cheat or use AI. But we’d catch that in interviews when your skills don’t match up. I interviewed one applicant whose task looked perfect but they struggled with basic coding questions. Suspicious! For an honest candidate, a test reveals your practices, habits, and tech expertise.
Now don’t get me wrong — as I’ve said before, tests aren’t a silver bullet. We’ve had people ace them and still be impossible coworkers. One hire aced his test but constantly missed deadlines after joining. Worst of all, he failed to communicate with the team properly, which is essential when working remotely. We also had great hires who never did a test. But they can provide insights you won’t find elsewhere.
Why Not Live Coding Instead?
In my view, live coding interviews are pointless. Even Homebrew’s creator Max Howell failed a Google whiteboard challenge. Their own devs rely on his tool daily. I can’t imagine what they were asking him, but probably something that you almost never do in real life.
These interviews focus on algorithms and obscure language tricks you’d just Google anyway. They remind me of exams — study to pass, then instantly forget that knowledge. A friend of mine was once stumped by an algorithm puzzle in an interview. But he’s an incredible engineer who builds robust systems for a living! Coding tests are way closer to real work.
And have you tried live coding interviews? The stress level alone disqualifies most people. You need nerves of steel and a photographic memory. I bombed a coding interview early in my career too — the pressure got to me and I was failing to do even the basic things! I’d certainly fail one today — maybe you would too.
Striking a Balance
I still believe short paid test tasks have merits when done right. But for experienced devs, your portfolio of real work should suffice. No designer would apply without a portfolio, so why should a developer? One of our best hires showed us code from a previous project — no test needed.
Contributing thoughtfully to open source or showcasing previous projects demonstrates your skills in a real setting. If you have that, you shouldn’t need a test task. Walk us through a Chrome extension you’ve built — seeing your code in action will tell us everything we need to know.
But if you lack experience, some sort of assessment may be warranted. The key is for potential employer to keep it small, paid, and reviewed. After all, it’s developers hiring the developers — we’ve all been there before. I still remember my first development test as a junior — I was thrilled when the CTO wrote me detailed feedback!
What do you think is the best way to evaluate candidates fairly while protecting everyone’s time? I’d love to hear your thoughts! With empathy on both sides, we can figure this out.
Originally published on Medium.com
