What to Study for a Technical Interview in One Week
Rank technical interview topics by how likely they are to be asked, what a weak answer costs you and how fast you can get passable out loud — then study in that order.
If you have limited time before a technical interview, study in this order: core data structures and one language's idioms first, then the role-specific tools named in the posting, then system design or depth in your specialty last. That is the short answer to what to study for technical interview prep. Rank every topic on three things — how likely it is to be asked, what a weak answer costs you, and how fast you can get to a passable spoken answer — and work down that list. The goal is not coverage. It is spending your hours where the interview actually tests you.
That ranking is a starting point, not a rule. Senior and system-design-heavy roles flip it, and the sections below show how to adjust. But most candidates who run out of time did not study the wrong things badly; they studied too many things at once.
What to study for technical interview prep: rank topics by yield, not by fear
The triage principle in three sentences. Multiply likelihood of being asked by the cost of a weak answer, then divide by how long it takes to reach a passable spoken answer. High on all three goes first. Low likelihood plus slow prep gets cut.
For most technical roles, the default order looks like this:
- Core data structures and one language's idioms — arrays, strings, hash maps, trees, graphs, and the patterns built on them.
- Role-specific tools and concepts named in the posting — a database, a container tool, a CI pipeline, a framework.
- System design, or depth in your specialty, if the loop includes it.
The exception matters. For senior roles, or any loop where design carries the decision, move system design up and shrink the coding block. You are being judged on judgment, not on how many exotic structures you can name.
If you only have ten hours, a reasonable split for a mid-level coding loop is roughly five hours on core patterns out loud, two on role-specific tools, two on one design walkthrough, and one on review. Adjust the shape, keep the principle.
Step 1: Read the job posting and interview loop like a syllabus
Most postings tell you more than they seem to. Read for named tools, languages, systems and responsibilities, and turn each into a study item. "Experience with PostgreSQL and containerised deployments" gives you two topics before you have opened a book.
Then ask the recruiter what the loop contains. This is a normal question, not a sign of weakness — recruiters usually answer it, and knowing the format stops you preparing for the wrong interview.
"Thanks for setting up the loop. So I can prepare sensibly, could you tell me the format of each stage — is there a coding exercise, a design discussion, a take-home, or a domain-specific round? And roughly how long is each?"
Keep it to one message. You are asking about structure, not fishing for questions.
The result of this step is a raw list of candidate topics. Do not rank them yet. Just get everything on paper, including the things you are avoiding.
Step 2: Score each topic on the triage grid
Draw three columns next to each topic: likelihood (high, medium, low), weakness cost (high or low), and prep speed (fast or slow). Add a fourth column for the cut list, so you decide explicitly what not to study.
Here is a filled-in grid for an illustrative candidate: mid-level backend engineer, one week left, applying to a company whose posting names Python, PostgreSQL, Docker and a CI pipeline.
| Topic | Likelihood | Weakness cost | Prep speed | Decision |
|---|---|---|---|---|
| Arrays, strings, hash maps | High | High | Fast | Study first |
| Trees and graph traversal | High | High | Fast | Study first |
| PostgreSQL indexing and query basics | High | High | Fast | Study first |
| Docker trade-offs | Medium | Medium | Fast | Study, one level deep |
| CI pipeline you have run | Medium | Medium | Fast | Study, one level deep |
| System design: URL shortener | Medium | High | Slow | One rehearsal only |
| System design: distributed message queue | Low | High | Slow | Cut list |
| Advanced dynamic programming | Low | Medium | Slow | Cut list |
| Language trivia and obscure flags | Low | Low | Slow | Cut list |
The sorting rule: high likelihood, high cost and fast prep goes first. Low likelihood with slow prep gets cut, or capped at twenty minutes and no more. The middle band — medium on everything — is where you spend whatever time is left after the top row is solid.
Writing the cut list down matters. It stops the anxious evening where you drift into a topic you already decided to skip.
Step 3: What to study in data structures and coding — and what to skip
The highest-yield patterns for most loops are arrays and strings, hash maps, two pointers, breadth-first and depth-first search on trees and graphs, and one recursion pattern you can explain cleanly. These come up in many technical loops, and each one gives you a structure to think out loud with.
Breadth beats depth here. An interviewer scores a candidate who can talk through a familiar pattern out loud, including the trade-offs and the edge cases, above one who half-remembers an exotic algorithm. The familiar pattern is also easier to recover in when nerves hit.
Rehearsing pointer reasoning aloud is a skill in itself. Our guide to narrating your pointer moves in a linked lists question is a good model: say what each pointer holds, why you move it, and what happens at the boundary.
When time is short, skip obscure data structures you have never used in code, algorithm trivia with no application in the role, and memorised solutions to problems you cannot re-derive. If a question lands on one of them, say what you do know and reason from first principles — that reads better than a recital you cannot defend.
Step 4: What to study in system design when you have days, not weeks
Do not start with a specific system. Start with the reusable skeleton: clarify requirements, estimate roughly, sketch the main components, then name one trade-off before you go deeper. That skeleton works for almost any prompt, and interviewers often notice when a candidate follows it without being prompted.
Practise two or three systems end to end rather than skimming ten. A walkthrough you can deliver in ten minutes out loud is worth more than ten diagrams you have only looked at. Our capacity estimation guide shows how to keep the numbers round and spoken, and the API gateway walkthrough models the component-by-component narration.
The skeleton is reusable across domains, which is the point. A rehearsal of a read-heavy service covers caching, replication and load balancing questions in several different industries. One good rehearsal can answer three possible prompts.
Skip deep dives into systems unrelated to the company's domain. If they build a payments product, a fraud-detection rehearsal will serve you better than a distributed file store.
Step 5: Role-specific tools — how deep do you need to go?
Use the one-level-below-the-surface rule. For each tool, know what it does, one trade-off, and one thing you have actually run or configured. That is usually enough to sound credible and to survive a follow-up.
A passable spoken answer for a database might be: what it stores, why you would choose it over a relational alternative for this workload, and a query or index you tuned. For a container tool: what problem it solves, one cost it introduces, and a container you built or debugged. For a CI pipeline: the stages, one failure you fixed, and one thing you would change.
Here is a weak answer and a stronger one to the same Docker question.
Weak: "Docker is a containerisation platform that packages applications and their dependencies so they run anywhere. It uses images and containers and it's very popular for DevOps."
Stronger: "We used Docker to keep the build and runtime environments identical, which killed a class of 'works on my machine' bugs. The trade-off is that images add a build and pull step, and you have to think about image size and layer caching or deploys get slow. In our pipeline I moved the dependency install above the copy step so it cached between builds — that cut the rebuild time noticeably. I would not containerise a small static site; the overhead isn't worth it."
The stronger answer works because it shows a decision, a cost and a first-hand detail. The weak one shows reading.
Our Docker trade-off guide and the CI/CD pipeline guide both follow this shape. Do not memorise command flags you have never used. If you are asked, say plainly that you have not used that flag and explain how you would find out — that is an honest answer, and interviewers usually can tell the difference.
Step 6: Turn the ranked list into a day-by-day study plan
Spend most of your study time speaking answers aloud and the smaller share reading and reviewing. Reading feels productive because it is comfortable. Speaking is what the interview tests, so it gets the bigger block.
Each day gets three blocks: one high-yield topic, one rehearsal block, one review block. Here is the 7-day template.
- Day 1: Hash maps and arrays; rehearse two problems aloud; review notes from day one.
- Day 2: Two pointers and strings; rehearse two problems aloud; review mistakes.
- Day 3: Trees and BFS/DFS; rehearse two problems aloud; review.
- Day 4: Graphs and one recursion pattern; rehearse; review.
- Day 5: Role-specific tools, one level deep; rehearse the weak-then-stronger answers; review.
- Day 6: One full system design walkthrough out loud; rehearse the skeleton twice; review.
- Day 7: Light review of your notes; two easy problems to stay warm; rest.
The 3-day version compresses the same order:
- Day 1: Hash maps, arrays, two pointers; rehearse four problems aloud; review.
- Day 2: Trees and graphs; role-specific tools; rehearse; review.
- Day 3: One design walkthrough; two easy problems; review your notes only.
Stop studying a topic when you can answer a typical question on it aloud in 90 seconds without notes and name one trade-off. That is the bar. Past it, extra hours on the same topic buy you very little.
Step 7: Rehearse out loud — the part most study plans skip
The practice loop is short: pick a question, answer aloud in 90 seconds, note one thing to fix, repeat. One thing, not five. Fixing one thing per repetition is how the answer actually changes.
Reading solutions feels like progress because the logic is easy to follow on the page. It does not build the spoken answer the interview tests, where you have to produce the reasoning in real time under mild pressure. That gap is why candidates who "knew" a topic freeze when asked to explain it.
Our talking-points guide covers how to rehearse without sounding scripted. Recording yourself, or using a practice tool to review structure and pacing, gives you the feedback a mirror cannot. You will hear the filler, the rushed ending and the missing trade-off faster than you would notice them live.
The three most common prioritization mistakes
Mistake 1: Studying what you enjoy rather than what the loop tests. The fix: put your favourite topic on the cut list for one week and replace it with the highest-likelihood item you have been avoiding.
Mistake 2: Spreading time evenly across every topic. The fix: rank the list, then give the top three topics half your total hours.
Mistake 3: Reading and watching instead of rehearsing spoken answers. The fix: set a timer and answer one question aloud before you open any solution.
Before you walk in
The ranking is the work. Once topics are ordered by likelihood, cost and prep speed, the remaining days take care of themselves, and you stop carrying the guilt of the topics you cut. Tonight, write your four-column grid, fill in the cut list, and rehearse one question aloud before you sleep.
Frequently asked questions
Should I study system design if the job posting doesn't mention it?
Ask the recruiter whether a design discussion is part of the loop before you spend hours on it. If the answer is yes, or the role is senior, include one end-to-end rehearsal using the clarify, estimate, sketch, trade-off skeleton. If the answer is no and the posting is coding-only, keep design on the cut list and put those hours into core patterns instead.
How do I know when I've studied a topic enough to move on?
Apply the two-stumble test. Rehearse the topic aloud and count how many times you get stuck on the same step. One stumble is normal; two on the same step means isolate that step and rehearse it once more. After that, move on even if it still feels rough — the remaining hours are better spent on a topic you have not touched at all.
Is it better to review my weakest topic or reinforce a strong one the night before?
Reinforce a strong topic. The night before, confidence and fluency matter more than a marginal gain on a weakness you cannot fix in a few hours. Do two easy problems in a pattern you know well, say your strongest answers aloud once, and stop. Save the weak topic for a morning review of notes only.
What should I do if the interviewer asks about a tool I've never used?
Say so in one sentence, then reason from what you do know. Name the closest tool you have used, describe the trade-off you would expect, and say how you would get up to speed. Interviewers usually care more about how you think under a gap than about whether you have touched that exact product.
How many coding problems should I aim to solve in a week?
Aim for a small number solved properly rather than a large number skimmed. For a one-week plan, two or three problems a day across the high-yield patterns, each rehearsed aloud to a clean explanation, is a sensible target. Solving the same problem twice, better the second time, often teaches more than a new one.