Explaining how something works
Start with a simple picture, add one technical layer, then ask how deep they want to go.
What they’re listening for
- • Do you understand it, or did you memorize it?
- • Can you explain it to different levels?
- • Do you know the costs, not just the benefits?
When you recite a definition, the interviewer can't tell whether you understand it. Explain it the way you would to a new teammate: an everyday picture first, then how it really works, then the catch.
Stiff vs. natural
Interviewer: “How does a database index work?”
Sounds stiff
“An index is a data structure that improves the speed of data retrieval operations on a database table at the cost of additional writes and storage space.”
Sounds natural
“So the simple version: it's like the index at the back of a book. Instead of reading every page to find “caching,” you look it up and jump straight to page 212. In most databases it's a B-tree, which is a sorted structure, so finding a value takes a few steps instead of scanning the whole table. The catch is that every insert or update also has to update the index, so you don't index everything. How deep do you want me to go?”
- Starts with an everyday picture anyone can follow.
- Then one technical layer (B-tree, sorted, a few steps).
- Mentioning the cost shows you've actually used it.
- Asks about depth instead of guessing.
Interviewer: “What happens when you type a URL into the browser and hit Enter?”
Sounds stiff
“First the browser checks the cache, then DNS resolution happens, then the TCP three-way handshake, then the TLS handshake, then the HTTP request is sent, then the server processes the request, then the response is returned, then the browser parses the HTML and builds the DOM and the CSSOM…”
Sounds natural
“Big picture first: the browser finds out where the site lives, connects to it, asks for the page, and turns what comes back into pixels. Finding it is DNS, connecting is TCP plus TLS for HTTPS, asking is an HTTP request, and the pixels part is parsing the HTML, loading CSS and JavaScript, and painting. Each of those is a rabbit hole, so pick one and I'll happily fall in.”
- A four-step map first, so the listener doesn't get lost.
- Then the real names for each step.
- The light ending invites them to choose the next topic.
Going one level deeper
Interviewer
“Okay, let's stay on indexes. Why not just index every column?”
You
“A couple of reasons. Writes get slower, because every insert has to update every index. They take space, sometimes more than the table itself. And the database might not even use them. If a column only has a few values, like true or false, scanning the table can be just as fast.”
Short list, then a concrete example.
Interviewer
“When would an index exist but not get used?”
You
“A classic one is wrapping the column in a function, like searching on lower(email) when the index is on email. The index is sorted by the original value, so it can't help. You'd add an index on lower(email) instead. I learned that one the slow way.”
A specific example from experience is more convincing than a rule.
Explaining clearly
- “The simple version is…”Starting with the big picture.
- “Think of it like…”An everyday comparison.
- “Under the hood…”Moving to the technical layer.
- “The catch is…”The cost or the limitation.
- “How deep do you want me to go?”Checking the level they want.
- “Want me to keep going, or is that enough?”Checking in during a long explanation.
Now say it out loud
Rehearse with the AI interviewer and get feedback on your answers.