How to Prepare for a Technical Interview in 7 Days

You have a technical interview in a week and a job description in your inbox. The usual answer to how to prepare for a technical interview is to open a problem site and start grinding whatever comes up first. That feels productive and mostly isn't, because the job description already told you what they are going to test.

This guide turns one job description into a seven-day plan, step by step, with the full worked example. It assumes about two hours a day. If your interview is tomorrow, skip to what to do in the 24 hours before a technical interview instead.

Start with the job description and the recruiter email

Two documents set your syllabus. The job description says what the team needs. The recruiter email, or whatever the scheduling message says about the format, says how they will check it. When the two disagree, the format wins: if nobody mentioned system design, a day of system design is a day stolen from something that will be tested.

Here is the example we will use for the rest of this guide. It is written for this article, not a real posting, but it is shaped like the ones we see.

Backend Engineer (mid-level), Payments Platform, remote (EU time zones)

You will: build and maintain REST APIs in Python (FastAPI) that handle payment events for merchants; design PostgreSQL schemas and fix slow queries; process webhooks from payment providers reliably (retries, idempotency); deploy with Docker on AWS and share an on-call rotation; review teammates' code and write design docs for new services.

You have: 3+ years of backend development, strong in Python; solid SQL and relational data modelling; experience designing APIs used by other teams or customers; comfort debugging production issues.

Nice to have: Redis, message queues (SQS or Kafka), payments or fintech experience.

Recruiter email: "The loop is a 45-minute coding interview in the language of your choice, a 45-minute system design conversation, and a 30-minute behavioural chat with the hiring manager."

Our example candidate has four years of Python, mostly Django, is comfortable with everyday SQL, has done on-call, has never designed a webhook pipeline, and is rusty on timed problem solving. Keep that person in mind; the table below is theirs.

Day 1: turn the job description into a skills-gap table

Give day one about ninety minutes. Go through the posting line by line and ask three questions of each requirement:

1. Will it be tested? Responsibilities and "you have" lines usually are. Nice-to-haves sometimes come up as follow-ups.
2. In which round? Map it to the format from the recruiter email.
3. Can I prove it today? Not "have I done it", but "could I explain or demonstrate it under a follow-up question".

For the example candidate, it looks like this:

Job description line	Likely round	Evidence today	Gap	Priority
Python, 3+ years	Coding	4 years of Django in production	Rusty at timed problem solving	High
PostgreSQL schemas, slow queries	System design	Writes queries daily; has never read a query plan seriously	Indexes, EXPLAIN	High
Webhooks, retries, idempotency	System design	None	The whole topic	High
REST APIs used by others	System design, behavioural	Built internal APIs	Never versioned a public API	Medium
On-call, production debugging	Behavioural	Two real incidents	Stories not written down	Medium
Code review, design docs	Behavioural	Yes	Stories not written down	Medium
Docker, AWS	Light mention	Uses Docker daily	Small	Low
Redis, message queues	System design follow-up	Has used Redis as a cache	Queues	Low; fold into day 4
Payments or fintech	Maybe a question	None	Do not fake it	Skip

The rule for the last column is simple: priority is likely to be tested multiplied by weak evidence. Three rows are high here, so three days get spent on them. The low rows get fifteen minutes or nothing, and "I haven't worked in payments, the closest thing I've done is…" is a perfectly good answer to the last one.

Finish day one with two small decisions. Pick your interview language and stop debating it; switching languages mid-week costs more than it saves. Then solve one medium problem on a thirty-minute timer, out loud, so you know your real starting point rather than the one you remember.

The 7-day technical interview plan

Every day from day two opens the same way: ten minutes of recall without notes. Re-solve yesterday's hardest problem or redraw yesterday's design from memory, then check. This is the one habit worth keeping even if you drop everything else. In Roediger and Karpicke's 2006 study, students who took recall tests on a passage retained more of it on tests given two days and one week later than students who restudied it the same number of times. Restudying won only on a test given five minutes later, which is exactly why rereading feels like it works.

Day	Focus	What you actually do	What you keep
1	Decode	Skills-gap table, format from the recruiter email, pick a language, one timed baseline problem	The table and your baseline time
2	Coding under time	Three medium problems at thirty minutes each (hash map, two pointers, intervals), talking out loud; write the pattern in one line after each	Three pattern notes and a list of misses
3	PostgreSQL gap	Model merchants, payments and webhook_events; write four queries; run EXPLAIN on one and add an index; explain the choice out loud in two minutes	A schema sketch and one index explanation you can say
4	Webhooks and system design	Design "receive payment provider webhooks reliably" on a 45-minute timer: requirements, API, data model, retries and idempotency keys, a queue, failure cases, trade-offs	A one-page design you can redraw from memory
5	Behavioural stories	Four stories, each tied to a line of the job description: an on-call incident, a code review disagreement, an API you shipped, a mistake you fixed. Six lines each, two minutes each out loud	Four stories you have actually spoken
6	Full mock interview	45 minutes of coding, 45 minutes of design on a new prompt such as "a payment status API", 15 minutes of behavioural. Record it	The recording and three things to fix
7	Consolidate, then stop	At most ninety minutes: re-solve the day 2 misses, redraw the day 4 design from memory, fix one thing from the mock. Then the setup check and an early night	Nothing new

That adds up to roughly fifteen hours. It looks light, and it is meant to: a week with three real gaps does not need forty hours of unfocused practice, and the Tech Interview Handbook's study plan makes the same point from the other direction, telling you to size the plan to the days and hours you actually have.

Why each day looks the way it does

Day 2 is out loud on purpose. The coding round tests whether someone else can follow your reasoning, not only whether the code runs. Narrating while you solve is a separate skill, and the first time you practise it should not be in the interview.

Days 3 and 4 come straight from the table. Neither is "study databases" or "study system design". Each one is the smallest piece of work that turns a "none" in the evidence column into something you can explain under a follow-up question. The day 4 prompt is lifted from the job description's own wording, because that is the conversation most likely to happen.

Day 5 ties every story to a requirement. A behavioural answer lands better when the interviewer can see which part of the job it proves. If a story does not map to a line in the posting, swap it for one that does.

Day 6 is the whole loop in one sitting. The point is fatigue and transitions as much as content: the second round feels different after the first. You can run it with a friend, a coach or a free voice AI playing the interviewer. Score yourself on four things: was it clear, was the reasoning visible, did you back claims with evidence, and what is the next thing to practise?

Day 7 is deliberately short. The mock is on day six so that there is a day to act on it. The evening and the morning belong to the 24-hour checklist: setup checks, stories out loud once, and sleep.

If you only have an hour a day

Keep the order and the shape; cut the volume.

• Day 1: the table only. Skip the baseline problem.
• Day 2: two problems instead of three.
• Days 3 and 4: one query plan instead of four queries, and a thirty-minute design instead of forty-five.
• Day 5: three stories instead of four.
• Day 6: keep the mock, but run coding and behavioural only, and redraw your day 4 design in the time you would have spent on a new one.

Do not cut the recall opener or the mock. Those two are what turn a week of reading into a week of practice.

If the format is different

The plan follows the format, not the other way round. Rebuild days three and four from what the recruiter actually told you:

• Take-home assignment: spend day three on the stack in the posting and day four on writing a small, well-tested project in it, including the README. Expect a follow-up call about your submission.
• Pair programming: move day four into a second coding day, with a partner or a recording, and practise asking clarifying questions before you type.
• No system design round: give days three and four to the two highest-priority rows that the remaining rounds will test.
• Nothing specified: ask. "Could you tell me what the rounds will cover and how long each is?" is a normal question, and the answer is worth more than any guide.

How long each round lasts matters too. In our study of 403 listening sessions, the median was 36.1 minutes, but that is a selected sample of app sessions, not a prediction of your interview. Use the length in your invitation to size your mock.

How long should you prepare for a technical interview?

As long as it takes to close the high-priority rows in your table, and no longer. For the example above, three gaps fit in a week. If your table has eight high-priority rows, a week is not enough to close them all, so pick the three most likely to come up, prepare honest answers for the rest, and ask whether the interview date can move. That's a normal request, and it's better than a week of cramming.

If you are not sure what a technical interview round will actually ask, we pulled the question formats out of real sessions in what technical interviews actually ask in 2026. Use it to fill in the "likely round" column, not to replace the job description.

Common mistakes in a one-week plan

Studying the internet's list instead of the posting. Generic lists are written for everyone, so most of each one is irrelevant to your interview. Every hour spent on a topic that is not in your table is an hour taken from one that is.

Rereading instead of recalling. Reading your notes again feels like revision and produces the weakest results of the options on the table. Close the notes and write down what you remember first.

Doing the mock the night before. A mock that goes badly the night before leaves no time to fix anything and plenty of time to worry. Two days out is the useful slot.

Faking the nice-to-haves. Spending a day becoming a fake fintech expert is worse than saying plainly what you have not done and naming the closest thing you have.

Where GeekBye fits

We build a desktop app, so read this with that in mind. You don't need it to follow this plan; a notebook, a timer and a friend are enough.

If you want your day 6 mock recorded and reviewed, GeekBye sits beside whichever mock you run, with a friend, a coach or a voice AI asking the questions. It transcribes both sides and turns the session into a report scored on six delivery and content dimensions, stored on your machine. You can keep the job description and your stories in a profile for the role and attach it to every mock. The AI mock interview tools comparison covers what it does and doesn't do next to the alternatives. The free Starter plan includes 30 minutes of Listen per calendar month; see how the free monthly allowance works.

For everything that comes after the week, from the kinds of rounds to the common mistakes inside them, the complete guide to technical interviews is the longer read.

---

Sources: Roediger, H. L., and Karpicke, J. D. (2006), "Test-enhanced learning: taking memory tests improves long-term retention", Psychological Science 17(3), 249–255, abstract on PubMed. Tech Interview Handbook coding interview study plan, checked September 2026. The job description and candidate in this guide are illustrative examples written for this article. The plan is preparation advice; we have not measured its effect on interview outcomes.