The short version
A well-funded fintech in San Francisco is hiring engineers. We're running the search and we're not naming them in the ad. You'll get the company, the founders, the backers and the full picture on a first call.
What we can tell you is what the work is, because that's the part that should decide it.
The work
You'd own money movement. Ledgered internal state, transaction lifecycle management, idempotency, retries, deterministic replay. Continuous reconciliation across independent ledgers, card network events, banking events and third party reports, and the tooling to chase a mismatch to its root before it compounds.
You'd build the guardrails that stop bad states happening rather than catch them late: double spend, duplicate webhook processing, inconsistent balances, orphaned settlements.
You'd own the integrations with card issuing, banking and disbursement, and credit partners, and the compliance and reporting infrastructure that the banking partner and the regulators depend on.
The system serves hundreds of accounts today. The job is taking it to hundreds of thousands, through spiky demand, without dropping or duplicating a single event. Correctness here isn't a quality bar. It's the product.
Why the title is Member of Technical Staff
Because they'd rather hire the person than fill the box.
Small engineering team, very large payments surface area. The engineers who do well there pick up whichever part of the stack matters most that quarter and own it end to end. Ledger one month, an issuing integration the next, fraud decisioning after that.
The title gets shaped around what you're strongest at once they've met you.
Who it's for
You've built systems that were critical. Payments, card issuing, banking rails, ledgered systems, high throughput backends. You've been close enough to money movement to have real opinions about how it goes wrong.
You've owned a system end to end, rather than a component inside a large organisation. You've been the person who gets paged, decides the architecture, and lives with the consequences of both.
You assume banks, queues, vendors and networks are unreliable, and you build things that stay predictable anyway. Reliable to you means the same behaviour at 10 payments or at 10,000,000.
You're obsessive about correctness and auditability. Retries don't erase history. Idempotency is deliberate. Validation belongs where truth lives.
If you want a defined lane inside a large payments organisation, this isn't it.
Practicalities
San Francisco, in person. Visa support available. Highly competitive SF-level compensation and top tier equity offered.
Fifteen minutes is enough for us to tell you who they are and for you to decide whether it's interesting.
Requirements
What we actually require
- You've built systems where being wrong had consequences. Money, records, claims, transactions, anything where a bug meant someone had to be told and something had to be corrected. Payments is the obvious version of this. It isn't the only one.
- You've owned something properly, end to end. You designed it, shipped it, kept it alive, made the architecture calls and lived with them afterwards. That can be a whole system at a small company or a serious subsystem inside a large one. What matters is that it was yours, not that it was big.
- You want to be in San Francisco, in person, and you want this kind of responsibility. Both of those are real and neither is flexible.
That's the list. If those three are true, apply. We'd rather read your application and decide than have you decide for us.
What helps, but isn't required
Any of these will get our attention. None of them are gates.
- Payments, card issuing, banking rails, ledgers, billing, settlement, trading infrastructure, lending, claims processing, tax or regulatory systems, government benefits, or marketplace payouts. Anything where money or entitlements moved and the numbers had to agree at the end of the day.
- Reconciliation work. If you've chased a discrepancy to its root cause and enjoyed it, say so. It's the single strongest signal we know of.
- Having built somewhere with a bank, an auditor or a regulator checking your work.
- High throughput distributed systems where consistency mattered more than throughput bragging rights.
- Shipping things to production for yourself, because you wanted them to exist.
- A personal story with education that isn't the standard one. Plenty of this team has one. You don't need one.
What genuinely doesn't matter
- Years of experience. We'll judge scope, not time served. We've hired people three years in who had owned more than people at fifteen. Tell us what you owned and we'll work it out.
- Your job title. Backend, infrastructure, platform, full stack, SRE, generalist. We don't care what it said.
- Your language or stack. We have opinions and we'll enjoy arguing about them with you. We're not filtering on them.
- An AI or ML background. We run models against live money and we'd like you to care whether they're right. We're not asking you to train them.
- Experience in a specific industry. The domain is learnable.
- Where you went to school.
This probably isn't the right role if
You want to work remotely. We're in the office together in San Francisco and that isn't flexible.
You want a defined roadmap to execute against. We often don't know what the right thing to build is until someone goes and finds out.
You'd rather go deep on one service for the next three years. That's a good way to work. It just isn't how this team is built.
Benefits
- Work within a top tier technical team and alongside experienced GTM professionals to scale a fintech unicorn
- Highly competitive SF-level compensation
- Top tier equity
- San Francisco office in FiDi (financial district)
- Visa support available