30-Day Technical Interview Prep Plan (Free Checklist)
Four weeks of structured drills, mock rounds, equipment checks and taper days, each with the time it takes and the setting it belongs in.
By Sofia Bauer · Sep 29, 2026 · 13 min read
By the end of this guide you'll have a dated, hour-by-hour plan for the four weeks before a technical interview: what to drill, when to be observed, what to rehearse out loud, and what to send afterwards. Every item has a time attached so you can see whether it fits your week.
Interviews exist to test qualifications, abilities, motivation and fit with the team (CareerOneStop, sponsored by the US Department of Labor). A plan that only builds coding speed leaves three of those four untested, so this one splits your time between problems, speaking and logistics.
Before
Days 1–3: measure where you actually are
- Block one 90-minute session and solve two unseen problems with a visible timer set to 35 minutes each. No searching, no editor autocomplete. Mark each one: solved clean, solved with hints, or not solved.
- Paste every target job description into a single document and highlight each named technology. Anything named twice goes on a study list; anything named once goes on a "recognise and discuss" list. Cap the study list at six items.
- Create one file called `mistakes.md`. One line per failure: the problem, the wrong assumption, the fix. You will read this file more often than any textbook.
- Ask one engineer doing the job you want for a short informational chat, and keep it to the slot you asked for — CareerOneStop, which is sponsored by the US Department of Labor's Employment and Training Administration, advises keeping informational interviews short. Ask two questions only: what the rounds are, and what candidates get wrong.
Days 4–14: core drills, 60–90 minutes a weekday
- Two timed problems each weekday: one at 25 minutes on a topic you already handle, one at 45 minutes on a weak topic from your audit. Stop when the timer stops, even mid-function, then write the log line.
- Solve out loud at conversational volume, sitting at the desk you'll actually interview from. A silent rehearsal is the one that collapses in the room.
- Every seventh day, re-solve three problems from `mistakes.md` from scratch with a 20-minute cap. If one fails twice, spend a full 45 minutes on the underlying concept the next morning.
- Twice a week, 30 minutes on fundamentals your target list names — complexity, memory model, transactions, concurrency, HTTP. Write the definitions by hand on paper; you should be able to say each in two sentences.
- One 40-minute design exercise per week, standing at a whiteboard or on plain paper: 5 minutes on requirements, 10 minutes on high-level boxes, 15 minutes deep on a single component, 10 minutes on failure modes and trade-offs.
Days 15–24: rehearsal under observation
- Book at least three mock interviews of 45–60 minutes with someone allowed to interrupt you. If you're in the US, you can ask a local American Job Center about a free interview workshop or mock interview to practise and get feedback (CareerOneStop).
- Record two practice sessions and watch them back with the sound on (CareerOneStop recommends recording yourself during virtual interview practice). Count the silences longer than about ten seconds, and mark every moment you started typing before stating an approach.
- Write a 60–90 second answer to "tell me about yourself" — CareerOneStop suggests preparing a short summary of your work background — and say it aloud five times, standing up, without notes. Then prepare five behavioural stories, each with a system, your scope and a measurable result.
Backend engineer, four years' experience, applying to a payments team
I'm a backend engineer. For the last three years I've worked on the order service at a logistics company — Java and Postgres, about forty services around us, and I owned the part that turns a booking into a set of shipment records. The work I'd point to is a rewrite of our retry handling: duplicate shipments were reaching carriers whenever a downstream timeout hit, and support was manually cancelling them most weeks. I added idempotency keys, moved retries onto a queue with backoff, and wrote the replay tool. Duplicates stopped appearing in the weekly support report, and the on-call pages for that service dropped to roughly one a month from several a week. I'm applying here because payments is the same problem with stricter guarantees, and I'd like to work where correctness is the product.
- Prepare four questions for the interviewer: how code gets reviewed, how on-call works, how the team decides what to build, and what the first 90 days look like. Keep pay and benefits off that list — CareerOneStop advises discussing them once you've been offered the job rather than during the interview.
Days 25–28: the logistics rehearsal
- Do one 15-minute equipment run-through at the same hour your interview is scheduled: camera, microphone, internet connection, screen share and the actual coding tool the company uses. CareerOneStop advises setting up equipment early and checking you have a good connection, closing extraneous applications and browser tabs, muting notifications, and being ready to sign on before the start time.
- Lay out a plain-coloured top rather than a patterned shirt — patterns can distract on camera (CareerOneStop).
- For an in-person round, pack a notebook and pen and leave the water bottle or coffee at home (CareerOneStop). Plan to turn the phone off, not to silent, before you go in.
- Map the journey once at the same time of day and add 30 minutes. Plan to arrive early enough to complete any paperwork before the interview starts (CareerOneStop).
Days 29–30: taper
- No new topics. 45 minutes re-reading `mistakes.md`, then one 25-minute easy problem to keep your hands warm.
- Reread the job description once and write, in one sentence, why this team and not another. Print your questions and put them in the notebook.
- Two nights of full sleep and a real meal beforehand. Recall degrades faster than knowledge does.
During
- Restate the problem in your own words in under 60 seconds, then say the constraints back: input size, types, whether duplicates or nulls are possible.
- Ask two clarifying questions before you write anything, and write the answers in your notebook so you can point at them later.
- Say the brute-force solution first with its time and space complexity, then say the one property you'll exploit to improve it.
- Take the pause you need. Developing an answer in your head before you respond is normal, and it's fine to take time before answering (CareerOneStop).
- Cap silence at about 20 seconds. Then say what you're weighing: "I'm choosing between a hash map and sorting first — sorting costs me the original indices."
- Write one small test case by hand before you run anything, including an empty and a single-element input.
- Trace your code line by line against that case, out loud, pointing at the line you're on.
- When you're stuck for five minutes, say so and ask for a nudge directly: "I've got a working approach at O(n²); would you rather I optimise it or move to the follow-up?"
- When corrected, say what you changed and why, rather than silently editing.
- In a design round, state your assumptions as numbers you chose — request volume, data size, growth — and label them as assumptions.
- Name the trade-off you rejected, not only the one you picked.
- Write down the interviewer's name and one specific thing they said; you'll use both in the follow-up note.
- Shake hands firmly if a hand is offered to you first (CareerOneStop) — and keep the phone switched off in your bag, not face-down on the table.
- Leave pay, holiday and remote policy for the offer conversation, however naturally the topic arises.
After
- Within two hours, while it's fresh: add the round to `mistakes.md`. The question, where you stalled, what you'd do differently, and any topic the interviewer probed twice.
- Within 24 hours: send a thank-you note by email or mail to the person who interviewed you, restating your interest in the job (CareerOneStop). Keep it to three short paragraphs and reference the specific thing they said.
- In the same note, if you got something wrong, add a two-to-four sentence correction: the fixed approach and its complexity. Don't attach a rewritten solution unless they asked for one.
- Within 24 hours: anything you promised — a repo link, a portfolio piece, a reference list, a code sample — sent in one message, not trickled.
- To the recruiter, same day: a one-line note asking when you should expect to hear back and what the next stage is.
- One follow-up, sent two or three working days after the date they gave you, in four sentences. Then a single check-in a week later. Nothing after that.
- If an offer comes, that's the point to raise pay, benefits and start date — CareerOneStop advises leaving those until the job is offered.
- If it's a no, reply once: thank them, ask which area they'd want stronger, say you'd welcome being considered again. Add whatever they tell you to `mistakes.md` and start the next cycle from the Days 4–14 block, not from Day 1.
What to avoid
| Mistake | Why it backfires | Fix |
|---|---|---|
| Chasing problem volume with no record of failures | You re-fail the same three concepts for a month and feel busy doing it, because nothing forces you to revisit them | One line in `mistakes.md` per miss; re-solve three of them from scratch every seventh day |
| Coding in silence until it works | The interviewer is scoring your reasoning as well as your output; silence reads as guessing, and a wrong turn goes uncorrected for ten minutes | State the approach and its complexity before your first keystroke, and narrate any pause longer than about 20 seconds |
| Typing before clarifying input size, nulls and duplicates | You produce a correct solution to a problem you weren't asked, and there's no time left to redo it | Spend 60 seconds restating the problem and ask exactly two clarifying questions first |
| Treating the tooling as trivial | Ten minutes lost to a microphone, a locked screen share or an unfamiliar editor comes out of your solving time, not theirs | Run a 15-minute rehearsal on the real tool, close spare apps and tabs, mute notifications and be signed on before the start time (CareerOneStop) |
| Asking about salary, holiday or remote days in the technical round | It signals you're weighing the terms before the work, and the interviewer usually can't answer anyway | Note the question down and raise it once an offer is on the table (CareerOneStop) |
| Adding a new topic in the last three days | Cramming displaces sleep and crowds out the material you can already retrieve under pressure | Days 29–30 are review only: `mistakes.md`, one easy timed problem, your questions printed |
Checklist
Days 1–3 — baseline
- [ ] 90-minute audit: two unseen problems, 35 minutes each, scored
- [ ] Job descriptions highlighted; study list capped at six items
- [ ] `mistakes.md` created
- [ ] One short informational chat booked, two questions prepared
Days 4–14 — drills
- [ ] Two timed problems per weekday (25 min strong topic, 45 min weak topic)
- [ ] Every session solved out loud at the desk you'll use
- [ ] Weekly: three problems re-solved from `mistakes.md`, 20-minute cap
- [ ] Twice weekly: 30 minutes of fundamentals, written by hand
- [ ] Weekly: 40-minute design exercise (5/10/15/10 split)
Days 15–24 — observed rehearsal
- [ ] Three mock interviews booked, 45–60 minutes, interruptions allowed
- [ ] Local mock-interview or workshop options checked (American Job Center, if you're in the US)
- [ ] Two sessions recorded and watched back
- [ ] 60–90 second work-background summary said aloud five times
- [ ] Five behavioural stories written with scope and result
- [ ] Four questions for the interviewer written; pay and benefits left out
Days 25–28 — logistics
- [ ] 15-minute equipment run-through on the real tool, at the real hour
- [ ] Spare apps and tabs closed, notifications muted, sign-on before start time
- [ ] Plain-coloured top laid out, no pattern
- [ ] Notebook and pen packed; no water bottle or coffee for in-person
- [ ] Phone off, not silent
- [ ] Route timed plus 30 minutes; early enough for paperwork
Days 29–30 — taper
- [ ] No new topics; 45 minutes on `mistakes.md`
- [ ] One 25-minute easy problem
- [ ] Job description reread; one sentence on why this team
- [ ] Two full nights of sleep, meal before
In the round
- [ ] Problem restated in under 60 seconds
- [ ] Two clarifying questions asked and written down
- [ ] Brute force stated with complexity before optimising
- [ ] Silence capped at ~20 seconds
- [ ] One hand-written test case, traced out loud
- [ ] Hint asked for after five minutes stuck
- [ ] Trade-off you rejected named
- [ ] Interviewer's name and one quote noted
Afterwards
- [ ] Log entry written within two hours
- [ ] Thank-you note sent within 24 hours, interest restated
- [ ] Promised links or samples sent in one message
- [ ] Recruiter asked about timeline
- [ ] One follow-up after the stated date, one check-in a week later
- [ ] Pay discussion reserved for the offer stage
Frequently asked questions
I only have ten days, not thirty. What do I cut?
Keep three things: the timed daily problems, one observed mock round, and the full logistics rehearsal. Cut breadth first — drop the "recognise and discuss" list, drop the weekly design exercise to one session, and don't start any topic you've never seen. Compress the taper to one day rather than two. The parts people cut first, mocks and equipment checks, are the ones that cost interviews.
How many practice problems a day is enough?
Two timed problems plus the log entries is a workable weekday load for most people, because the reviewing is where the learning happens. If you finish both in under an hour, add difficulty rather than volume: longer time limits, harder follow-ups, or solving with no editor hints. Doing eight problems you never revisit tends to build speed on patterns you already knew.
Should I prepare for the company's specific stack?
Prepare enough to talk about it, not enough to claim it. Highlight the technologies named in the job description, learn what problem each one solves and one trade-off it makes, and be ready to say honestly which you've shipped with and which you've only read about. Most technical rounds let you choose your language, but confirm that with the recruiter before day 25 so your drills match.
What if I'm asked something that feels off-limits?
Some questions are restricted, and what's restricted varies by country and region. In the US, CareerOneStop notes that employers cannot legally ask certain questions, including whether you've ever filed a Workers' Compensation claim or been injured on the job. You can answer the job-related concern behind a question rather than the question itself — for example, whether you can perform the duties described. For anything you think crossed a line, check the guidance of the relevant authority where you live; this guide isn't legal advice.
Sources
- CareerOneStop (U.S. Dept. of Labor) — Get ready to interview | CareerOneStop
- CareerOneStop (U.S. Dept. of Labor) — Interview Tips | CareerOneStop
- CareerOneStop (U.S. Dept. of Labor) — Interviews | GetMyFuture | CareerOneStop
- CareerOneStop (U.S. Dept. of Labor) — Practice interview questions | CareerOneStop
- CareerOneStop (U.S. Dept. of Labor) — Virtual interviews | CareerOneStop
- CareerOneStop (U.S. Dept. of Labor) — Informational interview | CareerOneStop
- CareerOneStop (U.S. Dept. of Labor) — Interview tips | Justice-Impacted | CareerOneStop
- CareerOneStop (U.S. Dept. of Labor) — Job Interview | CareerOneStop