Solving Mindset

How to think before you code

Before you reach for a specific algorithm, a few habits shape how you approach any problem: read the constraints, find the structure, and prove the move before you make it. Pair these with the problem library, the step-by-step course, and the pattern field guide.

Ten mindset tips

Durable habits that work across every problem on this site, from the first easy grid walk to the hardest DP recurrence.

Read the constraints before the algorithm

The same problem statement with n <= 20, n <= 10^5, or n <= 10^9 points at three different solution families. Read the bounds before you pick an approach.

Restate the problem in your own words

Convert the story text into five things:

input
output
operation
objective
constraints

Start with brute force first

Always ask: "What is the simplest correct solution?" Get the right answer on paper, then optimize only the bottleneck.

Identify the real bottleneck

Is the problem hard because of time, memory, repeated computation, ordering, search space, or state explosion? Naming the cost tells you what to fix.

Look for structure, not tricks

Tricks expire; structure repeats. Common structures to name first:

sorted order
prefix / suffix
graph edges
overlapping subproblems
monotonicity
frequency counting
intervals

Ask: what must I remember?

This question often reveals the data structure for free:

hash map, heap, stack, queue, set
tree, union-find
DP table

Reduce the problem to a known pattern

Match the shape of the question to a pattern:

"choose best among previous values"→DP / greedy
"shortest steps"→BFS
"dependencies"→topological sort
"continuous subarray"→sliding window / prefix sum
"can we achieve X?"→binary search on answer

Prove why it works before coding

Especially for greedy. Ask: "Why is this local choice safe?" If you cannot explain it, it may be wrong.

Design edge cases before implementation

Walk the idea through these inputs in your head:

empty input
one element
duplicates
all same values
negative numbers
maximum size
the impossible case

Code for invariants, not just steps

Know what each variable always means, at every line. For example:

left is the first valid index
dp[i] means best answer ending at i
heap holds current candidates only

A practical solving loop

Run this order on every problem. Steps 1 and 2 come before any algorithm; steps 7 through 10 are what separate a guess from a solution.

Understand input / output

Check constraints

Write brute force

Find bottleneck

Match pattern

Define state / invariant

Prove correctness

Code cleanly

Test edge cases

Analyze complexity

Set up any dynamic programming problem in four questions

When a problem rewards remembering earlier answers instead of redoing them, it is usually dynamic programming. Before writing code, answer these four in plain words. You can work through them live in the step-by-step course.

What does each saved answer mean?

Finish the sentence dp[i] is the ... out loud. A fuzzy state is the root of most stuck moments.

What is the choice at each step?

Counting every route means add. Paying for one means keep the min. Picking items means keep the max.

How does a bigger answer use smaller ones?

The recurrence: one line building dp[i] from earlier boxes such as dp[i-1] and dp[i-2].

Which cases can you fill directly?

The base cases: the first box or two you know with no formula. Hand-check them before trusting the rest.

Two tools that make DP click

The idea lands faster when you can see the boxes fill, whether you draw them or press play.

Draw the table by hand first

On paper, draw one box per subproblem and fill them left to right. Watching the numbers appear turns an abstract recurrence into something you can point at.

Step through the visualizer

Every problem on this site plays back one cell at a time. Pause on any step and read what each box means before moving on. Start with Climbing Stairs.

The one question that matters most.

Don't start with "Which algorithm should I use?"

Start with "What prevents the brute-force solution from being fast enough, and what repeated work or structure can I exploit?"

Algorithms are answers. That question is how you earn the right to them, one problem at a time.