How to Approach Hard LeetCode Problems

Step 2: Identify Constraints and Implicit Hints

The constraints of a problem aren’t just there to make your life hard; they are your biggest hints. LeetCode problems, especially hard ones, are often designed to force you into a specific algorithmic approach.

• The O(n) Clue: If the input is unsorted, O(n) often points toward a hash map, a sliding window, or a two-pointer technique.
• The O(log n) Clue: This is the biggest giveaway. Achieving logarithmic time almost always means you need to use binary search or a data structure like a heap or balanced binary search tree. For “Median of Two Sorted Arrays,” the O(log (m+n)) requirement screams binary search.
• The O(n log n) Clue: This often points to sorting, followed by a linear scan, or using a greedy algorithm with a priority queue.
• Space Constraints: If the problem says “do it in-place” or “with O(1) extra space,” you’re likely looking at pointers, swaps, or reversing parts of the input.

Step 3: Recognize the Underlying Pattern

Hard problems are rarely completely novel. They are often combinations of well-known patterns. Your job is to find the pattern hidden under the story.

Think of patterns as your coding cheat codes. Here are a few for complex problems:

• Graph Traversal (BFS/DFS): Keywords like “connected components,” “shortest path,” “maze,” “network,” or “tree” are your clues.
• Dynamic Programming (DP): Look for optimization keywords like “maximum,” “minimum,” “longest,” “number of ways,” and crucially, “overlapping subproblems” (where you calculate the same thing repeatedly).
• Union-Find (Disjoint Set Union): This pattern appears when you hear “connect,” “group,” or “find if two elements are in the same set.”
• Monotonic Stack: Keywords like “next greater element,” “daily temperatures,” or “largest rectangle in histogram” point here.

Step 4: Start with a Brute Force Solution (and Be Proud of It)

There’s a misconception that you must immediately see the optimal solution. You don’t. 

Even senior engineers start with brute force to ensure they understand the problem. Verbally acknowledge the brute force approach.

“Okay, for finding the median, the brute force way is to merge both arrays into one new array, which takes O(m+n) time and space, and then just pick the middle element. That’s too slow, but it guarantees a correct answer.”

Articulating this does two things:

1. It shows you know how to get a correct answer.
2. It clarifies exactly why it’s inefficient, which guides your optimization.

Step 5: Optimize Relentlessly (The Pivot)

Now you have a working baseline. Your goal is to eliminate the inefficiencies. Ask yourself these questions to pivot toward the optimal solution:

• Can I eliminate the extra space? (Move toward in-place algorithms, pointers)
• Can I reduce the time complexity? (Can I use binary search instead of a linear scan? Can I use memoization to avoid recomputation?)
• Can I process the data in a different order? (Would sorting help? Would iterating from the end help?)
• Is there a data structure that’s perfect for this? (If you need fast lookups, is a hash map better than a list? If you need the smallest element repeatedly, is a min-heap the answer?)
  For our median problem, you realize the O(log n) requirement forces you to find a way to binary search on both arrays simultaneously, partitioning them so that all elements on the left are smaller than all elements on the right.

Step 6: Walk Through a Concrete Example

Before you code, dry-run your optimized logic on a small, concrete example. Use a whiteboard, a notebook, or even just talk it out loud.

For “Median of Two Sorted Arrays,” use:

nums1 = [1, 3], nums2 = [2]

If your partitioning logic is correct, you should end up with a left partition containing [1, 2] and a right partition containing [3], making the median 2.0.

This step catches logical errors before they become frustrating debugging sessions.

 

💡 Pro Tip: Use a small example that covers all edge cases. If your example is too simple, you might miss a crucial condition, like what happens when one array is empty.

 

Step 7: Code with Intent

Now, translate your verified logic into code. Don’t just type. As you write each line, comment on its intent. This helps you stay focused and is a huge plus in interviews.

# Example: LeetCode 4 - Median of Two Sorted Arrays (Conceptual Logic)
def findMedianSortedArrays(nums1, nums2):
    # Ensure nums1 is the smaller array for efficient binary search
    if len(nums1) > len(nums2):
        return findMedianSortedArrays(nums2, nums1)

    A, B = nums1, nums2
    m, n = len(A), len(B)
    total = m + n
    half = total // 2

    # Binary search on the smaller array
    left, right = 0, m - 1
    while True:
        # i = partition point for A, j = partition point for B
        i = (left + right) // 2  # A has i+1 elements on left
        j = half - (i + 1) - 1   # B has j+1 elements on left

        # Handle edge cases where partition is at the very beginning/end
        A_left = A[i] if i >= 0 else float("-infinity")
        A_right = A[i + 1] if (i + 1) < m else float("infinity")
        B_left = B[j] if j >= 0 else float("-infinity")
        B_right = B[j + 1] if (j + 1) < n else float("infinity")

        # Check if we have found the correct partition
        if A_left <= B_right and B_left <= A_right:
            # Found correct partition, calculate median based on total length
            if total % 2:
                return min(A_right, B_right)
            return (max(A_left, B_left) + min(A_right, B_right)) / 2
        elif A_left > B_right:
            # Too many elements from A on left side, move partition left in A
            right = i - 1
        else:
            # Too few elements from A on left side, move partition right in A
            left = i + 1

Step 8: Test and Reflect

After you have a working solution, run it against the provided test cases. Then, think of your own edge cases:

• What if one array is empty?
• What if all numbers are the same?
• What if the input contains negative numbers or zeros?
• Finally, reflect on the process. Why did this pattern work? Could this approach be used for a different problem? This reflection is what turns a finished problem into a learning experience.

4. Common Mistakes

Even with a great process, it’s easy to fall into traps. Here are the most common ones students make.

• Mistake 1: Coding ImmediatelyWhat it looks like: Typing furiously within the first 30 seconds of seeing the problem.
• Why they make it: Overconfidence or panic.
• How to avoid it: Force yourself to spend at least 5-10 minutes on a whiteboard or paper before touching the keyboard.
  Mistake 2: Ignoring the Constraints
• What it looks like: Writing an O(n²) solution when the constraints clearly require O(n log n).
• Why they make it: Missing the hints the problem is giving you.
• How to avoid it: Before starting, circle the input size limits. Let them guide your algorithm choice.
  Mistake 3: Getting Lost in the Narrative
• What it looks like: Focusing on the story about “zombies infecting a grid” instead of the underlying “BFS on a 2D matrix.”
• Why they make it: The story is designed to distract you.
• How to avoid it: Actively practice stripping away the story to find the core data structure and algorithm pattern.
  Mistake 4: Not Testing Edge Cases
• What it looks like: The code passes the examples but fails on [] or [1,1,1,1].
• Why they make it: Assuming the happy path is the only path.
• How to avoid it: Make it a habit. After you finish coding, immediately ask, “What’s the smallest input? What’s the most repetitive input? What breaks my code?”
  Mistake 5: Giving Up Too Soon
• What it looks like: Looking at the solution after 10 minutes of frustration.
• Why they make it: Discomfort with not knowing the answer.
• How to avoid it: Set a timer for 45 minutes to an hour. Your goal isn’t to solve it; it’s to make as much progress as possible. Struggle is where the learning happens.

5. Frequently Asked Questions (FAQ)

Q: How many hard problems should I do before an interview?
A: Quality over quantity. It’s better to deeply understand 15-20 hard problems across different patterns (DP, Graphs, Trees, etc.) than to have superficially looked at 100. Focus on the process of deriving the solution.

Q: I can solve them but it takes 2-3 hours. Is that normal?
A: Absolutely. In the beginning, it can take a full day to truly understand a single hard problem. The time will naturally decrease as you build your pattern recognition library.

Q: Should I memorize solutions?
A: No. Memorization is a trap. Focus on memorizing patterns and strategies. Instead of memorizing the code for “Trapping Rain Water,” understand why a two-pointer or monotonic stack approach works for that class of problems.

Q: What if I can’t even come up with a brute force solution?
A: This is a sign you might be missing some fundamental knowledge. Review the basic data structures (arrays, hash maps, linked lists) first. The brute force solution for 90% of problems is “iterate over everything in a nested loop.”

Q: What’s the single most important skill for hard problems?
A: Pattern recognition. Being able to look at a problem about “connecting cities with the lowest cost” and immediately think “Kruskal’s algorithm with Union-Find” is the key to speed.

Q: How do I handle the pressure of solving a hard problem in an interview?
A: Communicate. Your interviewer wants to see your thought process more than they want to see a perfect, bug-free solution. Talk through your decomposition, your brute force idea, and how you would optimize it.

Q: What resources do you recommend for learning advanced patterns?
A: In addition to our tutoring sessions, resources like “Cracking the Coding Interview” and the “Algorithms” by Robert Sedgewick are excellent for deep-diving into advanced concepts.

Q: Is it worth solving LeetCode hard if I’m only a freshman?
A: It can be a great challenge, but make sure your fundamentals are solid first. Focus on mastering easy and medium problems in your coursework. Hard problems are great for honing problem-solving skills but shouldn’t replace foundational learning.

6. Conclusion

Approaching hard LeetCode problems is a skill, not a talent. By decomposing the problem, using constraints as hints, recognizing underlying patterns, and systematically optimizing from a brute force solution, you can tackle any coding challenge that comes your way. Remember, the goal isn’t just to get a green “Accepted” stamp; it’s to build a resilient, analytical mindset that will serve you throughout your academic and professional career.

Don’t let a tough problem make you feel alone. Whether you’re debugging a stubborn piece of code or preparing for a high-stakes interview, getting a fresh pair of eyes on your work can make all the difference.

Submit your assignment for a detailed code review, or Book a tutoring session for one-on-one guidance. For more strategies and tips, explore more articles on our blog.