Observability, Quality, Cost & Security

The job description names it directly: build observability, alerting, SLAs/SLOs and operational standards across the platform. In the loop that line becomes a probe - when a column goes null at 3am, do you find out from a dashboard or from an analyst's angry Slack?

Cursor ingests billions of product-telemetry events a day and a slice of that feeds agent and model work. Bad data there is not a cosmetic bug. A silently broken bronze table can poison a gold metric a VP reads or skew a feature an agent learns from. So the interviewer wants a mental model of what can go wrong, not a list of vendor names.

The dimensions you actually monitorfive, not three

Observability for data is usually framed as a small set of dimensions. Name them, then say which ones you'd wire up first for a brand-new platform.

Two ways to catch bad datainline gates vs. out-of-band watchers

Strong answers use both and say why. Inline tests encode the failures you can predict. Anomaly detection covers the ones you can't - but it earns trust slowly, so you start it in observe-only mode before letting it page anyone.

Lineage is impact analysisthe difference between a 5-minute and 5-hour incident

When a bronze table breaks, the first question is who consumes it. Without lineage you find out by getting paged by each downstream owner in turn. With lineage you query the graph, see the eleven silver assets and the one revenue dashboard hanging off it and decide blast radiusHow much breaks if a change goes wrong; the scope of potential damage. in one look.

An agent can walk that graph for you. A finance team hit discrepancies in a revenue-recognition booking table that sits downstream of five or six upstream tables plus the jobs running between them. They pointed Cursor at the bad number and it traced the reconciliation issue back up the chain - which tables feed which, which jobs produce which outputs, whether snapshots existed and which PRs changed how each table gets built - walking the whole history to the furthest upstream source.

Circuit-breakers: block, don't just alertstop bad data at the silver gate

An alert that fires after corrupt data reached the gold serving layer is a postmortem, not a save. The higher-impact pattern is a circuit-breaker: the quality check sits on the boundary into silver/gold and when it fails, the bad partition does not promote.

1. 1Land raw in bronze unconditionally. Never block ingestion; you want the evidence even when it's malformed.
2. 2Gate the bronze→silver promotion. Run asset checks before the write commits. On failure, halt that partition and hold the last-good version.
3. 3Quarantine, don't drop. Route failing rows to a dead-letter/quarantine table so they're inspectable, not lost.
4. 4Page with context. The alert says which check, which partition and what's downstream - so the on-call can act, not investigate from zero.

A data platform is a product with internal customers and customers want commitments. The behavioral theme in the JD is explicit: treat the platform as a product. SLAs are how you write that down.

The mistake juniors make is one blanket promise for everything. The mistake of someone who's run a real platform is a tiered promise - because agent-training data and revenue numbers do not deserve the same reliability budget as an analyst's exploratory scratch table.

SLA, SLO, SLI - keep them straightthe vocabulary interviewers check

Tier datasets by what they feednot everything is tier-1

Alert on symptoms, not just causeswhat the consumer actually feels

"Job failed" is a cause. "The gold table consumers read is now stale past its SLA" is a symptom. You want both, but the symptom alert is the one that maps to a broken promise - and it fires even when the job succeeded but produced nothing.

On-call without burning the teamdata on-call is different from service on-call

Data incidents are often slower-burning than a downed API. A late table at 2am rarely needs a human at 2am if the consuming dashboard is read at 8am. Encode that: severity tiers decide who gets paged and when.

1. 1Severity-tier every alert. Sev-1 pages immediately (revenue/agent data broken). Sev-3 opens a ticket for business hours.
2. 2Route by ownership. The alert goes to the team that owns the asset, not a shared firehose nobody reads.
3. 3Dedupe and group. One upstream break should fire one incident, not forty downstream alerts that bury the root cause.
4. 4Write the runbook before the incident. Each tier-1 asset has a runbook: how to detect, how to backfill, who to escalate to.
5. 5Degrade gracefully. Serve last-good data with a staleness banner rather than a hard failure where you can.

The JD's recurring trio is scale, reliability, and cost. At billions of events a day, a sloppy storage layout or an always-on cluster isn't a rounding error - it's a line item someone in finance will ask you about.

Cost optimization splits cleanly into two bills: what you pay to store the data and what you pay to compute over it. Treat them separately, because the levers are different and a good answer touches both.

Storage: the small-file problem and friendsobject-store cost and read amplification

Compute: stop paying for idlethe biggest dumb-money leak

• Right-size clusters. Match worker type and count to the job's shuffle and memory profile, not a copy-pasted default that's 4x too big.
• Autoscale and auto-terminate. Scale workers to the workload and kill idle clusters - an interactive cluster left running overnight is pure waste.
• Spot for the interruptible. Backfills and stateless batch ride spot/preemptible instances; keep on-demand for the latency-critical tier-1 path.
• Tune the job. Fix skew, prefer broadcast joins for small dimensions, cache reused datasets and turn on Photon where the workload suits it.

Attribution: make teams see their own spendyou can't optimize what no one owns

A single platform bill nobody can decompose is a bill nobody will reduce. Tag every cluster and job by team and pipeline, lean on Unity Catalog system tables for usage and surface a per-team breakdown. Showback (here's your spend) usually comes before chargeback (it hits your budget) - you earn the right to charge back by running clean, trusted showback first.

Tiering and the replay windowthe question that decides retention

Cursor's data is unusually sensitive: it can include developers' code and how they use an AI coding tool and some of it feeds model and agent work. The JD asks you to expand agent-data capabilities while upholding security and privacy. That tension is the whole section.

Governance is not a compliance afterthought you bolt on at the end. At this scale it's an architecture decision you make on day one, because retrofitting access controls onto a sprawling lakehouse is a nightmare you want to avoid.

Unity Catalog as the control planeone place for access, lineage, audit

Producers, consumers and the data contractwho owns correctness when data crosses teams

Ownership gets murky once data crosses team lines - analytics, accounting and engineering all touch the same numbers. A clean mental model is producers vs. consumers. When finance runs its close on platform data, finance is the consumer; the partner teams emitting the upstream tables are the producers. The thing that makes the relationship work is an explicit data contract negotiated with those producers, covering three dimensions.

PII: classify, then controlyou can't protect what you haven't found

1. 1Classify first. Tag columns by sensitivity (PIIPersonally Identifiable Information. Data that can identify a person (names, emails, SSNs); regulated and sensitive., code content, internal-only). You can't apply a policy to data you haven't labeled.
2. 2Mask or tokenize at rest. Replace raw PIIPersonally Identifiable Information. Data that can identify a person (names, emails, SSNs); regulated and sensitive. with masked or tokenized values so most consumers never touch the original.
3. 3Column- and row-level security. Grant the marketing analyst the aggregate, not the email; scope rows by tenant where it applies.
4. 4Least privilege by default. Access is requested and granted, not the ambient default - and it's reviewed, not granted forever.

Separate environments to bound blast radiustraining vs. analytics vs. raw

Retention, deletion and the right to be forgottendeletion across a lakehouse is genuinely hard

A deletion request is easy to honor in a single transactional database and hard across a lakehouse where one user's events are scattered through partitioned Parquet, copied into silver, aggregated into gold and maybe cached. You need a plan: a way to find every copy via lineage, Delta's delete/vacuum to physically remove rows and retention policies that age data out so you're not hoarding what you don't need.

The JD hands you real authority: evaluate and deploy BI platforms, catalogs, ingestion connectors and reverse-ETL. So expect a build-vs-buy question and expect the interviewer to care about your reasoning far more than which vendor you name.

As one of the first data platform engineers, your time is the scarcest resource on the team. Build-vs-buy is really a question about where your hand-rolled engineering creates durable advantage and where it's just reinventing a solved commodity.

The decision frameworkfive lenses, not vendor hype

The usual answer per layerwhere the industry tends to land

The thread through all of it: buy the commodity, build the differentiator. Your moat is the first-party ingestion at extreme scale and a reliable, governed lakehouse - not a homegrown dashboard tool.

Reverse-ETL, brieflythe gold layer flows back out

Most pipelines pull data in to model it. Reverse-ETL pushes the modeled result back out - a churn score computed in gold lands in the CRM so a rep sees it or a usage tier syncs to billing. It closes the loop so the data platform drives operational tools, not just dashboards.