The Role, Decoded

What the company is

The company runs an open-access GPU marketplace and inference service — pooling GPU capacity from many providers and renting it out to AI developers at substantially lower prices than the hyperscalers. The pitch is "democratize AI by breaking down the barriers to computing power."

Company shape:

• Stage: Series A, prepping for growth. Small team.
• Founders: PhDs in AI, Math, and CS.
• Business model: two-sided marketplace — GPU suppliers on one side, AI developers on the other. Plus a managed inference service on top of the same supply.
• Domain: AI infrastructure / cloud compute. Direct competitors include RunPod, Vast.ai, Lambda Labs, Together.ai on different axes.

Two-sided marketplaces and inference services are data-heavy by nature: pricing, utilization, supply elasticity, cohort retention, GPU-hour economics, latency-per-tier — every business decision routes through metrics that don't yet have a canonical definition at the company.

What this role actually is

The JD says "Senior Data Analytics Engineer." The structural reality is "founding analytics hire":

That means:

• There is no canonical metric set yet. You define it.
• Reporting infrastructure is likely thin — possibly a few one-off dashboards and ad-hoc SQL.
• Stakeholders are leadership, not embedded PMs. You'll present to the co-founders.
• The work spans modeling decisions ("what counts as an active GPU?"), dashboard building, ad-hoc analysis, and basic data pipeline hygiene.
• The growth path is leading the analytics function as the team scales — so this hire is being chosen for trajectory, not just task execution.

Day-to-day decoded

The JD's responsibilities cluster into four buckets:

1. Metric definition. What's our take rate? How do we count active vs idle GPUs? What does cohort retention mean for a usage-based product?
2. Analytical answers. Why did margin compress last week? Which supplier segment is most retentive? Where should we discount to drive supply growth?
3. Dashboards & BI. Build out the self-serve layer so leadership and operators can find numbers without asking.
4. Data quality & debugging. Make sure the numbers are right. The JD calls this out explicitly: "Expert at data debugging and ensuring data correctness with a proactive approach to data health."

Where the screen sits in the loop

You've been told the screen is SQL creation + SQL debugging + Python pandas LeetCode. That structure tells you something about how the company thinks about this role:

• SQL creation ≈ "can you actually answer business questions in SQL?" A real founding-analytics hire will write hundreds of queries a quarter. Speed and correctness matter.
• SQL debugging ≈ "can you keep our data trustworthy?" This is the JD line about data health. Their pain is metrics that disagree across dashboards because someone wrote a subtle bug — they're filtering for someone who'll catch those before they ship.
• Python pandas LeetCode ≈ "can you script analytical work outside of SQL?" When SQL isn't the right tool — text manipulation, complex feature engineering, time-series cleaning, anomaly investigation — pandas fluency is the alternative.

The screen is the gatekeeper round. After it, expect a system-design or analytical-deep-dive round, plus behavioral and a meet-with-leadership round.

The stack, decoded

Hiring signals to read

• "Ability to accept direct feedback and continuously improve." This phrasing — direct feedback specifically called out — is a tell. The founders likely give blunt feedback in code review and discussions. Match that energy in interview answers: be confident, but visibly update when something better is suggested.
• "Proactive in seeking clarification when needed and comfortable navigating ambiguity." They expect you to ask the question, not wait for it to be written down. In live coding, ask clarifying questions before writing code — that's part of the signal, not delay.
• "Working with highly technical teams and understanding technical business models." The founders are PhDs. They'll explain the business in technical terms (GPU utilization curves, inference batch sizing). Don't pretend to know more than you do, but track and ask follow-ups.
• "Clear path to growing into a leadership role." They're hiring for trajectory. In behavioral rounds, name leadership behaviors even at an IC level (mentoring, owning quality bars, leading without authority).

What to ask them

• "What's the analytical question you're most uncertain about today, and why?"
• "How do you currently define an 'active GPU' — and where do different definitions hurt you?"
• "Walk me through a recent decision that an analysis changed, or that one would have helped change."
• "What's the gap between what leadership wants from data and what the team can deliver today?"
• "What's the trajectory you imagine for this role over the first 12 months?"
• "How does the analytics function partner with engineering on instrumentation today?"
• "What's a metric you're tracking that you suspect is wrong?"

The last one is especially good — it acknowledges the JD's data-debugging emphasis and lets them tell you exactly where you'd be useful in week one.

✓ Check yourself

Answer from memory before opening each one.

1. The job description calls this the first analytics hire and asks you to define, build and deliver the critical metrics. What does that tell you about the state of the data on day one, and what should your first deliverable be?

   Show answer

   It tells you there is no agreed metric set, only one-off dashboards and ad-hoc SQL, so the same question can already have two answers. Your first deliverable is a short, written set of definitions for the few numbers leadership uses, agreed with the people who use them, before any new dashboard. See what this role actually is.

2. Why would a screen for this role include a debugging round and not only query writing?

   Show answer

   The job description asks for data correctness, and the likely pain is metrics that disagree across dashboards because someone wrote a subtle bug. A candidate who writes fast but cannot find a fan-out or a hidden inner join ships those bugs. The debugging round tests whether you will catch them before they ship. See where the screen sits in the loop.

3. A founder asks two things. First, how many customers launched a GPU within a week of signup. Second, where users drop out of the console flow before launching. Which tool in the stack would you reach for in each case, and why?

   Show answer

   The first is a warehouse question over signup and session tables, so it belongs in Hex or Metabase on top of SQL. The second is event-level product behaviour, which is what PostHog captures with funnels and session replay. The tools overlap, but each answers its own kind of question with less work. See the stack, decoded.

4. A co-founder explains GPU utilization curves in terms you only half follow. What do you do, and what does the posting suggest about why?

   Show answer

   Track what you follow, say which part you do not, and ask a follow-up that shows where your understanding stops. The posting asks for comfort with highly technical teams and with ambiguity, and the founders will detect bluffing within a follow-up or two. Calibrated questions earn more trust than a confident nod. See hiring signals to read.

5. You can ask only one question about the data in the final round. Which of the listed questions gives you the most, and what does it do that the others do not?

   Show answer

   "What's a metric you're tracking that you suspect is wrong?" It connects to the data-correctness emphasis in the job description and gets them to name the first piece of work you would own. The others describe the situation; this one hands you a week-one target. See what to ask them.

Takeaway

• The role is a founding analytics hire, so no canonical metric set exists and defining it is the job, not a preliminary to it.
• The screen mirrors the work: creating SQL answers business questions, debugging SQL keeps the numbers trustworthy, and pandas covers what SQL does badly.
• Debugging gets its own round because the stated pain is metrics that disagree across dashboards.
• Hex and Metabase answer warehouse questions, while PostHog answers event-level product questions; the stack is a division of labour, not three rivals.
• The founders are technical and blunt, so calibrated honesty about what you do not know scores better than confident vagueness.

Most candidates meet this role with a gap somewhere, and the next chapter covers how to state it and close it. → Positioning From Scratch