[Hiring] Senior Backend Engineer @RiverHealth

Role Description

• The core API.
• A Go service on Postgres. You co-own it with the engineering lead and are the reviewer of record for billing, eligibility, partner integration and member data changes.
• Plans, enrollment and billing.
  • Plan configuration, employer contributions, plan years, Stripe subscriptions, and the path from an employer's eligibility file to an active member. Getting dates and dollars right.
• Partner integrations.
  • Eligibility exports over SFTP, a card program for in-person visits, lifecycle email and SMS, vision benefits, e-prescribing, video visits and HR data. When a partner's records and ours disagree, you find out why.
• Scheduled jobs.
  • Workers that pause, top up, reconcile and sync. You make them idempotent, observable and safe to rerun.
• Production health.
  • Structured logs, traces and alerts. You work the production errors queue down and keep it down. You're part of the on-call rotation.
• Member data protection.
  • Access scoping, audit logging and HIPAA data handling across every endpoint.
• Agent guardrails for billing, eligibility and member data.
  • The skills, guidance, evals and guardrails that let agents, and the people using them, work safely in these areas. You and the engineering lead decide what an agent does on its own and where a person signs off.

How we build

• Small pods.
  • Cross-functional pods own outcomes. You sit in the Clinical Pod, which owns the patient and provider experience, and review backend work for every pod.
• AI-first, end to end.
  • Agents plan, build, review and test. Engineers spend their time on judgment: scoping, review, data correctness and production calls.
• You own QA for what you ship.
  • End to end ownership of projects is typical - plan, build, test and rollout. An automation partner covers regression.
• Product ships code too.
  • Product makes light-weight code changes and design in front-end code.

Qualifications

• Health and Benefits industry and/or System of Record experience.
• US health benefits experience: enrollment, eligibility files, benefits administration, TPA, payer, ICHRA or digital health company. Or the same kind of work in payroll, insurance or fintech, where records have effective dates, eligibility rules and partner files.
• Experience working with coding agents and check what they claim.
• 6+ years building backend systems in production.
• Strong Postgres.
• Shipped code that moves money.
• Partner integrations with messy data.
• You make the engineers around you better.
• Clear writing for non-engineers.

Nice to have

• LLMs in a regulated setting: PHI handling, evals.
• HIPAA programs, BAAs and audit logging.
• OpenTelemetry, Axiom or similar observability tools.
• TypeScript and React.
• Card issuing or other fintech programs.
• 834 EDI or carrier eligibility feeds.

This role isn't for you if

• You want a separate QA team to catch your bugs.
• You want finished specs before you start. Here you help write them.
• You don't use AI coding tools, or you trust them without checking.
• You'd rather not talk with ops and clinical teams.

Compensation and how to apply

• Compensation: $175,000 to $210,000 base, plus equity.
• Benefits:
  • Medical, dental, and vision coverage (through ICHRA up to $600 is our policy, Vision XP, and River Essentials for everyone).
  • Paid time off and company holidays.
  • Training and professional development.
  • Transportation stipend.
  • 401k w/ company match.
• In addition to sharing your resume, please respond (under 350 words) to the below via cover letter:
  • Everyone answers: Tell us about an agent-written backend PR you sent back even though its tests passed. What was wrong, how did you catch it, and did you change anything so the agent wouldn't make the same mistake again?
  • Then pick one:
    • A time production data was wrong: dates, dollar amounts, a record your system and a partner's system disagreed on (such as a customer your system showed as cancelled who was still active with the partner), or a bulk edit or migration that didn't do what you expected. How did you find it, and how did you fix the records that were already affected?
    • A job, import or webhook that ran twice or stopped halfway. What did it do to the data, and what did you change so it was safe to run again?
    • A backlog of production errors or noisy alerts that you worked down. What did you fix first, and why?
    • A backend change you had to explain to people outside engineering, such as an operations or support team. What did they need to know, and how did you make sure it landed?