The 5 Things FAANG Interviewers Actually Score You On

Most candidates prepare for FAANG SQL rounds by grinding more LeetCode problems. Then they bomb the loop and can't figure out why — the SQL was right. They were even fast. So what happened?

What happened is that they optimized for one dimension on a five-dimension rubric.

I've seen the rubrics from Meta, Google, Amazon, and Stripe data analyst loops. They're not identical, but they're remarkably similar: five categories, each scored 1-5, with the offer threshold typically a 4 average and no category below 3. SQL correctness is one of the five. The other four are what candidates ignore — and what tanks loops.

Here's what they actually score, and how to move yourself up on each.

Dimension 1 — Problem Structuring

What they score: Did you clarify the question before writing SQL? Did you decompose the problem into steps? Did you state assumptions explicitly?

Why it's weighted heavily: Because in real work, the analyst who jumps to SQL without understanding the question delivers the wrong answer. FAANG interviewers test for the failure mode that costs companies the most money: well-executed work on the wrong problem.

What scores high:

• Restating the question in your own words
• Asking 2-3 specific clarifying questions
• Naming your assumptions: "I'm going to assume 'active user' means at least one session, unless you want a different definition"
• Sketching the query plan before writing SQL: "Two CTEs, then a final join"

What scores low:

• Starting to type SQL immediately
• Asking only generic questions ("how big is the data?")
• Building a complex query, then realizing halfway through you misunderstood

The move that moves you up: spend the first 60 seconds not writing SQL. Use it to clarify and decompose. Every interviewer notes whether you did this.

Dimension 2 — SQL Correctness

What they score: Does your query return the right answer? Do you handle edge cases (nulls, duplicates, empty groups)? Is your syntax clean?

Why it matters but less than you think: Yes, correctness matters — a query that returns the wrong number fails the round regardless of how well you talked through it. But correctness alone is table stakes. Every candidate who passes the phone screen can write a correct query. Correctness gets you a 3 on this dimension. The 4s and 5s come from edge-case handling.

What scores high:

• Explicit NULLIF to prevent divide-by-zero
• COUNT(DISTINCT user_id) when the question is about users, not rows
• LEFT JOIN when you need to preserve nulls, named as a deliberate choice
• Casting to numeric before division (Postgres) or using 1.0 * (everywhere) to prevent integer truncation
• CTEs labeled with clear names, not t1, t2

What scores low:

• Off-by-one in time windows ("last 30 days" — is today included?)
• Counting rows when you meant users
• Missing the WHERE clause that filters to the specific experiment / cohort / segment
• Letting NULL values silently break aggregations

The move that moves you up: every query, before you say "done," run through a mental edge-case checklist: nulls, duplicates, empty groups, time window inclusivity, integer division. 20 seconds of self-review costs nothing and catches the bugs that lose points.

Dimension 3 — Communication

What they score: Can you narrate your thinking? Can you explain your SQL to someone who didn't write it? Can you accept feedback mid-query without defensiveness?

Why it's weighted as much as correctness: Because analysts spend more time explaining their queries than writing them. A query whose results you can't explain is worth less than a slightly worse query whose results you can.

What scores high:

• Narrating decisions, not actions: "I'm using a window function here because we need a per-user ranking"
• Pausing to check understanding: "Does that match what you'd expect?"
• Gracefully accepting redirection: "Good catch, let me rework that"

What scores low:

• Silent typing for 60+ seconds
• Reading your SQL out loud line by line (different from narrating decisions)
• Defensiveness when the interviewer suggests an alternative

The move that moves you up: if you're silent for more than 30 seconds, you're losing points. Narrate even when you're stuck — "I'm thinking through how to handle the duplicates here" — so the interviewer can see your reasoning.

For more on narration specifically, see the strategy article on talking through queries without sounding robotic — it's the single highest-ROI prep activity for FAANG loops.

Dimension 4 — Business Judgment

What they score: Do you understand what the metric means? Can you spot when a number is misleading? Do you propose what to do next?

Why it's the differentiator at senior: This dimension separates senior offers from junior. A senior candidate doesn't just compute the metric — they interpret it. They notice that a 30% lift in a small segment is consistent with random noise. They flag that ROAS isn't LTV. They ask what the cost of being wrong is before recommending a ship.

What scores high:

• Interpreting results, not just reporting them: "Mobile converts at 9% vs desktop's 18% — let me think about why"
• Naming what would change your recommendation: "If retention is high, this CAC is fine. If retention is low, we need to renegotiate"
• Spotting confounds: "The lift might be a novelty effect — I'd want to see week 3 data"
• Distinguishing significance from importance: "This is statistically different but probably not actionable"

What scores low:

• Reading the result and stopping: "So conversion is 14%."
• Recommending action with no caveats: "Looks good, ship it"
• Treating every number as definitive

The move that moves you up: after every query, before declaring done, add one sentence: "What I'd do next is..." That single sentence is the senior signal.

Dimension 5 — Code Quality

What they score: Is your SQL readable? Are CTE names meaningful? Would a teammate understand this query a month from now?

Why it matters in senior loops: Because at senior, you're not just writing SQL — you're producing artifacts that other people maintain. Interviewers downgrade beautiful SQL that looks like a tangled mess.

What scores high:

• Meaningful CTE names: active_users_q4, not cte1
• Consistent indentation
• One concept per CTE, not five things crammed into one
• Comments only where the why isn't obvious

What scores low:

• Single 40-line subquery with no CTE structure
• Variable names like a, b, t1
• Inconsistent capitalization (Select vs SELECT vs select)
• Inline comments narrating obvious syntax

The move that moves you up: at the end of every query, take 20 seconds to rename your CTEs and align your indentation. The interviewer's last impression of your code is the version they're scoring.

The Senior vs. Junior Pattern

Looking at how candidates score across the five dimensions:

The pattern: junior candidates put 80% of their effort into Correctness and 20% scattered across the rest. Senior candidates spread it evenly. The score reflects that distribution.

What This Means for Prep

If you've been grinding pure SQL drills and not getting interviews to convert, your bottleneck probably isn't SQL. It's one of the other four dimensions. Here's the time reallocation that fixes most loops:

• 30% SQL practice (correctness)
• 20% Talking out loud on practice problems (communication)
• 20% Reading real analyst case studies (business judgment)
• 15% Writing 2 paragraphs of interpretation after every practice problem (judgment + communication)
• 15% Reviewing your own SQL from a week ago (code quality + structuring)

The grinders fail because they're at 100% on dimension 2. The candidates who land offers spread the prep.

How To Practice This

Pick one practice problem. Solve it. Then score yourself on all five dimensions, 1-5. Be honest. The dimensions where you scored 3 or below are your prep targets for the week.

Most candidates discover they're a 5/3/2/2/2. That's diagnostic — and fixable. Improving from 2 to 4 on Communication or Business Judgment is faster than improving from 4 to 5 on Correctness. The returns on improving the weak dimensions are huge.

FAANG SQL rounds don't reward better SQL writers. They reward better analysts. The rubric makes that explicit. Prep to the rubric, not to the SQL.