I've been pretty involved in the hiring process at the startup I currently work at. Our process works like this: 1) Phone screen of roughly 30 minutes. 2) Cod

I've been pretty involved in the hiring process at the startup I currently work at. Our process works like this: 1) Phone screen of roughly 30 minutes. 2) Coding challenge. There are a couple different ones you can work on, such as exploring and scraping data from an HTTP REST API programmatically, building it into a report and submitting it to a different endpoint, or slightly more complex one that involves reading raw socket data to download a video stream, validate it's checksums, and extract it. This is an offline challenge that candidates can do on their own time, using whatever tools, docs they want. But the point is that candidate's choose which one they want to work on, giving them some choice to pick the easy thing or the harder challenge, and send it to us as a sample of their coding style. 3) Assuming the challenge code they sent us wasn't god awful they can usually get an on site interview. During this interview they sit with a few engineers they would be working with and each engineer has their own type of approach to interviewing. Personally I have developed the following test that I find works quite well: https://github.com/nathanpeck/wordladder/blob/master/ladder.js https://github.com/nathanpeck/wordladder/blob/master/ladder.... One advantage of a code exercise like the one above is that you can go as deep as you wish depending on the candidate's skills. When interviewing a very junior candidate you can focus on their understanding of how to organize code, refactor it, and their knowledge of the basic JS toolkit. For someone more advanced you can get down into details like "Is this a breadth first or depth first algorithm?" or "How can this be optimized to make it more memory efficient?"