Technically Curious, Get's It Done

After hiring 50+ engineers over 27 years, I’ve noticed something: the best ones don’t always know the most—they know how to think when they don’t know. Most interviews test the wrong thing. We quiz on syntax and frameworks instead of the skill that actually predicts success: technical curiosity.

The best engineers I’ve worked with all had the technical curiosity to want to understand complex problems at the atomic level and the capability to recursively decompose those problems sufficiently to gain that insight.

As an example of a recursive decomposition let’s talk about how I was taught to program computers.

In most languages any program you want to write has “main” procedure that runs. Where you put your event loop if it’s a long running process, or wrap everything up neatly so that you don’t leave a mess in memory after execution. The way I was taught to reason about complicated problems was to write that main procedure first. Not as in write the entire program in one procedure, but to write down the major steps of that program in one procedure. As other procedure calls. Then with that list of procedures defined, I’d dig in and define each of those procedures the same way. In this way I was solving the problem as a recursive process. Defining a list of procedures or functions to call, then defining those functions as a similar list to call, setting up appropriate control structures as I reasoned my way through, loops, if/then/else constructs, case statements as needed. Eventually your steps are just commands from the language. That’s when you know you are done.

This method is NOT the only valid method I have used with great efficacy. Bottom up programming approaches, hybrid approaches and others are all valid methodologies for recursive decomposition. But this approach taught me the habits and rigor of structured decomposition, and that habit is what matters.

I often say I can teach technical skills, but I have to interview for technical curiosity, determination, and ability to reason about problems. I always interview for fit and ability to share with others on the team. There is a still a basic line for technical skill. You have to test for someone who has the skills you need to get on the team and up and running with an acceptable level of effort. But ESPECIALLY in the age of Vibe coding and AI Assistance, that technical interview can’t be over-indexed on which language the interviewee knows today, or even this week. The interviewer must probe the ability to successfully reason about complex problems and decompose those problems in a rigorous way to find valid solutions.

To Interview for that I conduct a standard technical screen, but with a shared workspace, working on the problem with myself as a “Rubber Duck” participant. I’m there to answer questions, provide clarifications and perhaps provide pointers, but not to provide concepts or ideas for the skills being reviewed. I ask candidates to narrate their thinking: ‘What are you considering right now? What would you try next?’ Then I listen—not just for their approach, but for whether they can collaborate and explain their reasoning. Their ability to reason about the problem in a successful way and find attempted solutions is far more important than their ability to successfully create python code on a whiteboard even if the job is to write python code. Let me be clear: the job is not to write python code. The job is never to write python code. The job is decomposing complex problems recursively, and creating repeatable solutions enshrined in code. That is what the job always has been, and always will be.

This isn’t about finding the perfect way to decompose a problem, one of my life tenets is that there are 4,000,002 ways to solve ANY problem. Of those, 1 is the perfect way, 3,999,999 are all good enough to move us forward and 2 will stop us dead in our tracks as a team. Our job is not to find the 1 perfect way, it’s to avoid the 2 that kill our efforts.

All teams and all developers get stuck on problems. Having teammates who are then curious and driven enough to pick up and solve those problems in a disciplined, structured way is imperative to team success in my experience. Using this as an interview tool, not a gate, but one tool of many, has helped me build teams that I have been proud to be part of and proud to serve as a leader with.

I’m curious, of those of you reading who have lead, or even just participated in interviews for engineers, how do you test technical curiosity? Do you test technical curiosity? What has your experience been working with engineers who share these traits, or don’t?