[gregrata]

I wrote a book on this:

https://www.amazon.com/dp/B07FJ6N8P1 (the book will be free tomorrow - would love for you to give me some feedback...)

Lighter-weight then this paper - just my experience in using different kinds of tech interviews, and what I found that worked the best for my team and company.

Some key points:

- Interviews should be as close to what the candidate will do in the job - if they'll be writing a lot of code, that's just basic algorithms - on a whiteboard - then whiteboard interviews are perfect. If they will be doing a full project and interact with others as part of that project, then do something more like that (For me, that's a take-home - with an emphasis on the interaction part, and how they go about creating software... not coding). Treat it like a project, not an interview quiz question.

- If doing the takehome, respect peoples time - it needs to enough be close to something they'd do in the job, but something that can be done in a handful of hours (and NEVER treat it like getting free work. I personally would love to be able to do a paid take-home, but haven't had the budget for it) The total expected time of the take-home + onsite should be able what they do for just a full on-site

- Understand that not everyone will have time to do this. Have a backup (my backup is "Project Day", which is on-site, but still about creating software)

- Try to do the same one for all candidates. At my last company, 80+ people ran though the same take-home. The team really started to get a sense of a good result and bad result.. and not JUST on code. What questions did they ask? How did they go about driving the project? What tools did they use?

- I did catch a few people cheating (after 80+, the code was out there, so not hard to cheat). LOOKING at someone else's project for this was ok (if you read the book, you'll see why). Outright copying was not. Part of the process is a friendly code review after the project is done - if the candidate wrote the code, they'll be able to talk to it, and have ideas of how to improve it. If they can't do that and don't see to know the code, they probably didn't write it... which was painfully obvious for those that tried to cheat.

Do what works best for your team and company. This worked best for me; I have yet to see whiteboard interviews be a strong indicator of someone being a great fit for a team, but I was able to build a great, happy, very productive team using this method.