You're Practicing on the Wrong LeetCode Difficulty

You've spent three weeks grinding hards. Segment trees with lazy propagation. Edit distance with k allowed changes. Bitmask DP over subsets. You've ascended. You've seen things other engineers haven't seen.

Then you interview at a solid tech company and they ask you to find the k-th largest element in a stream. Classic medium. You finish in 18 minutes, explain every decision out loud, and handle two follow-up questions. You get the offer.

The hards didn't carry you. The medium you knew cold did.

Most coding interviews ask LeetCode medium problems, not hards, and the reason is structural. A 45-minute session has physics. That physics selects for mediums. Once you understand why, the right prep strategy becomes obvious, and you can stop torturing yourself with problems that were never going to show up.

The 45-Minute Problem

Subtract the preamble. Five minutes of introductions. Five minutes to read the problem, ask clarifying questions, confirm edge cases. That's ten minutes gone before you've written a line.

Count backward from 45. You want five minutes at the end to walk through test cases and ask the interviewer your own questions. That leaves 30 minutes of actual problem time. Call it 25 if you're being honest about context-switching overhead and the mild panic that sets in when your first approach doesn't work.

Hard problems on a first attempt, for most people, take 40 to 90 minutes. They don't fit the window, and interviewers know this.

There's a subtler reason experienced interviewers prefer mediums too. A well-chosen medium has layers. Start with the brute force: O(n²), five lines, easy to get talking. Then optimize: where's the bottleneck, what data structure removes it? Then edge cases. That's three distinct moments where an interviewer gets an independent read on how you think.

# Two Sum: the layered medium
# Layer 1: brute force - O(n²), instant to code and discuss
def two_sum_naive(nums, target):
    for i in range(len(nums)):
        for j in range(i + 1, len(nums)):
            if nums[i] + nums[j] == target:
                return [i, j]

# Layer 2: "what if we cache complements instead?"
# The tradeoff conversation: O(n) time, O(n) space
def two_sum(nums, target):
    seen = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i

Hard problems don't have that structure. There's often no coherent brute force to discuss. The problem turns on a single insight you either have or you don't. Either way, the interviewer gets one data point. That's a poor test, and most interviewers know it.

What Companies Actually Ask

The numbers are less dramatic than the discourse suggests.

Amazon's commonly asked problem pool breaks down to roughly 19 easy, 60 medium, and 21 hard. Meta's is similar: 26 easy, 60 medium, 14 hard. In both cases, medium makes up 60% of the question bank. And these are pools. The problems that actually appear in most screening calls skew even more heavily toward medium because interviewers self-select for questions they can meaningfully evaluate in 45 minutes.

Meta's format makes this concrete: they ask two problems in one 45-minute session. If both are mediums, the math works. If either is a hard, the session breaks. Glassdoor candidate reports consistently describe "LeetCode medium" as the baseline.

Google is the genuine outlier. Their problems can feel harder, but "harder" usually means an unfamiliar combination of two patterns you already know, not a fundamentally different problem class. A BFS over an unusual state space. Binary search on a transformed function. The distinction matters for prep.

The presence of true LeetCode hards is rare. One analysis estimated roughly 4% of interviews involve a problem most engineers would call unreasonably difficult. Many candidates who report getting hard problems likely received mediums they personally found hard, which says more about prep gaps than company expectations. Difficulty is subjective. Your three weeks of segment trees are not.

Four Dimensions, Not One

This is where the "just grind hards" strategy falls apart even on its own terms.

What top companies actually score: communication, problem solving, technical competency, and testing. Four dimensions. A candidate who solves a medium while narrating every decision outscores one who silently produces a hard solution. Interviewers don't just want to see the answer. They want to see the process. The silent hard-solver is like acing a test but being unable to explain a single answer. Not a hire.

(If you want to go deep on why communication is half the score, this breakdown is worth reading.)

The communicative medium-solver scores across all four dimensions. Communication and problem solving are evaluated independently of whether you reach the correct answer. Clean code is a separate rubric line. Testing is another. A hard problem solved silently in 38 minutes is weaker interview performance than a medium solved with clear thinking and live narration in 22 minutes.

Bane from Dark Knight faces Pink Guy with the caption: candidate with a master's and 2 internships under their belt vs me who just solved a leetcode medium Solving a medium clean and loud beats "I once implemented Dijkstra from memory" at 11pm in a panic.

Practice under mock conditions with real-time feedback closes this gap faster than solo problem grinding. SpaceComplexity runs voice-based mock interviews graded on those four dimensions, which is the part most home practice skips entirely.

When Hards Do Show Up

Volume filtering. When companies receive thousands of applications for a small number of roles, hard problems act as a coarse filter. Campus recruiting at scale is the clearest case. If you're applying fresh out of a top program for a role that gets ten thousand applicants, expect harder problems. The company is optimizing for throughput, not signal quality.

Google and the combination style. Google's problems sometimes require combining two familiar patterns in an unfamiliar way. These feel hard but yield to systematic pattern recognition. The answer is knowing fewer patterns more deeply, not knowing more problems.

Staff and senior roles. At L6 and above, coding matters less than system design. The coding round may include a harder problem, but failed coding is rarely why senior candidates get rejected. They fail on system design depth or leadership signal.

If you're applying to Amazon, most mid-sized tech companies, or startups, mastering mediums is sufficient. Push harder only after your foundation is solid, and only if you're targeting Google specifically or a team known for competitive programming culture.

Medium vs Hard: The ROI Math That Misleads People

There's a data point from interviewing.io that looks like an argument for grinding hards. Completing 50 hard problems improves interview success rates by roughly 7 percentage points. Completing 50 mediums? About 3 points. Twice the return.

That's technically true. In the same way it's faster to take the highway when there's a 45-minute backup on the highway.

Hard problems take three to four times longer to work through than mediums. Getting through 50 hards takes roughly as long as 150 to 200 mediums. At 3 points per 50 mediums, those 150 mediums represent 9 points of improvement, not 7. The per-hour ROI of mediums beats hards. The same research showed most top performers plateau around 500 problems, and the majority of those are mediums.

The real breakthrough is solving unseen mediums cold, under a 20-minute clock, while explaining your thinking out loud. People who can do that consistently pass most interviews. People who've only ground hards in private often can't, because they've never built the live communication habit. That's a whole second skill they forgot to practice.

Patterns Are the Unlock

Ten to fifteen core patterns account for roughly 80% of what interviews ask: sliding window, two pointers, binary search, BFS/DFS, backtracking, heaps, monotonic stack, union-find, dynamic programming, topological sort. These patterns mostly manifest at medium difficulty. When you can recognize and implement any of them cold in 20 minutes, you have the building blocks for most hard problems too, since hard problems usually combine two patterns you already know.

You can't compose patterns you've only half-internalized at medium, no matter how many hards you've attempted above them. Bitmask DP over a graph you don't understand yet is not practice. It's tourism.

Two to three mediums per pattern, solved unseen, under time pressure, with narration. That's the repetition that builds transferable skill. Not a list of problems to memorize, not 200 hards you half-completed while reading the editorial after ten minutes.

This connects to a broader failure mode that costs engineers interviews: treating LeetCode as a memory exercise rather than a pattern-recognition exercise. The goal is not to have seen the problem before. The goal is to recognize the pattern the moment you see the problem.

The Strategy in Plain Terms

Learn patterns first, then validate with problems.

Start with the 10-15 core patterns. For each one, do two or three unseen mediums under a 20-minute clock. Narrate your approach before writing any code. Get to a working brute force first, then optimize. Handle edge cases explicitly.

When you can consistently hit mediums under time and explain them clearly, add hards as a supplement. Not before. At that point, a hard problem is just a composition exercise: which two patterns does this combine, and how do they interact?

Mock interviews belong in the plan from the beginning, not as a one-week cram at the end. The communication dimension is not something you develop by solving problems alone. You develop it by talking while solving problems, which is a completely different skill.

The Short Version

Most interviews ask mediums. The 45-minute format makes hard problems structurally difficult to evaluate.
Mediums have brute-force layers that generate multiple evaluation signals. Hard problems often don't.
Amazon and Meta ask predominantly mediums. Google asks medium-hard combinations, not true hards.
Around 4% of interviews include an unreasonably hard problem. Know which companies that applies to.
The per-hour ROI of mediums beats hards. Learn patterns at medium, add hards only after you can hit them cold.