Technical interviews are a contentious topic, to say the least. It applies both as a candidate and as an interviewer. It feels that you end up sinking a lot of time into it, often with little to show for it.
More concretely, it seems that take-home coding assignments are becoming more and more the norm in the tech industry. Do you have opinions about them? I surely do! In this post, I want to talk about some practices I’ve observed lately that make companies look bad and poison the goodwill essential for a successful interaction between candidates and companies.
What is a Take-home Coding Assignment, anyways?
It’s a programming exercise that a candidate completes on her own time. Some examples are:
Building a small application from scratch. Fixing a provided application, or extending it with new functionality. Sketching the architecture for a system.
The main justification behind giving homework is that it allows the candidate to work at her own pace, without the pressure of an interview setting. Many candidates struggle to code live, and they sometimes get rejected because they couldn’t showcase their knowledge within the strict boundaries of an interview. Fair enough.
There is another benefit for the companies that they like to downplay: The candidate has to invest time, and the company doesn’t. Even if you discard the submitted code, it still counts as labor in my book. I’ve never heard of any organization that pays for that time, by the way. Let’s call it like it is, this is working for free. Being forthcoming and honest about this is crucial to design an exercise that gives the company the information they need without putting undue pressure on a candidate. Let’s go over some antipatterns that are sadly all-too-common.
Taking the Candidate’s Time for granted
If somebody is going to do some work for you, you have to respect their time. There are two aspects to it:
Deadline
Are you going to set a deadline of, like, one week without actually checking with the candidate? Great news, you just planned their weekend for them. I love when companies do that. I’m sure people with family commitments appreciate it.
Time Investment
How much time should you invest in it? Set clear boundaries. Is it two hours maximum, or two days? The candidate has no idea what you’re expecting. And I mean realistic expectations. Setting up an application from scratch takes some time, even if you have some sample code to help with the bootstrapping. The asymmetry of information will lead people to invest much more than what you had in mind.
A related point is reciprocity. How long are your engineers going to spend going over the code? I know for a fact certain organizations send out exercises that take multiple hours to complete. Then, an engineer might spend five minutes at best going over the code before rejecting it. That’s just demeaning. I mean, come on.
Putting this Step Way too Early in the Process
There is a balance here. As a company, you might have multiple steps in the recruitment process. You don’t want to set up a panel for somebody who can’t show any technical proficiency whatsoever. That’s understandable.
On the other hand, your responsibility is to explain the position well enough so that a candidate can make an informed decision. It feels silly to write this, but I’ve seen it happen. A company congratulating a candidate for having the privilege of taking part in this challenge. But they couldn’t bother to explain what the role entails. Let alone how the rest of the process looks like (another pet peeve of mine!).
Vague Instructions
A home exercise is not the place to show the world how smart and cunning you are. Be specific! Do you want to see tests? Say it so. You prefer a vertical slice that’s not production-ready, or do you want to see a smaller part that is finished? What is important for you?
Now, somebody will surely object to this and say that real-life problems are vague and that as a candidate you need to navigate unclear requirements. Then, do a proper coding exercise, where the candidate has the opportunity to ask questions and clarify the requirements. You went for the asynchronous route, it’s your job to make it clear and explicit.
I have the theory that some companies leave requirements vague to have plausible deniability to reject whatever they don’t like. Which I find terribly unfair.
Expect Over-specific Knowledge
Having been a consultant for some time, I’ve noticed that people in many organizations assume that everybody else has the same context about their problems as they do. Then, they design their challenge as if somebody who doesn’t know the deep details of an API is not worth talking to.
Are you sure you want to be that person? Are the finer details of SpringBoot’s dependency injection the difference between success and failure in your organization? Really? I find that hard to believe. I’ve been guilty of this myself, and I think the only thing it accomplishes is reducing your candidate pool. Unless you’re a big brand that can afford it, it’s likely not in your best interest.
Not giving actual Feedback
After having somebody invest their time in building something for you, you owe them some useful feedback so that they can improve their craft. In Germany, many companies won’t give feedback to candidates at all. Or if they do, it will be so soulless, generic, and corporate that it might as well be read in a robot’s voice.
I get that rejection is never easy, and it might expose a company to some liability. But seriously, giving feedback about source code ought to be doable. If you’re afraid of doing it, maybe your criteria are more arbitrary than what you’d care to admit.
In Summary, Empathy!
Are take-home coding assignments here to stay? I’d guess so. They bring some benefits, after all. When you’re setting one up for a position, keep one word in mind: Empathy. Show a bit of empathy toward the people that are considering your organization as a possible destination. Don’t assume infinite time, instant availability, or people reading your mind to understand exactly what you want. It really grinds my gears when somebody treats my time as if it’s worthless.
If not for general decency, do it for branding reasons. Good candidates have options. A thoughtful recruitment process is a signal that you’re better than other organizations out there that only want fresh meat in. I’m personally willing to listen a lot more when I feel that a company respects my time.
Thanks to Anna and Vicky for the feedback.
Top comments (0)