Take home interview programming tests

A few times in my career I've been invited to perform a take home programming test as part of an interview process.

So far, every time I've encountered this I've gone through a similar thought process that starts with me being initially open to the prospect and ends with me withdrawing my application before writing any code. My reluctance can be split into a few different points.

Every time this has come up, I've already been employed and have just been assessing the market for growth opportunities. Obviously, if you're unemployed with no savings and have bills to pay then the balance shifts a lot, but in my case "I'm not interested in this job after all" has always been a perfectly acceptable outcome.

How long is this going to take?

It's obviously a bad sign if a company expects you to work for free, but I think most of us would agree that up to two hours of work is not completely unreasonable (assuming that it cuts out two hours of interview time).

So far I haven't been asked to produce a piece of work that would take up to two hours. Or anywhere near that. They've all been in the 15+ hour range, requiring some kind of full application touching many dependencies to be developed from scratch.

That's not reasonable at all.

What am I actually being assessed on here?

The implied criteria of assessing the test is that the candidate produces some 'sensible' code that does what it's supposed to. But without clear requirements, 'sensible' is a very subjective word.

Suppose there's an implied need for a data store. Am I going to get criticised if I use SQLite for speed of set-up instead of the full blown SQL Server installation that the employer uses? What if I decide that storage isn't really an important part of a demo application and just serialize to JSON and stick it in a file on disk? What about error handling; robust, production standard error handling can easily make simple blocks of code 3-4x as long as they'd otherwise be; if I skip this will I be opening myself up to criticism? If I implement it, will I be criticised for over-engineering?

Without clear requirements it's difficult to reliably produce a piece of software that does what it's supposed to. This is a basic tenet of professional software development. Usually, in real life, a lot of the requirements are implicit because of obvious real life constraints (e.g the customer's budget or current number of users, etc). But for a fictional scenario, assumptions are a risky thing to make.

So far, I'm yet to see a take home assessment that has clear requirements. If we need to start going back and forward to clarify the requirements, this firstly takes up additional time, and secondly implies the test isn't being administered to a professional standard.

How does this make me feel?

An interview is a two way process, and a mutual investment of time. The company invests its time, as do I. A take home programming test is not mutual. The company expects the candidate to put in time, but the company isn't investing in the process at all. If the company isn't investing its resources into hiring a candidate, why would the candidate feel that pursuing the matter further is an effective use of their time?

A candidate's motivation for entering an interview process is to determine if they want to work somewhere. "Go away and spend a few days on some fairly basic CRUD application code" isn't adding value to the candidate. They're not gaining any more idea of whether they want to work for the employer or not. For them it doesn't move the process forwards at all.

Final thoughts

I think my thoughts can be summarised as follows: A take-home test is a very one-sided thing. While I could invest a lot of time into it in the hope that it might result in an offer, 1. It might not, and 2. I don't have much guarantee at this point that such an offer is likely to preferable to my current circumstances.

For me, it's never made sense to progress further.