Your 2-minute elevator pitch.

"I'm currently a senior data engineer at Instacart, where I own the experiment platform's data layer — the pipeline that computes metric deltas for every A/B test across about 12 million active users. Before that I was at a Series B startup where I built our entire lakehouse from scratch on top of Delta Lake and dbt.

The thread through my career is making analytics trustworthy at scale. I got obsessed with that problem after watching a bad data pipeline kill a product decision — the wrong variant looked better because of a 6-hour backfill lag, and the team shipped it. Since then I've specialized in freshness SLOs and data contracts — how you enforce promises between teams without a central gatekeeper.

What draws me to Google is the Monarch project and the work on distributed metric computation at the scale you operate. The problems I've been solving at Instacart are a smaller version of what Monarch handles for internal SREs, and I want to work on that problem at a harder scale.

That's the quick version. Happy to go deeper on the experiment platform work — or I'd love to hear what the team here is focused on in 2026."

"I'm a staff data engineer at Lyft. My current scope is the streaming data platform — Kafka, Flink, our internal table service — used by 300+ engineers across the company for everything from real-time pricing to compliance reporting. I own the reliability SLOs and the platform roadmap.

I've spent the last four years going deep on one question: how do you make a streaming platform feel as reliable as a database to the teams consuming it? My answer involved building a lightweight contract layer on top of our Protobuf schemas that enforces backward compatibility at publish time, and a freshness alerting system that surfaces lag before consumers notice.

Meta's scale of cross-functional data dependencies is what pulls me here. The problems I'm solving at Lyft are structurally similar to what I understand Meta faced building Scuba and the internal data platform — but the stakes here are an order of magnitude higher, and I'm at the point in my career where I want to work on that harder version of the problem.

Happy to dig into any of that — and I'm curious what the team's current priority is on the streaming side."

"I'm a senior data engineer at Capital One, on the team that runs our real-time fraud detection data pipeline. We're ingesting about 2 billion events a day and my work is on the feature engineering layer — the piece that enriches transactions in under 50ms so the ML model can score them before authorization completes.

My career's been in financial data infrastructure — I started in BI at a regional bank, moved to a fintech startup as their first data hire, and joined Capital One three years ago to work on harder latency problems. The common thread is high-stakes pipelines where data quality isn't negotiable because the output feeds a decision that has a dollar value attached.

What brings me to Amazon, specifically AWS Analytics, is that I've been a heavy user of Kinesis and Redshift for four years and I have opinions — some of them critical. I want to be on the team that's making decisions about those products, not just working around their limitations. The real-time analytics roadmap on the EMR and Redshift Streaming side is exactly where I want to contribute.

That's the overview — I'd love to talk about the fraud pipeline if that's useful, or hear more about what the team is building."

"I'm a data engineer at Shopify. I'm on the platform team — we build the tooling that 80 internal data teams use to author, test, and deploy dbt pipelines on top of our Lakehouse. My specific focus is table maintenance: how we keep Iceberg tables compacted and vacuumed without affecting query performance.

I've been in platform-side data engineering for five years. My career bet has been that the infrastructure layer matters as much as the analytics layer, and that most companies treat it as an afterthought until it falls over. I've spent time in consulting, at a mid-size SaaS company, and now at Shopify — each time going deeper on the infrastructure plumbing.

Databricks is a direct fit because I've been living in Delta Lake and the Unity Catalog for two years, and the decisions your team makes about how table maintenance works affects my job every single day. I want to be on the team making those decisions. The Liquid Clustering work is particularly interesting to me — I've been reading the blog posts and I have questions.

Happy to go into the Iceberg compaction work in detail — or wherever is most useful."

"I'm a data engineer at Braintree — a PayPal company — where I own the reconciliation data pipeline. Every night we reconcile about $800 million in settled transactions against bank records, identify discrepancies, and feed them to the finance and risk teams. The job is: no discrepancy goes undetected, ever.

Payments infrastructure data is all I've done for six years, first at a startup building payment rails, then at Braintree. The technical specialty I've developed is exactly-once semantics in data pipelines — how you guarantee that a transaction record is counted exactly once even when upstream systems retry. It sounds simple and it is brutal in practice.

Stripe is where that problem is most interesting. Your scale and the diversity of payment methods — global acquiring, embedded finance, the Link wallet — mean the reconciliation problem is orders of magnitude harder than what I'm working on now. That's why I'm here.

I can talk about the exactly-once work in detail if that's relevant."

"I'm an analytics engineer at Booking.com. I own the supply-side semantic layer — the dbt models that define inventory, availability, and pricing metrics across the platform. About 50 analysts and data scientists rely on those models as their source of truth.

I've been in analytics engineering for four years, starting in consulting where I helped companies get their first dimensional model right, then at a proptech startup, and now at Booking. The skill I've built is translating ambiguous business questions into metric definitions that don't break when the business changes — that last part is harder than it sounds.

Airbnb is interesting to me because of Minerva. I've read the engineering blog posts and the Airbnb data papers going back to 2021, and the consistency-first approach to metrics governance is the right answer to a problem I've been dealing with in a less elegant way. I want to contribute to that platform and also to work in the marketplace domain — the supply-demand dynamics at Airbnb are more complex than anything in my current stack.

Happy to go into the semantic layer work or the marketplace modeling challenges if either is relevant."

"I'm a senior data engineer at Cohere, on the team that runs our training data pipelines. I own the deduplication and quality-filtering stage — the part that takes raw web crawls and produces the cleaned dataset that goes into model pre-training. We're processing about 15 trillion tokens a cycle.

My background is in large-scale data processing — I started in ETL at an analytics company, moved to ML data pipelines at a computer vision startup, and joined Cohere because I wanted to work on the data side of foundation model training. It's a different problem than analytics data — the scale is different, the quality signals are different, and the downstream consumer (a training run) has very different failure modes.

What I know about your team is the backgrounds of the founders — the distributed systems and ML infrastructure work is exactly the intersection I'm in. Even without knowing exactly what you're building, I'm confident the data infrastructure problems at a company with that technical DNA are going to be interesting. I'm at a stage where I want to be early enough to have real influence on how things are built.

I'd love to learn more about what you're working on — and I can talk in detail about the training data pipeline work."

"I'm a data engineer at Plaid, where I work on the data infrastructure for our bank connection reliability metrics. We track uptime and latency for 12,000+ financial institution connections, and my job is making sure that data is accurate enough that product and engineering can trust it when making SLA commitments to partners.

My career has been in fintech data — I've been in this space for seven years across three companies, each one dealing with financial data at different layers of the stack. What I've come to specialize in is data reliability in regulated environments: how you build pipelines that can survive an audit, not just a production incident.

With your team, the founding background tells me you're probably working on something in the financial data infrastructure space — Stripe and Plaid alumni tend to see the same gaps. Whatever the product is, the data problems in that space are the ones I've spent my career on. And honestly, the stage matters to me — I want to be architect number one or two, not inheriting a system built before I arrived.

I'd love to hear what you're building — and talk about how my background fits."