DSA problem-solving strategy

A stated brute force proves you understood the problem, gives the interviewer a correct baseline to score, and becomes your fallback if the clever idea collapses. Silence while hunting for the optimal answer reads as being stuck.

Clarifying is the cheapest place to be wrong. A couple of minutes spent restating the task and asking about empty input, single elements, duplicates and negative values beats thirty minutes spent solving the wrong problem.

Compute the totals once and answer each query by lookup: q queries over n rows drop from O(q*n) to one O(n) pass plus O(1) per query. You pay extra memory, and staleness whenever the underlying rows change.

State each approach in a sentence or two, name the cost that separates them, say which one you would take and why, then ask the interviewer to confirm before you write a line of code.

An accepted solution proves your approach worked, not that it was the best one available. Reviewing it surfaces the idea you never had - a better pattern, a lower complexity class - which is what practice is meant to add.

Roughly 5 minutes clarifying, 10 planning, 20 coding, 5 tracing in a 40-minute slot. Fixing the split in advance gives you checkpoints, so you notice time slipping at minute 15 instead of discovering at minute 35 that it is gone.

At a whiteboard, done means a defended plan: correct approach, stated invariant, complexity, and edge cases named out loud. In a shared editor, done means code that actually runs on the cases you named, including the ugly ones.

Interviews hand you an unseen variant, not a problem you have already done. What transfers is the pattern category, so covering every category with fewer problems beats grinding many problems from a handful of categories.

Multiply the work, do not count the loops: O(n^2) index pairs times an inner scan of up to O(n) comparisons gives O(n^3) worst-case time. The scan compares in place, so auxiliary space is O(1).

An example is a sample, not a contract. Sensors buffer and flush late, so a feed that happened to arrive in order once can arrive scrambled tomorrow. Ask, and treat the answer as a fact that changes the plan.

Re-run the exact example you hand-traced earlier through the optimized version step by step, checking every transition: first row, last row, a day change, a day with no rows. Faster is not correct.

Treat a hint as new data, not a verdict. Say it back in your own words, state what it changes about your plan and what it costs, then adjust visibly. Resisting one signals you will argue with review feedback.

Stop writing new code and trace a small concrete example through what already exists. A partial solution whose boundaries you checked yourself reads far better than an untested complete one that the interviewer has to debug for you.

A counting statement points at a table-filling plan, and that plan names four things: what one entry counts, how an entry is built from smaller ones, the base cases, and a fill order that computes dependencies first.

Name a defensible target: reading every record floors you at linear, and a comparison-based full ordering at n log n. State the gap from your quadratic baseline to that floor, then whether the real input size makes closing it worth anything.

Tiny traces test the problem statement, not just the code. A tie exposes an output rule nobody stated — first match, last, or all of them — and a one-element or empty input exposes whether the output is defined at all.

Total cost is a sum of terms, and the ordering phase was not the dominant one. A quadratic pairing pass still sets the runtime, so removing a log factor from a smaller term changes nothing measurable.

Decisions are scoreable; keystrokes are not. Narrate the choices, the reasons behind them, the assumptions you are making and the risks you accept. Reading your own code aloud or voicing every passing thought produces volume without signal.

A cluster is a diagnosis, not a diary entry. Take the category with the largest share, drill problems chosen specifically to provoke it, then re-read the tally two weeks later to see whether the rate fell.

Following a written solution is recognition; producing one later with nothing in front of you is recall, and only recall is what an interview measures. Read the approach paragraph, close it, and rebuild the solution from your own brute force.

Verification breaks first. With no run button you discover you had been checking correctness by executing rather than reasoning, and the audience plus the missing undo then eat the working memory you were using to hold the plan.

The medium changes what an unverified claim costs. At a board nobody can run anything, so intent is the deliverable; in a live editor an elided step reads as a check you chose not to make.

Consecutive problems in one category let you see the same technique under different dressing, which is what turns a solution into a reusable pattern. Daily category hopping gives variety but each problem stays an isolated fact.

Argue admissibility before speed: sorting needs the whole stream resident, and the stream has no known length and a hard ceiling, so that plan cannot run regardless of its time class. Then name what a single pass gives up.

Range and sign are design inputs, not trivia. Totals in cents across a large payroll can outgrow a fixed-width 32-bit signed accumulator, and negative adjustments invalidate any shortcut that assumes a total only grows. Both are cheap questions and expensive bugs.

Sorting is paid once and changes what every later step costs: equal keys become adjacent, so repeated matching collapses into one sweep or a logarithmic probe. It pays when you would otherwise rescan many times, and loses on a one-shot query.

Run a rehearsed ladder out loud: re-work a small concrete example by hand, then solve a deliberately simplified version, then scan known technique families aloud and say why each fits or fails. Announce which rung you are on.

The README is the tradeoff record, not install instructions. It should state how to run everything, the approach chosen and what it was chosen over, what was deliberately cut and why, known limitations, and what a production version would add.

Treat the cap as part of the specification. Ship a correct, tested core path and cut breadth: extra features, configurability, and speculative structure. A scoped eighty percent with the cuts stated beats an unfinished attempt at everything.