A few months ago, I asked in a YouTube post if you would like a video where I answer your questions.
Andreia sent a super thoughtful question:
“If you could ask just one question in a technical interview, as the interviewer, what would that question be?“
I think it’s a great question, and I want to thank Andreia for asking it.
In this post, I’ll share my answer.
▶️ If you prefer a video instead, I got you covered:
Just to clarify a bit. In a real interview, it’s pretty unlikely that you would ask only one question. To really get to know the person you’re interviewing, you usually need to cover several points, depending on the role you’re hiring for. So I want to set the stage from the start that Andreia’s question refers to a hypothetical scenario, and we can assume the technical interview is for a Software Engineer role.
Another important point is that the Software Engineer role is so broad and complex that you physically cannot cover everything in an interview. So you need to ask a question that’s open-ended and flexible enough to fit any level of experience, whether the candidate is junior or senior. I think in this scenario I would ask the following question:
“What happens when you click on a button on a website?”
It might seem like a simple question, maybe even a bit naive, but it’s a question everyone can understand. Even someone who is not a Software Engineer. The difference is that only a tech person can explain what actually happens when you click a button on a website.
The beauty of this question is that it’s short, clear, neutral, and it opens the door to a huge range of insights about a candidate’s understanding of software development. As a candidate, you can talk about how the button is built, how it’s styled, how the browser renders it, how the request is sent to the server, what happens when the request reaches the server, what happens in the back-end, and even what happens in the database if any data is involved. This is just a broad overview, because depending on the candidate’s experience, each person can focus on what they know best.
For example, someone who is front-end oriented can go into details about how things work on the front-end. From HTML, CSS, JavaScript, how the Document Object Model works, frameworks like Vue or React, different types of browsers, UI, components, and so on.
Someone who is back-end oriented can talk about how the requests are triggered to the server, how the browser makes a request, how the data is processed on the server, how errors are handled, authentication, and also what happens at the database level, and so on.
The candidate can also talk about how the code could be written, the project architecture, design patterns, logging, scalability, caching, and so on. They could even go as far as talking about the server hardware and how the processor or RAM works. The idea is that there is no limit.
And that’s exactly where the challenge with this question comes in.
Because it’s so open-ended, most candidates won’t know how much to talk about or how deep they can go with their explanations. They will most likely stop after just two or three sentences. But that’s not enough to properly evaluate a candidate.
To take the discussion further, you need to be able to ask guiding questions or follow-ups that lead them toward a specific area. If we assume the interviewer is allowed to ask follow-up questions, then they can guide the candidate much more effectively. That way, you can have a real discussion with the candidate, instead of the candidate giving a short monologue.
For example, if I see the candidate chooses to focus more on the back-end, let’s say they start talking about public APIs, I can follow up by asking about the security of those APIs. Are they truly public for everyone, or are they protected by authorization? What kind of authorization do they use? What about throttling or rate limiting?
Or if the conversation moves towards working with large amounts of data, I can ask about scalability and performance, how the system scales, and how it performs under a certain amount of stress, and so on.
Even in an extreme situation where I couldn’t ask any follow-up questions, I think I would still choose to ask this question if I could ask only one.
It’s open-ended, adaptable, and gives a lot of insight into a candidate’s knowledge, problem-solving skills, and way of thinking, whether they are junior or senior.
If you could ask just one question in a technical interview, what would that be?
Share your thoughts in the comments. I’m really curious to see what you think.
Let me know what you think about this article in the comments section below.
If you find this article helpful, please share it with others and subscribe to the blog to support me, and receive a bi-monthly-ish e-mail notification on my latest articles.