On Take-home Coding
The instant we got rid of our “take home exercise” at LinkedIn, we saw an increase in the number of qualified candidates engaging in our interview process. We seem to be going against the grain here, as many large companies seem to want a “take home coding exercise” as part of the process before candidates even move into a more formal interview. I’m here to hopefully stop you, the reader, from falling into this trap.
Noise, Not Signal
I totally understand the company side of this; take home activities offer a really effective way to get the candidate producing code which can be screened at the luxury of the company. You can save your already hired employee sometime by only interviewing people who have produced code that meets a minimum bar. You can even use this code during the on-site interview for follow up questions and diving deeper into the work in order to understand the candidate’s thought process. By raising the barrier to entry, you’ve also ensured only people who really want to work at your company will proceed with the interview process.
What nobody counted on was the Internet. For all the time spent on building a question, one quick post to a site like Glassdoor can remove all of the value the company hoped to gain from a take home exercise. Building solid, reliable, and consistently measurable take home activities for candidates takes a very large and constant investment of time. And all of this before a single exercise has actually come back to your company.
If the interviewer thinks the code is flawless, then the question is probably on the Internet in some form. If the code was absolutely terrible, chances are that the recruiter wouldn’t have provided the take home activity in the first place. This leaves everything in between, where an interview is still required in order to assess capability.
The Candidate’s Priorities
Things are even worse when one considers the other side of the interviewing relationship. Sending a take home activity to an engineer sends a very clear message that your company doesn’t value their time. “Please build for me this fictitious thing”, you say. “Complete this task, and we may let you talk to an engineer.” That’s a large hurdle to someone who doesn’t even know if they would really like to be a part of your company in the first place.
Passive candidates don’t have time, as they were quite happy with what they are doing currently(hence passive). These candidates often are spending their non-work time having families, pursuing hobbies, or contributing to open source projects. For these people, nothing is a bigger buzzkill than an activity that offers nothing to the candidate other than more of the same work they do.
Active candidates have the time. Since they are actively looking for a new opportunity, it’s safe to say there’s definitely more than one company they are talking to. In this scenario, asking the candidate to take 3 days for a coding activity is three days everyone else is actually talking to the candidate, assessing fit, and selling the candidate on the awesomeness of their respective companies. In these scenarios where an active candidate hedges their bets, take home activities rarely come back.
There are thousands of opportunities in our industry. When a company sends the “we don’t trust you, so prove yourself” email, that company gets mentally shuffled lower in the queue for both active and passive candidates alike.
The Work is Out There
It doesn’t have to be like this. Our industry has already built LinkedIn, Stack Overflow, GitHub, BitBucket, TopCoder, and hundreds of other places where people can show their work. As a recruiter or engineer, ask them for code they would like to share. If there is no public samples available or offered, then it’s worth sitting the candidate down with an engineer to perform a small directed coding task. Not only will the company get a chance to see the candidate’s development process, the candidate will have the opportunity to learn more about what it is like to work with the team.
As for me, I will likely pass on your take home coding exercise. I hope my work can stand on its own.
I’m more conflicted on this original piece in light of the pandemic. Interviewing against a dry erase board was already a bad measure; adding a remote code session just increases the number of things that can go wrong exponentially. That said, I think giving someone an activity they can perform in an hour and having the candidate share their screen is a suitable alternative. If you absolutely must give people take home exercises, for whatever reason, consider compensating them for their time.
This was rescued from the archives of the old felocity.org. As a result, many links in this piece were left pointing to archive.org destinations.