What Amazon, Google, and Meta actually test in coding interviews (with specific problems)

Table of Contents

• Meta: Two stages, two completely different problems
• Google: The problem that reveals who actually prepares
• Amazon: The company where coding is table stakes
• The pattern across all three
• What to prioritize per company

Background

Most interview prep advice is generic. "Know your trees." "Practice dynamic programming." "Be comfortable with graphs." It's not wrong — it's just not enough.

After building company-specific interview prep paths from confirmed candidate reports going back to 2022, here's what the data actually shows about how Amazon, Google, and Meta interview — and specifically where most candidates go wrong.

Meta: Two stages, two completely different problems

Meta's process has a phone screen and an on-site. The problems that dominate each stage are different, and conflating them is a common prep mistake.

Phone screen staples:

• LC 680 — Valid Palindrome II (near-certainty)
• LC 408 — Valid Word Abbreviation (common warm-up, finish under 10 min)
• LC 88 — Merge Sorted Array (expects O(1) space reverse-merge immediately)
• LC 3 — Longest Substring Without Repeating Characters

The phone screen pattern: sliding window and two-pointer problems where you're expected to jump to the O(n) solution within 3 minutes of reading the problem. Spending more than 2 minutes on brute force is a signal Meta interviewers watch for explicitly.

On-site: the #1 most-reported Meta problem

LC 1249 — Minimum Remove to Make Valid Parentheses. Appears in 95%+ of reported Meta on-sites.

The trap is pushing characters instead of indices:

def minRemoveToMakeValid(self, s: str) -> str:
    stack = []       # stores indices of unmatched '('
    to_remove = set()

    for i, c in enumerate(s):
        if c == '(':
            stack.append(i)
        elif c == ')':
            if stack:
                stack.pop()          # matched pair
            else:
                to_remove.add(i)     # unmatched ')'

    to_remove |= set(stack)          # remaining stack = unmatched '('
    return ''.join(c for i, c in enumerate(s) if i not in to_remove)

The junior vs senior answer at Meta:

A junior pushes characters and tries to rebuild the string on the fly.

A senior says: "I push the index of every open paren. On a close paren, if the stack is non-empty I pop — matched. If empty, I mark that close paren's index for removal. After the pass, everything still on the stack is an unmatched open paren — mark those too. One reconstruction pass."

The follow-up Meta always asks: "What if you need to handle square brackets too?" Answer: extend the stack to track pairs — push both the index and the bracket type.

The Jedi round (behavioral) is one round, culture-fit-heavy. Pick disagreements with real technical dimension — architecture, reliability, API design. Technical depth in behavioral answers impresses Meta interviewers even in that round.

Google: The problem that reveals who actually prepares

Google's reputation for broad scope is real — arrays, binary search, trees, graphs, DP, heaps, backtracking, data-structure design, and Google-specific problem types. But there is one problem that shows up as a diagnostic filter more than any other:

LC 238 — Product of Array Except Self

Google asks this specifically because division is prohibited. The question is whether you'll independently derive the prefix/suffix product trick or whether you'll ask "can I use division?" and get stuck.

def productExceptSelf(nums):
    n = len(nums)
    output = [1] * n

    prefix = 1
    for i in range(n):
        output[i] = prefix
        prefix *= nums[i]

    suffix = 1
    for i in range(n - 1, -1, -1):
        output[i] *= suffix
        suffix *= nums[i]

    return output

The junior vs senior answer at Google:

A junior asks "Can I use division?" and gets stuck when told no.

A senior says: "Division is forbidden and breaks on zeros anyway. Two passes — left prefix products into the output array, then multiply in a right suffix product in-place with a single variable. O(n) time, O(1) extra space, zeros propagate naturally with no special cases."

The complexity proof standard

Google cares more about this than Meta or Amazon. Saying "O(n log n)" is weaker than:

"The sort dominates at O(n log n). The merge pass is a single O(n) scan. Total: O(n log n) time, O(n) output space."

Handwaving complexity is a yellow flag at Google even when the solution is correct.

Top K Frequent Elements (LC 347) is another Google-specific diagnostic. They want both the heap solution (O(n log k)) and the bucket sort solution (O(n)) — and an explanation of why bucket sort is valid here (frequencies are bounded by n, which makes the index trick possible). The transition between the two is where they assess depth.

Googleyness is a structured rubric in the final behavioral round — intellectual curiosity, collaborative problem-solving style, comfort with ambiguity. It's a full interview section, not an afterthought.

Amazon: The company where coding is table stakes

Amazon's loop includes a bar-raiser round dedicated entirely to Leadership Principles. But more importantly: every interviewer in the loop asks LP questions, not just the bar-raiser.

There are 16 LPs. The most tested at senior levels:

• Deliver Results — "How did you measure success? What were the metrics?" Have your numbers ready: latency reduction, defect rate, revenue impact, customer satisfaction score.
• Have Backbone; Disagree and Commit — The drill-down: "Did you fight for your position? Then what happened? Did you fully commit after the decision was made?"
• Customer Obsession — "Tell me about a time when doing right by the customer conflicted with a technical constraint." They want the tension, not the easy version of the story.

The rule: have 2+ STAR stories per LP. Amazon interviewers are trained to ask for a second example if the first is weak.

For coding, Amazon patterns skew toward well-known mediums where clarity and communication matter as much as optimization.

LC 128 — Longest Consecutive Sequence

The O(n) HashSet approach is required. The key insight: only numbers with no left neighbor (num - 1 not in the set) should trigger a count — otherwise you recount the same sequence multiple times and degrade to O(n²).

def longestConsecutive(nums):
    num_set = set(nums)
    longest = 0

    for num in num_set:
        if num - 1 not in num_set:    # only start from sequence beginning
            length = 1
            while num + length in num_set:
                length += 1
            longest = max(longest, length)

    return longest

Amazon interviewers specifically appreciate when you articulate why the O(n log n) sort approach misses the stated O(n) constraint — it signals you read requirements carefully.

LC 139 — Word Break

The insight worth knowing: Word Break is structurally identical to Coin Change. Both are "try each option from each position" tabulation problems. If you understand the Coin Change recurrence, Word Break follows immediately — same DP shape, different domain.

The pattern across all three

If you're doing multi-company prep, master hash maps, prefix sums, sliding window, stack with index tracking, and BFS/DFS on trees first. That's the overlap that pays off across all three.

What to prioritize per company

Meta: Narrow to the 30–40 problems that appear most in confirmed reports. Get the sliding window template automatic before your phone screen. Know Valid Parentheses → Minimum Remove → Basic Calculator I → II → III as a progression — each builds directly on the last.

Google: Go wide but practice explaining your reasoning out loud the entire time. Google's diagnostic isn't whether you solved it — it's how you reason through it. Prove complexity claims step by step, not just state them.

Amazon: LP prep deserves as much time as coding prep. Build 8–10 strong career stories. Map each story to multiple LPs it could cover. Know your metrics cold — every LP story needs a quantified result.

I've been building these prep paths at streamprep.dev — company-specific tracks built from confirmed interview reports, each problem with a guided discovery flow and the "what the interviewer is actually testing" framing shown above. Free during beta.

Explore company-specific interview paths on StreamPrep (Free during beta)

Curious what patterns people are seeing that aren't covered here — drop a comment.