Senior Backend Engineer — Data & Identity

Pantheon builds a relationship layer over the places people actually talk. That means continuously taking in records from many independent systems, each with its own idea of who someone is, and resolving them into one coherent view without ever silently merging two different humans or splitting one into two.

That problem does not get easier with scale — it gets sharper. An identifier that looked stable turns out to be reassignable. A record arrives twice with different keys. A well-meaning cleanup job treats history as duplication. Every one of those is a real failure mode we have hit, and each was caught by a person reading a query plan rather than by a test.

Right now this surface is owned by our founder alongside everything else. It is the largest single concentration of risk in the company, and it is the first thing we are hiring against.

• The ingestion path. High-volume writes from many sources into shared tables, idempotent by construction, resumable after failure, and honest about what it dropped.
• Entity resolution. The rules that decide two records describe the same person or organization — and, harder, the ones that decide they do not. Including how a wrong decision gets reversed later without losing the history that proves it was wrong.
• Schema evolution under live traffic. We ship migrations continuously against a database real customers are reading. You will own how that stays safe.
• Backfill safety. Bulk operations on shared data are the highest-blast-radius thing we do. Our standing rule is that they are reversible by design, prove their premise against production before they run, and never execute unattended. You will be the person who enforces that, including on your own work.
• The correctness bar for everyone else. Reviewing the data-touching changes other engineers write, and saying no when a query does something subtle.

We care much more about judgement under ambiguity than about a list of technologies.

• Deep, practical Postgres. Not "I have used an ORM" — you have read plans, chosen index shapes deliberately, reasoned about lock behaviour during a migration, and know why a query returning fewer rows than expected is more dangerous than one that errors.
• You have been burned by a silent failure and it changed how you write code. The bugs that matter on this surface do not raise. They return a truncated result set, or a default, or a success. If your instinct on reading a new data path is "what does this do when it is wrong, and would anyone find out" — that is the instinct.
• Distributed-write discipline. Idempotency, ordering, retries, and at-least-once delivery are things you have designed around rather than read about.
• You can operate without a safety net, and then build one. We do not yet have the test and review infrastructure a team this ambitious should have. You will work without it at first and help decide what it should be.
• Comfortable in a large TypeScript/Node codebase. The language is not the hard part; you should be fluent enough that it never is.

• Experience with identity or entity-resolution problems in any domain — customer data platforms, healthcare record linkage, fraud, logistics, or anywhere "is this the same thing?" was genuinely hard.
• You have run a schema migration on a large table without downtime and can describe what you were afraid of.
• You have deleted data you should not have, or nearly did, and built the guardrail afterward.
• Experience with row-level authorization models in the database rather than only in application code.

We are a very small, remote, engineering-led team, and we ship continuously — a change that is right goes out the same day. There is no ceremony tax: no standups for their own sake, no story points, no committee between you and production.

The counterpart to that is real ownership. You will be the person accountable for this surface, including at the point where something breaks. We are hiring seniors specifically because that trade only works with people who can hold it.

We use AI tooling heavily and expect you to. It is very good at producing code and completely indifferent to whether that code is correct, which is precisely why the judgement we are describing above is the thing we are actually paying for.

Fair warning on ramp: this is a large codebase with a lot of hard-won institutional knowledge, and a fair amount of it still lives in one person's head. Expect four to six weeks before your first meaningful independent merge. We would rather tell you that now than have you discover it in week three.

Competitive salary and meaningful equity. We will give you the band in the first conversation rather than making you ask — if it does not work for you, neither of us should spend four interviews finding that out.

The process is short and deliberately not a trivia exam:

1. A 45-minute conversation with our founder about your background and what you would be walking into.
2. A technical deep-dive on something you have actually built — your work, not a whiteboard puzzle.
3. A paid, scoped exercise against a realistic problem in our domain, sized to a day.
4. A final conversation on how we work, comp, and your questions.

We do not do unpaid take-homes and we do not do surprise algorithm rounds.