It’s 10:43 am and the candidate is standing by the white board, giving me a blank stare. With fifteen minutes left in the interview, I still can’t decide whether the guy is faking it or simply nervous.
I walk over, grab the marker and draw a rectangle, setting up the stage for my perennial technical question that should settle this for good.

As engineering leaders, we rely on our teams to conduct the technical evaluation of applicants. It’s the logical thing to do. The developers are the closest to the technology and are well equipped to suss out the candidate’s technical chops.

In turn, we interview along non-technical dimensions such as cultural fit, raw intellect, work ethic, etc. In a competitive recruiting climate, a good part of the interview is actually spent on selling to the candidate as well.

This does not leave much time for anything else. Yet somehow, we also need to form our own opinion of the candidate’s technical aptitude. How can we best do that?

I’ve been using one interview question that I repetitively ask for this purpose. It is open ended, universal, relevant and on a subject that I master. It’s broad enough that it will spur multiple follow up questions, yet specific enough that it provides a good read of a person’s actual knowledge.

This is the question I ask:

“Pick your favorite browser. Type ‘’ into the address bar and hit enter. Describe in as many details as you wish, everything that happens until the page is displayed.”

On the surface, this can be seen as a simple “explain how a browser work” question.

However, with some good guidance and prodding, this question engenders a conversation that will cover many topics relevant to selecting a web or mobile developer. For instance:

  1. Client Application - rendering, memory management, parsing, local storage, I/O.
  2. Networking - DNS, TCP/IP protocol, network sockets.
  3. Servers - HTTP servers, application servers, databases, caching.
  4. Web Application - HTML, CSS, Javascript.
  5. DevOps - Configuration, vhosts.
  6. Architecture
    • Client/server concepts and optimizations (compression, multi-threading)
    • OSI layers
    • Session management in a stateless protocol
    • Cookies
    • Common HTTP Headers and their use
    • RFC standards
  7. Debugging - Protocol analyzer, raw telnet to server, logging.

The broad and open ended nature of the question also provides insight on how the candidates conduct themselves in an engineering setting. Can they describe abstract concepts? Do they communicate clearly? Are they at ease in front of a white board?

I also make sure to probe past the boundary of their knowledge. Seeing how candidates behave when they don’t know something is as important as discovering what they do know. Do they make things up? Do they acknowledge they don’t know something? Are they curious and appreciative when I give them the answer? This offers a glimpse into their self-confidence, natural curiosity and willingness to learn.

I’ve asked this very question hundreds of times and never once was I disappointed by the results. I can spend five or fifty minutes with it and usually get a read of the candidate that correlates well with the technical assessment of others.

Sometimes candidates quickly gloss over everything. They mix HTTP with HTML, get confused by local and remote IP addresses and ports and can’t explain how cookies work. They can’t seem to be bothered with the intricacies of something they relied on and made a living from for most of their life.

I marvel at their lack of curiosity. How can they be content to build applications with so little understanding of the underlying technology that make the web work? This baffles me.

In other cases, I’ve had candidates engage in very deep ways. They dug in the subject and the interview turned into a sparring match of sort. I could tell they were having fun and that I’d enjoy working with them in this way.

And then, after one candidate drew the perfect sequence diagram, meticulously described all the protocol layers, came the seminal interview moment. He cleared his voice and without hesitation eloquently explained the purpose of the TCP three way handshake. I chocked up a little and at that instant I knew I had a keeper.

What’s your one interview question gonna be? Adopt mine or develop one of your own that suites your style.