Originally published on LeetCopilot Blog
Staring at a blank screen with no clue how to begin? Learn a systematic framework for breaking down any LeetCode problem into actionable steps, even when the solution feels completely invisible.
You open a new LeetCode problem. You read it twice. You understand what it's asking.
But you have no idea where to start.
The problem isn't knowledge—you've studied arrays, hash maps, maybe even dynamic programming. The problem is bridging the gap between reading a problem and knowing what to do next. This is the most underrated skill in coding interview prep, and it's rarely taught explicitly.
This guide gives you a systematic framework for approaching any LeetCode problem when you feel stuck before you've even written a single line of code. By the end, "I don't know where to start" will become "Here's what I'll try first."
TL;DR
- Feeling lost at the start is normal—even experienced engineers face this. The difference is having a process to follow.
- The first step is never "find the algorithm"—it's understanding the problem deeply through examples and constraints.
- Work examples by hand first before thinking about code. This reveals patterns you'd miss otherwise.
- Brute force is always a valid starting point. Write it down, even if you don't code it—it clarifies the problem structure.
- Constraint analysis tells you what approach is feasible. If n ≤ 10^5, O(n²) won't work—this rules out many approaches immediately.
- Common mistake: Trying to jump straight to the "trick" instead of building understanding step by step.
Beginner-Friendly Explanations
Why "No Idea Where to Start" Happens
This feeling occurs because of a mental gap: you're trying to jump directly from problem description to solution pattern. But that's skipping the most important part—problem understanding.
When you read a problem and immediately think "what pattern is this?", you're asking the wrong first question. The problem hasn't revealed enough information yet for pattern matching to work reliably.
The Real First Step: Slow Down
Counter-intuitively, when you feel most lost, the best thing to do is slow down rather than speed up. The anxiety of not knowing pushes you to scan for keywords, guess at patterns, or jump to solutions. This almost always fails.
Instead, treat "I don't know where to start" as a signal that you need to spend more time understanding the problem before attempting to solve it.
Step-by-Step Learning Guidance
Step 1: Read the Problem for Understanding, Not Solutions
On your first read, don't try to solve anything. Focus only on:
- What is the input? (Data types, structure, constraints)
- What is the output? (What exactly are you returning?)
- What are the constraints? (Input size, value ranges)
Example problem: "Given an array of integers, find two numbers that add up to a target."
First-read extraction:
- Input: array of integers, a target integer
- Output: indices of two numbers (or the numbers themselves—clarify!)
- Constraints: One solution exists? Multiple solutions? Can I use the same element twice?
At this stage, you're not solving—you're making sure you understand what "correct" looks like.
Step 2: Work Through Examples by Hand
Before writing any code, manually work through the provided examples. Then create your own.
For the two-sum example:
Given: [2, 7, 11, 15], target = 9
Manual process:
- Start with 2. Need 7 to reach 9. Is 7 in the array? Yes, at index 1.
- Answer: indices [0, 1]
Now create edge cases:
- What if the array is empty?
- What if no valid pair exists?
- What if multiple pairs exist?
- What if the array has negative numbers?
This manual process often reveals the algorithm. In the two-sum case, you just discovered the core insight: "For each number, I need to check if its complement exists."
Step 3: Articulate the Brute Force Solution
Always start with brute force. Even if it's too slow, writing it down clarifies what you're actually trying to do.
Two-sum brute force:
For each number at index i:
For each number at index j > i:
If nums[i] + nums[j] == target:
Return [i, j]
Time complexity: O(n²)
Now you have something concrete. You know what needs to happen—you're just looking for a more efficient how.
Step 4: Analyze Constraints to Guide Your Approach
Constraints tell you what complexity is acceptable:
| Input Size | Acceptable Complexity | Common Approaches |
|---|---|---|
| n ≤ 20 | O(2^n), O(n!) | Backtracking, recursion |
| n ≤ 100 | O(n³) | Triple nested loops |
| n ≤ 1,000 | O(n²) | Double nested loops, some DP |
| n ≤ 10^5 | O(n log n), O(n) | Sorting, hash maps, two pointers |
| n ≤ 10^6+ | O(n), O(log n) | Linear scans, binary search |
For two-sum with n ≤ 10^4: O(n²) might pass, but O(n) is expected. This suggests hash maps or sorting.
Step 5: Look for Optimization Patterns
Once you understand the brute force, ask: What repeated work can I eliminate?
In two-sum brute force, for each element, you scan the entire remaining array to find the complement. That's redundant—you're asking the same question repeatedly: "Does this number exist in the array?"
Pattern recognized: When "does X exist" is asked repeatedly, use a hash map/set for O(1) lookup.
Optimized approach:
Create empty hash map
For each number:
complement = target - number
If complement in hash map:
Return [hash_map[complement], current_index]
Add number to hash map with its index
Time: O(n), Space: O(n)
This connects directly to our hash map pattern guide for a deeper dive on when this optimization applies.
Practical Preparation Strategies
Strategy 1: The "Before Code" Checklist
Before writing any code, verify you can answer:
- What is the output format exactly?
- What are two edge cases?
- What is the brute force approach?
- What is the expected time complexity given constraints?
If you can't answer all four, you're not ready to code yet.
Strategy 2: The "Explain It Out Loud" Test
Try to explain your approach in plain English before coding. If you stumble or say "and then somehow...", you don't understand your approach well enough yet.
This mirrors the verbal explanation technique crucial for actual interviews.
Strategy 3: Time-Boxed Exploration
Set a timer for 10-15 minutes of exploration before expecting any solution ideas. Use this time for:
- Working examples by hand (5 min)
- Writing brute force pseudocode (5 min)
- Constraint analysis (2-3 min)
This prevents the anxiety of "I should have an idea by now" from derailing your process.
Strategy 4: Use Guided Hints Strategically
When truly stuck after genuine exploration, targeted hints that point you toward the right pattern—without revealing the full solution—keep you in active problem-solving mode. Tools like LeetCopilot can provide this kind of progressive guidance, helping you build intuition rather than just copying answers.
Common Mistakes to Avoid
Mistake 1: Trying to Pattern Match Immediately
Wrong: Read problem → "This looks like sliding window" → Start coding
Right: Read problem → Work examples → Understand structure → Identify pattern from understanding
Pattern matching without understanding leads to forcing wrong patterns onto problems.
Mistake 2: Skipping Brute Force
Brute force isn't just for beginners—it's a problem-solving tool. Skipping it means you might miss what the problem is actually asking.
Fix: Always articulate brute force, even if you immediately see the optimization.
Mistake 3: Ignoring Constraints
Constraints aren't just for evaluating your solution—they guide your approach selection.
Fix: Read constraints before thinking about solutions. Let them narrow your options.
Mistake 4: Treating "Stuck" as Failure
Feeling stuck is part of the process, not a sign you're bad at this. The goal isn't to avoid feeling stuck—it's to have a process for getting unstuck.
Fix: When stuck, return to an earlier step: re-read the problem, work another example, or revisit your brute force.
Mistake 5: Rushing to Code
Code is the last step, not the first. Premature coding creates more problems than it solves.
Fix: Don't open your IDE until you can explain your full approach verbally.
Visualizable Example: The Complete Process
Problem: "Given an array of meeting time intervals, determine if a person could attend all meetings."
Step 1: Understand
- Input: list of [start, end] intervals
- Output: boolean (can attend all?)
- Hidden question: What prevents attending all? Overlapping meetings
Step 2: Work Examples
[[0,30], [5,10], [15,20]]
→ [5,10] overlaps with [0,30] → false
[[7,10], [2,4]]
→ No overlap → true
Step 3: Brute Force
For each pair of intervals:
Check if they overlap
Return true if no overlaps found
Time: O(n²)
Step 4: Constraint Analysis
n up to 10^4 intervals. O(n²) might pass, but O(n log n) is likely expected.
Step 5: Optimize
After sorting by start time, you only need to check adjacent intervals for overlap:
function canAttendMeetings(intervals: number[][]): boolean {
// Sort by start time
intervals.sort((a, b) => a[0] - b[0]);
// Check adjacent pairs for overlap
for (let i = 1; i < intervals.length; i++) {
// If previous meeting ends after current starts → overlap
if (intervals[i - 1][1] > intervals[i][0]) {
return false;
}
}
return true;
}
Why sorting helps: After sorting, if any overlap exists, it must be between adjacent intervals. This reduces O(n²) comparisons to O(n).
FAQ
How long should I spend understanding before trying to solve?
Aim for 5-10 minutes on understanding for Medium problems. If you can't articulate the brute force after 10 minutes, you might be misunderstanding the problem—re-read it carefully.
What if I understand the problem but still can't find an approach?
That's different from "no idea where to start." If you understand the problem and have brute force, you're not stuck on starting—you're stuck on optimizing. Focus on what repeated work exists in your brute force.
Should I memorize patterns?
Learn patterns, but don't rely on blind pattern matching. Understanding why a pattern works is more valuable than memorizing when to apply it. Our pattern recognition guide covers this distinction.
What if the brute force is too complex to even think of?
For very complex problems, start even simpler: solve a tiny, concrete example by hand. What steps did you take? That's your brute force.
Is it okay to look up hints if I'm stuck?
Yes, but progressively. First, check the problem's topic tags. Then, read just the first line of the approach. Get the minimum information needed to continue yourself. This is covered in detail in our dealing with getting stuck guide.
Conclusion
"I don't know where to start" isn't a sign of inadequacy—it's a signal that you need a process. That process is: understand deeply, work examples by hand, articulate brute force, analyze constraints, and only then look for optimizations.
The key insight is that finding the solution is the last step, not the first. Most of your time should be spent understanding the problem so thoroughly that the solution approach becomes apparent.
When you have a systematic process, "stuck" becomes "working through the steps." The anxiety of not knowing fades because you always know what to do next: go back one step and understand more deeply.
Next time you open a LeetCode problem and feel that familiar blankness, resist the urge to panic or guess. Pull out your checklist, work an example by hand, and trust the process. The solution will come—and more importantly, you'll understand why it works.
If you're looking for an AI assistant to help you master LeetCode patterns and prepare for coding interviews, check out LeetCopilot.
Top comments (0)