TCTechClinic
About usTC BrainVisualizersPricing
LibraryDSAInside a 45-Minute Coding Round
1/192
DSAData Structures & Algorithms
Overview
The Five Basic Terms
Big-O: Measuring Speed
The Five-Step Problem Method
Inside a 45-Minute Coding Round
Assessment→TC Tutor ↗
Data Structures & Algorithms

Inside a 45-Minute Coding Round

The clock, what is scored, what to say out loud

4. Inside a 45-Minute Coding Round

The idea

You are on a video call with one engineer. There is a shared editor on the screen. They paste a problem. Forty-five minutes later the call ends and they write a few paragraphs about you. Everything on this page is about what goes in those paragraphs.

The good news: the round has a fixed shape, and the shape is the Five Moves with a clock on them. Once you know the clock, nothing about the round is a surprise except the problem itself — and the Five Moves handle that.

Watch it

The round is the Five Moves with a clock on them
The round is the Five Moves with a clock on themComponents: 0–5 min, 5–10 · Move 1, 10–15 · Moves 2–3, 15–35 · Move 4, 35–42 · Move 5, 42–45. Connections: 0–5 min to 5–10 · Move 1; 5–10 · Move 1 to 10–15 · Moves 2–3; 10–15 · Moves 2–3 to 15–35 · Move 4; 15–35 · Move 4 to 35–42 · Move 5; 35–42 · Move 5 to 42–45.0–5 minhellos, problem pasted5–10 · Move 1say it back, ask questions10–15 · Moves 2–3dumb way, its cost, the waste15–35 · Move 4walk the example, then code35–42 · Move 5test, state the cost42–45follow-up, your questions
Twenty of the forty-five minutes are for typing. Most people spend forty there and lose the round in the other twenty-five.

And the same clock with the sentences you actually say:

What they are actually scoring

Every company's rubric uses different words, but they all come down to four things, and you can hit all four on purpose.

What goes in the write-up
What goes in the write-upComponents: Understood the problem, Found a good approach, Code that runs, Could be followed. Connections: Understood the problem to Found a good approach; Found a good approach to Code that runs; Code that runs to Could be followed.Understood the problemMove 1 — restated it, asked about weird inputsFound a good approachMoves 2–4 — right shape for the size, can say whyCode that runshandles the weird inputs, no hand-wavingCould be followedtalked while thinking, took hints well

Did you understand the problem before solving it? This is Move 1. Restating the problem and asking about the weird inputs is not a formality. Skipping it is the single most common way strong coders fail a round — they solve a slightly different problem perfectly.

Did you find a good approach, and can you say why it works? Moves 2 to 4. "Good" means the shape the size hint allows (see Big-O: Measuring Speed). "Why it works" means you can explain the pattern in a sentence, not just recite it.

Does the code run? Real code, no hand-waving, handles the weird inputs. This is where the practice problems matter: they are graded by hidden tests, exactly like the real thing, and reading never taught anyone to write code that runs.

Can they follow your thinking? You talk while you think. Not a lecture — a running commentary. If they can follow you, they can help you, and a candidate who takes a hint well scores better than one who never needed it but never spoke.

Say it out loud — the sentences

You do not need to be a natural talker. You need about six sentences, and you already have most of them from the last two pages:

  • "Let me make sure I understand. So the input is… and I hand back…"
  • "My small example is… and the answer should be…"
  • "What should happen if the input is empty? Can there be duplicates? Negatives?"
  • "The obvious approach is…, which costs…. Let's see if we can do better."
  • "Before I code, let me walk my example through this."
  • "Let me test with the tiny case… the empty case… okay. This is O(…) time and O(…) space because…"

Practise saying them until they are boring. Boring is the goal. When the problem is hard, you want the talking to be free.

When you get stuck

You will get stuck. It is designed that way; the problem is meant to have a wall in it. What the interviewer watches is what you do at the wall.

Do not go quiet for more than about a minute. Say what you have ruled out and why. Go back one move — nine times out of ten you jumped from reading straight to coding and skipped the dumb way, and the dumb way is where the waste, and therefore the pattern, shows itself. Try a smaller example. Ask "what if it were sorted?" or "what if I walked backwards?". And if none of that works, ask for a hint. A hint costs a little. Silence costs everything.

The five ways people lose

  1. Coding in silence. The interviewer has no idea whether you are thinking or panicking, and cannot help.
  2. Skipping Move 1. Solving the wrong problem well.
  3. Not testing. Declaring done and letting the interviewer find the off-by-one. Always run the tiny example and the empty case yourself, before they ask.
  4. Fighting the hint. When they nudge, they are telling you where the wall is. Take it, say thank you, keep going.
  5. Refusing the "dumb" answer. Some rounds want the O(N²) answer written cleanly first, then improved. Getting stuck hunting for a clever trick while the clock runs is worse than shipping the honest version and then upgrading it.
Each way to lose has a fix
Each way to lose has a fixComponents: Coding in silence, Skipping Move 1, Not testing, Fighting the hint, Hunting for clever, Narrate every decision, Say it back, name the weird inputs, Run tiny + empty case before they ask, "Good point" — take it, keep going, Ship the honest O(N²), then upgrade. Connections: Coding in silence to Narrate every decision; Skipping Move 1 to Say it back, name the weird inputs; Not testing to Run tiny + empty case before they ask; Fighting the hint to "Good point" — take it, keep going; Hunting for clever to Ship the honest O(N²), then upgrade.THE SLIPTHE FIXCoding in silenceSkipping Move 1Not testingFighting the hintHunting for cleverNarrate every decisionSay it back, name the weird inputsRun tiny + empty case before they ask"Good point" — take it, keep goingShip the honest O(N²), then upgrade

The new kind of round

A few companies now run an AI-assisted round: you may use an AI assistant while you code, and they score how well you check what it gives you — do you write tests first, do you catch the planted bug, can you explain the fix. Everything on this page still applies, and Move 5 becomes the whole game. A module on this is coming later in the course.

How to use this course

The modules go in order, and the order is deliberate: each pattern is built on the ones before it. Every page has a short quiz and three practice problems that are graded by real hidden tests. Do the problems. A page you have read but not practised is a page you do not know yet. Aim for one module a week, and by the end you will have done the Five Moves a few hundred times — which is exactly how many it takes for them to stop being a checklist and start being how you think.

Practice

Nothing to solve yet. Start Module 1, Arrays & Hashing, next. Bring a pen: for the first few problems, write Moves 1 to 5 on paper before you type anything.

In the room

If you remember one thing from this page: the interviewer is not waiting to catch you out. They are trying to find reasons to say yes, and they need you to give them those reasons out loud. Understand first, talk always, test before they ask, state the cost. That is the round.