Nền tảng luyện tập & Chuẩn bị phỏng vấnPlatforms to Practice & Interview Preparation

Part of the Data Structures & Algorithms Roadmap knowledge base.

Overview

Everything in the previous twenty-three topics is knowledge you can acquire by reading. This one is not. Data structures and algorithms are a skill, and skills are acquired by doing the thing badly, getting feedback, and doing it again — not by reading about people who do it well.

The mistake almost everyone makes is treating practice as a volume problem: “I’ll do 300 problems.” Volume without structure produces people who have seen 300 problems and can solve about 40 of them, because they solved the other 260 by reading the editorial after twenty minutes and feeling like they understood it. Understanding a solution and being able to produce one are different skills with a nine-month gap between them, and only one of them is what an interview or a real deadline tests.

What works is smaller and less glamorous: learn one pattern, drill it on five to ten problems until the pattern is automatic, then move on and come back a week later. Twelve patterns at ten problems each is 120 problems, which is fewer than most people grind, and it produces a far better result — because after it you recognize the shape of a problem instead of trying to remember whether you have seen this exact one before.

This note covers where to practice, how to practice, in what order, and how to convert that practice into a passed interview. The technical content it draws on lives in the pattern notes: dynamic programming, two pointers and sliding window, and algorithmic complexity, which is the one you will be asked to talk about in every single interview regardless of the problem.

Fundamentals

The platforms, and what each is actually for

Platforms are not interchangeable. Each one optimizes for something different, and using the wrong one for your goal wastes months.

If you want a single recommendation: LeetCode for interview preparation, CSES for building actual algorithmic depth, Codeforces or AtCoder if you find you enjoy this and want to get genuinely good. Everything else is optional.

A note on the “Blind 75” / “NeetCode 150” / “Grind 75” curated lists: they are excellent and you should use one. Their value is not the problems (which are just LeetCode problems) but the curation — someone competent removed the redundancy and the noise, so 75 problems cover the same pattern space that 400 random ones would. Pick one list and finish it; do not collect lists.

The practice loop

Here is the loop that actually builds skill, per problem:

1. Read the problem twice. Restate it in your own words. Write down the input constraints — they are the single strongest hint about the intended complexity (see the recognition heuristics in dynamic programming).
2. Set a timer. 25 minutes for easy/medium, 40 for hard. Think without writing code for the first 5–10 of them.
3. Solve it, or fail cleanly. “Fail cleanly” means: when the timer expires, write down what you tried and where you got stuck, in one sentence, before opening anything.
4. Read the editorial — properly. Not “skim until it clicks”. Read until you can explain the key insight without looking. The key insight is usually one sentence (“sort by end time”, “the state is the prefix of each string”, “move the shorter line”). Write that sentence down.
5. Close everything and implement it from scratch. This step is not optional and it is the step everyone skips. Reading a solution creates the illusion of competence; reproducing it from the one-sentence insight is what creates the competence.
6. Log it. Problem name, pattern, the one-sentence insight, and how it went. A spreadsheet or a plain text file is fine.
7. Re-solve it from scratch a week later, from the log entry alone. If you cannot, you did not learn it — you recognized it. Re-read and re-schedule.

Step 7 is spaced repetition, and it is the single highest-leverage habit in this whole note. The schedule that works: 1 day, 1 week, 1 month. Three repetitions at expanding intervals converts a solution from “I saw that once” into recall you can rely on under pressure. Anki works well for this if you already use it; the card front is the problem name plus constraints, the back is your one-sentence insight.

Timeboxing, and why struggling has a limit

The 25-minute timer is a compromise between two failure modes. Give up after five minutes and you never develop the ability to sit with an unsolved problem, which is precisely the ability an interview tests. Refuse to look at the editorial for three hours and you spend a whole evening learning one thing instead of five.

The right rule: struggle productively until you stop generating new ideas, then stop. If you have spent ten minutes cycling through the same three failed approaches, you are not learning, you are marinating. Look it up, extract the insight, and reimplement — the reimplementation is where the learning is.

A useful middle step before the full editorial: read only the tags or only the first paragraph of the editorial. “This is a sliding window problem” is often all the unlock you need, and you keep most of the value of solving it yourself.

Key Concepts

A suggested order through this section

Order matters more than most people think, because roughly half of these topics are prerequisites for the other half. Attempting graphs before you are comfortable with queues and recursion means learning three things at once and none of them well.

Phase 1 — Foundations (do not skip, do not linger).

1. Programming fundamentals & pseudocode — only if you are not yet fluent in your language. Edabit or Exercism are the right tools here.
2. What are data structures and algorithmic complexity. Complexity is the vocabulary of every later discussion and every interview. Learn it properly now.
3. Arrays, linked lists, stacks and queues, hash tables. About 80% of interview problems are solved with an array, a hash map, or both.

Phase 2 — The core algorithmic toolkit.

4. Sorting and searching. Binary search deserves more time than it gets — especially “binary search on the answer”, which is the most under-practised high-yield technique on this list.
5. Two pointers and sliding window. Yes, out of numerical order — it depends only on arrays, it appears constantly, and it is the fastest confidence win available. Do it here.
6. Recursion and divide and conquer. Everything after this assumes you are comfortable with recursion.

Phase 3 — Trees and graphs.

7. Tree data structures — traversals, BSTs. Then heaps and priority queues, which unlock the top-k and merge-k families.
8. Graph data structures — BFS, DFS, connected components, topological sort. This is where a large share of “medium/hard” problems live.
9. Shortest paths, minimum spanning trees, union-find.

Phase 4 — Problem-solving techniques.

10. Brute force, greedy, and randomised algorithms, then backtracking.
11. Dynamic programming. Last, deliberately: it is the hardest to learn and it builds directly on recursion and memoization. Attempting DP first is the most common reason people conclude they are “bad at algorithms”.

Phase 5 — Depth, if you want it.

12. Balanced and multiway trees, advanced tree structures (trie, segment tree, Fenwick), indexing. Tries appear in interviews reasonably often; segment trees almost never, but they are common in competitive programming.

For interview prep specifically, Phases 1–4 are the syllabus. Phase 5 is for depth and for competitive programming.

The pattern list

The reason to organize practice by pattern rather than by topic is that patterns are what you actually recognize under time pressure. This is the list worth internalizing — twelve to fifteen patterns cover the overwhelming majority of interview problems:

Drill one row at a time. Five to ten problems on a single pattern, done consecutively, teaches you the pattern’s shape — the variations, the edge cases, the moment it stops applying. Ten random problems across ten patterns teaches you ten disconnected facts.

Communicating in a technical interview

An interview is not a problem-solving test. It is a simulation of working with you, and the code is the artifact, not the point. Candidates who solve the problem silently and correctly are routinely rated below candidates who solve it collaboratively with a hint. The protocol below is what interviewers are trained to look for.

1. Clarify before you code (2–3 minutes). Ask about input size and ranges, empty and single-element inputs, duplicates, negative numbers, whether the input is sorted, whether it can be modified in place, what to return when there is no answer, and whether the input fits in memory. Restate the problem in your own words and confirm.

This is not a ritual. Interview problems are deliberately underspecified, and asking is how you find out that the array is sorted (which unlocks two pointers), or that values are in 1..n (which unlocks cyclic sort), or that n ≤ 20 (which unlocks bitmask DP). The constraints are half the solution.

2. Work an example by hand. Take a small input and produce the correct output manually. This catches misunderstandings immediately and often reveals the structure of the solution. It also gives you a test case for later.

3. State the brute force, with its complexity, and then say you can do better. Something like: “The obvious approach is to check every pair, which is O(n²) time and O(1) space. Let me see if I can do better.” This is a strictly dominant move. It shows you understand the problem, it puts a working baseline on the table in case you run out of time, and it establishes the complexity you are trying to beat. Never sit in silence hunting for the optimal solution — a stated brute force is worth more than an unstated better idea.

4. Think out loud while you optimize. Say what you are considering and why you are rejecting it: “I could sort, which gives O(n log n), but the problem says the original indices matter, so I’d need to keep them — let me try a hash map instead.” Rejected approaches with reasons are evidence of judgement, which is exactly what is being assessed. Silence is unreadable and gets scored as being stuck.

5. Agree on the approach before writing code. “So: hash map from value to index, one pass, O(n) time and O(n) space. Shall I code that?” If the interviewer is going to redirect you, this is when they will — and it saves you fifteen minutes of writing the wrong thing.

6. Write clean code and narrate. Real names, not a/b/tmp. Handle the edge cases you identified in step 1. Say what you are doing as you do it, but do not narrate syntax — narrate intent (“now I’m shrinking the window until it’s valid again”).

7. Test it yourself, before being asked. Trace through your own code with the small example from step 2, out loud, line by line, watching the variables. Then run the edge cases: empty, one element, all-identical, the target at the boundary. Finding your own bug is a positive signal — it demonstrates exactly the self-checking you would apply on the job. Being told about your bug is a neutral-to-negative one.

8. State the final complexity and any trade-offs. “O(n) time, O(n) space. If memory were tight I’d sort first and use two pointers — O(n log n) time but O(1) extra space.” Naming the alternative you did not take, and why, is a senior-level signal that costs you fifteen seconds.

Common failure modes

These are the ways prepared people still fail, roughly ordered by how often they happen.

• Grinding volume without patterns. 400 problems solved once each, none of them retained. The fix is the pattern list plus spaced repetition.
• Reading the solution and moving on. This is the big one. Recognition is not recall. If you did not close the tab and reimplement, you did not learn it.
• Never practising out loud. Talking and coding simultaneously is a distinct motor skill and it is genuinely hard the first time. If your first attempt is in the real interview, it will go badly. Practise narrating even when alone — mock interviews with a friend, or Pramp/interviewing.io, are better.
• Jumping straight to code. No clarification, no example, no stated approach. You end up solving a problem the interviewer did not ask, and discovering it at minute twenty.
• Chasing the optimal solution and shipping nothing. A working O(n²) with an explanation of the O(n) you did not have time to write beats an unfinished O(n).
• Ignoring edge cases. Empty input, one element, all duplicates, integer overflow (in languages other than Python), the target at index 0 or n−1. Interviewers keep a mental checklist and tick it.
• Being unable to state your own complexity. If you cannot say why your loop is O(n log n), nothing else you said counts. Reread algorithmic complexity.
• Studying only the hardest problems. Hard problems have poor learning-per-hour. Mediums are the interview distribution and the best training signal.
• Practising in an IDE with autocomplete. Then getting a plain text editor or a whiteboard on the day. Practise in the environment you will be tested in at least some of the time.
• Neglecting the non-algorithmic rounds. For most senior roles, system design and behavioural rounds carry as much or more weight than the algorithms round. Budget your preparation accordingly.
• Burning out three weeks before the interview. Two focused hours a day for eight weeks beats eight hours a day for two weeks, by a wide margin, because retention is a function of spacing, not of total hours.

The last week before an interview

The week before is not for learning new material. Anything you have not learned by now will not be reliable in seven days, and cramming displaces the retrieval practice that would actually help.

7 days out. Stop new topics. Re-solve 20–30 problems you have already done, one or two from each pattern, from your log. Speed matters here — you are rebuilding recall, not understanding.

5 days out. Do two full mock interviews with a real human, out loud, timed, on a shared editor with no autocomplete. This is the single highest-value activity of the whole week and the one people avoid because it is uncomfortable. That discomfort is the point.

3 days out. Go through your log and list the patterns where you still hesitate. Do three or four problems on each. Reread your one-sentence insights for everything else.

2 days out. Research the company: which round is which, how long, what language you may use, whether it is a shared doc or a real IDE. Prepare your questions for them, and your two or three project stories for the behavioural section.

1 day out. One or two easy problems to stay warm — nothing hard, nothing new. Reread your notes for thirty minutes, not three hours. Then stop, and sleep properly. Sleep does more for problem-solving performance the next day than any amount of last-minute revision, and the effect is not small.

On the day. Warm up with one easy problem an hour before, so the first code you write is not in the interview. Check your setup: camera, microphone, editor, a glass of water, and a pen and paper for diagrams. Have your clarifying questions ready as a checklist — under stress you will forget to ask, and asking is worth more than any single line of code you will write.

Best Practices

• Choose one curated list and finish it (Blind 75, Grind 75, NeetCode 150, or CSES by topic). Collecting resources is procrastination with good branding.
• Practise by pattern, not by random problem. Five to ten problems on one pattern consecutively. The goal is that the shape of the problem triggers the pattern automatically.
• Always reimplement from scratch after reading a solution, in the same session. Then again a week later, from your one-line note only. This step is where the learning happens and it is the one that gets skipped.
• Keep a log with a one-sentence insight per problem. Not the code — the insight. “Sort by end time and greedily take the earliest-ending compatible interval.” If you cannot compress it to one sentence, you do not understand it yet.
• Space your reviews: 1 day, 1 week, 1 month. Three spaced repetitions beat ten massed ones, and the research on this is not ambiguous.
• Timebox every problem (25 minutes medium, 40 hard) and stop when you stop generating new ideas. Struggle is productive right up until it becomes marination.
• Say your complexity out loud for every single problem you solve, even alone. It has to be automatic, because you will be asked every time.
• Do mock interviews out loud with another person. Talking while coding is a separate skill from coding. Do not let the interview be the first time you try it.
• State the brute force before optimizing, always. It banks a working baseline, demonstrates comprehension, and frames the optimization.
• Test your own code before being asked, with the small example plus the edge cases you identified during clarification. Catching your own bug scores better than having it caught for you.
• Prefer mediums. They are the interview distribution and the best ratio of learning to time spent. Do enough hards to not be shocked by one; do not live there.
• Consistency over intensity. Two hours daily for two months beats a two-week sprint. Retention is a function of spacing.
• Use your standard library and say why. heapq, bisect, collections.deque, sorted — knowing what exists and what it costs is a professional signal; reimplementing a heap under time pressure is not.
• Do not neglect system design and behavioural rounds if you are interviewing above junior level. The algorithms round is often the easiest one to pass.
• Stop learning new material a week out. Consolidate, mock, sleep. The last week is for retrieval, not acquisition.

References

• roadmap.sh — Data Structures & Algorithms
• LeetCode
• HackerRank
• Codeforces
• AtCoder
• CodeChef
• Edabit
• Exercism
• Codewars
• Project Euler
• InterviewBit
• CSES Problem Set
• Advent of Code
• NeetCode — curated problem lists
• Big-O Cheat Sheet
• VisuAlgo — algorithm visualisations
• cp-algorithms
• MIT 6.006 — Introduction to Algorithms (OpenCourseWare)
• Spaced repetition — Wikipedia
• Testing effect (retrieval practice) — Wikipedia