The One Leetcode Pattern That Fixed 70% of My Interview Problems

I am going to describe a framework that completely changed how I approached DSA problems in interviews, and I am going to do it without the usual preamble about how I used to struggle until one day everything clicked. The reality is messier: I figured this out slowly, got corrected by an interviewer mid-problem, and spent a week after that applying it retroactively to fifty problems I had already solved to understand why it worked.

The pattern is called state-transition decomposition and you will not find it with that name in any Leetcode tag. I named it myself to remember it.

The Core Idea

Almost every medium-to-hard interview problem involves tracking some state that changes as you move through input. The key insight is this: before writing a single line of code, define (1) what state you are tracking, (2) how that state transitions when you process each element, and (3) what you want to extract from the final state. If you can write these three things in plain English, the code almost writes itself.

Example: the classic two-sum problem. State: a map from value to index. Transition: for each number, check if complement exists in map; if yes, return; if no, add current to map. Extract: the pair of indices. This sounds trivial for two-sum. Apply it to sliding window maximum, and suddenly you realise the state is a monotonic deque and the transition is maintaining that monotonicity while sliding. Apply it to buy-sell stock with cooldown and the state is a three-way DP over positions. The framework does not change. The state definition changes.

How I Used This in Interviews

Before writing code, I would say out loud: 'Let me define my state.' I would write it on the whiteboard or type it as a comment. The interviewer could see my thinking. If my state definition was wrong, the interviewer could correct me before I went down a bad path. If it was right, I had a map to follow and coding became mechanical. This also bought me time to think without looking like I was stuck.

• Two pointers: state = two positions + condition between them

• Sliding window: state = window boundary + running aggregate

• Tree DP: state = (node, additional constraint) -> value

• Graph BFS/DFS: state = (node, visited set or depth)

• String DP: state = (i, j, mismatch count) -> decision

None of these are original insights. They are all in textbooks and in Neetcode videos. What changed for me was making the state definition explicit and verbal before writing any code. This one habit, in my experience, is worth more than two hundred additional Leetcode problems solved silently. Talk to yourself. Write the state. Then code.