Summary
Two weeks is enough for technical interview prep if you spend it on the right things. interviewing.io's data shows only about 20% of candidates perform consistently from one interview to the next, and people who complete at least five practice interviews are almost twice as likely to pass. So the plan below builds in five spoken, timed mocks, rebuilds core patterns by topic in week one, then mixes problem types in week two so you practise choosing a method, which is the part a real interview tests.
Most technical interview prep starts with the same instinct: open LeetCode, sort by topic, and solve as many problems as the calendar allows. However, with two weeks to go, that instinct wastes about half of them.
The data points somewhere else. Across more than a thousand interviews on its platform, interviewing.io found that only about 20% of candidates perform consistently from one interview to the next. In fact, strong engineers regularly score a top mark in one session and a fail in the next. What narrows that swing is not more solo problems. Instead, it is rehearsal under interview conditions.
Therefore, this guide turns that into a concrete day-by-day plan: five timed mock interviews, one week of rebuilding core patterns, and one week of mixed practice that trains the skill a real interview actually tests.
What does technical interview prep actually need to fix?
Volatility, more than knowledge. Only about 20% of candidates perform consistently across interviews, so most engineers already know enough to pass on a good day. Technical interview prep in two weeks should raise your bad-day floor through spoken, timed practice rather than add another 100 problems.
Your score depends on the day. In interviewing.io’s data, candidates who earned a top score of 4 often also earned a 2, and a meaningful share of perfect scorers also recorded a 1. Even so, the most volatile group had nothing obvious in common — roughly half worked at top companies, and experience ranged from one to 20 years.
Practice moves the floor. In a separate analysis, interviewing.io reported a sharp jump in results after at least five practice interviews: candidates became almost twice as likely to pass. Moreover, among students who practised regularly, school tier stopped predicting performance altogether.
Solo problems do not rehearse the performance. After all, solving a problem silently at your desk, with unlimited time and a run button, skips the three things interviewers score: explaining your approach, handling a hint, and finishing inside 45 minutes.
That reframes the goal of technical interview prep. In other words, you are not trying to know more. Rather, you are trying to perform closer to your best on an average day, and a mock interview is the only drill that trains that directly.
| What most plans optimise | What the data says matters |
|---|---|
| Number of problems solved | Number of timed, spoken mock interviews (5+) |
| Topic-by-topic coverage | Choosing the right method on an unlabelled problem |
| Your own sense of how it went | Scored feedback from someone else |
| Cramming the night before | A rested, consistent final 48 hours |
Why should week two mix problem types?
Because a real interview never tells you the topic. Practising by topic lets the chapter heading choose your method for you. In a controlled study, mixed practice beat topic-blocked practice by 74% to 42% on a test 30 days later, because learners had to pick the strategy themselves.
Every “Top 75” list groups problems by pattern: arrays, then sliding window, then trees. Of course, that structure is useful for learning a pattern for the first time. It becomes a trap once you know the patterns, because you stop practising the hardest step.
A classroom study by Rohrer, Dedrick and Stershic, published in the Journal of Educational Psychology, tested this directly with 126 students. Those who practised with mixed, interleaved problem sets scored 80% versus 64% on a test one day later, and 74% versus 42% after 30 days, compared with the same students practising in topic blocks.
The authors’ explanation maps neatly onto coding interviews: solving a problem requires choosing a strategy, not only executing one. For example, when every problem on the page is a binary search, you never practise noticing that it is a binary search.
So the plan splits in two. Week one rebuilds patterns by topic, which is where blocked practice earns its place. Week two removes the labels: random problems, a timer, and no hint about which pattern applies.
Hide the tag before you start
Most practice sites show a problem's topic tags and difficulty right next to the title. In week two, hide the tags where the site allows it, or have a friend pick problems for you from a mixed list. Before writing any code, say out loud which pattern you think applies and why. If you guessed wrong, log it — a wrong pattern guess is the most useful mistake you can make in practice, because it is the exact mistake that sinks a real interview.
What does the 2-week technical interview prep plan look like?
Week one rebuilds core patterns by topic, with two mock interviews. Week two switches to unlabelled mixed sets, adds three more mocks, and finishes with a full-loop rehearsal and a light final day. Budget roughly two to three hours on weekdays and four on weekends.
The schedule assumes a mid-level software role with a standard loop: one or two coding rounds plus a behavioural round. In any case, adjust the topics, not the structure, if your target company differs.
Week one: rebuild the patterns
| Day | Focus | Output |
|---|---|---|
| 1 | Diagnostic: 2 mixed problems, 45 min each, out loud, recorded | Gap list and an error log |
| 2 | Arrays, hashing, two pointers | 4–5 problems, complexity stated for each |
| 3 | Sliding window, stacks, queues | 4–5 problems |
| 4 | Binary search and sorting | 3–4 problems plus Mock 1 |
| 5 | Linked lists, trees (DFS and BFS) | 4–5 problems |
| 6 | Graphs, topological sort, heaps | 4 problems |
| 7 | Review error log; draft 2 behavioural stories | Mock 2; re-solve 2 failed problems from scratch |
Week two: remove the labels
| Day | Focus | Output |
|---|---|---|
| 8 | Dynamic programming, one-dimensional | 3 DP problems plus 2 unlabelled week-one problems |
| 9 | Backtracking and 2D DP | 3 problems plus Mock 3 |
| 10 | Mixed set only: 4 random problems, 30 min each | Pattern guess logged before coding |
| 11 | Error-log re-solves; company format research | Mock 4 |
| 12 | Mixed set; finish 5–8 behavioural stories | 3 problems, stories timed at about 2 minutes |
| 13 | Full-loop rehearsal at your real interview time | Mock 5: coding round plus behavioural round |
| 14 | Light: 3 easy re-solves, equipment check, early night | No new topics |
Similarly, senior candidates should swap Days 8 and 9 for system design practice if the loop includes a design round; the principle of mixing and mocking still applies.
How should you run a mock interview?
Out loud, on a timer, with someone else scoring you. Engineers judge their own interview performance poorly, so the feedback has to come from the other side of the table. Record it, score it against a fixed rubric, and turn every miss into an entry in your error log.
Get an outside score. In an interviewing.io analysis of 254 interviews with feedback from both sides, candidates’ ratings of their own performance explained only about a quarter of the variation in their interviewers’ scores (an R-squared of 0.24). In addition, many strong performers believed they had done badly. Your gut is not a reliable scorer.
Use a real person where you can. For instance, a friend who interviews engineers, a peer swapping sessions with you, or a paid platform all work. Similarly, Tech Interview Handbook, run by Yangshun Tay, recommends mock interviews with experienced engineers from large tech companies.
Score four things every time. Did you clarify the problem before coding? Could you state an approach and its complexity before writing it? Were you talking while you coded? Finally, did you test your own code with an edge case?
What goes in the error log
Keep one line per miss: the problem, the pattern you should have spotted, and the specific slip. “Forgot empty-input case” is useful. By contrast, “Bad at graphs” is not. Afterwards, on Days 7, 11 and 14, re-solve the logged problems from a blank editor without looking at your old answer.
Volume approach: 10 problems filtered to "Medium, Trees", solved silently, no timer, answers checked after each one. Feels productive; tests nothing an interviewer measures.
Plan approach: 4 random problems, tags hidden, 30-minute timer each. Before coding, say "This looks like a sliding window because the input is a contiguous range" — and log it when that guess turns out wrong. Fewer problems, but each one rehearses choosing, explaining and finishing on time.
How do you prepare for the non-coding rounds?
Give them a fixed slot in the plan rather than the night before. Most technical loops include at least one behavioural round, and it can sink an otherwise strong coding performance. Two stories in week one and five to eight by Day 12 covers most question sets.
Behavioural rounds count. Structure each story with the STAR method interview format and draw on the common behavioral interview questions: a conflict, a failure, a hard deadline, a technical decision you would make differently. Above all, say “I”, not “we”, and choose situations where you needed little guidance.
Know the format. On Day 11, find out whether you face an online assessment, a live pair-programming round, a take-home or a whiteboard. Naturally, each rewards slightly different habits, and your final mocks should copy the real format.
Rehearse the setup for remote rounds. Therefore, test the shared editor, camera and microphone on Day 14, not five minutes before the call. The zoom interview tips guide covers lighting, audio and screen-sharing.
Prepare your end-of-interview questions. Engineers often ask about on-call load, code review culture and how the team measures success. Meanwhile, the full bank lives in questions to ask in an interview.
Narrate your reasoning continuously, including dead ends — interviewers can only credit the thinking they hear, and a hint only helps if they know where you are stuck.
Spend the last 48 hours learning a new topic; re-solve logged problems, check your equipment and sleep, because a rested average performance beats an exhausted best one.
What if you have less or more time than two weeks?
Protect the mocks and the mixed practice, then scale the topic work. With one week, compress week one into three days and keep at least three mocks. With four weeks, double the pattern work and spread the five mocks out rather than adding more topics.
One week. Days 1–3 cover arrays, trees and graphs at speed. Then, Days 4–7 are mixed sets with a mock on Days 4, 6 and 7. You lose depth on dynamic programming; accept it, because a candidate who performs steadily on medium problems usually beats one who half-knows everything.
Three to four weeks. Run week one twice as long, adding tries, intervals and union-find. However, keep week two as written for the final fortnight. Free generators such as Grind 75 on Tech Interview Handbook build a question list for different lengths of preparation, and they slot into the topic days of this plan.
After drawing on over a thousand interviews, the numbers hold up. In other words, technical interview outcomes do really seem to be kind of arbitrary.
What can two weeks of technical interview prep not fix?
A missing foundation or a mismatched role. Two weeks sharpens skills you already have; it will not teach data structures from scratch, and it cannot rescue an application for a level you are not ready for. It also cannot remove the randomness in any single interview.
Be honest about the starting point. Indeed, if Day 1’s diagnostic shows you cannot yet implement a hash map lookup or a tree traversal, this plan moves too fast. Take four to six weeks, or apply to roles where the loop leans on practical work rather than algorithm puzzles.
Randomness also survives preparation. With only about one candidate in five performing consistently, even a well-prepared engineer will have an off round. Good technical interview prep raises your average and your floor; it does not guarantee any single outcome. Applying to several companies at once spreads that risk.
The rest of the process still matters too. A strong loop follows a resume that got you in the door and a phone screen interview questions round that got you to the technical stage. For company-specific practice questions and mock answers, Rezoom’s interview preparation tools pick up where this schedule ends.
Frequently asked questions
Is two weeks enough for technical interview prep?
Yes, if you already know the basic data structures and spend the time on mocks and mixed practice rather than volume. If the Day 1 diagnostic shows real gaps in fundamentals, allow four to six weeks.
How many LeetCode problems should I do in two weeks?
Around 40 to 60 is realistic on this plan, but the count matters less than how you practise. Timed, spoken, unlabelled problems train the interview skill; silent problems filtered by topic mostly do not.
How many mock interviews should I do?
At least five. interviewing.io found candidates became almost twice as likely to pass after five or more practice interviews, which is why this plan schedules exactly five.
Should I study by topic or mix problems?
Both, in order. Learn patterns by topic first, then mix problem types so you practise identifying the pattern yourself. A classroom study found mixed practice beat topic-blocked practice by 74% to 42% after 30 days.
Can I tell how well an interview went?
Not reliably. In interviewing.io's data, self-ratings explained only about a quarter of the variation in interviewer scores, and many strong performers thought they had done badly. Get scored feedback from someone else.
What should I do the day before a technical interview?
Re-solve two or three problems you already know, check your equipment and editor, and sleep. Learning a new topic the night before adds stress without adding a pattern you can use reliably.
Do I need to prepare for behavioural questions in a technical interview?
Yes. Most technical loops include a behavioural round, so prepare five to eight stories in STAR format and rehearse them at about two minutes each.
What if I fail a technical interview after preparing?
Treat it as data, not a verdict. Only about 20% of candidates perform consistently across interviews, so one bad round predicts little. Log what went wrong and apply it to the next one.
Comments