The short answer
To prepare for a DSA interview in two weeks, spend the first week on the patterns that cover most questions (arrays and strings, hashing, two pointers, sliding window, binary search, trees and graphs), solving three or four problems a day out loud and against a timer. Take a mock interview on day 7 to find your weakest areas, spend the second week on those plus heaps and dynamic programming, and take a second mock on day 13. Rest on day 14. Depth on common patterns beats a shallow pass over everything.
What the round actually tests
A DSA round, often called the coding round, gives you one or two problems in 45 to 60 minutes. You are expected to understand the problem, find an approach, write working code, test it and explain its time and space cost. Getting the optimal answer helps, but it is not the only thing marked. An interviewer who watches you find a brute-force solution, explain why it is slow and improve it step by step often scores you higher than one who sees you type out a memorised answer in silence.
So preparation has two halves. One is knowing the patterns well enough to recognise them under pressure. The other is the habit of thinking out loud, testing your own code and handling edge cases without being asked. Most two-week plans only train the first half.
How it is scored
After the 60-minute round, the interviewer marks each line below 1 to 5 in your written report, due within 24 hours, with notes on what you said and wrote behind each mark. The verdict is one of Strong hire, Hire, Lean hire, Lean no hire or No hire.
| Skill (1 to 5) | What the interviewer looks for |
|---|---|
| Problem solving | You clarify the problem, find a working approach, then improve it, and can explain why each step is better. |
| Code quality | Clear names, small functions where they help, and code that runs without large rewrites. |
| Testing and edge cases | You test your own code by hand, including empty input, one element, duplicates and the largest sizes. |
| Complexity | You state time and space cost correctly and know which part of the code drives it. |
| Communication | You think out loud, take hints well and keep the interviewer with you from start to finish. |
The 14-day plan
Aim for two to three focused hours a day. Each day: one short review of the pattern, then three or four problems, each timed at 25 to 30 minutes and solved out loud. Write down every problem you could not solve; those are your revision list.
| Day | Focus | What to do |
|---|---|---|
| Day 1 | Arrays and strings, hashing | Frequency counts, prefix sums, using a hash map to turn a nested loop into one pass. |
| Day 2 | Two pointers and sliding window | Pairs in sorted arrays, longest substring problems, fixed and variable windows. |
| Day 3 | Binary search | Classic search, then search on the answer: the smallest value that makes a condition true. |
| Day 4 | Linked lists, stacks and queues | Reversal, fast and slow pointers, a monotonic stack for next-greater problems. |
| Day 5 | Trees | Depth-first and breadth-first traversal, recursion that returns values up the tree, binary search trees. |
| Day 6 | Graphs | Grids as graphs, connected components, shortest path on an unweighted graph, cycle detection. |
| Day 7 | Mock interview and review | Take a full mock interview. Then reread your list of unsolved problems and the mock's notes. |
| Day 8 | Your weakest area from the mock | Redo the problems you missed, then three new ones on the same pattern. |
| Day 9 | Heaps | Top-k problems, merging sorted lists, a running median. |
| Day 10 | Dynamic programming, part one | One-dimensional problems: write the recursion first, then add memoisation, then a table. |
| Day 11 | Dynamic programming, part two; greedy | Two-dimensional grids and strings; when a greedy choice is safe and how to argue it. |
| Day 12 | Backtracking and mixed practice | Subsets and permutations, then four mixed problems with no topic label. |
| Day 13 | Second mock interview | A full mock at your level. Compare the marks with day 7. |
| Day 14 | Light review and rest | Reread your notes, solve two easy problems for confidence, sleep well. |
Which topics come first, and why
Our DSA mock interviews draw on thirteen topic areas: arrays and strings, hashing, two pointers, sliding window, linked lists, stacks and queues, trees, graphs, heaps, binary search, dynamic programming, greedy and backtracking. In two weeks you cannot master all of them equally, so order matters.
Start with the ones that underpin the others. Hashing and two pointers turn up inside graph, string and array problems alike. Trees and graphs come next because they test recursion and traversal, which interviewers lean on heavily. Dynamic programming is left to the second week on purpose: it is the hardest to learn quickly, and it is easier once recursion on trees feels natural.
If your interview is for a frontend role, check whether there is a DSA round at all; many frontend loops replace it with a machine coding round. If you are senior, expect fewer pure puzzle questions and more problems that look like real work, but the same patterns underneath.
How to practise talking while you code
This is the habit most people skip, and it is where many marks are lost. Interviewers can only score what they can see and hear.
- Repeat the problem back. Say it in your own words and ask about input size, duplicates, empty input and what to return when there is no answer.
- Say the brute force first. State the simple approach and its cost before you optimise. It shows you understand the problem and gives you a fallback.
- Name the pattern. "The input is sorted, so two pointers or binary search should work." Naming the pattern tells the interviewer where you are heading.
- Narrate while typing, briefly. One sentence per block of code is enough. Long silences are worse than imperfect sentences.
- Test before you are asked. Walk through one normal case and two edge cases by hand. Fix bugs out loud.
- Finish with the cost. State time and space complexity and one idea for doing better if you had more time.
Why the mock interviews sit on day 7 and day 13
The day 7 mock is a diagnosis. After a week of patterns you will feel ready on some topics and shaky on others, but your own sense of it is unreliable. A real interviewer, marking you on a fixed rubric, tells you which skill is actually costing you: often testing and edge cases or communication, not problem solving. The second week of the plan is built around what that mock finds.
The day 13 mock is a dress rehearsal. It shows whether the gaps closed, gets you used to the pressure of a stranger watching you code, and leaves one day to rest rather than cram. If you can only afford one mock, take it on day 7: finding your gaps early is worth more than confirming them late.
Mistakes that waste the two weeks
- Solving hundreds of easy problems. Volume feels like progress; patterns at medium difficulty are what the round tests.
- Reading solutions too early. Struggle for at least 20 minutes before looking, then close the solution and write it again from memory the next day.
- Practising in silence. If you have never explained your code out loud, the interview is the wrong place to start.
- Skipping complexity. Every answer needs a time and space cost; practise stating it every time.
- Cramming on the last night. Tired candidates miss edge cases they would normally catch.