Software interviews are a mess.
Interviews are a stressful environment. That’s by design. At some point in your time in the job, you’re going to be faced with an impossible situation, and you’ll have to address it one way or another. The crushing sense of anxiety when you’re being assessed by your future colleagues is a genuine test of how you handle unpleasant situations. Some people walk into an interview completely unfazed - striding through with utter confidence that they’re the perfect person for the job. They’re the people you learn the least from. The ones pushing through an obviously unpleasant experience with a clear sense of tenacity - those are the times where you’ll get some real insight.
But for Developers - there’s a built-in sense of distrust towards potential new-hires. It’s seen as safest to assume incompetence, and work up from there. An unpleasant starting place, but an understandable one. Some people who make it through to interview with a perfect CV are genuinely unable to write even the most trivial code. And of the people who’ve honestly listed no relevant experience, some can be moulded into the most knowledgeable and reliable members of the team. So what’s the quick way to find out who’s the right person for the job?
The more time I spend on either side of the table - the more I become convinced that there isn’t a silver bullet. People are complicated. Great engineers can be stumped by simple logic puzzles, and a good cramming session can make anyone look better on a test. Everybody has a bad day sometimes.
The only method I’ve used that’s had any real success boils down to one goal:
Let them shine.
The process of filtering out those who obviously don’t fit the bill should’ve been done by running through CVs. Once you’ve got them in the room, give every person as many opportunities to display their abilities as you can. How you find out will vary depending on your needs and how your team works.
Personally, I’ve found my blueprint for a successful interview focuses on: Problem Solving, Logic and Applied Maths, Code, and Architecture. Demonstrating a decent ability on any one of these should at least have a solid chance of developing into a strong member of the team. Those can change dramatically based on your problem space and team makeup. If you’ve already got a stack of solid coders, you might need someone with a strong sense of design above all else, or if you’re a team of coders who’ve never run a server before, you’ll probably be after more interested in that person who’s been maintaing swarms of Linux boxes for the last decade. Don’t stick to the same checklist for every new hire. And please make sure they know what level of dress you expect - there’s nothing more awkward than being massively overdressed compared to the people interviewing you.