DSA problem-solving strategy

26 roadmaps 35 questionsupdated 2026-09-29

How I attack a coding problem end to end: a repeatable solving method, reading constraints to plan before coding, curated study plans, deliberate-practice habits, and knowing what each round format expects. Interviewers grade the process as much as the final code, so this meta-skill layer often decides borderline calls.

▸ follow the data structures & algorithms roadmap jump to the questions →

on this pageshow

guide

overview

~1 min

The subject splits into five sections. The structured solving method covers the phases of one problem, from clarifying questions through a brute-force baseline to optimizing and verifying. Constraint-driven planning is about choosing a technique from the wording and limits before writing code. Study plans and deliberate practice are about preparation: how curated lists are meant to be used, and how to train under the conditions the round imposes. Round formats explains how a whiteboard, a shared editor and a take-home each define a finished answer.

Start with the solving method, because the other sections build on it. Questions range from a junior asking why a naive solution is worth saying out loud to a senior deciding what to cut from a time-boxed take-home.

Problem-solving strategy is the layer of a coding round that sits around the algorithm rather than inside it. Two candidates can reach the same solution and leave with different verdicts, because the interviewer also scores the route: whether you pinned down the task before building anything, whether a correct baseline existed on the board early, whether your plan followed from the limits in the statement, and whether you checked the result instead of announcing it. On borderline calls this process evidence is often what tips the decision. The subject splits into five sections. The [structured solving method](/topics/found-dsa-problem-solving-method) covers the phases of one problem, from clarifying questions through a brute-force baseline to optimizing and verifying. [Constraint-driven planning](/topics/found-dsa-problem-solving-constraints) is about choosing a technique from the wording and limits before writing code. [Study plans](/topics/found-dsa-problem-solving-study-plans) and [deliberate practice](/topics/found-dsa-problem-solving-practice) are about preparation: how curated lists are meant to be used, and how to train under the conditions the round imposes. [Round formats](/topics/found-dsa-problem-solving-round-formats) explains how a whiteboard, a shared editor and a take-home each define a finished answer. Start with the solving method, because the other sections build on it. Questions range from a junior asking why a naive solution is worth saying out loud to a senior deciding what to cut from a time-boxed take-home.

primer

These sections rest on a few ideas. Hold them and most of the questions below read as consequences.

The process is part of the answer

An interviewer cannot grade reasoning they never heard. A stated plan, a named trade-off and a visible check each give them something to credit, even when the final code is incomplete. A silent candidate gives them little to write down, even when the answer arrives.

Being wrong early is cheap

Each phase exists to catch a class of mistake while it still costs minutes. A clarifying question catches a misread task; a hand-traced example catches an undefined output rule; a baseline catches a misunderstanding of what the output even is. The same mistake found after twenty minutes of code usually costs the round.

A baseline is an asset, not an admission

A slow but correct solution shows the task was understood, sets a cost to beat, and leaves something standing if a better idea does not pan out. Optimizing then means naming the gap between that cost and the lowest cost the problem allows, and closing only the part that matters for the stated input size.

Constraints decide what is admissible

Input sizes, memory ceilings and whether the data can be read twice rule approaches in or out before speed is even discussed. A plan that ignores them can be elegant and still unusable.

Practice has to match the test

Solving at leisure with a run button trains a different skill from solving aloud against a clock. Preparation transfers when it covers every pattern category, rebuilds solutions from memory rather than rereading them, and reviews each attempt for the cause of an error rather than the error itself.

These sections rest on a few ideas. Hold them and most of the questions below read as consequences. ### The process is part of the answer An interviewer cannot grade reasoning they never heard. A stated plan, a named trade-off and a visible check each give them something to credit, even when the final code is incomplete. A silent candidate gives them little to write down, even when the answer arrives. ### Being wrong early is cheap Each phase exists to catch a class of mistake while it still costs minutes. A clarifying question catches a misread task; a hand-traced example catches an undefined output rule; a baseline catches a misunderstanding of what the output even is. The same mistake found after twenty minutes of code usually costs the round. ### A baseline is an asset, not an admission A slow but correct solution shows the task was understood, sets a cost to beat, and leaves something standing if a better idea does not pan out. Optimizing then means naming the gap between that cost and the lowest cost the problem allows, and closing only the part that matters for the stated input size. ### Constraints decide what is admissible Input sizes, memory ceilings and whether the data can be read twice rule approaches in or out before speed is even discussed. A plan that ignores them can be elegant and still unusable. ### Practice has to match the test Solving at leisure with a run button trains a different skill from solving aloud against a clock. Preparation transfers when it covers every pattern category, rebuilds solutions from memory rather than rereading them, and reviews each attempt for the cause of an error rather than the error itself.

Brute-force baseline: The simplest correct solution, stated with its cost before any optimization, so there is something correct to score and a reference to improve on.
Edge case: An input at the boundary of what the statement allows, such as empty, single-element, all-equal or extreme values, where solutions most often break.
Dry run: Tracing a small concrete input through the solution by hand, step by step, to check behaviour without executing anything.
Dominant term: The part of a total cost that grows fastest and so sets the runtime; improving any smaller term changes little that can be measured.
Lower bound: The least work any correct solution to a problem must do, such as reading every input once; it marks how far optimizing can go.
Test oracle: A trusted reference, often the naive solution, used to check a faster version's output on many generated inputs.
Pattern category: A family of problems solved by the same technique, such as sliding window or graph traversal; the unit curated study lists are built around.
Deliberate practice: Practice aimed at a named weakness, done under realistic conditions and followed by review, rather than solving more problems of the kind you already handle.
Recall versus recognition: Producing a solution from nothing versus following one you are shown. Interviews test recall; rereading solutions mostly builds recognition.
Time box: A fixed limit set in advance for a phase or a whole task, used as a checkpoint for when to move on or what to cut.

The five sections split into two halves: what you do during the round, and what you do in the weeks before it.

Inside the round

The solving method is the backbone. Clarifying and working examples fixes what the problem is; the brute-force baseline fixes a correct answer and its cost; optimizing and verifying closes the gap and proves nothing broke. Constraint-driven planning happens between the first two phases: once the task is clear, the limits tell you which families of technique are worth trying, which keeps optimization from being a guess. Round formats then adjust the method rather than replace it. The phases stay the same; what counts as finished shifts from a defended plan at a whiteboard to running, tested code in an editor, and to scoping and written trade-offs in a take-home.

Before the round

Study plans decide what to practice: enough problems per pattern category that the technique becomes recognisable in an unfamiliar problem. Deliberate practice decides how: under a clock, out loud, with a routine for getting unstuck and a review afterwards. Its three sub-sections mirror the round itself. Timed mocks rehearse the phase budget, think-aloud and hint recovery rehearse the conversation, and post-solve review turns each attempt into input for the next.

The algorithm sections of the parent data structures and algorithms hub supply the techniques; this hub is about choosing, sequencing and presenting them under time pressure.

The five sections split into two halves: what you do during the round, and what you do in the weeks before it. ### Inside the round The [solving method](/topics/found-dsa-problem-solving-method) is the backbone. [Clarifying and working examples](/topics/found-dsa-problem-solving-method-clarify-examples) fixes what the problem is; [the brute-force baseline](/topics/found-dsa-problem-solving-method-brute-force-baseline) fixes a correct answer and its cost; [optimizing and verifying](/topics/found-dsa-problem-solving-method-optimize-verify) closes the gap and proves nothing broke. [Constraint-driven planning](/topics/found-dsa-problem-solving-constraints) happens between the first two phases: once the task is clear, the limits tell you which families of technique are worth trying, which keeps optimization from being a guess. [Round formats](/topics/found-dsa-problem-solving-round-formats) then adjust the method rather than replace it. The phases stay the same; what counts as finished shifts from a defended plan at a whiteboard to running, tested code in an editor, and to scoping and written trade-offs in a take-home. ### Before the round [Study plans](/topics/found-dsa-problem-solving-study-plans) decide what to practice: enough problems per pattern category that the technique becomes recognisable in an unfamiliar problem. [Deliberate practice](/topics/found-dsa-problem-solving-practice) decides how: under a clock, out loud, with a routine for getting unstuck and a review afterwards. Its three sub-sections mirror the round itself. [Timed mocks](/topics/found-dsa-problem-solving-practice-timed-mocks) rehearse the phase budget, [think-aloud and hint recovery](/topics/found-dsa-problem-solving-practice-communication) rehearse the conversation, and [post-solve review](/topics/found-dsa-problem-solving-practice-review) turns each attempt into input for the next. The algorithm sections of the parent [data structures and algorithms](/topics/found-dsa) hub supply the techniques; this hub is about choosing, sequencing and presenting them under time pressure.

Clarify & Work Examples →
Every later phase depends on solving the right problem, and clarifying questions are the cheapest point at which to find out you have not.
Brute Force First →
A correct, costed baseline is what the interviewer scores first and what every optimization is measured against.
Constraint-Driven Planning →
Reading the limits turns optimization from guesswork into choosing among a few admissible technique families.
Optimize & Verify →
Improving the baseline and then proving the faster version still gives the same answers completes the method.
Think-Aloud & Hint Recovery →
Narrating decisions and absorbing hints is the skill that separates solving alone from solving with an audience.
Round Formats & Expectations →
Once the method is solid, learn how each format redefines finished so you spend minutes where they are graded.

Starting to code before restating the task and asking about ranges, ordering and empty input; the misread often surfaces only after most of the time is gone.
Treating the sample input as a guarantee, for example assuming sorted order or positive values because the example happened to show them.
Searching silently for the optimal idea instead of stating a correct baseline first, which leaves the interviewer nothing to credit if time runs out.
Optimizing a term that does not dominate the total cost, then claiming a speed-up the runtime will not show.
Declaring an optimized version correct because it is faster, without re-tracing the earlier example and the boundary cases through it.
Writing new code in the last minutes rather than tracing a small example through what already exists.
Measuring preparation by problems completed rather than by whether each pattern category can be re-derived cold a week later.

The same few tensions come up across this hub, and naming the one you are managing is part of what is scored.

Time spent clarifying versus time left to code. Questions and hand traces are cheap insurance, but a plan that never commits is its own failure. A phase budget set before the round tells you when the balance has tipped.
Baseline first versus straight to the target. Stating the naive version costs a minute and buys a fallback. Skipping it can pay off only when the optimal idea is obvious and you can defend it at once.
Optimizing versus stopping. A lower complexity class is worth pursuing only if the stated input size makes the difference matter and the extra complexity can still be verified in the time left.
Breadth versus depth in a take-home. A tested core with the cuts written down usually beats a wide submission that nobody can trust.
Coverage versus volume in preparation. More problems in familiar categories feel productive; fewer problems spread across every category transfer better to an unseen variant.

The same few tensions come up across this hub, and naming the one you are managing is part of what is scored. - **Time spent clarifying versus time left to code.** Questions and hand traces are cheap insurance, but a plan that never commits is its own failure. A phase budget set before the round tells you when the balance has tipped. - **Baseline first versus straight to the target.** Stating the naive version costs a minute and buys a fallback. Skipping it can pay off only when the optimal idea is obvious and you can defend it at once. - **Optimizing versus stopping.** A lower complexity class is worth pursuing only if the stated input size makes the difference matter and the extra complexity can still be verified in the time left. - **Breadth versus depth in a take-home.** A tested core with the cuts written down usually beats a wide submission that nobody can trust. - **Coverage versus volume in preparation.** More problems in familiar categories feel productive; fewer problems spread across every category transfer better to an unseen variant.

A handful of routines recur across the questions below, each usable on problems you have never seen.

Restate, then probe the edges. Restate the task in your own terms, then ask about empty, single, tied, extreme and negative inputs before planning.
Baseline, cost, gap. State the naive solution, its time and space, the lower bound the problem allows, and whether closing the gap between them matters at the given size.
Constraint to technique. Map the input size and memory limit to a complexity class, and the wording ("count the ways", "shortest", "at most k") to a technique family.
Fork and check in. When two approaches compete, state both, say where their costs differ, pick one, and confirm before writing.
The unsticking ladder. Rework a small example, then a simplified version of the problem, then scan technique families aloud, announcing each step as you move to it.
Log, cluster, drill. Record the cause of each practice error, find where they cluster, and target that category until the rate falls.

A handful of routines recur across the questions below, each usable on problems you have never seen. - **Restate, then probe the edges.** Restate the task in your own terms, then ask about empty, single, tied, extreme and negative inputs before planning. - **Baseline, cost, gap.** State the naive solution, its time and space, the lower bound the problem allows, and whether closing the gap between them matters at the given size. - **Constraint to technique.** Map the input size and memory limit to a complexity class, and the wording ("count the ways", "shortest", "at most k") to a technique family. - **Fork and check in.** When two approaches compete, state both, say where their costs differ, pick one, and confirm before writing. - **The unsticking ladder.** Rework a small example, then a simplified version of the problem, then scan technique families aloud, announcing each step as you move to it. - **Log, cluster, drill.** Record the cause of each practice error, find where they cluster, and target that category until the rate falls.

explore

Structured Solving Method12 questions
- Clarify & Work Examples4 questions
- Brute Force First4 questions
- Optimize & Verify4 questions
Constraint-Driven Planning3 questions
Study Plans & Curated Lists4 questions
Deliberate Practice Technique12 questions
- Timed & Mock Practice4 questions
- Think-Aloud & Hint Recovery4 questions
- Post-Solve Review4 questions
Round Formats & Expectations4 questions

~20 s

Treat the list as a baseline map, not a syllabus. Audit its category weights against what the target loop actually asks, then supplement the thin category with problems chosen to span its sub-patterns rather than to raise the total.

open as a page

showing 31–35 of 35

§guide

overview

§primer

▾core ideas~1 min

The process is part of the answer

Being wrong early is cheap

A baseline is an asset, not an admission

Constraints decide what is admissible

Practice has to match the test

▾vocabulary10 terms

▾how it fits~1 min

Inside the round

Before the round

▾where to start6 steps

▾common pitfalls7

▾trade-offs5

▾patterns6

§explore

▾sections5 · 35 questions

▾roadmaps that cover this26

§questions

How do you decide a curated problem list is finished rather than merely completed?

basics

Your recorded mock spent 22 of 40 minutes before the first line of code — what do you diagnose?

basics

Why keep the naive all-pairs checker in the test suite after the optimized version ships?

basics

A spaced re-attempt of a previously failed problem fails the same way - what does that tell you?

basics

A curated list gives graphs three problems but your target loop is graph-heavy — what do you do?

basics

The process is part of the answer

Being wrong early is cheap

A baseline is an asset, not an admission

Constraints decide what is admissible

Practice has to match the test

Inside the round

Before the round

guide

primer

explore

questions