The Interview Prep Checklist: A Printable Plan for the Days Before

How to use this checklist

Most interview failures are not knowledge failures. They are preparation failures: the candidate who forgot to test their webcam, who never practised saying their own story out loud, who walked in without one researched question for the interviewer. Knowledge gaps you can rarely close in a week. Preparation gaps you can close in an afternoon. This checklist is built around that distinction. It is deliberately mechanical, because the point of a checklist is to move decisions out of your head and onto paper so that nothing depends on you remembering it under pressure.

Print this page, or copy the boxes into a notes app, and tick items off as you go. The plan is split into five windows: four weeks out, the week before, the day before, the morning of, and immediately after. If you have less than four weeks, start wherever you are and compress. The later sections matter more than the earlier ones, because a calm, well-rehearsed candidate with a few gaps beats a panicked expert every time.

This is general preparation guidance, not a guarantee of any outcome. Adapt it to your role, your seniority, and the specific company. A staff-level system design loop and a graduate coding screen need very different emphasis, and the role-specific question sets linked at the end of this guide will tell you where to put your hours.

What good preparation actually looks like

Before the checklist items, it helps to know what you are aiming for. Good preparation has three properties: it is specific to the format you are actually facing, it is spaced across time rather than crammed, and it builds fluency rather than memorisation.

Specific. If you do not know whether round three is a system design or a domain-specific technical discussion, you are guessing. A well-prepared candidate has confirmed the format in writing, knows the interviewer's likely background, and has tailored their examples to what that panel will value.

Spaced. Forty hours of prep spread across four weeks produces better recall under pressure than forty hours the week before. The reason is consolidation: your brain solidifies material during sleep. One focused hour each weekday for four weeks beats a weekend binge every time.

Fluent, not memorised. An interviewer can tell when someone is reciting a rehearsed script. The goal is to know your material well enough that you can adapt it on the fly, not to deliver it verbatim. You want answers that feel spontaneous but are actually well-structured.

Preparation is not about eliminating uncertainty. It is about reducing the number of things that can surprise you, so your cognitive capacity on the day goes to the hard, novel parts of the conversation rather than to logistics and nerves.

What weak preparation looks like

It is worth naming the failure modes explicitly, because most candidates make at least one of them.

• Doing only the comfortable parts. Reading about data structures without actually writing code under a timer. Thinking about your STAR stories without saying them out loud.
• Treating research as a box-ticking exercise. Skimming the company's About page and calling it done, rather than reading the engineering blog, recent product launches, or public talks from the team.
• Confusing knowledge with performance. You can know every sorting algorithm and still perform poorly because your mind goes blank under pressure, or because you cannot explain your reasoning while your hands are typing.
• Over-engineering the prep and under-delivering on the fundamentals. Spending hours on edge-case system design scenarios while never rehearsing the two-minute introduction that opens every loop.
• Neglecting logistics until the last minute. Discovering on the morning of the interview that the video platform requires a browser extension, or that the office entrance is on a different street from the postcode.

Four weeks out: build the foundation

This is the only window where you can genuinely move your skill level, so spend it on the hardest, slowest-to-improve things first.

• Confirm the format in writing. Email the recruiter and ask exactly what each round covers: coding, system design, behavioural, take-home, domain-specific. Ask how long each is and what tools you will use (their platform, a shared editor, a whiteboard). You cannot prepare for a format you are guessing at.
• Map the gap. List the topics each round will test, then rate yourself honestly on each. Your prep time goes to the lowest-rated, highest-weighted topics, not to the ones you already enjoy.
• Schedule daily reps, not a weekend cram. Spaced practice beats one long session. Block thirty to sixty minutes a day for the slow-to-build skills: coding patterns, system design fundamentals, or your domain.
• Start a story bank. Write down six to eight real situations from your work that show impact, conflict, failure, leadership, and ambiguity. You will reshape these into answers later; right now just get the raw material on paper.
• Do one timed mock per week. Untimed practice hides the thing that actually breaks in interviews: the clock. A weekly timed run, ideally with another person, surfaces your real failure modes early enough to fix them.
• Research the company properly. Read the product, the engineering blog, recent news, and the values. Note two or three specifics you can reference naturally. This is the raw material for "why this company" and for your questions to the interviewer.

The week before: rehearse and tighten

Skill is mostly set by now. This week is about turning what you know into smooth, repeatable performance.

• Rehearse your two-minute story out loud. "Tell me about yourself" opens most loops and sets the tone. Say it aloud until it is fluent and under two minutes. Reading it silently is not rehearsal.
• Convert your story bank into STAR answers. For each of the six to eight situations, structure it as Situation, Task, Action, Result, and make sure the Result has a number or a concrete outcome. Practise the three or four most likely ones out loud.
• Drill your weakest technical area one more pass. Do not start anything new this week. Reinforce the patterns you already half-know so they are reliable under pressure.
• Prepare three questions for the interviewer. Make them specific to the team and the role, not generic. Good questions signal genuine interest and give you information you actually need.
• Write your "why this company" and "why this role" answers. Anchor them to the specifics you researched, not to flattery. Two or three honest sentences each.
• Do a full dress-rehearsal mock. One end-to-end run under real conditions: same time of day if you can, camera on, no notes you would not have on the day.

The day before: logistics and rest

The day before is not for cramming. Cramming before a cognitively demanding interview trades a tiny knowledge gain for a large performance loss. Spend today removing every source of morning-of friction.

• Test the technology. For a remote interview, test the exact platform link, your camera, your microphone, your headphones, and your internet on the device you will actually use. Restart the machine so updates do not ambush you mid-call.
• Set up your space. Tidy, neutral background, good front-facing light, phone on silent and out of reach, a "do not disturb" note on the door. Have water within reach.
• Lay out everything physical. For an onsite: clothes, ID, printed directions, the building and floor, the contact's name and number, and travel time with a buffer. For remote: a charged laptop and a backup way to join (phone hotspot, dial-in number).
• Re-read the basics, lightly. A calm fifteen-minute skim of your STAR answers and your questions list is fine. A three-hour panic session is not.
• Plan the timeline. Know exactly when each round starts, factoring in time zones for remote loops. Set two alarms.
• Sleep. A rested brain recalls and reasons far better than a tired one that crammed. This is the single highest-return item on the entire list.

The morning of: arrive calm

The goal this morning is to walk in regulated, not wired. Small physical habits do more for your performance than any last-minute fact.

• Eat something steady. Avoid a sugar spike and crash. You want even energy for sixty to ninety minutes.
• Arrive or log in early. Ten minutes early for remote, fifteen to twenty for onsite. Early means you absorb a small delay without panic; late poisons the first impression before you say a word.
• Do a two-minute reset. Slow breathing for a couple of minutes genuinely lowers the physical symptoms of nerves. A shaky voice and a racing mind are largely a breathing problem.
• Have your anchors visible. Your two or three interviewer questions and the headline of each STAR story on a single sticky note, where you can glance without reading from a script.
• Warm up your voice. Say a few sentences out loud before you join so your first words are not the first you have spoken all day.
• Reframe the nerves. The physical sensation of anxiety and of excitement is nearly identical. Naming it as readiness rather than dread measurably helps. You prepared for this; now you get to show it.

Immediately after: close the loop

The work is not quite done when the call ends.

• Note what came up while it is fresh. Write down the questions you were asked and where you stumbled. This is gold for the next round and the next company.
• Send a short thank-you within a day. Two or three genuine sentences referencing something specific from the conversation. It is a small, polite signal that costs nothing and occasionally tips a close decision.
• If an offer follows, do not negotiate from the gut. Check whether it is competitive against real market data before you respond, and counter in writing rather than on the spot.
• Do a debrief regardless of outcome. Even if you get a rejection, request feedback from the recruiter. You will not always get it, but when you do it is more valuable than any third-party advice.

A fully worked example: one candidate's prep

The following is a realistic scenario for a mid-level backend engineer interviewing at a mid-size fintech, with a four-week runway.

The format (confirmed week one): two technical rounds (one live coding, one system design), one behavioural panel, one hiring manager conversation. Live coding is in a shared editor, no IDE, Python or Go only.

Week one actions:

• Rated themselves: dynamic programming (weak), system design for financial data (medium), behavioural storytelling (medium). No work done on graph problems in two years.
• Blocked 45 minutes each weekday morning before work.
• Started a story bank with seven situations: a production incident they led, a scope disagreement with a PM, a performance optimisation that reduced latency by 40%, a failed project and what they learned, two examples of mentoring, and a time they pushed back on a deadline.
• Did a timed LeetCode session on Saturday: struggled badly with tree recursion under time pressure.

Week two and three actions:

• Focused coding practice on trees, graphs, and DP patterns. Used a spaced-repetition approach: solved a problem, wrote the pattern in their own words, revisited it two days later.
• Drafted system design notes for a payment processing pipeline, a fraud detection feed, and a notification service. Practised talking through the design out loud, timing the key sections.
• Converted three story bank items into STAR format, with specific numbers in the Result section. Recorded themselves on a phone and listened back; noticed they rushed the Action section and buried the actual outcome.
• Did two peer mocks with a friend who had recently gone through a similar process. Both mocks revealed a habit of solving silently rather than narrating thinking, which would look like a black box to the interviewer.

Week four actions:

• No new topics. Reinforced the weak DP patterns until they felt reliable, not just familiar.
• Rehearsed the two-minute introduction until it was fluent at 1 minute 45 seconds with a natural pause before the "what I am looking for next" section.
• Prepared five questions for the interviewers, split across the technical rounds and the hiring manager conversation. The best one: "What does the on-call rotation look like for this team, and how has it changed in the last year?"
• Did a final dress-rehearsal mock three days before, not the day before, so there was time to notice and fix any remaining rough edges.

The day before: Tested Zoom, set up the desk, laid out a notepad. Skimmed STAR answers for fifteen minutes. Slept eight hours.

The morning of: Ate a proper breakfast. Logged in nine minutes early. Said a few sentences out loud to warm up. Had a single sticky note with the headlines of three STAR stories and two of the prepared questions.

Outcome: Passed the technical rounds. Stumbled slightly on a DP problem but narrated the reasoning clearly enough that the interviewer followed the approach. The behavioural panel went well; the specific numbers in the stories helped. Received an offer five days later.

The candidate's own summary of what made the difference: "Narrating my thinking out loud was the thing I was worst at before the mocks. Fixing that one habit changed both rounds."

How this checklist differs by role and seniority

The phase structure above applies broadly, but the weight of each section shifts significantly depending on what you are interviewing for.

One general principle: the more senior the role, the more the interviewer is evaluating how you think, not just whether you know the answer. At staff level, a strong candidate who says "I would want to understand the write-to-read ratio before committing to this architecture" will score higher than a junior candidate who jumps to a solution without asking.

Remote vs onsite: the differences that actually matter

The core prep is identical. What differs is the logistics layer and the dynamics of the conversation.

Remote-specific checklist additions:

• Test the platform the company uses, not a different video tool. Some companies use proprietary interview platforms that behave differently from Zoom or Google Meet.
• Check your lighting. Overhead lighting casts shadows that make you look tired. A lamp positioned in front of you, at eye level, makes a visible difference.
• Remove distractions from your desktop. Close every tab and application you are not using. A notification popping up mid-answer is a small but unnecessary distraction.
• Know the dial-in backup number. If the internet drops, you need to rejoin in under thirty seconds, not in two minutes while you find the email.
• Position your camera at eye level or slightly above. Looking up into a webcam makes you appear more engaged than looking down at a laptop screen.

Onsite-specific checklist additions:

• Do a dry run of the journey if you have not been to the building before. Knowing the entrance, the reception process, and whether you need ID saves you from a slow, flustered arrival.
• Build in buffer for security or reception. Some offices have badge processes that take five minutes. Arriving twenty minutes early and sitting nearby is better than rushing through reception at T minus two.
• Bring something to write on. Even if the interview is mostly on a whiteboard, having your own notepad means you can jot the question down before answering, which signals you are being careful.
• Manage your energy across a multi-round loop. An onsite is often three to five back-to-back rounds with short breaks. Eat something before you go in and accept water when it is offered.

Common mistakes to avoid

These appear repeatedly across candidates at every level.

Preparing answers, not conversations. A rehearsed answer is a starting point. If the interviewer asks a follow-up and you cannot adapt, it signals that the answer was memorised rather than understood. The test is always whether you can go one level deeper when pushed.

Practising without feedback. Solving a coding problem on your own tells you whether you got the right answer. It does not tell you whether you communicated your thinking, whether you asked good clarifying questions, or whether you would have failed on time in a real setting. You need at least two timed mocks with another person before the real thing.

Spending prep time on the wrong signal. The behavioural round is not a soft round. At most companies above a certain size, it carries as much weight as the technical rounds and is often the deciding factor in close calls. Candidates who treat it as an afterthought frequently lose offers they could have won.

Confusing "I could answer that" with "I can answer that fluently under pressure." The gap between knowing the answer in your head and delivering it clearly while someone is watching you, with a timer running, is larger than most candidates expect until they experience it. The only way to close it is to practise under those conditions.

Asking no questions, or asking only compensation questions. "Any questions for me?" is an opportunity to signal genuine curiosity and to gather information you need. Asking nothing suggests low interest. Asking only about salary at that stage suggests you care only about the offer, not the role. Prepare questions that show you have thought about the work itself.

FAQ

How long before an interview should I start preparing? Four weeks is comfortable for most roles. Two weeks is tight but workable if you have no major gaps. Less than a week means the focus shifts entirely to logistics and rehearsal; skill-building is off the table.

Should I prepare differently for a startup vs a large tech company? Yes. Large companies with structured hiring processes have predictable formats: you can find reliable accounts of what each round covers. Startups vary more. Confirm the format in writing and ask whether there is a take-home or a portfolio review. The behavioural content also differs: at a startup, expect questions about working with ambiguity, scope changes, and wearing multiple hats.

Is it worth doing a take-home project if the company offers an alternative? That depends on your strengths. A take-home lets you work at your own pace and show polished, well-commented code. A live coding session gives you less time but removes the risk of over-engineering. If your strongest signal is code quality rather than speed, the take-home is usually the better choice.

How many behavioural stories do I need? Six to eight distinct situations is the sweet spot. Fewer than that and you will repeat yourself across a multi-round loop or get caught without a good answer for an unexpected question type. More than ten and they become hard to recall quickly under pressure.

What if I blank on a question during the interview? Say so, calmly. "I would like to think through this for a moment" is not a red flag. Silence for three seconds while you organise your thoughts is normal. What is not normal is saying "I don't know" and stopping. A stronger response is: "I haven't solved this exact type of problem before, but here is how I would approach breaking it down." Show your reasoning, even when you are uncertain.

Is sending a thank-you email actually worth it? Rarely the deciding factor, but occasionally the tiebreaker. It signals professionalism. Keep it to three sentences, reference something specific from the conversation, and send it within twenty-four hours.

Continue your prep

A checklist works best when it points at the specific things you still have to practise. Once you have confirmed your format, go straight to the role-specific question sets below and spend your daily reps where the gap is widest. Pair the behavioural items above with worked STAR examples, and when an offer arrives, use the salary and offer tools to make sure the number is right before you accept.

• Browse interview questions by role to target your weakest round.
• Work through behavioural questions with STAR example answers.
• When an offer lands, check it with the free offer evaluator and prepare your reply with the counter-offer email templates.