There's a very specific kind of confidence that evaporates the second a real clock starts. You've solved this exact LeetCode problem before — twice, actually, comfortably, with your IDE open, a coffee in hand, and absolutely nobody watching. Now it's 10:04am on a Tuesday, a stranger named Priya from a company you'd very much like to work for is watching your screen share, the timer in the corner of your eye says 35:00 and counting down, and the same problem that took you four relaxed minutes last week is somehow eating your soul one syntax error at a time. You are not worse at coding than you were last Thursday. You practiced the problem. You never practiced the conditions.
This is the single biggest reason candidates who clearly "know the material" still bomb interviews, and it has a name borrowed straight from sports science: practice like you play. Coaches have known for decades that rehearsing a skill in a low-stakes, pause-whenever, no-audience environment builds a completely different — and much weaker — kind of competence than rehearsing it under conditions that resemble the real game. A basketball player who only ever shoots free throws in an empty gym, alone, with unlimited time, will not automatically perform under a packed arena with a shot clock running down. The skill transfers partially at best. Interview prep has the exact same problem, and almost nobody fixes it on purpose. This guide covers how to apply the practice like you play principle to interview preparation specifically — coding rounds, system design, and behavioral interviews — with a practical breakdown of which conditions actually matter and how to rebuild your practice routine around them.
Where "practice like you play" actually comes from
The phrase is a coaching cliché for a reason: it's been independently rediscovered by basically every serious athletic program, because the underlying problem keeps showing up. American football coaches run full-speed, full-contact scrimmages instead of only walking through plays on a whiteboard, because a player who can recite the playbook perfectly in a film room often freezes the instant a real 250-pound opponent is sprinting at him. Musicians who only ever rehearse alone, slowly, stopping to fix mistakes, frequently fall apart the moment they're on a stage with an audience and no ability to stop and restart — a phenomenon conservatory teachers specifically train against by running "performance class," low-stakes mock concerts designed purely to simulate the conditions of a real one. Surgeons train on simulators that intentionally introduce time pressure and unexpected complications, not just clean step-by-step procedures, because the operating room doesn't pause for them to look something up.
The common thread across every one of these examples is the same: skill is not a single, transferable thing — it's tightly bound to the conditions under which it was rehearsed. Practicing a skill under condition A builds competence under condition A specifically, and that competence transfers to condition B only partially, in proportion to how similar B actually is to A. If your practice condition is "alone, unlimited time, can pause and Google anything, no one watching, no consequences for being wrong," and your real condition is "with an audience, a hard 45-minute clock, no pausing, real follow-up questions, and a job on the line," the gap between those two conditions is exactly the gap that ambushes you on interview day, no matter how many hours you logged.
The five conditions that actually transfer
Not every detail of a real interview needs to be reproduced in practice — that would be exhausting and largely pointless. What matters is identifying the specific conditions that change your performance if missing, and deliberately rebuilding practice around exactly those. For interviews, five conditions do almost all of the work.
1. The clock
A real coding round, system design round, or behavioral interview has a hard time limit, and that limit changes your decision-making in ways that untimed practice never trains. Under no time pressure, you can explore three different approaches to a problem leisurely and pick the elegant one. Under a real clock, you have to make a judgment call about which approach to commit to quickly, accept that you might not finish the optimal solution, and communicate trade-offs out loud while still coding — an entirely different skill from solving the same problem with all the time in the world. If you've only ever practiced untimed, the first time you feel that specific kind of pressure will be in the interview that actually counts.
The fix: practice every problem, every system design prompt, every behavioral story with a visible, running timer matched to the real round's length. Not a vague "I'll try to be quick" — an actual clock you can see, the same length as the real thing (typically 35–45 minutes for a coding round, 45–60 for system design).
2. No pausing
In untimed solo practice, the moment you hit something you don't know, the natural move is to pause and look it up — open a new tab, check the documentation, glance at a previous solution. This is fine for learning a concept the first time, and actively harmful as a rehearsal habit, because the real interview offers no pause button. The moment you don't know something in a live interview, the only options are to reason through it out loud, say "I'm not sure, here's my best guess and why," or stall — and which of those three you default to under pressure is determined entirely by which one you've rehearsed.
The fix: once you're past the initial learning phase on a topic, practice it with looking things up explicitly banned. If you hit a wall, narrate the wall out loud — "I don't remember the exact syntax for this, but the approach would be..." — rather than reaching for a tab. This single habit change is responsible for more visible improvement in mock interview performance than almost anything else, because it's rehearsing the exact recovery behavior the real interview will demand.
3. An audience
Solving a problem silently in your head and solving it while narrating your reasoning out loud to another person are different cognitive tasks — not just different in feel, but measurably different in execution. Narrating forces you to convert half-formed intuitions into actual sentences in real time, which is a skill with its own learning curve, completely separate from the underlying technical skill. A candidate who's an excellent silent problem-solver and has never practiced narrating their thinking out loud will sound disorganized in an interview not because their reasoning is bad, but because they've never rehearsed producing reasoning as speech under any kind of social pressure.
The fix: practice out loud, every time, even when alone — explain your approach to an empty room, a phone recorder, a rubber duck on your desk, whatever's available. When possible, practice with an actual listener — a friend, a study partner, or a mock interview that can react and follow up. The audience doesn't need to be intimidating; it needs to exist, because the mere presence of another perceiving party changes how your brain produces explanations.
4. Real follow-up questions
This is the condition most solo practice methods structurally cannot reproduce, and it's arguably the most important one. A real interviewer doesn't just receive your answer — they probe it. "What's the time complexity of that?" "What if the input were ten times larger?" "Why did you choose this over the alternative?" These follow-ups are specifically engineered to find the edge of your understanding, and a candidate who's only ever practiced producing a first-pass answer, with nobody pushing back, has never rehearsed the skill of defending or extending that answer under questioning.
The fix: this is the condition that most clearly separates passive study from genuine practice-like-you-play prep, and it's the reason a real or AI-driven mock interview is structurally different from reading a model answer — see the comparison section below for the full breakdown. If a human study partner isn't available for every session, drill the habit of asking yourself the follow-up an interviewer would ask immediately after every answer, before moving on.
5. Real stakes (or at least the feeling of them)
It's hard to manufacture genuine stakes in practice — you can't actually be denied a job offer by a rehearsal session. But you can manufacture the feeling of stakes closely enough to matter: recording yourself and knowing you'll watch it back, practicing with a study partner whose opinion you care about, or using a mock interview platform that gives you an actual score and feedback report rather than just letting you "feel" like you did fine. The mild discomfort of being evaluated, even informally, triggers a version of the same physiological response a real interview does — and that response is exactly what untimed, unobserved, consequence-free solo review never trains you to manage.
The fix: add a real evaluation step to every practice session — a recording you commit to reviewing, a score, a partner's honest reaction — rather than ending the session the moment you've produced an answer that feels acceptable to you.
Applying this to coding interviews
Most candidates' coding prep looks like this: solve a problem on LeetCode, check the solution if stuck, move to the next problem. This builds real pattern recognition — it is genuinely useful — but it reproduces almost none of the five conditions above. Here's the game-speed version of the same practice.
Set a real timer before you start, matched to the actual round length you're prepping for (most technical screens run 35–45 minutes including a brief intro). Start the clock the moment you read the prompt, not after you've already thought about it for a minute.
Talk through your approach out loud before writing a line of code, the way you'd be expected to in a real interview — state your understanding of the problem, propose an approach, name the time and space complexity you expect, and only then start typing. If you're alone, record this out loud; if you have a study partner or mock interviewer, this is the part they're actually evaluating, more than the final code.
Ban yourself from looking anything up mid-problem. If you forget a specific syntax detail, say so out loud and reason through an approximation, exactly as you would in a real interview where Stack Overflow isn't an option. This single rule does more to close the gap between practice performance and interview performance than any other single change.
Build in a forced follow-up. After you finish (or run out of time), ask yourself — or have a partner ask — the two or three questions a real interviewer would: "What's the complexity?" "What would change if the constraint were different?" "Can you optimize this further?" Answer them on the spot, without revisiting your code in detail first.
For the broader set of habits this connects to — how to actually talk while you code without losing your train of thought — pair this with coding interview communication tips, which goes deeper on the narration skill itself once you've got the practice conditions right.
Applying this to system design interviews
System design rounds are unusually vulnerable to the practice-like-you-play gap, because most system design prep is reading — articles, YouTube breakdowns, "how Twitter scales" deep dives — which builds recognition (you've seen this before) without building the much harder skill of producing an architecture live, under questioning, with a blank whiteboard and a ticking clock.
Time-box the whole exercise, typically 45 minutes for a real system design round, and run through the standard skeleton — clarify requirements, estimate scale, sketch the high level, deep-dive one component, name failure modes — inside that window, out loud, on an actual whiteboard or blank doc, not a pre-drawn diagram you're narrating from memory.
Force yourself to commit to numbers on the spot. A common failure mode in untimed solo review is reading "design Twitter" articles that hand you the scale estimates (millions of users, billions of reads) — and then freezing in a real interview when asked to actually do that estimation yourself, live, with rough math. Practice doing the back-of-envelope math under time pressure specifically, not just reading someone else's finished estimate.
Build the follow-up into every drill. After sketching an architecture, ask the question a senior interviewer actually asks: "what's the first thing that breaks at 10x this scale?" or "what happens if this service goes down?" Drilling the deep-dive and failure-mode steps under a real follow-up, rather than stopping once the high-level sketch looks clean, is what separates a mid-level answer from a senior one. What system design interviews actually test breaks down the full framework these drills should follow; running it under a real clock and a real follow-up is what turns the framework into a transferable skill rather than a thing you can recognize but not produce.
Applying this to behavioral interviews
Behavioral prep has its own version of this gap, and it's sneaky because behavioral stories feel rehearsed even when they've only ever been thought through silently, never actually spoken under any pressure. A story that's been turned over in your head fifty times can still come out as a disorganized ramble the first time you have to say it out loud, in real time, to someone who might interrupt.
Tell every story out loud, on a clock, with no editing mid-sentence. Behavioral answers in real interviews typically run 90 seconds to three minutes — practicing with that same time box, and forcing yourself to land the story within it rather than rambling until it feels "done," trains the actual skill of pacing a story for an audience.
Practice the interrupt. Real interviewers occasionally jump in mid-answer with a clarifying question or redirect ("can you go deeper on the decision you made there?"). Solo rehearsal never includes this, which means the first time it happens is, again, in the interview that counts. If you have a study partner, ask them to interrupt you on purpose at least once per story. If you're alone, build in an artificial interrupt — pause your own recording at a random point and continue from a slightly different angle, simulating the disruption.
Get an honest reaction, not just a silent self-assessment. It's nearly impossible to judge your own delivery accurately while you're the one delivering it — you can't hear your own rambling the way a listener can. Behavioral STAR answers for senior engineers and how to prepare for a mock interview both go deeper into structuring the content of these stories; practice-like-you-play is specifically about rehearsing the delivery of that content under conditions that match the real thing.
A worked before-and-after: the same coding problem, two ways
It's worth seeing the difference in practice, not just in principle, because the gap between low-fidelity and game-speed rehearsal is easy to underestimate until you watch it play out on one concrete example.
Low-fidelity version. A candidate opens a two-sum-style problem on a laptop, no timer running. They read it twice, think for a couple of minutes, write a brute-force nested loop, run it against the sample input, see it pass, and then — with no time pressure pushing them forward — decide to look up the optimal hash-map approach "just to see it," copy the pattern mentally, rewrite their solution to match, and move on feeling like they've "learned" the optimized approach. Forty minutes pass. They feel productive. They have, in fact, learned something — but what they've rehearsed is "recognize the optimal pattern when nothing is stopping me from finding it," which is a different skill from "produce the optimal pattern from a blank state, live, with a clock running and someone watching."
Game-speed version. Same problem, same candidate, one week later. A visible 25-minute timer starts the moment they open the prompt. They state their understanding out loud first: "Okay, I need to find two numbers that sum to a target — brute force would be checking every pair, that's O(n²), but I think there's a faster way using a hash map to track what I've seen." They commit to the hash-map approach immediately, narrating why as they type, hit a small bug, can't pause to Google the exact dictionary syntax, reason through it out loud instead ("I think it's .get() with a default, let me just try that"), fix it, finish with six minutes left, and then face a forced follow-up: "what if the array could contain duplicates, or the target could be hit by the same element twice?" They have to reason through an edge case live, under a clock that's still visibly running down, with no opportunity to quietly think it through off to the side first.
The second version is uncomfortable in a way the first never was. That discomfort is not a sign the second session went worse — it's the sign that it's actually rehearsing the skill the real interview will test. A candidate who only ever runs sessions that feel like the first version will walk into an interview and feel that discomfort for the very first time at the worst possible moment.
Why this gap hides from candidates who feel well-prepared
One of the more frustrating aspects of the practice-like-you-play gap is that it's nearly invisible from the inside. Passive, low-fidelity review feels like real progress — you finish a study session having "covered" a topic, you can recognize the right answer when you see it, your confidence genuinely rises. None of that confidence is fake, exactly; it's just calibrated to the wrong condition. You've built real confidence in your ability to perform under low-fidelity conditions, and that confidence transfers to the interview only as much as the interview resembles your practice — which, per everything above, it usually doesn't, on at least three or four of the five key dimensions.
This is also why post-mortems after a bad interview so often feel confusing to the candidate: "I knew this material, I'd studied it for weeks, I don't understand why I froze." The honest answer is usually that they'd built strong content knowledge and weak performance-under-condition skill, and the interview tested the second thing almost exclusively. It's not a knowledge gap — it's a conditions gap, and it's specifically the kind of gap that doesn't show up until the real stakes are live, which makes it one of the most expensive kinds of gap to discover for the first time mid-interview rather than ahead of time in deliberate practice.
A useful diagnostic question to ask honestly about your own prep: of the last ten hours you spent studying, how many were run with a real clock visible, out loud, with no pausing to look anything up, in front of someone (or something) that could ask a real follow-up? For most candidates the honest answer is close to zero — which means nearly all of their practiced confidence is calibrated to a condition the real interview won't offer them.
How interviewers unintentionally test for this gap
It's worth understanding that interviewers aren't deliberately trying to expose the practice-conditions gap — they're just running a standard interview, which happens to include a clock, an audience (them), no pause button, and natural follow-up questions, because that's simply what a real interview is. The gap shows up as a side effect of the interview format itself, not because anyone designed a trap. This actually matters for how you should think about prep: you're not trying to out-think an adversarial test designer, you're trying to make the ordinary structure of a normal interview feel unremarkable to your own nervous system, because you've already rehearsed something close enough to it many times before the real one happens.
This reframing also explains why candidates sometimes report a strange phenomenon after enough game-speed practice: the real interview starts to feel almost anticlimactic, in a good way — "it felt like just another practice session." That's the entire goal. A real interview that feels novel and high-stakes in a way nothing in your preparation resembled is exactly the scenario where a capable, knowledgeable candidate underperforms relative to what they actually know. A real interview that feels familiar because you've deliberately rehearsed something close to its actual conditions, many times, is the scenario where performance finally matches knowledge.
How this compares to other prep methods
It's worth being specific about where the practice-like-you-play principle exposes real gaps in the most common prep tools, because the gap isn't always obvious until you name it directly.
Versus reading GeeksforGeeks-style question dumps. These are genuinely useful for discovering what topics to study — but reading a list of questions and model answers reproduces zero of the five conditions above. You're alone, unlimited time, no audience, no follow-up, no stakes. It's a study aid for content, not a rehearsal for delivery, and treating it as the latter is the single most common prep mistake.
Versus LeetCode grinding, solo. Solving problems builds real pattern recognition and is genuinely necessary — but solving them at your own pace, pausing to check the constraints page, with no one watching, only reproduces the content of a coding interview, not its conditions. The fix isn't to stop using LeetCode; it's to occasionally run the exact same problems under a real clock, no-pause, narrated out loud, which turns the same content into actual interview-shaped practice.
Versus a friend's WhatsApp PDF of interview questions. Useful as a checklist, harmful as a substitute for production. Reading someone's polished written answer to "tell me about a conflict you resolved" tells you what a good answer looks like; it does nothing to train you to produce your own answer, live, under a clock, with a follow-up. Use the PDF to pick topics, then close it and rehearse under real conditions.
Versus generic ChatGPT prompting. Asking an LLM "give me a mock interview question" and then quietly thinking through an answer in your head reproduces almost none of the five conditions — there's no real clock pressure unless you impose it yourself, no audience, and critically, no genuine follow-up unless you specifically prompt for one and then actually treat the exchange as live rather than something you can edit and resend. It's a content generator, not a conditions simulator, by default.
Versus a real (or AI-driven) mock interview. This is the prep method that comes closest to reproducing all five conditions simultaneously, which is exactly why it tends to produce the largest single jump in real interview performance per hour invested. A mock interview has a real clock, a real audience (human or AI), no pause button on the actual conversation, and — critically — real follow-up questions that you didn't write yourself and can't predict, which is the one condition almost nothing else reproduces. Greenroom runs spoken mock interviews specifically built around this principle: a live clock, a voice conversation with no pausing to type or Google, and follow-up questions generated from your actual answer — including questions about your real GitHub projects — rather than a fixed script you could memorize in advance. The honest tradeoff: a mock interview takes more setup and more nerve than reading an article, which is exactly why most candidates under-invest in it relative to how much it actually moves the needle.
Building a practice-like-you-play routine
Audit your current practice for which of the five conditions it's missing. For most candidates, the honest answer is three or four of the five — most solo prep has no real clock, allows pausing, has no audience, and definitely has no real follow-up question. Naming the gap precisely is the first step, because it tells you exactly what to add, rather than vaguely "practicing more."
Add one condition at a time if a full rebuild feels overwhelming. Start with the clock — it's the easiest to add to literally any existing study habit, costs nothing, and immediately changes your decision-making in a way you'll notice within a single session. Then add no-pausing. Then add narrating out loud. Audience and real follow-up questions are the hardest to self-supply, which is exactly why they're worth specifically seeking out — a study partner, a mock interview, a recorded session you commit to reviewing critically.
Reserve your highest-fidelity practice for the final week before a real interview. You don't need every single study session to reproduce all five conditions — that's exhausting and not how skill-building actually progresses. Early in prep, building raw content knowledge (what is a hash map, how does sharding work) matters more, and the Feynman Technique is the right tool for that phase. As the real interview approaches, shift the ratio toward full-condition rehearsal — clock running, no pausing, out loud, with a real follow-up — so the last thing you've practiced most recently is the thing closest to what you'll actually face.
Treat the discomfort as the signal, not the problem. Practice-like-you-play sessions feel harder and less pleasant than passive review — that's not a sign you're doing it wrong, it's the entire mechanism. The discomfort of a real clock, an audience, and a follow-up you can't predict is precisely the thing you're training your nervous system to tolerate, so that the same discomfort in the actual interview registers as familiar rather than novel.
Common objections, answered honestly
"This sounds exhausting — do I really need to do this for every topic?" No. Practice-like-you-play is a finishing layer, not a replacement for the bulk of your study time. Most of your hours should still go toward building real content knowledge at whatever pace lets you actually learn — slowly, with pauses, looking things up freely. Reserve full-condition rehearsal for your highest-priority topics and for the final stretch before a real interview, where the return on closing the conditions gap is highest per hour invested.
"I don't have a study partner or money for a coaching service — is solo game-speed practice even worth it?" Yes, partially. You can self-supply the clock, the no-pausing rule, and the out-loud narration entirely on your own, and those three conditions alone close a meaningful share of the gap. The audience and real-follow-up conditions are harder to self-supply convincingly — recording yourself and reviewing critically gets you partway there, but it's not a full substitute for a real listener who can react and probe unpredictably. Do what you can solo, and treat finding at least occasional access to a real listener (a friend, a free mock interview, an AI-driven one) as worth prioritizing precisely because it's the hardest condition to fake.
"Won't practicing under pressure constantly just make me more anxious, not less?" The opposite, reliably. Anxiety in performance situations is driven largely by unfamiliarity and uncertainty about how you'll react — and repeated, deliberate exposure to a manageable version of the same pressure is the standard, evidence-backed way to reduce that anxiety over time, the same mechanism behind exposure-based approaches to performance anxiety in music and sport. The first game-speed practice session usually feels worse than passive review. The fifth one usually feels close to routine, because your nervous system has started treating the conditions as familiar rather than novel.
"What if I just freeze during a game-speed practice session — doesn't that mean it's not working?" It means it's working exactly as intended. Freezing during low-stakes practice, where the only cost is mild discomfort, is enormously cheaper than freezing during a real interview, where the cost is a missed offer. The entire value of rehearsing under realistic conditions is that the failures happen somewhere safe to fail, with time left to adjust, rather than for the first time when it actually counts.
A worked weekly schedule
Early prep phase (3+ weeks out). Mostly content-building — learning topics, working through problems at your own pace, using the Feynman Technique to verify real understanding. One game-speed session per week to start calibrating what "under pressure" actually feels like for you specifically.
Middle phase (2 weeks out). Roughly even split — half your sessions still building content, half run under full game-speed conditions: timed, no-pause, narrated out loud, with a forced follow-up at the end of each one.
Final week. Almost entirely game-speed. This is the week to run full mock interviews — ideally with a real follow-up question generator, human or AI — on your weakest two or three topics, plus a full timed run-through of your strongest behavioral stories with an actual listener.
Day before. One light, full-condition run — timed, out loud, one coding problem, one behavioral story — and then stop. The goal isn't to cram new content the night before; it's to make sure the last rehearsal your nervous system remembers is a successful one under real conditions, not a frantic, untimed, last-minute read-through that reintroduces exactly the practice/performance gap this whole approach is designed to close.
Building the habit without burning out
There's a real risk in taking this principle too literally: turning every single study session into a high-pressure simulation is a fast route to burnout, and burnout produces worse interview performance than an imperfect but sustainable practice routine. The goal is not maximum discomfort at all times — it's matching your practice conditions to your actual goal for that session, and being honest about which goal you're pursuing on any given day.
A useful mental split: separate your sessions explicitly into "build" sessions and "rehearse" sessions, and don't blur them. A build session's job is to add new knowledge or skill — slow, low-pressure, pauses allowed, looking things up encouraged, because the goal is learning efficiency, not performance simulation. A rehearse session's job is to test whether knowledge you already believe you have survives real conditions — clock running, no pausing, out loud, with a follow-up. Doing a rehearse session on material you haven't actually built yet is just frustrating and teaches you little, since you're testing performance on a skill that doesn't exist yet. Doing only build sessions, indefinitely, is the original problem this entire guide is about.
A reasonable cadence for most candidates: three or four build sessions for every one rehearse session early in prep, shifting toward roughly even by the middle of the prep window, and mostly rehearse sessions in the final week. This isn't a rigid formula — the right ratio depends on how much raw content you still need to learn versus how much you've already learned but never pressure-tested — but it's a far better default than either extreme (all passive review until the week before, or grinding high-pressure simulations from day one before you have anything solid to rehearse).
It's also worth normalizing that a rehearse session can be short. A single timed, no-pause, out-loud run-through of one coding problem with a forced follow-up takes maybe 30 minutes including the follow-up discussion. A full behavioral story under a clock with a partner takes five minutes per story. The barrier to doing this regularly is almost never time — it's the mild social and psychological friction of doing something that feels more exposed than quietly reading notes. Naming that friction explicitly, and treating it as the actual target of the exercise rather than an unpleasant side effect, makes it easier to keep the habit going past the first uncomfortable week.
Frequently asked questions
What does "practice like you play" mean for interview preparation?
"Practice like you play" is a sports-training principle, applied to interviews, that says you should rehearse under conditions matching the real performance environment — a real clock, no pausing to look things up, an audience, and real follow-up questions — rather than passive, low-stakes study. It works because skill built under one set of conditions transfers only partially to a different set of conditions, and most solo interview prep accidentally trains the wrong conditions entirely.
Why doesn't solving LeetCode problems alone, untimed, prepare me for a real coding interview?
It builds real pattern recognition and problem-solving knowledge, which matters — but it reproduces almost none of the conditions a real interview actually tests: no clock, the ability to pause and look things up, no audience, and no follow-up questions. The fix isn't to stop solving problems; it's to occasionally rehearse the same problems under a real clock, with no pausing, narrated out loud, so the practice conditions match the interview conditions.
Which condition matters most to rehearse — the clock, the audience, or follow-up questions?
Follow-up questions are arguably the hardest condition to self-supply and the one most solo practice methods structurally cannot reproduce, which makes it the highest-leverage gap to close — typically through a study partner or a mock interview. That said, all five conditions (clock, no pausing, audience, follow-ups, real stakes) compound, and a candidate who's only fixed one of the five will still feel a noticeable gap on interview day.
How is a mock interview different from reading model answers to common questions?
Reading a model answer trains recognition — you can confirm a good answer sounds right when you see it. A mock interview trains production under real conditions: a clock, an audience, no pausing, and crucially, a real follow-up question you didn't write yourself and can't fully predict, which is exactly the condition a real interviewer will introduce and a static model answer never can.
Should I practice under full game-speed conditions from the very start of my prep?
No — early in prep, when you're still building raw content knowledge (what a concept is, how an algorithm works), low-pressure study and techniques like the Feynman Technique are more efficient. Shift the balance toward full game-speed conditions — timed, no pausing, out loud, with real follow-ups — as the actual interview date approaches, so your most recent and most vivid rehearsals are the ones that most closely match what you'll really face.
Can I simulate an audience and follow-up questions if I don't have a study partner?
Partially — recording yourself and committing to review it critically simulates some of the audience effect, and asking yourself the follow-up question an interviewer would likely ask immediately after every answer simulates some of the probing effect. Neither fully replaces a real listener who can react and interrupt unpredictably, which is why a mock interview — human or a well-built AI one — closes a gap solo practice structurally can't.