Interview home coding tasks: my policy

In recent years there seems to have been a shift in interviews: less pairing exercises and more home coding tasks / projects.

After recent experience of home coding projects pre-interview, I’ve set a policy for my engagement in these tasks. I’m detailing it below, in part to avoid repeating myself to recruiters. Further down I give some reasons and discussion.

My home coding test policy

• I expect transparency around the existence of a test, and its conditions, as early possible
• Maximum one hour length for ‘fire and forget’ tests where I’m not guaranteed feedback or interview (and I expect that time limit to apply to everyone, otherwise, what’s the point?)
• Longer tests are possible but they need a set length¹ and to not be open-ended. I need guarantee of meaningful feedback and/or actual interview discussion after, depending on time I’m committing
• Don’t ask me to design features or code for your actual product

Discussion

There are alternatives to home code tests and we appear to be forgetting this. And I think they can be more informative in less time.

• Viewing applicant’s open source projects
• Have applicant talk about some of their open source code
• Do a code review
• Pairing session

The asymmetry of being asked to commit two or more hours before any interview (and without even getting any feedback or interview afterwards) is too much.

There’s also a question of fairness: longer home code tests significantly favour those with the disposable time to complete them.

Time creep

This is a dark pattern that is pretty insidious: getting a specification of how much time you should spend (typically low-balled), but there being an unstated expectation that you spend more time. This is a red flag to me. Why would they punish applicants for following instructions? Maybe not a company you want to work with.

War stories

With permission, here’s a few experiences from developers I know:

I once spent 4 hours on a “no more than three hours” take home exercise. Left a list of all the things I hadn’t done but would have given the time, and a section discussing any potential controversial choices I’d made.

Guess what the only feedback I got was?

I’ve had a few coding tests where it’s perfectly clear that the job does not involve coding at all, but someone used this for another role once and so it’s showed up in some other role’s process.

Special mention for the company that put me through 11 rounds of interview including a take-home coding test and a live coding interview for a non-coding role, before deciding they didn’t have the budget to hire anyway.

Last year I interviewed for a place that needed someone in a hurry. Like, it was Thursday, they wanted to interview on Monday. They said “We might give you some homework.” I said, “okay, I’ve got plans this weekend, but I’ll do what I can so long as there’s an understanding that I’m doing what I can in a short timeframe.”

Then, at 7pm on the Friday night, the recruiter drops a three-hour homework assignment in my inbox. Which I manage to mostly do on the Sunday in between other commitments, skipping only the last task, which was basically the same as the previous task. I figured “We can talk about my coding style and stuff in the interview, this seems redundant.”

The Monday interview went well, and then a couple of days later I get the rejection email. All of the feedback was about what I hadn’t done on the homework assignment.

• Dev
• Interviews