Technical interviews often come in a variety of flavors and I thought it would be interesting to list as many as I can think of and my thoughts on each one. In general I think there’s value in each type of approach but some are going to be more appropriate than others depending on the person’s experience and role.

• Brainteaser. These are seemingly simple problems that require a trick or insight to get them right. If you’ve heard it before or are familiar you can blow through these otherwise you’ll need to rely on a series of hints to get to the final answer. Probably not the best way to judge someone’s ability since it’s likely removed from the work they’ll actually be doing.
• Data structures. A bit more legitimate than the brainteaser approach this question digs into your knowledge of data structures. These usually start with some sense of complexity and then end up in implementing some type of traversal or tree search. The theory and knowledge of these is important but it’s pretty rare to have to implement a low level data structure.
• Architecture. This moves higher level and asks you to think about designing a larger application. How would the various components look? If it’s a service what endpoints would be exposed? What are the arguments and results for each of the calls? How would you scale this? What if you needed to make changes? These are a useful way to see how someone thinks and whether they have some familiarity thinking through the architectures of large and complex systems.
• Technical. Depending on the domain this gets into the nuances of a language or technology. These range from a rapid fire style that’s asking for descriptions of various HTTP status codes to a deeper dive into the TCP/IP protocol to discussing high level networking or the nuances of particular language or application versions. The goal here is to quickly get a sense if the person knows what they’re talking about or whether there’s only a superficial knowledge. Used alongside some of the other approaches this is a solid way of gauging the accuracy of a resume.
• Code test. This is the typical code test where you’re given a problem, a computer, and a time limit. Hopefully the problem is simple enough and offers a variety of implementation options that allow you to see the thought and decision process. The most successful ones involve introducing the problem and making sure everyone is on the same page and an occasional check-in to answer and address any questions. The difficulty here is that not everyone can code in a high pressure environment and you may be missing out on a lot of great people that are strong coders but don’t do well on code tests.
• Pair programming. A variation of the code test that tries to make it a bit less stressful is to do a pairing exercise where you’re both working on a problem and bouncing ideas off of one another. The goal is to have the candidate do most of the coding and you act as a sounding board since you do want to get a sense of the person’s coding ability. This also serves the benefit of showing you whether you’d get along since it’s a quick glimpse into how you’d work together on the same project.
• Feature addition. This is working with someone on the production code to build out a simple feature. Pair programming is usually done on a predefined problem but this takes an actual problem you’re working on and turns it into a pairing exercise. I haven’t seen this done much since it usually requires a ton of context to ramp someone up to your codebase and every person ends up with a different experience. Nice in theory but I don’t know how well it works in practice.
• Unit test fixing. I’ve seen this done a few times and it’s usually set up as a fully written project with a few broken unit tests. It’s your job to go through the underlying code and fix it to get the unit tests to pass. I like this one since it tests something everyone needs to do - go through someone else’s code, understand what it’s trying to do, and make some enhancements without breaking the existing functionality. This requires a fair amount of setup work, especially if you need to support multiple languages, but it’s a great way of testing the skills any developer should have.

The goal of every interview is to make sure the person you’re interviewing will be successful at their job. The best way is to give them something that’s as close to the job itself as possible. If they succeed it’s likely they’ll be able to do the job itself and if they fail it’s likely they wouldn’t be able to cut it. The implication is that you need to structure your process to optimize for this. No single one of these will tell you everything you need to know so it’s important to mix and match to find the combination that gives you the most confidence in your process.