Day-of playbook

Why a "playbook" at all — the one idea behind this lesson

A playbook is a pre-written set of moves you decide on before the pressure hits, so that in the moment you simply execute instead of deliberate. Sports teams use one; pilots use a checklist for the same reason. The insight that makes this lesson worth a page of its own is this: on interview day your raw ability — the algorithms you know, the patterns you can spot — is already locked in. Cramming a new technique at the last minute almost never lands, and trying to do so usually makes you more anxious, not more capable. What is still very much in your control are two things: your state (how rested, calm, and warmed-up you are) and your process (the visible sequence of moves you run from the first second to the last). This lesson is a timeline that scripts both, moment by moment, so the high-stress parts of the day become automatic rather than improvised.

Two terms used throughout that are worth pinning down up front. STAR is a four-part template for answering behavioral ("tell me about a time…") questions — Situation (the context), Task (what you needed to accomplish), Action (what you specifically did), Result (the measurable outcome). SoloMock is this guide's name for a mock interview you run alone: you read a problem, then narrate your entire thought process out loud — as if an interviewer were listening — to rehearse talking and coding at the same time, which is the skill most people never practice.

The night before: protect, don't cram

The strongest temptation the night before is to "get one more rep in" on a hard problem. Resist it. A brand-new problem you can't crack at 11pm does not teach you anything in time to matter — it just hands your brain fresh evidence that you are unprepared, and that doubt is exactly what derails people the next morning. The goal tonight is not to learn; it is to arrive tomorrow rested and confident. Three concrete things to do instead:

• Re-skim your STAR stories — read them, don't rewrite them. You are refreshing the shape of each story (the four beats) so they come out smoothly, not memorizing a script word-for-word (which sounds robotic and falls apart the moment the interviewer asks a follow-up).
• Confirm logistics — for a remote interview: test your camera, microphone, and the coding environment link; charge your laptop; know the exact time in your own time zone. For onsite: know the address, the building, and your travel time with a buffer. Logistics anxiety is avoidable anxiety.
• Protect your sleep — sleep is the single input with the largest swing on next-day reasoning, working memory, and mood. It does more for your score than any last-minute problem could. Stop screens early, set two alarms, and treat going to bed on time as part of the prep, not a luxury.

Why this matters: interviews test performance under load, and a sleep-deprived brain is measurably worse at exactly the things you'll be graded on — holding state in your head, catching your own mistakes, and staying composed when stuck. Trading an hour of sleep for an hour of frantic cramming is a bad deal every time.

Thirty minutes before: warm up the engine

A cold start is real. The first problem of the day is always slower and clumsier than your true ability, because your brain hasn't yet switched into "coding mode" — the loaded mental state where syntax, patterns, and your own voice all come easily. You do not want to burn that warm-up tax on the actual interview. So spend the half-hour before deliberately warming up:

• Solve one easy problem you've already solved. The point is not difficulty — it's momentum and confidence. Re-solving something familiar gets your fingers, your syntax recall, and your problem-solving rhythm all online. Pick something you can finish in 5–10 minutes.
• Do a 60-second SoloMock out loud. Narrate a quick problem to an imaginary interviewer. The single most important reason: you want the first time you hear your own voice explaining code to be in your bedroom, not on the call. Talking and thinking at once is a separate muscle, and this wakes it up.
• Clear the deck: water within reach, bathroom done, door shut, phone silenced, notifications off. Every one of these is a future interruption you are removing in advance. A dry throat or a buzzing phone mid-problem is a small thing that lands at the worst possible moment.

Why this matters: interviewers form an impression fast, and a fumbling, cold-start first ten minutes can color everything after it. Arriving already warm means the version of you they meet is your real one.

The first 60 seconds: open like a pro

How you open a problem is itself a graded signal. Diving straight into code tells the interviewer you might solve the wrong problem confidently; a deliberate opening tells them you'll clarify before you commit — which is exactly how good engineers work on real teams. The opening has three moves, in order:

1. Read the problem out loud, verbatim. Reading aloud forces you to actually process every word instead of skimming and assuming. It also slows you down enough to catch the constraint you'd otherwise miss.
2. Restate it in your own words. "So I'm given X, and I need to return Y — is that right?" This does two things at once: it confirms you understood, and it gives the interviewer a chance to correct a misread before you waste twenty minutes on it.
3. Ask exactly 2 clarifying questions. Good targets: input size and ranges ("Can the list be empty? How large can it get?"), and edge or tie-breaking rules ("Are duplicates allowed? What should I return if there's no answer?"). Two is the sweet spot — enough to show rigor, not so many that you stall.

A clarifying question is a question whose answer changes how you'd solve the problem (size affects the algorithm; duplicates affect the data structure). Asking about things that don't change your approach just eats time — aim for the questions that genuinely fork your solution.

If you get stuck: recover out loud

Everyone gets stuck — interviewers expect it and are watching how you handle it more than whether it happens. The failure mode that hurts you is silence: staring at the screen for two minutes gives the interviewer nothing to evaluate and signals that you freeze under pressure. The recovery move is to make your thinking audible:

• Name the wall out loud. Something like: "Let me back up — the bottleneck I'm not seeing is how to avoid re-scanning the array each time." Saying it converts a vague stuck feeling into a concrete sub-problem, and it lets the interviewer follow (and sometimes nudge) your reasoning.
• Walk a fresh, small example by hand. Take a tiny concrete input and trace what should happen step by step. Working a small case almost always surfaces the pattern your abstract thinking missed.
• It is fine to ask, "Would a hint help here?" This is not a confession of failure — it shows self-awareness and a willingness to collaborate, both of which are positive signals. Many interviewers plan to give hints and grade how well you use them.

Why this matters: the interview is partly a simulation of working together. An engineer who narrates the wall, probes a small case, and asks for help at the right moment is showing you the exact behavior you'd want from a teammate. Graceful recovery often scores higher than a silent solve.

The last five minutes: close strong

A working solution is not the finish line — the close is. Many candidates write correct code and then go quiet, leaving the interviewer to wonder whether the candidate even knows why it works. Spend your final minutes proving it does. Four moves:

• Trace your own code on an example. Pick a concrete input and walk line by line, saying what each variable holds. This is how you catch your own off-by-one bug before the interviewer does — which reads far better than them finding it.
• Volunteer 2 edge cases. An edge case is an unusual input that often breaks naive code: an empty list, a single element, all-duplicate values, negative numbers, the maximum allowed size. Proactively saying "let me check the empty-input case" shows you think about robustness, not just the happy path.
• State the final time and space complexity. Use Big-O notation — a shorthand for how runtime/memory grow as input grows (e.g. "this is O(n) time because I touch each element once, and O(1) extra space because I only keep a couple of variables"). Even a quick, correct statement signals you understand the cost of your approach.
• Offer one tradeoff. One sentence on an alternative and why you chose what you did: "I could sort first for O(n log n) and simpler code, but the hash-map version is O(n) at the cost of extra memory." This shows you see solutions as choices, not the one true answer.

Questions for them: end on the right note

Most interviews end with "Do you have any questions for me?" Treat this as part of the evaluation, not a throwaway — thoughtful questions signal genuine interest and that you're sizing up the team the way a serious candidate should. Have a few ready so you're never caught with "no, I think I'm good," which reads as disengaged. Strong, reusable options:

• "What does success in this role look like 6 months in?" — surfaces real expectations and shows you're thinking about delivering, not just getting hired.
• "What is the team struggling with right now?" — invites an honest answer and tells you what the day-to-day actually is.
• "What's the feedback rhythm like — how would I know if I'm doing well?" — signals you value growth and want to improve.

Common pitfalls to dodge

• Cramming the morning of. See "night before" — it adds anxiety, not ability. Warm up on the easy and familiar instead.
• Silent stalling. Two quiet minutes feels like nothing to you and like forever to the interviewer. Narrate, even when you're unsure.
• Coding before understanding. Skipping the restate-and-clarify step is the fastest way to solve the wrong problem beautifully.
• No close. Writing correct code and going silent wastes the easiest points on offer — trace, edge cases, complexity, tradeoff.
• "No questions for me." Always have two or three banked; it's a free signal of interest you'd be throwing away.