How to Prepare for Coding Interviews: A 12-Week Roadmap

The most reliable way to prepare for coding interviews is to learn a small set of problem-solving patterns in a deliberate order, practice them under realistic time limits, and rehearse explaining your thinking out loud. Random problem grinding feels productive but leaves gaps. This 12-week roadmap shows how to prepare for coding interviews with a structured plan you can fit around a full-time job, using roughly an hour or two on weekdays and a longer session on weekends.

What do coding interviews actually test?

Before planning, be clear about what interviewers evaluate. Most technical screens and onsite coding rounds look at four things:

• Problem solving: can you break down an unfamiliar problem and find a workable approach?
• Coding: can you turn that approach into correct, readable code without an IDE's help?
• Analysis: can you state and justify time and space complexity?
• Communication: do you clarify requirements, explain trade-offs, and respond well to hints?

Getting the optimal answer silently often scores worse than reaching a good answer while communicating clearly. Plan to train all four, not just the first two.

The 12-week coding interview roadmap at a glance

Adjust the pace if you already have a strong foundation, but keep the order. Later topics build on earlier ones: tree problems assume recursion, and graph problems assume queues, stacks, and hash sets.

Weeks 1-2: foundations and complexity

Start with Big O, because every solution you write later needs a complexity statement. Then cover arrays, strings, hash maps, and hash sets, which appear in a large share of interview problems. Learn how sorting works and what it costs, since "sort first" is often the key insight.

If Big O feels shaky, read Big O notation explained with practical examples before starting problems.

Aim for easy problems in these weeks. The goal is speed and accuracy on fundamentals, not difficulty.

Weeks 3-4: core array and string patterns

This is where pattern recognition begins. Focus on:

• Two pointers for sorted arrays, pairs, and in-place partitioning. See two pointers: turning O(n²) scans into one pass.
• Sliding window for longest or shortest subarrays meeting a condition. The sliding window guide covers fixed and variable windows.
• Prefix sums for fast range queries.
• Stacks and monotonic stacks for matching brackets and "next greater element" problems.
• Binary search, including binary search on the answer. Binary search is a decision rule, not a trick explains the mindset.

For each problem, write down which pattern it used and why. That note is what you will review later.

Weeks 5-6: linked lists, recursion, and trees

Practice linked list manipulation (reversal, fast and slow pointers, merging), then move to recursion. Once recursion feels natural, trees become much easier: most tree problems are a traversal plus a small amount of work at each node. Finish with binary search trees and heaps, which power "top k" and scheduling problems.

Weeks 7-8: graphs and backtracking

Learn BFS and DFS on both adjacency lists and grids, then topological sort and union-find. Add Dijkstra if time allows. Our overview of graph algorithms every developer should know covers when to use each one. Close these weeks with backtracking for subsets, permutations, and combinations.

Weeks 9-10: dynamic programming and greedy

Dynamic programming is where many candidates stall. Use a fixed method: define the state, write the recurrence, pick base cases, choose an order, then optimize space. The guide on dynamic programming for beginners walks through that method with examples. Pair DP with greedy and interval problems, since knowing when greedy fails is itself a common question.

Weeks 11-12: mock interviews and review

Stop learning new topics. Instead, run timed sessions of mixed problems so you practice identifying the pattern without a topic label. Do at least a few mock interviews with a peer or a practice platform, and record yourself if you can. The mock interview practice guide explains how to structure sessions and give useful feedback.

Spend the rest of the time re-solving problems you previously struggled with. Re-solving from scratch, without looking at old code, is one of the most effective ways to lock in a pattern.

A repeatable framework for every problem

Use the same steps in practice and in the real interview, so they become automatic:

1. Clarify. Restate the problem, confirm input sizes, and ask about edge cases such as empty input, duplicates, and negative numbers. The problem clarification guide lists useful questions.
2. Work an example. Walk through a small input by hand to confirm your understanding.
3. State a brute-force approach and its complexity, even if you plan to improve it.
4. Optimize. Look for the bottleneck and ask which pattern removes it.
5. Code cleanly, narrating the key decisions as you go.
6. Test with your example and one or two edge cases, tracing the code rather than assuming it works.
7. Analyze final time and space complexity.

A sample weekly schedule

Mon  Learn one pattern (read + 2 easy problems)
Tue  3 medium problems on that pattern, 30-40 min each
Wed  Learn a second pattern (read + 2 easy problems)
Thu  3 medium problems on the second pattern
Fri  Re-solve 2 problems from earlier weeks without notes
Sat  Timed set: 3 mixed problems in 90 minutes, then review
Sun  Rest, or light review of your pattern notes

Treat the time limits seriously. If you are stuck after the limit, read a hint or the solution, understand it, and add the problem to your re-solve list. Struggling for hours on one problem has diminishing returns.

Common coding interview preparation mistakes

• Solving only easy problems, or jumping straight to hard ones before patterns are solid.
• Reading solutions without re-solving them later.
• Practicing silently and never rehearsing explanation.
• Skipping complexity analysis until the interview.
• Neglecting edge cases and manual testing.

Key takeaways

• Learn patterns in a deliberate order; later topics build on earlier ones.
• Track which pattern each problem uses, and re-solve weak problems from scratch.
• Practice with time limits and talk through your reasoning out loud.
• Use the same clarify, plan, code, test, analyze framework every time.
• Reserve the final two weeks for mixed timed practice and mock interviews.

Frequently asked questions

How many problems should I solve to prepare for coding interviews?

There is no magic number; coverage of patterns matters more than volume. A few well-understood problems per pattern, re-solved until you can do them quickly, usually beats hundreds solved once. Focus on recognizing why a pattern applies.

Is 12 weeks enough to prepare for coding interviews?

For most developers with some prior exposure to data structures, 12 weeks of consistent practice is enough to become comfortable with common interview patterns. If you are starting from scratch, extend the foundation and pattern phases. If you have interviewed recently, you can compress the plan.

Which programming language should I use in coding interviews?

Use the language you are most fluent in, as long as the company allows it. Python is popular because it is concise and has convenient built-in data structures, but Java, C++, JavaScript, and TypeScript are all widely accepted. Fluency matters more than the choice.

What should I do if I get stuck during a coding interview?

Say what you are thinking, restate what you know, and try a smaller example or a brute-force approach. Interviewers often give hints when they can see your reasoning. Staying calm and communicating usually scores better than silent struggle.