Education · 6 min read

Say It Before You Solve It: A Student Interview Practice Routine That Makes Your Thinking Visible

For dev-school students: interviewers judge your thinking, not just your typed answer. Practise talking through a problem before you code it, narrating decisions as you go, and testing your answer out loud — with a runnable Python example you can practise today.

Published 2026-11-04

TL;DR

Interviewers judge your thinking, not just your typed answer. Practise saying the plan before you code, narrating each decision as you make it, and stating the expected result before every test run — then save the practised solution as a snippet you can explain again tomorrow.

Key takeaways

In a coding interview, your thinking is part of the answer: interviewers are listening for how you understand the problem, choose an approach, and handle the cases that break a first idea.
Say the plan before you write code: restate the problem, name the inputs and outputs, and state the edge cases you already expect, in about thirty seconds.
Narrate decisions while you code, not after: say why you chose a step, what it costs, and what you are deliberately leaving for later, so a silent pause never looks like being stuck.
Test out loud: state the answer you expect before each run, then compare it with what actually happens, so a wrong result becomes evidence about your thinking rather than a surprise.
Free gives you 20 code executions a day, 10 AI requests a day, 10 saved snippets, 3 private snippets, and 3 collaborators per snippet — upgrade to Pro ($9/month or $69/year) when daily interview practice actually runs into a limit.

Your Thinking Is Part of the Answer

Most students practise interviews the wrong way: alone, silently, staring at a problem until code appears. That trains typing, and leaves the skill interviewers actually judge almost untrained. In a real interview, the interviewer is not only checking whether your final code works. They are listening for how you understood the problem, why you chose one approach, and whether you noticed the awkward cases first. All of that is invisible unless you say it out loud.

Talking through code feels unnatural at first, and that is why it needs practice, not just good intentions. Under pressure, most people go quiet exactly when they should speak: at the start, when the plan is forming, and in the middle, when something stops working. The routine below gives you a script for those three moments — before you code, while you code, and when you test — with a small example you can practise in the browser today.

Step One: Say the Plan Before You Write Code

When you first see a question, do not touch the keyboard. Spend about thirty seconds saying three things out loud: what the problem asks for, what the inputs and outputs look like, and which edge cases you already expect. That short speech proves you understood the question, lets the interviewer correct a misunderstanding before you build on it, and forces you to face awkward cases early, when they are still cheap to handle.

Take the example below: find the second largest distinct number in a list. A good thirty-second plan sounds like this: “I need the second largest distinct number, so duplicates should not count. If there are fewer than two distinct numbers, there is no second largest, so I will return nothing. My plan is to remove duplicates, sort what is left, and take the second item from the end.” That plan already contains the definition, the edge case, and the approach. If the interviewer wanted duplicates to count, they can say so now.

Step Two: Practise on a Small, Runnable Example

Paste the program below into the browser editor in Python — one of the 34+ executable languages on CoderFile (120+ syntax-highlighted) — and practise saying the plan above before you run it. Then run all four cases, saying the answer you expect before each one. The program is short; the habit of speaking first and testing second is the point.

# second_largest.py — say the plan, then run all four cases.
def second_largest(numbers): unique = sorted(set(numbers)) if len(unique) < 2: return None return unique[-2] print(second_largest([5, 2, 9, 9, 3])) # Expected: 5 (9 is largest, 5 next)
print(second_largest([7])) # Expected: None (only one distinct number)
print(second_largest([])) # Expected: None (no numbers at all)
print(second_largest([4, 4, 4])) # Expected: None (duplicates are one number)

The first run gives 5, because removing duplicates leaves 2, 3, 5 and 9, and the second from the end is 5. The other three all give None, each for a reason you already named: too few numbers, no numbers, or all numbers the same. Saying those expectations before you run the code is the whole technique in miniature. When the result matches, you have proved your plan. When it does not, the mismatch tells you which part of your thinking was wrong.

Step Three: Narrate Decisions While You Code

Once you start coding, keep talking, but talk about decisions, not keystrokes. Nobody needs to hear “now I am typing a loop.” They need to hear why you chose the step and what you expect it to do. For the example above, that sounds like: “I am removing duplicates first with a set, because the question asks for distinct numbers, and then sorting, because sorting makes largest and second largest easy to read off. This is not the fastest approach, and I can improve it later if we have time.” That sentence shows you chose clarity first on purpose.

Narrating decisions also protects you during silences. A pause with a spoken reason — “I am thinking about whether the empty case should return nothing or raise an error” — reads as careful thought; the same pause in silence reads as being lost. If you notice you have gone quiet, that is your cue to speak again, even if all you can say is what you are unsure about. In Lab lessons, explaining a lesson to yourself before running its checks often reveals the gap first.

Step Four: When You Get Stuck, Say So and Shrink

Every student gets stuck in interviews, and interviewers expect it. What they judge is not whether you get stuck, but what you do next. Freezing silently, guessing code you do not believe, and starting over all look worse than the honest sentence: “I am stuck here. I have the sorting step, but I am unsure about the all-duplicates case, so let me work through that one case on its own.” That sentence keeps the interview moving and usually unlocks the answer, because the smaller case is easier to reason about.

Shrinking works for the same reason it works in debugging: a small example you can hold in your head beats a large program you cannot. Work the stuck case by hand — write the numbers, cross out duplicates, count what is left — and let that answer tell you what the code should do. Then say the answer, write the code for it, and test it against the same small case. If it passes, you have shown exactly the recovery skill interviewers hope to see.

Step Five: A Twenty-Minute Practice Routine You Can Repeat

One explained solution does not build a habit, so make it a short daily routine. Pick one question from interview practice, set a twenty-minute timer, and follow the same shape: thirty seconds saying the plan, code while narrating decisions, then test out loud with a normal, an awkward, and an almost-empty case. When the timer ends, stop, even if the solution is unfinished, and write one sentence about what went well and one about what went quiet.

Practise with a classmate when you can: take turns, one person talking through the solution while the other only asks questions, never gives answers. The listener notices moments you went silent or skipped a reason, and asks: “why did you choose that step?” Afterwards, save the finished program as a snippet, with a note recording the plan, the cases, and the moment you got stuck. Next week, explain it again from the note alone — if you can, the understanding is yours, not just the code.

When Daily Practice Hits a Limit, That Is the Upgrade Moment

Stay on Free ($0: 20 executions a day, 10 AI requests a day, 10 saved snippets, 3 private snippets, 3 collaborators per snippet) while it fits — a twenty-minute session with a few questions, each tested on three or four inputs, fits comfortably. But interview season grows: mock interviews, a question a day, and a library of explained solutions to keep. That is when Pro earns its $9/month or $69/year — unlimited saved snippets and executions, 100 AI requests a day, 10 collaborators per snippet, and unlimited private snippets — and Team ($19/user/month, or $15/user/month billed annually) covers a class practising together. See the pricing page for current terms, and upgrade for a limit you hit, not for a feature you might use.

Your next step is the example above, not a new question. Open the editor, paste the second-largest program, and practise it out loud: say the plan in thirty seconds, run all four cases stating each expected answer first, then save it as a snippet with a note about the plan and the three None cases. Then try one question in interview practice the same way, and save that one too. Two explained solutions, saved with their reasoning, show an interviewer how you think, not just what you typed.

Frequently asked questions

Do I really have to talk while I code in an interview?

Yes, because the interviewer cannot see your thinking unless you say it. Silent coding leaves them guessing whether a pause means careful thought, confusion, or a plan they missed. Talking does not mean narrating every keystroke: it means saying the plan before you code, naming each decision as you make it, and stating what you expect before you test. That running commentary is what turns a correct answer into a convincing one, and it also helps you — saying a plan out loud often exposes a flaw before you have written a line of code.

What should I say first when I get a question?

Restate the problem in your own words, then name the shape of the answer. For example: “I need the second largest distinct number, so duplicates should not count, and if there are fewer than two distinct numbers there is no answer.” That one sentence proves you understood the question, surfaces the edge cases early, and gives the interviewer a chance to correct you before you build on a misunderstanding. If anything is unclear — what counts as distinct, what to return when there is no answer — ask it now, not after you have written the solution.

What do I say when I get stuck?

Say that you are stuck, say exactly where, and shrink the problem. “I have the sorting step, but I am unsure what to return when every number is the same — let me work through that one case on its own” is a strong answer, because it shows the interviewer your thinking is still moving. Interviewers expect stuck moments; what they judge is whether you freeze, guess silently, or break the problem into a smaller piece you can reason about. A small example worked by hand is often the fastest way out.

How much interview practice can I do on the free plan?

Free ($0) gives you 20 code executions per day, 10 AI assistant requests per day, 10 saved snippets, 3 private snippets, and up to 3 collaborators per snippet — enough for a focused daily session of a few practice questions, each tested on three or four inputs. Pro ($9/month or $69/year) adds unlimited saved snippets and executions, 100 AI requests a day, 10 collaborators per snippet, and unlimited private snippets, and Team ($19/user/month, or $15/user/month billed annually) covers a class practising interviews together.