Senior Backend Engineer (Python)

Why this role exists

When our state machine is wrong, somebody’s money is wrong. That is the entire job description. Supero’s core is a set of Python services holding other people’s transactional data — orders, payments, inventory, claims, signatures, ledgers — and we need engineers who find that stake motivating rather than terrifying.

What you’ll own

• The transactional services. Cart and order. Payment authorize → capture → refund → void. Two-phase inventory reserve-and-commit. Subscriptions with dunning. A double-entry loyalty ledger. Multi-signer e-signature. Approval chains with delegation. You would extend these and make the invariants hold under concurrency — which is the whole job, because when the state machine is wrong somebody’s money is wrong.
• Saga compensation — the honest version. An invalid transition is rejected before it mutates anything and returns a 409: that part works and it is real. Compensation — walking a half-finished saga back — is the part that is not finished. It is opt-in per workflow, and a contract suite we keep deliberately red reports broken compensation templates where one wrong key name does not degrade a single step, it abandons the walk-back for every earlier step too. Closing that is one of the two most valuable things an engineer could do here this year.
• Idempotency and correctness. Invoked twice, applied once, because the idempotency key really is a unique partial index and not a hope — the insert itself is the gate, and the race surfaces from the database as a 409.
• The multi-tenant data path. MongoDB (Atlas in production) behind a pluggable backend interface, plus a PostgreSQL backend that models every object of every tenant as one partitioned objects table with a single JSONB document column and no per-schema DDL. Tenancy is carried as the record’s address either way. Most teams would have gone schema-per-tenant; we did not, and you will have opinions about that.
• The MCP server. The surface an outside AI agent drives to build on Supero. Every tool you add needs an authorization story, not just a handler — an agent holding a scoped key must not be able to reach past what that key covers. It is the most interesting security problem in the building.

What we look for

• 5+ years of production backend engineering, with real scars from distributed systems: partial failure, retries, ordering, exactly-once fantasies.
• Deep Python — across two eras of it. The newer services (AI, connectors, billing, tenant, analytics) are FastAPI, Pydantic and asyncio. The core API server and control plane are Bottle on gunicorn/gevent — synchronous, greenlet-based, with hand-rolled validation and not a line of async def. You would work in both, and help move the boundary. If that sounds like the interesting part rather than the bad news, good.
• Databases past the ORM. Query plans, isolation levels, indexing strategy, and what a long-running transaction does to everyone else — against MongoDB in production and PostgreSQL/JSONB in the alternate backend and across the connector fleet.
• API contract discipline. You have designed the error responses on purpose. You return 409 rather than 500 and you can say why.
• AI and MCP at depth. This is one of three roles where MCP is a real requirement rather than a curiosity — you would be building the surface that agents drive.

Nice to have

Multi-tenant SaaS at scale. Payments or ledger systems. Having written an MCP server. Having found a security bug in something you owned and written the honest RCA. Event streaming — we have Kafka scaffolding that has never been lit up, and an opinion about whether it should be is welcome.

Your first 90 days

• Weeks 1–2. Ship a fix to a live service. Read the 111-file contract suite until you can say what it does not cover.
• Weeks 3–6. Own one transactional service end to end.
• Weeks 7–12. Take a state machine that is under-tested and close it — with the test that discriminates against the old behaviour, not the one that passes either way.

Build something on Supero and skip our take-home entirely

The most reliable signal we have ever had about a candidate is an application they built. So we made it the front door. Build a small system on Supero — over MCP from your own AI editor — and send us the link: it shows us you understand the platform far better than a résumé line can. Aim for 90 minutes, and note there are two equally valid ways to satisfy this, listed below.

• Bring your own idea, and scope it small. We build tooling that generates full-stack apps — it would be strange to ask you to interview without it. So bring your own idea, use whatever gets you there, and be ready to explain every decision inside it. Model something you actually know: a domain you have worked in, or a system that annoyed you. Three to five entities, two roles, one thing that can go wrong. Aim for 90 minutes; four hours is the hard cap.
• Turn multi-tenancy on when you generate — and notice that you had to. It is a generation-time flag, it defaults to off, and it is expensive to retrofit. We think that default is wrong. It is the same shape of problem we criticise elsewhere — opt-in per thing, someone has to remember, painful to add later — and it is on the list to change. We are telling you because you will hit it, because we would rather you hit it knowingly, and because what you would do about it is a question we would genuinely like your answer to. Meanwhile: switch it on, because we do look at whether your model survives a second tenant.
• Send a screenshot, the link, and your read on us. A screenshot of your application’s landing page is the one thing we always want — a running app can go down, and the screenshot survives. Send the live URL too, and optionally push the source to your own GitHub and send that link. Then a few paragraphs: what you were modelling, one decision you reversed, and two things about Supero itself — what you liked most, and what you would improve. That last one is not a courtesy question. What you notice tells us how you think, and we act on it.
• What you get back. A person reads every submission — not an auto-responder, and not a keyword screen. If it moves forward, an engineer writes back with what they saw in your model. And a completed build replaces our screening call and our take-home entirely: you go straight to a technical conversation with the people you would work with.

Two ways to satisfy this — they are scored the same

• Build it over MCP — the one we prefer. Point Claude Code, Cursor or Copilot at Supero’s MCP server and drive the whole build from your own editor. This is the route we would rather you took: it is how the platform is meant to be used, it is the closest thing to the actual job, and it tells us the most about how you think. App Studio exists and works, but MCP is what we are looking for here.
• Send something you already built. Any stack, any age, any domain — plus one page on the data model and the decision you would now reverse. Scored exactly the same way. Nothing about this route is a lesser option.

Start with MCP →Create an account for your key →

The fine print

• You own what you build. Full intellectual property and copyright stay yours, and our platform terms do not override that. We receive only a limited licence to review your submission as part of your application.
• Do not submit anything that is not yours to submit. No current or former employer’s confidential information, proprietary code or data. No real personal data belonging to anyone, including yourself. Invent your test data. If a contract restricts outside development, tell us and take route 2 or 3 instead.
• Time-box it. Aim for 90 minutes and do not exceed four hours. We mean it: a submission built in 90 minutes is scored exactly like one someone spent a fortnight on, and the small sharp one usually wins. Spending longer does not help you.
• What happens to your data. The account you create stays yours. We delete our copy of your submission, and any repository access you granted, within 90 days of a final decision — or sooner if you ask. Write to [email protected] at any time.
• A human scores every submission. No automated screening decides whether you move forward.
• Where the line is on breaking things. Inside your own project — including across tenants you created yourself — break whatever you like. Probe the tenant boundary, try to read a field your second role should not see, send the state transition that should be rejected. That is the exercise, and telling us what you found is one of the things we score. Outside your own project — other people’s accounts, our infrastructure, our authentication, anything you were not given — please stop. No scanners. If you find something that reaches beyond your own project, do not keep pulling: write to [email protected] and we will thank you properly. Reporting in good faith is never held against you.
• What the account gives you. No credit card. A challenge account carries an allowance sized well above what this exercise needs — if you genuinely run out mid-build, write to us and we will top it up. Your submitted URL stays live for at least 30 days.
• No obligation either way. Doing this is not a condition of being considered, and we are not obliged to hire or pay for any submission.

How this goes

Every step, stated up front, so you can decide whether to start it. No fixed timeline — we go as fast or as slow as it takes to be sure, in both directions.

• STEP 1 — You apply. A person reads it. No keyword screen. If you did the build challenge, that is what we read first.
• STEP 2 — 30-minute conversation. With the person who would be your manager, about what you have built. Skipped entirely if you submitted a build.
• STEP 3 — 90-minute technical session. A real problem from our backlog, or a walkthrough of your build. No algorithm puzzles and no whiteboard trivia.
• STEP 4 — Two 45-minute conversations. With people you would work with. One is a design-review simulation, which is the closest thing to the actual job.
• STEP 5 — Founder conversation, then offer. We tell you where you stand after every stage, including when the answer is no.

Find us

• GitHub. github.com/supero-platform/supero-apps — Example applications built on Supero.
• LinkedIn. www.linkedin.com/company/supero-dev/ — Company updates and the people here.
• Docs. docs.supero.dev — The platform, in full technical detail.

Equal opportunity

Supero is an equal opportunity employer. We consider all applicants based on their qualifications, skills, and experience, without regard to race, color, religion, caste, sex, pregnancy, sexual orientation, gender identity or expression, national origin, citizenship or immigration status, age, disability, medical condition, marital or family status, veteran status, or any other characteristic protected by applicable law.

We maintain an Equal Opportunity Policy and designate a Liaison Officer in accordance with the Rights of Persons with Disabilities Act, 2016. We also maintain an Internal Committee in accordance with the Sexual Harassment of Women at Workplace (Prevention, Prohibition and Redressal) Act, 2013.