I'm pretty proud of the interview loop we use at DefenseStorm: - First section is "pair programming". We try to replicate what coding on the job is actually l

I'm pretty proud of the interview loop we use at DefenseStorm: - First section is "pair programming". We try to replicate what coding on the job is actually like: you can whatever IDE/REPL/language you want and can use google to look up docs. Our problem is specifically designed to be a fiddly problem which leads to edge-case handling with no possible 'beautiful algorithm' answer. Once they get the first solution, they have to revise their code to support a new fiddly use case. One interviewer actually provides help: pointing out syntax errors and suggesting alternate approaches if they appear to be heading towards a dead end. Most applicants "succeed" - so we evaluate on how well they can keep their code organized and readable, how they respond to suggestions, and if they are easy to work with/good communicators. - Second section is code review. We give them several snippets of not-so-great code and ask what they would suggest we change before putting it into production. Does a great job of showing us where the candidate has depth of knowledge, and is a good approximation of a portion of the duties we expect them to perform. I was surprised to learn that very few companies do this - we find it extremely valuable. - Third section is a conversation about tool familiarity (can you linux/aws?), depth of knowledge in the various domains we use regularly and designing an architecture (indicative of developer seniority). This is probably the least remarkable section. Every section is set up so there are no gotchas and there are always multiple correct answers. I think we do better than most at minimizing the anxiety inherent to the interview process.