Brainteaser Interview Questions: Why Manhole Covers Are Round

A candidate once went quiet on me for about forty seconds. Not on a coding problem, and not on one of those brainteaser interview questions everyone insists are extinct. The question was: "Roughly how many servers would this need?"

She had, ten minutes earlier, written a clean lock-free ring buffer from scratch. Now she was staring at a blank whiteboard because someone asked her to make up a number in front of a stranger.

That is the manhole cover question wearing a hoodie. Brainteaser interview questions never actually went away. They got a rebrand, moved into the system design round, and most candidates don't recognize them anymore.

TL;DR

• A round manhole cover can't fall through its own hole no matter how you rotate it. It also rolls, and it never needs to be aligned. That's the whole answer, and it takes ten seconds.
• Google publicly walked away from brainteasers over a decade ago after finding they predicted nothing about job performance. They mostly measured whether you'd heard the trick before.
• The genre survived as back-of-the-envelope estimation inside system design: QPS, storage, server count, cache hit rate.
• Estimation questions are scored on decomposition and stated assumptions, not on your final number. Landing within 10x is a pass.
• A question with exactly one clever answer you either know or don't is still a red flag about the team asking it.

Why are manhole covers round?

Because a circle is the one common shape that cannot fall through its own hole. Turn a square cover diagonally and it drops straight down the shaft onto whoever is working below. A circle has the same width in every direction, so there is no angle that lets it slip through.

Two more reasons that get you full credit: a cover weighs on the order of 50 kilograms and a round one can be rolled instead of carried, and a round cover needs no orientation, so a tired city worker at 2 a.m. can't put it back wrong.

The genuinely fun follow-up, and the reason I still like the question as a conversation piece: circles are not the only shape that works. Any shape of constant width does, like a Reuleaux triangle. Some cities use them. If a candidate gets there on their own, that's a nice moment. It's not a hiring signal.

What do brainteaser interview questions actually test?

Mostly, whether you've seen the question before. That's the uncomfortable finding. Once a puzzle has one clever unlock, the interview stops measuring reasoning and starts measuring exposure. The candidate who read a puzzle book in high school looks brilliant. The candidate who didn't looks slow.

Google is the well-known example here. They ran the "how many golf balls fit in a school bus" era harder than anyone, then went looking in their own hiring data for correlation with actual performance and didn't find it. Their head of People Ops said as much publicly around 2013: the puzzles served mostly to make the interviewer feel clever.

That is the part worth stealing. The failure mode of brainteasers is not that they're hard. It's that they flatter the person holding the answer key.

Where did the brainteaser interview question go?

It moved into system design, as estimation. Nobody asks you about golf balls anymore. They ask:

• "How much storage does this need after a year?"
• "What's the read QPS at peak?"
• "How many boxes to serve that?"
• "Does this fit in memory?"

Same cognitive move as the golf balls: decompose a fuzzy question into numbers you can defend. Crucial difference: there's no trick and no answer key. Ten senior engineers will produce ten different numbers and all of them can be right, because the grading is on the path.

Here's the whole move, on a URL shortener.

Start with one assumption, stated out loud: 100 million new links a day. A day is 86,400 seconds, which I round to 100,000 because I am not doing long division on a whiteboard.

• Writes: 100M / 100k ≈ 1,000 per second. Call peak 3x, so ~3k/s.
• Reads: shorteners are read-heavy, say 100:1. ~100k reads/sec. That's the number that actually shapes the design.
• Storage: ~500 bytes per row × 100M = 50 GB a day, about 18 TB a year. Fits on a handful of disks. Not a distributed-storage problem.
• Cache: the hot 20% of links serve most traffic. 20 GB of a day's links fits in RAM on one machine easily, so the read path is a cache problem, not a database problem.

That took four lines of arithmetic and it just decided the architecture. Writes are trivial. Reads are a cache. Storage is boring. Anyone who jumps straight to sharding strategy before doing that math is designing from vibes.

The interviewer does not care that I said 100M. If they think it's 10M they'll say so, you divide by ten, and the conversation continues. Stated assumptions are editable. Silence isn't.

How do you answer an estimation question without freezing?

Say a number in the first fifteen seconds, then fix it. The freeze is what kills people, and it's almost always a confidence problem rather than a math problem.

The script I coach people through:

1. Name the unit. "Okay, I want reads per second at peak." Half of all flailing is not knowing what you're solving for.
2. Pick a top-line number out loud and label it a guess. "Let's say 50 million daily actives. Adjust me if that's wrong."
3. Round aggressively. 86,400 becomes 100,000. 365 becomes 400. You are estimating, not billing.
4. Do one arrow at a time, out loud. Users to actions to per-second to bytes. Never do two steps in your head silently.
5. Sanity check against something physical. "That's 40 TB, so a few dozen disks, so not a cluster problem." A number you can't picture is a number you can't defend.

Step 4 is the one people skip, and it's the one being graded. Your mental arithmetic is invisible. If you compute the whole thing in your head and announce "about 200k QPS," you scored zero on the thing the question exists to measure, even if you're exactly right.

Which is why this round is worth rehearsing out loud rather than in your head. Full disclosure, I built a tool for exactly this: Preterview runs voice mock interviews with three interviewer styles, scores your resume and portfolio, and hands back a written report. Estimation questions are the ones where the gap between "I know this" and "I can say this at conversational speed to a stranger" is widest, and the only fix is reps with a microphone on.

Which brainteaser interview questions are still red flags?

Sort every weird question you get into three buckets. This is also how you interview the company back.

Green: open-ended estimation with no fixed answer. "How much would it cost to run this at 10x traffic?" No answer key, infinite valid paths, directly maps to work you'll do on the job. Ask this one yourself when you're on the other side.

Yellow: classic Fermi questions. Piano tuners in Chicago, gas stations in the US. Structurally fine, and I've seen them run well. The risk is an interviewer sitting on a "correct" number they read somewhere. Probe: "Are you looking for a specific figure, or the reasoning?" A good interviewer answers instantly. A bad one gets defensive.

Red: one-trick riddles. Bridge crossings, pirates dividing gold, the two-eggs-off-a-building problem, anything where the answer is a specific insight you either have or don't. When I hear one of these in 2026, I'm no longer thinking about the puzzle. I'm thinking about what code review is like on that team.

You can ask, politely: "Out of curiosity, what does a strong answer here tell you about how I'd do the job?" A team with an actual rubric loves that question. A team running on ritual will get uncomfortable, and you just learned something more useful than the answer to their riddle.

So why are manhole covers round, really?

Because a circle cannot fall through its own hole, it rolls instead of getting carried, and it can't be replaced misaligned. As an interview question it's dead, and it deserved to die, because it tested exposure to a puzzle rather than engineering judgment. What replaced it is the estimation question inside your system design round: how many requests per second, how much storage in a year, how many machines. Same skill, no answer key. The interviewer is scoring whether you can turn a vague question into stated assumptions and defensible arithmetic out loud, not whether you land on their number. Say a rough figure in the first fifteen seconds, show every arrow, and let them correct your assumptions. That's the whole trick, and unlike the manhole cover, it's a trick you'll use on the job next week.