Take-home interviews

> Problem the 1st: how do you verify the example project is actually the candidate's own work?

Get them to talk about it in the interview

> Problem the 2nd: building and maintaining a non-trivial open source project is a huge investment of time...

Not really - in one weekend you probably can create something interesting and good enough for showing off to an employer. Also it will probably draw you in and you spend more time (for the fun of it) making it better. But you don't have to.

For those people who prefer FizzBuzz tests to implementing interesting stuff, I suggest companies provide the option to do a test for those who don't want to submit their project code.

> Good luck with that co-ordination problem.

A first stage could be that we say "no tests until at least an interview has occurred and the candidate has progressed to the next stage". That is in any candidates own interests regardless of other's actions - so wouldn't require coordination, just communication of the idea. It is in his own interests because the time spent on the speculative work could be better yielded doing something else, such as attending a meetup and generating more opportunities. Looking at it from a sales perspective of how to spend your time - lead qualification, lead generation etc. Why spend a lot of effort on an unqualified lead?

If you're interviewing with 20 companies, you're probably already spending 4+ hours with each of them in person.

That's a lot of companies to entertain! When I was interviewing, I could barely maintain the composure to interview with 3 companies! (Only one of which had a take-home assignment.)

>"Why should I program for free at home, my resume clearly shows I am already a skilled programmer. All this will do is cater to young people without families, or those fresh out of school".

I share this opinion, but only for certain ways of doing it. If it's done in a fully automated way, before even having a phone screen, then it's too easy to waste my time. As an alternative to the whiteboarding interview, however, it could be great.

I've been giving applicants home assignments for years now, in 3 companies. I do it as a third step, only after a phone screening and at least one personal interview (that might include some very very light whiteboard coding, but will touch a lot of technical stuff), and only if I find the person to be right for the job.

So out of dozens of CVs, a handful will be invited to a personal interview, and maybe one or two people will actually get the home test. I get that it's time consuming so I try not to waste people's time if I'm not serious about them. On a couple of occasions when people said they're time limited, interviewing for a lot of places, etc - I've allowed them a one hour on site task that is of course simpler.

And it's very rare that people are rejected based solely on the code in the home test, it usually has more factors than that. But if you have two good candidates, it might help tip the balance in favor of one of them.

BTW I don't only review the code. I find that the quality of the documentation (not only comments - I ask for a short text describing the design choices, code structure, etc) is usually one of the best signals. Bad grammar and poor language, complicated descriptions of simple things, focusing on unimportant parts - are huge telltales of problems in a person's thinking. Clear, well versed, concise text usually indicates a smart and pragmatic person.

Wow, that's pretty awful. I might posit some rules for good take-home tests:

1. A very loose time limit. Maybe, as a rule of thumb, at least 10x the time you expect the challenge to take (so, a 1-hour challenge is given a 10-hour limit to turn it in, and a 5-hour challenge is given two days). If you expect it to be done in real time, why they heck don't you just bring the candidate in for a normal interview?

2. If the challenge is expected to take more than, say, 5 hours, the candidate should be paid for their time. Long challenges are going to disincentive candidates with lots of good alternatives to your company, so compensating them as in your own interest if you want good engineers to make it through your process. Plus, it's a strong signal that you value their time.

3. The challenge should be as close as possible to the sort of thing you do day-to-day. This should be obvious, but don't ask math questions or graph traversal questions unless this sort of thing comes up regularly in the job you're hiring for.

4. The candidate should be given an opportunity to discuss their solution. In real-life code, a seemingly stupid decision is may well be totally justifiable, but not obviously so from the code itself.

5. The candidate always gets an explanation of why they were rejected. At one company I worked at, I was in the position of reviewing takehome tests (which were one component of a longer process which involved some on-site coding). I had to write those explanations, and I know it's hard. It's easy to say "your skills are not a good fit at this time", but it's hard to tell someone you don't know what's wrong with something they put a lot of work into. It's still worth doing.