Data structures and algorithms (DSA) interviews: what to study and how deep

Study the patterns interviews actually draw from

Data structure and algorithm coverage, usually shortened to DSA, is wide, but interviews concentrate on a short list. Arrays and hash maps dominate because they test whether you can trade space for time. Two pointers and sliding windows cover most contiguous-subarray questions. Trees and graphs test traversal reasoning. Heaps appear in top-k and streaming problems. Dynamic programming shows up less often than its reputation suggests and is usually bounded to recognisable patterns at most levels.

Amazon's interview guidance asks candidates to apply computer science fundamentals rather than memorise answers, which is exactly what this list rewards: recognising which pattern a new problem resembles, then justifying the choice. Deprioritise rarely-asked structures such as balanced tree rotations, suffix structures, and advanced graph algorithms unless the role or company is known for them. Breadth feels productive; depth on the common patterns is what converts.

• High priority: arrays, hashing, two pointers, sliding window, trees, graphs, heaps
• Medium: recursion and backtracking, binary search variants, simple DP patterns
• Lower priority unless signalled: segment trees, tries beyond basics, advanced graph algorithms

Reference: Amazon Careers: software development interview topics

Match study depth to your level

Junior interviews typically test whether you can pick a correct approach and implement it cleanly: arrays, hashing, a traversal, and honest complexity analysis. Mid-level adds follow-up pressure: alternative approaches, boundary handling, and explaining why your complexity claim holds. Senior candidates are expected to reach for the right pattern quickly, discuss trade-offs unprompted, and reason about the problem's shape rather than its category.

Calibrate honestly. If the role is junior, grinding hard problems builds skill you may never be asked for while the fundamentals go unrehearsed. If the role is senior, a correct-but-shallow answer without trade-off discussion reads as junior. The job description's level and your recruiter's answer about interview difficulty should set the bar, not the hardest problem list you can find.

Learn to explain complexity as a claim you defend

Saying O(n) is a conclusion, not an explanation. The interviewable version states the variable, the reasoning, and the assumption: 'With n events, each is processed once and each hash lookup is expected constant time, so the total is expected O(n) time and O(k) space for k distinct IDs.' That phrasing survives the follow-up 'why expected?' where a bare O(n) does not.

Practise the same defence for space. A separate set or output array is not free; recursion uses call-stack space; an in-place algorithm that modifies the input has a different contract, not zero cost. Interviewers probe complexity answers specifically because memorised solutions come with memorised complexity claims that collapse under 'what does k represent?'

• Name the variable: what does n measure in this problem
• State the assumption: expected versus worst-case and why
• Count space honestly: auxiliary structures, output, call stack
• Anticipate 'why': what property of the data structure carries the claim

Rehearse explaining your reasoning aloud

Most DSA preparation is silent: read, solve, submit. Interviews are spoken. The gap shows up when a candidate who can solve a problem cannot narrate it: they go quiet to think, produce a correct answer with no visible reasoning, and lose credit the interviewer needed to give. Practise explaining the invariant your code maintains, why this data structure fits, and what you would try if the approach stalled.

This is also where memorised solutions fail visibly. A memorised solution arrives fully formed and sounds like recitation; a reasoned one includes false starts, comparisons, and a stated choice. Interviewers trust the second because it predicts how you work on novel problems. Study so that you can reconstruct the solution from the reasoning, not recall the code.

Worked example: turning a brute-force start into a pattern

Suppose the problem is: given a list of event timestamps, find the shortest window containing at least one of each event type. The brute-force answer checks every window and is quadratic. Saying 'I would use a sliding window' is a pattern recall; the stronger version reasons it out: windows can only improve by shrinking, we can expand until the constraint is met then contract while it still holds, and a frequency map tracks what the window contains. That reasoning produces the sliding-window-with-counter solution and explains why it is linear.

Then defend the complexity with named variables: each element enters and leaves the window once, so O(n) time; the map holds at most one entry per type, so O(t) space for t event types. The whole answer is a chain of justifiable decisions, which is what the interview is scoring.

Each timestamp enters the window once when the right pointer reaches it and leaves at most once when the left pointer passes it, so the total work is linear in n. The frequency map holds one counter per event type, O(t) space. If types were unbounded I would discuss whether the map or a different structure fits better.

Build a study plan around reconstruction, not volume

A sustainable plan does fewer problems with more rigour. For each problem: attempt unaided with a timer, write the approach before the code, implement, test boundary cases, and state the complexity aloud. Then, a week later, reconstruct the solution from the reasoning rather than re-reading it. If you can rebuild it, you learned the pattern; if you can only recognise it, you memorised a solution.

Track where you lose time across a session's worth of problems. Clarifying slowly, picking the wrong structure, debugging, and failing to explain are different weaknesses with different fixes. A spreadsheet of fifty completed problems with no failure analysis teaches less than twenty problems with honest notes on what each exposed.

Combine silent solving with spoken rehearsal

Alternate two drill types. Silent drills on real problems build the solving skill: run code, check correctness, verify complexity. Spoken drills build the interview skill: take a problem you already solved and narrate the approach, the invariant, the complexity defence, and one follow-up variation aloud.

The spoken drill is the one most candidates skip and the one interviews grade. If your practice tool does not execute code, keep the two skills separate deliberately: verify correctness in your own environment, rehearse the explanation out loud. Both need reps before the interview combines them under time pressure.

Frequently asked questions

Practise the next answer

Use a Coding Mock Session to rehearse the part that separates candidates: explaining your approach, invariants, and complexity aloud while you solve. Where a session includes the Code Pad, the AI Interviewer reads it but never executes code, so verify implementations and run tests in your own environment.

Practise for your job

Sources and scope

Employer sources describe their own processes, which may change. The exercises and illustrative examples are PrepRole editorial guidance, not employer questions or hiring criteria.

• Amazon Careers: software development interview topics
• Atlassian: engineering interview handbook

Related guides

• Practise the full clarification-to-testing loop
• Extend to systems-level reasoning
• Rehearse explaining decisions on real work