How to stop rambling in technical interviews (the 60-second rule)

You know the answer. You know it well. So you start talking. You cover the main concept, then the edge cases, then the historical context of why it works that way, then a tangent about a production incident from last year — and somewhere around the three-minute mark, the interviewer’s eyes glaze over.

Rambling is the senior engineer’s interview disease. Juniors tend to give answers that are too short. Seniors give answers that are too long. And the more you know about a topic, the worse the rambling gets.

Why developers ramble

Three things drive it, and they usually stack on top of each other.

Anxiety disguised as thoroughness. Interview nerves create a compulsion to fill silence. Your brain interprets a pause as a failure signal, so you keep talking. You tell yourself you’re being thorough. You’re actually being nervous.

The proof impulse. You want to demonstrate that you really know this. Not just the textbook answer — you know the edge cases, the gotchas, the production reality. So you keep adding layers of evidence, hoping each one pushes your score higher. It doesn’t. After a certain point, you’re not adding signal. You’re adding noise.

No defined stopping point. When you write code, you know when a function is done — it returns a value. When you speak in an interview, there’s no natural return statement. Your mouth just keeps running until you trail off with “…so, yeah.”

The third one is the real problem. The first two go away if you have a structure to fall back on.

The cost of rambling

A rambling answer hurts you in ways that aren’t obvious:

• It obscures your key point. When everything gets equal airtime, nothing stands out.
• It eats the clock. A 45-minute interview has room for maybe 4-6 substantial questions. If your answers run 5 minutes each instead of 2, the interviewer gets less data to evaluate you on.
• It signals how you’ll communicate on the job. Design reviews, incident responses, Slack threads — if your interview answers ramble, your daily communication probably does too. Right?
• It takes control away from the interviewer. They have a plan. They want to probe specific areas. When you monologue for four minutes, you’re not letting them drive. Most won’t interrupt — they’ll just wait it out and move on.

The 60-second rule

Your first answer to any interview question should be under 60 seconds.

Not 60 seconds total. 60 seconds for your initial response. Then stop. Let the interviewer decide where to go next.

This feels counterintuitive. Sixty seconds isn’t enough to cover everything about database indexing or event-driven architecture. That’s exactly the point. You’re not supposed to cover everything. You’re supposed to cover the most important thing and then let the interviewer pull for more.

Think of it like an API. Your first response is the summary endpoint. If the interviewer wants the detail endpoint, they’ll ask for it. Don’t return the entire database on every request.

It forces you to prioritize. When you have 60 seconds, you can’t cover everything. You have to decide: what’s the single most important thing the interviewer should take away?

It creates a conversation. Interviews that go well feel like technical discussions, not presentations. Short answers invite follow-up questions. Follow-ups let you demonstrate depth on the things the interviewer actually cares about — not the things you assumed they’d care about.

It gives you feedback. When the interviewer asks a follow-up, they’re telling you what they want to hear about. A 4-minute monologue gives you zero feedback until it’s over.

I should mention — 60 seconds is arbitrary. Some questions genuinely need 90 seconds. System design walkthroughs are a different thing entirely. The number isn’t the point. The habit of stopping early and letting the interviewer steer is the point.

A simple structure: claim, evidence, stop

Okay, 60 seconds. What goes in them?

Claim (about 10 seconds). State your answer directly. No preamble, no “that’s a great question.” Lead with the point.

• “The main benefit of event sourcing is auditability — you get a complete history of every state change.”
• “I’d use a message queue here rather than synchronous HTTP calls.”

This is what the first 30 seconds are about — anchoring the interviewer to your key point before details muddy the water.

Evidence (about 40 seconds). Support your claim with one or two concrete points. Not five. Pick the strongest.

• A technical reason (“Because event sourcing stores immutable events, you can replay them to debug production issues or build new read models after the fact.”)
• A trade-off (“The downside is eventual consistency — your read models will lag behind writes, which doesn’t work for every use case.”)

Two points is almost always enough. It feels like you’re leaving stuff out. You are.

Stop (0 seconds). This is the hard part. Actually stop talking. Don’t add “and also…” Don’t trail into a tangent. Just stop.

The silence feels uncomfortable. Your brain will scream at you to fill it. Let it scream. The interviewer needs a moment to process what you said.

Stopping mid-thought when you know there’s more to say goes against every instinct. I still struggle with this in meetings — I’ll make my point and then keep talking for another 30 seconds, adding nothing. In an interview the stakes are higher and the instinct is stronger.

Recognizing the ramble

Here’s something worth trying. Pick a technical concept you know well — dependency injection, the event loop, whatever. Set a timer and explain it out loud.

Most developers blow past 60 seconds without getting to a clear point. They start with context, then definitions, then history, and then maybe get to the actual answer.

That gap — between how well you understand something and how concisely you can explain it — is the whole problem. Knowing something and being able to say it clearly in real time are two different skills. The second one only improves with actual verbal practice, not just reading about it.

When you’re unsure, you ramble more

Rambling gets especially bad when you don’t fully know the answer. You talk in circles, hoping you’ll stumble into something coherent, because admitting uncertainty feels dangerous.

It’s usually not dangerous. Saying “I’m not sure about the specifics of X, but here’s how I’d approach it” is a much better signal than a three-minute non-answer. Interviewers can tell when you’re stalling. Most would rather hear you name what you don’t know and reason from there.

There’s more to say about handling the “I don’t know” moment — it’s its own skill. I wrote about it here.

What happens after

After your 60-second answer, the interviewer will do one of three things:

Ask you to go deeper. Now you know exactly what they want. Give another short chunk on that specific subtopic.

Move to a new question. Your answer was sufficient. A lot of people interpret this as “I didn’t say enough.” Try reframing it: you said enough.

Push back. This is actually good — it means you said something substantive enough to debate. Engage with their specific point. Don’t retreat into “well, it depends.”

Building the habit

You can’t just decide to be concise in the interview. It has to be a habit you’ve already built.

Time yourself. Record yourself answering a question. If your first answer is over 90 seconds, it’s too long. Cut it and try again. The first recording will be painful to listen to. Every recording after that gets slightly less painful.

Practice the stop. The hardest part isn’t talking for 60 seconds — it’s stopping after 60 seconds. Practice sitting in the silence for a few seconds after you finish.

Use the structure outside of interviews. Code reviews, team meetings, Slack answers. The more places you practice claim-evidence-stop, the more automatic it becomes when the stakes are real. I started doing this in PR descriptions — state the change, give the reason, stop. No three-paragraph context essay.

One thing I haven’t figured out: how to practice this for system design questions, where the format is fundamentally different. The 60-second rule breaks down when you’re expected to lead a 30-minute discussion. Maybe it still applies to each sub-answer within the discussion? Not sure.

Pick a technical topic you could talk about for ten minutes. Explain it in under 60 seconds, out loud. Record it. Play it back.

Were you under 60 seconds? Did you actually stop?