There’s one question I ask almost every engineering candidate. It’s not mine originally — credit goes to Stephen Veiss, who asked it during my interview at Scribd. I liked it so much, I stole it. I’ve been using it ever since.
It’s deceptively simple, but it opens a window into how an engineer thinks, how deep their understanding goes and where their curiosity stops. It’s also a great way to reveal what I call their “paint drip.”
If you haven’t come across that term before, it comes from this blog post by Bob Marshall, where Kent Beck talks about the difference between T-shaped and paint drip-shaped people. The idea is that we all have areas where we’ve drilled deep — places where we’ve fallen into a rabbit hole and kept going. That’s the paint drip. And this question helps me see where those drips are.
Here’s how I pitch it:
“The following question is based on a given situation. You are in control of every possible variable and can dictate the entire architecture, every aspect and every level of detail.
Imagine you are sitting at your computer. You’ve entered a URL into a web browser. You’re just about to press enter.
Tell me everything you know that happens from the time the key is pressed to the time the last pixel is painted on the screen.
You can take as long as you want to answer. Use the remainder of this interview if needed. Be as detailed as humanly possible.
Only talk about things you know. No guessing. You’re free to ask questions to clarify the setup, but don’t ask me to confirm whether something is right or wrong.”
That’s it. That’s the question.
What happens next is always fascinating.
Some people give a high-level answer — a sentence or two. Others start low-level: keyboard interrupts, kernel scheduling, system calls and work their way up through DNS, TLS, HTTP, layout engines, GPU pipelines… and sometimes even into user perception, color theory and accessibility.
I’ve had candidates talk for forty-five minutes straight. I’ve had others wrap it up in less than five. I’ve even had someone give up entirely — too embarrassed to say what they didn’t know.
And for me, that’s the real beauty of this question: not just what someone knows, but how they handle what they don’t.
Do they freeze? Do they admit gaps? Do they ask smart questions? Do they lean into it with curiosity?
Most importantly — does this make them want to go learn more?
You can’t fake this answer. There’s no leetcode trick, no memorized regurgitation. You either have the paint drips or you don’t. And if you don’t, maybe this question sparks your first one.
So if you’re reading this, I’m curious: how would you answer?
Would you start with the keyboard scan code hitting the motherboard’s interrupt controller? How about how sodium and potassium ions exchange triggering a motor response in your finger? Would you talk about the browser’s multi-process model? The render tree? The compositor thread?
Or would you stop and say “huh, I’ve never really thought about that”?
Both are good answers, honestly.
If you’d rather not post your thoughts publicly, send me your answer: christian@jensenbox.com — I’d love to read it.