I’ve been through my fair share of technical interviews. Typically, they’ll ask you to complete a live exercise, provide code samples, or answer mundane questions about a particular language or framework. Generally, those approaches are useless. Even the most talented software engineers do not always remember how to implement hashCode(), the differences between various search/sort algorithms, or the most appropriate data structure to use for a specific context.
In my stint as a software engineering manager, I set out with all the typical “I can do this better” mantras. I won’t ask the stupid technical bits — I’d rather have someone who knows the right questions to ask and how to use Google. I won’t ask for a live coding exercise, since that’s so far from reality and folks are often nervous. I’ll focus more on how they’ve used specific technologies to tackle problems, what they’re proud of, their hobbies, communication skills, blah blah blah.
All that is well and good, but I found it missed critical areas: how well can this candidate critically think about design patterns, component design, the composition of components, governance, and working effectively in a team? I’d argue those skills are the most important to have, but also the hardest to gauge and discover. We tried all sorts of tactics, but never really found the sweet spot.
Continue reading “The Right Way to Run a Technical Interview”