The 5-Step LeetCode Problem-Solving Framework

Step 1: Understand the Problem Deeply (2-3 min)

Ask these questions:

• What are the inputs? (types, constraints, edge cases in input)
• What are the outputs? (return type, format)
• What are ALL the constraints?
  • Sorted or unsorted?
  • Duplicates allowed?
  • Empty input possible?
  • Size limits?
  • In-place modification required?
  • Does order matter?
• What's the trick/pattern here? (sorted → two pointers, find duplicates → hash set, etc.)

Don't skip this! Read the problem 2-3 times and list constraints explicitly.

Step 2: Work Through Examples ON PAPER (5 min)

This is the most critical step!

Pick Diverse Examples:

• Normal case: typical input
• Edge case - empty: [] or ""
• Edge case - single element: [1] or "a"
• Edge case - two elements: [1,2]
• Edge case - all same: [2,2,2]
• Edge case - no matches/all matches: boundary conditions
• Large/complex case: tests if your logic scales

For Each Example:

1. Draw it out - visualize arrays, pointers, strings
2. Trace step-by-step:
   • Show variables at each step
   • Show pointer positions
   • Write what your brain is doing in plain English
3. Pay attention to edge cases - when do pointers cross? go out of bounds?

Use actual paper or whiteboard! Don't just think in your head - your brain lies to you!

Step 3: Write Pseudocode (3-5 min)

Use plain English, not code syntax:

# Good pseudocode example
initialize left pointer at start
initialize right pointer at end

while pointers haven't crossed:
    if elements match:
        move both pointers inward
    else:
        try skipping left element - check if rest is palindrome
        try skipping right element - check if rest is palindrome
        return true if either works
        
return true (no mismatches found)

helper function to check if substring is palindrome:
    use two pointers from ends
    return false if any mismatch
    return true if all match

Key principles:

• No syntax - focus on logic
• Be specific about what each step does
• Include helper functions if needed
• Note what you return and when

Step 4: Test Pseudocode & Identify Edge Cases (3-5 min)

Manually trace pseudocode against ALL your examples from Step 2:

• Does it handle empty input?
• Does it handle single element?
• What happens when pointers are equal?
• Can pointers go out of bounds?
• Are there off-by-one errors?

Common edge cases to check:

• Empty input
• Single element
• Two elements (same/different)
• All elements same
• No matches found
• Already optimal (e.g., already a palindrome)
• Pointers start at same position
• Boundary conditions

Add checks to pseudocode for any issues found!

Step 5: Code & Verify (5-10 min)

Now and only now, write actual code:

1. Keep paper examples nearby
2. Translate pseudocode line by line to actual syntax
3. After coding, trace through examples again - line by line
4. Don't trust your intuition - verify every step on paper
5. Test edge cases before submitting

Common bugs to watch for:

• i-1 vs i -= 1 (expression vs assignment)
• i < len(arr) vs i <= len(arr) (off-by-one)
• Not checking bounds before accessing array
• Wrong return value
• Forgetting to update loop variables

Time Allocation

Total: ~20-25 minutes for medium problems

• Understanding: 2-3 min (10-15%)
• Examples on paper: 5 min (25%)
• Pseudocode: 3-5 min (15-20%)
• Edge case analysis: 3-5 min (15-20%)
• Coding & verification: 5-10 min (30-40%)

Planning should be ~60% of your time, coding ~40%

Key Principles

DO:

✓ Paper/whiteboard is mandatory - physical tracing catches bugs
✓ Diverse examples - normal + all edge cases
✓ Pseudocode first - logic before syntax
✓ Test before coding - trace pseudocode against examples
✓ Verify after coding - trace code against examples

DON'T:

✗ Never skip examples - this is where bugs are caught
✗ Never code without pseudocode - for medium+ problems
✗ Never trust mental simulation - always write it down
✗ Never skip edge cases - they will break your solution

Red Flags (When to Stop & Go Back)

If you encounter these while coding, STOP and return to steps 2-3:

• "Wait, what happens if...?"
• Finding a bug during tracing
• Unsure what a variable should be
• Code getting messy/complicated
• Multiple nested loops appearing unexpectedly

Practice Tips

1. Time yourself - force yourself to spend time on steps 2-3
2. Keep a bug journal - write down every bug and which step would have caught it
3. Do problems twice - first time use framework, second time optimize
4. Review your traces - see where your mental model diverged from reality
5. Start with Easy problems - build the habit before tackling Hard

Problem Template

Use this for every problem:

PROBLEM: [Name]

STEP 1: UNDERSTANDING
- Input: 
- Output: 
- Constraints:
- Key insight/pattern:

STEP 2: EXAMPLES
Normal case:
Edge case 1 (empty):
Edge case 2 (single):
Edge case 3 (two elements):
Edge case 4 (all same):
Edge case 5 (boundary):

[Draw out each example with step-by-step trace]

STEP 3: PSEUDOCODE
[Write plain English pseudocode here]

STEP 4: EDGE CASE VERIFICATION
- Test pseudocode against all examples above
- Check: bounds, pointers crossing, off-by-one, empty input

STEP 5: CODE
[Write actual code]

COMPLEXITY ANALYSIS:
- Time: O(?)
- Space: O(?)

Next Problem Challenge

For your next problem:

1. Set 10-minute timer - NO coding allowed
2. Do steps 1-4 only
3. Review your examples + pseudocode
4. Only after verification, then code

This builds the muscle memory of proper planning!

Remember

15 min planning + 5 min coding + 0 bugs = 20 min total

2 min thinking + 5 min coding + 30 min debugging = 37 min total

In interviews, planners finish faster than coders.