SDE 2 - Backend Platforms

Why this team exists

We run a growing portfolio of consumer businesses — Seekho at scale, alongside several younger products still finding their shape. The reason to build them under one roof is leverage: a new product should launch with login, payments, and notifications already working, and spend its first year on the thing only they can build.

That’s what this team builds. Identity, payments, and notifications as real platforms — designed once, run centrally, adopted by every product in the group. You’d own one of them end to end.

The direction is set. The design is wide open — how tenancy works, where the boundaries sit, what each product adopts and when. You’d be shaping those, not inheriting them.

What you’ll own

• One platform service, end to end — data model, API contract, rollout, operations
• The multi-tenancy and isolation decisions every consumer inherits
• Public API contracts, and evolving them without breaking the teams that depend on them
• How the service gets consumed — by other services, by developers integrating it, and increasingly by agents
• The self-serve surface for your service — consoles and tooling, built with the frontend and design folks on the team — so a product team can adopt it without you in the room
• SLOs, on-call, and incident response for what you build
• Adoption across every engineering team in the group — platform adoption is earned, not mandated

What makes this role different

• Your customers are engineers, not consumers. No funnel, no retention curve. Success looks like another team shipping faster because your service existed. Expect real time on API ergonomics, documentation, and migration support.
• Scope is yours to defend. The platform owns the mechanism — how a message is delivered, how money is recorded, how access is granted. Products own the intent — who, what, and how much. Requests will arrive that are genuine needs but sit on the product side of that line. Knowing the difference, and redirecting rather than absorbing, is a core part of the work.
• Not an infra or DevOps role. Kubernetes, pipelines, and cloud architecture belong to a separate platform engineer on the team. You build services, not the substrate they run on.
• Interfaces are the product. Once other teams build on an API, evolving it means versioning, migrating consumers, and deprecating deliberately. Some engineers find that the most interesting constraint in the work; others find it a drag. Worth knowing which you are.
• You own it in production, including being on call for a service the whole group depends on.

Requirements

• Strong Python, and the judgment to know when a problem isn’t a Python problem (platform services are greenfield — stack is open; existing systems are Django)
• Data modelling depth — schema design, zero-downtime migrations, knowing when a foreign key is a trap
• API design as a first-class skill — contracts, versioning, backwards compatibility, deprecation
• Distributed systems fundamentals — idempotency, consistency trade-offs, what happens when the webhook arrives twice
• Security instinct — authn/authz design, secret handling, an eye for fail-open defaults
• Operational maturity — SLOs, observability, debugging production under pressure
• You work well with engineers as customers — clear docs, patient migrations, adoption taken personally
• AI is how we work: We use coding agents daily — Claude Code and similar — for implementation, refactors, and the repetitive majority of the work. That’s the baseline, not a perk, and we expect fluency.
  What matters more: AI-generated code fails differently from human code. Plausible, confident, subtly wrong. We expect it reviewed with the same rigour, and we test that directly.

Good to Have:

• Built or operated a payment ledger, an auth system, or messaging infrastructure
• Indian payment rails — UPI mandates, autopay, Play Billing, Apple IAP
• Compliance exposure — DPDP, PCI, DLT/TRAI
• Worked on a platform team where adoption was voluntary