Here's the strategy we feel is working pretty well for us. First of all, our tech stack looks like this: Java/Spring(MVC)/MyBatis/Hibernate/etc Ruby/Sinatra/

Here's the strategy we feel is working pretty well for us. First of all, our tech stack looks like this: Java/Spring(MVC)/MyBatis/Hibernate/etc Ruby/Sinatra/ActiveRecord/etc JavaScript/Angular/etc A bit of SQL (MS) We look for candidates of all skill levels who have experience with any "systems" programming language (Java/C/C++/C#) and any scripting language (Ruby/Python/JS). Once we've found a candidate that has any level of experience with both a scripting and systems language, we send them a small coding project. The coding project is very easy. Any experienced programmer would be able to solve it in about an hour. We tell the candidates to solve the problem in any programming language and that the goal is to show off problem solving, testing and design skills. Once we've received the code, we review it for the above stated qualities with an emphasis on clean, readable and well-tested code. We're not too hard on these code reviews, we just want to try to eliminate obviously poor fits. People who write no tests are immediately eliminated. Hugely over-architected solution? Eliminated. Code is bad enough the person might not actual be able to program? You get the idea. Once the person has passed this stage, they come in for an in-person interview. They are asked to bring their laptop. When they arrive, the dev manager will show the candidate to the room where they will be interviewed, talk a bit and then come get two developers for a coding interview. The coding interview is somewhat on a per-candidate basis, but fundamentally the two interviewers will review the code beforehand and find places for improvement. Improvements might be refactorings to make the code cleaner or new features if the code is particularly well-written. We first have the candidate give us a code walk-through and explain what's happening, thought processes, etc. Then one of the interviewers will pair with the candidate for a while and switch out with the other interviewer after a while. The whole process thus far is an attempt to, as closely as possible, simulate what it would be like to work with this person on a real task. No writing quick sort on the white board. Writing code, at a computer, with an IDE as a pair. Google stuff, whatever your normal workflow is. We just want to know what it's like to work with you. After the pairing part of the interview, we do a more informal group interview with the rest of the team. We're currently 7 people counting the development manager, a scrummaster/QA and a PM/QA. So the group isn't too big. This is an opportunity for more high-level and philosophical questions. "Why do you want to work here?", "Anything in particular you dislike about Java?". Maybe if they're more senior, I'll have them explain OOP to our designer to see how well they can mentor. At the end of this section, we open it up for questions from the candidate. So far we've had particularly good success with 1) not wasting our time with people who can't code, can't test their code or are poor at designing the structure of their code; 2) finding good cultural fits - if someone doesn't like pair programming or TDD, we'll be able to figure that out as part of the interview; 3) not arbitrarily eliminating people because they didn't study their CS textbook ahead of time or aren't comfortable writing syntactically correct code on a whiteboard.