The same coding answer gets three different grades at Meta, Google, and Amazon

Picture the same candidate giving the same performance three times: they hear the problem, sketch a brute-force approach out loud, talk through why it's quadratic, then work toward the optimal solution with a couple of nudges. Clean code, decent communication, gets there in the end.

At Google, that performance can score near the top of the rubric. At Meta, it's a borderline no-hire. At Amazon, the coding barely decides anything — what decides is a question they never saw coming. Same person, same skill, three different outcomes. Not because interviewers are random, but because these companies are deliberately grading different things.

Google grades the journey

Google is the only one of the three with a published, numeric coding rubric: four axes — algorithms, coding, problem solving, communication — each scored 1 to 4, with roughly a 3.0 average as the hire bar. Notice what that weighting means: communication is about a quarter of your score, the heaviest of any major tech company.

And Google's culture is explicitly brute-force-first. In their own calibration examples, a top-scoring answer "effortlessly illustrated several solutions along with their drawbacks." Starting simple and reasoning upward isn't a weakness there — it's the exact behavior the rubric rewards. Their interviewers are also trained to give hints, because a hint creates a measurement: do you integrate new information fast? That's the learning-agility signal Google actually cares about, since they hire generalists into a level, not a team.

One more Google signature: trick questions disguised as familiar patterns. The problem looks like standard binary search until the twist surfaces. They want to see whether you check your pattern-matching or barrel ahead on autopilot. After your working solution, expect the chain: "Can you do better?" → "What if the input is streaming?" → "How would you test this?"

Meta grades the clock

Meta runs the same 45 minutes completely differently: two problems, back to back, roughly 35 minutes of actual coding time. That's ~17 minutes per problem, and the hire bar is two optimal solutions — not two solutions. The calibration is blunt: 2/2 optimal is a hire signal, 1.5/2 is borderline.

That math is why the Google-style exploratory ramble fails here. A leisurely brute-force discussion that "ate up the time" is logged as an underperformance signal at Meta, even if you eventually got the optimal answer. Interviewers move on if you're stuck more than about seven minutes, and over-engineering a simple problem is its own red flag. Meta penalizes slow output, not slow thinking — they expect the optimal approach to be near the front of your mind, because that's what their interview volume calibrates for.

Two questions are effectively mandatory in every Meta coding round, and omitting them hurts even with perfect code: "How does this scale to our size?" and "How would you test this?" If your solution works but you never mention what happens at a billion users, you left rubric points on the table that the next candidate collected.

Amazon grades the person

Amazon's coding bar is the most forgiving of the three — brute force is acceptable, hints are scarce but the difficulty is calibrated medium. The catch is that the coding round isn't really only a coding round. Around the 20-minute mark, many Amazon interviewers deliberately pause the technical work: "Let's take a quick break from the code — tell me about a time you went above and beyond for a customer."

That interruption is the round. Amazon's actual rubric is its 16 Leadership Principles; every interviewer is assigned two or three of them to probe, and the panel covers all sixteen. Your STAR story needs metrics in the Result — "reduced latency 40%, from 500ms to 300ms," not "significant improvement." Saying "we" when you mean "I" is an explicitly trained-against signal. And by published estimates, about a quarter of candidates who clear Amazon's technical bar are rejected on behavioral grounds anyway — many by the Bar Raiser, a third-party interviewer with independent veto power who isn't even on the hiring team.

The same five minutes, three scorecards

Go back to our candidate's opening move — "let me start with brute force and reason from there":

• Google: rubric-positive. Multiple approaches with trade-offs is literally the description of a 4.
• Meta: clock-negative. Seventeen minutes per problem means the optimal approach needed to surface in the first three.
• Amazon: mostly neutral — but the interviewer is quietly noting whether you mentioned the customer impact of the slow solution, because Customer Obsession is one of their assigned LPs and you just missed a free data point.

This is why "I did 300 LeetCode problems" and "I'm ready for my onsite" are different claims. The code is maybe half the grade, and the other half is company-specific in ways most candidates never train for because most practice tools treat every interview as the same interview.

How to actually prep for the company you're facing

1. Going to Google? Practice narrating multiple approaches with trade-offs before committing. Treat hints as part of the test — respond to them visibly and fast. Budget real energy for communication; it's ~25% of your score.
2. Going to Meta? Drill speed. Two mediums in 35 minutes, optimal-first, out loud, with a timer. End every practice problem by answering "how does this scale?" and "how would you test it?" unprompted, until it's a reflex.
3. Going to Amazon? Prepare 6–8 STAR stories with numbers in every Result, mapped to specific Leadership Principles. Practice being interrupted mid-code and switching modes without losing your place — because that's not a malfunction, it's the format.

Most candidates can't simulate any of this. A practice partner doesn't run a strict two-problem clock, doesn't know Google's hint culture, and definitely doesn't pause your coding to demand a customer-obsession story with metrics. That's exactly the gap Viewkite was built around: each company's mock is tuned to that company's actual format — Meta's pace and mandatory follow-ups, Google's hint-friendly trick-question style, Amazon's mid-round LP interruption — and the report afterward scores you against that company's rubric, not a generic one.

Whatever you use to practice: stop prepping for "the coding interview." Find out how your target company grades, and train for that scorecard.