A 10-week DSA plan for your first developer interview

Week by week

1. Week 1Arrays, two pointers, and getting your baseline

   • Solve five easy problems on day one without help, and note honestly how long each took. This is your baseline.
   • Two pointers: opposite ends, and same direction.
   • Sliding window, fixed and variable size.
   • Prefix sums.

   By the end of the week: About 15 problems, and a written note of which ones you could not start unaided.

2. Week 2Hashing and strings

   • Hash maps for frequency counting and for seen-before checks.
   • Anagram, subarray-sum and duplicate-detection families.
   • String manipulation without reaching for library functions that would be disallowed.
   • Time complexity stated out loud for every problem, before you look at the answer.

   By the end of the week: About 15 problems; you state complexity before checking, and are right most of the time.

3. Week 3Stacks, queues, and linked lists

   • Monotonic stack — next greater element and its variants.
   • Linked list reversal, cycle detection, and merging, all done by drawing the pointers first.
   • Implementing a queue from stacks and vice versa.
   • Practise writing linked-list code on paper. Interviews often ask for it without an editor.

   By the end of the week: You can reverse a linked list on paper, first try, no hesitation.

4. Week 4Binary search, beyond sorted arrays

   • The standard template, written from memory until the off-by-one errors stop.
   • Binary search on the answer space rather than on an array — this is the version interviews actually test.
   • Rotated arrays and finding boundaries.
   • First-true / last-true framing as a way to avoid index bugs.

   By the end of the week: About 12 problems; you write the template from memory without an off-by-one error.

5. Week 5Trees

   • All four traversals, recursive and iterative.
   • Depth, diameter, balance checks — the recursive-return-value pattern that unifies them.
   • Binary search tree properties, insertion, validation.
   • Lowest common ancestor.

   By the end of the week: About 15 problems; recursion on trees feels routine rather than clever.

6. Week 6Graphs

   • Adjacency list representation, built by hand a few times.
   • BFS and DFS, and knowing which one a problem wants and why.
   • Grid problems as graph problems — islands, flood fill, shortest path in a maze.
   • Topological sort and cycle detection in a directed graph.

   By the end of the week: About 15 problems; you convert a word problem into a graph without being told it is one.

7. Week 7Recursion and backtracking

   • Subsets, permutations, combinations — the three templates they all reduce to.
   • N-queens and sudoku as pruning exercises.
   • Drawing the recursion tree before writing any code.
   • Knowing where the state is restored, and why it matters.

   By the end of the week: About 12 problems; you draw the recursion tree first every time.

8. Week 8Dynamic programming

   • Start with memoised recursion, never with tabulation. The recursion makes the state obvious.
   • One-dimensional: climbing stairs, house robber, coin change.
   • Two-dimensional: grid paths, edit distance, longest common subsequence.
   • Knapsack, and recognising the disguises it appears in.

   By the end of the week: About 15 problems; you can name the state and the transition before writing code.

9. Week 9Mock interviews

   • Four mock interviews with a person, not a website. A friend reading a problem aloud is enough.
   • Talk continuously while solving. Silence is the most common thing freshers are marked down for.
   • Practise the opening two minutes: restate the problem, ask about constraints, state a brute force, then improve.
   • Record one session and watch it back, however unpleasant that is.

   By the end of the week: Four mocks done, and a list of your verbal habits under pressure.

10. Week 10Weak spots and consolidation

    • Re-solve every problem you failed in Weeks 1–8, from scratch, without looking at your old solution.
    • Two timed mixed sets of five problems in ninety minutes.
    • Revise complexity analysis for every pattern in one sitting.
    • Stop adding new topics. The week before interviews is for consolidation only.

    By the end of the week: Every previously failed problem re-solved unaided.

Where people lose time on this

• —Chasing a problem count. Numbers feel like progress and are the weakest available signal of it.
• —Looking at the solution after ten minutes. Sit with a problem for thirty to forty minutes before you look — the struggle is where the learning is, not the solution.
• —Solving silently and then being unable to speak while coding in the actual interview. Practise narrating from Week 1.
• —Starting dynamic programming with tabulation. It looks cleaner and teaches you nothing about where the state came from.
• —Skipping the re-solve week. A problem you solved once with a hint is a problem you have not solved.

Common questions