Section A · Orient · Read first

Start Here

Drill-focused interview prep for a Senior Data Analytics Engineer screen — SQL creation, SQL debugging, and Python pandas LeetCode-style problems.

The role, in plain English

The hiring company is a Series-A AI infrastructure company running an open-access GPU marketplace and inference service. The role is "Senior Data Analytics Engineer" on the Strategy team — but read carefully, it's a founding analytics hire:

First data analytics hire at the company.
Reports into Strategy, works with leadership directly.
Owns the data foundation for the GPU marketplace business — pricing models, supply/demand metrics, customer cohorts, GPU utilization.
Bridges "highly technical AI infrastructure" and business decisions.
Stated path: grow into a leadership role as the team expands.

The JD itself emphasizes SQL fluency, Python scripting, data debugging, dashboard development (Hex / Metabase / PostHog), and stakeholder communication. The screen you're prepping for is the technical filter — SQL creation, SQL debugging, and Python pandas LeetCode — which gatekeeps the rest of the loop.

What the screen tests

You've been told the screen has three parts. Each one is testing something specific.

SQL creation

Given a schema and a business question, write the SQL. Tests:

Window functions fluency (ranking, lag/lead, running aggregates, partitioned aggregates).
Cohort / funnel / retention patterns — the analytical staples.
Handling NULLs and dedupe deliberately, not by accident.
Picking the right granularity for the question.
Composition: chaining CTEs cleanly rather than nested subqueries.

SQL debugging

Given a query that's wrong, broken, or slow, find and fix it. Tests:

Reading SQL critically — does the join cardinality make sense?
Spotting the classics: NULL semantics, hidden filters in WHERE on a LEFT JOIN, window-frame defaults, off-by-one in date math.
Performance intuition — full scans, skewed joins, missing indexes, the difference between OLTP and OLAP query plans.
Empathy with the data — what does a sane row count look like for this question, and does the result match?

Python pandas LeetCode

The interviewer told you this is "relevant to the role." That means:

Data manipulation problems that map cleanly to pandas (groupby, merge, time-series).
Multiple-approach discussion: vectorized vs apply vs "actually I'd push to SQL at scale."
Code quality — types, small functions, sensible variable names — not just the right answer.
Honest scale awareness — "this would not work on 100M rows; here's what would."

This guide covers all three.

The folder, in reading order

Section A — Orient (read first)

File	Why
01-the-role	Decode the JD — founding-analytics framing, GPU marketplace context
02-positioning-from-scratch	Honest framing when you don't have GPU/AI-infra domain experience

Section B — SQL

File	Why
03-sql-creation-patterns	The window / cohort / funnel / session patterns you compose to answer prompts
04-sql-debugging	The eight categories of broken SQL, with worked fixes
05-sql-problems	Ten drillable problems with multiple approaches

Section C — Python & pandas

File	Why
06-pandas-fundamentals	Groupby, merge, vectorization, the SQL↔pandas translation table
07-pandas-problems	Ten drillable LeetCode-style problems solved in pandas

Section D — Domain & execution

File	Why
08-gpu-compute-domain	GPU marketplaces, inference economics — the domain edge
09-interview-questions	~25 drillable Q&A
10-day-of	Live-coding moves, recovery patterns, closing statement

Study schedule

4+ days

Day 1: 01, 02 → 03 SQL creation patterns
Day 2: 04 SQL debugging, drill 5 SQL problems
Day 3: 06 pandas fundamentals, drill 5 pandas problems
Day 4: 08 GPU domain, drill 09, reread 10

24–48 hours

01, 03 (skim), 04 (full), drill 5–6 SQL problems, 06 fundamentals, drill 4–5 pandas problems, drill 09, reread 10.

< 12 hours

03 window-functions section only, 04 in full, drill 3 hardest SQL problems, 06 SQL↔pandas translation table only, drill 3 pandas problems, drill 09 background section, reread 10.

The single most important reframe

Read this twice

The screen isn't testing whether you can write the query or the pandas. They assume that. It's testing whether you narrate your tradeoffs as you write — which approach you considered, which you discarded, what would change at 100M rows, what would break if a NULL showed up. Silent correct code reads junior. Out-loud correct code reads senior.

What this means tactically:

State your approach in one sentence before you start typing.
While typing, mention the alternative you didn't pick and why.
When you finish, trace one or two example rows through your query out loud. Catches bugs, signals discipline.
Anticipate the "what would change at scale?" follow-up before they ask.

What winning looks like

You reach for a window function before a self-join when both work, and you can explain why.
You handle NULL semantics deliberately — NOT IN with subquery NULLs, LEFT JOIN filters in WHERE vs ON, COUNT(*) vs COUNT(col).
When given a broken query, you diagnose by reading the join cardinality and the row counts at each CTE, not by guessing.
When given a pandas problem, you write the vectorized version first, and only reach for apply with a comment about why it's the right call.
You commit to a recommendation and caveat it, instead of listing five options.
You can talk about a GPU marketplace's metrics — utilization, supply/demand, take rate, retention by cohort — like you understand the business, not just the SQL.

Hit those six on demand and you're in.