# How to Interview at Thatch, the ICHRA Health Benefits Unicorn

Source: https://www.techinterview.org/post/3233477521/thatch-interview-guide/
Updated: 2026-09-27 · techinterview.org

Thatch publishes its interview stages right in its engineering job postings: a recruiter conversation, a collaborative pair-programming session, a systems-design interview, a "how we work together" conversation with an engineer, and a final round with engineering and company leadership, usually inside three weeks. What each round actually asks isn't publicly reported, so the specifics below are inferred from Thatch's reqs and the loops at fintech and health-fintech peers like Stripe, Ramp, Mercury, Brex, and Plaid. Posted engineering bands span roughly $161,000 to $250,000 across roles (Backend and Full Stack at $161K-$230K, Infrastructure at $180K-$250K), labeled "Estimated Compensation Range."

First, disambiguation, because "Thatch" is an overloaded name. This is thatch.com, the San Francisco health-benefits company that reached a $1B valuation in a $108M round on September 15, 2026 (per TechCrunch). It is not the travel-planning app also called Thatch, and it has nothing to do with roofing. The company that concerns you here builds software for ICHRAs: Individual Coverage Health Reimbursement Arrangements, where an employer gives each employee a fixed tax-advantaged budget to buy their own individual health plan instead of one company-wide policy. Some coverage calls these CHOICE Arrangements, after proposed federal legislation, but it's the ICHRA rule that has existed since 2020.

That business model tells you almost everything about the engineering interview. Money has to move correctly between employers, payroll systems, banks, and insurance carriers, every month, without rounding errors or double-payments, in a regulated domain. Thatch was co-founded in 2021 by CEO Chris Ellis, from MIT research and biotech, and Adam Stevenson, who spent seven years at Stripe leading customer engineering teams. That's a solutions-and-integrations function, not core payments infrastructure, so don't over-read the pedigree; the problem itself points the same way.

## What Thatch actually builds, and why it changes the questions

The backend job req is explicit about the shape of the work. You would "design, build, and evolve backend systems that support enrollments, payments, payroll, and benefits management," architect data models and fund flows that "handle large volumes of financial transactions," and build integrations with "payroll providers, banks, insurance carriers, and other external partners." The recurring theme in the reqs: money must move correctly and benefits must stay compliant.

The stack, again from the req: Ruby on Rails on the backend, React and TailwindCSS on the frontend, small amounts of Python and JavaScript where it fits. Prior Ruby is explicitly not required, and they say they value engineers who "can learn quickly and think clearly about systems." Practically, that means the coding portion is almost certainly language-agnostic. You will not be asked Rails trivia. You will be asked to model a problem cleanly and handle the cases where money or eligibility goes sideways. The [standard coding-interview patterns](/algorithm-patterns-cheat-sheet/) still matter for the fundamentals, but the questions that separate candidates here look more like real ledger and reconciliation work.

The three engineering tracks Thatch posts share this domain but weight it differently. Backend is the center of gravity for the money-movement work above, and it's where the correctness questions would bite hardest. The Full Stack role adds the React and Tailwind surface, so expect its pair-programming session to lean toward the benefits-enrollment UI: forms with real validation, complex client state, and rendering the plan-selection flows members actually use. The Infrastructure role, the highest-banded at $180,000 to $250,000, skews toward reliability and platform design, so its systems-design round would push harder on deployment, observability, and pipeline durability than on product features.

## The interview loop, from Thatch's own postings

Thatch is unusually open about its process: the stages below come straight from its engineering job postings, not from leaked candidate reports. What each stage actually asks is not published, so those specifics are inferred from the role's domain and from the well-documented correctness-first loops at [Stripe](/companies/stripe/) and at fintech and health-fintech peers [Ramp](/companies/ramp/), [Mercury](/companies/mercury/), [Brex](/companies/brex/), and [Plaid](/companies/plaid/). Treat the stage list as reported and the question predictions as educated guesses.

| Stage (from Thatch's published interview process) | What each round likely covers (inferred) | How to prepare | Source |
| --- | --- | --- | --- |
| Recruiter conversation | Motivation, level fit, comp expectations, why health/fintech | Have a clear reason for caring about the benefits problem; know your number | Stage: Thatch job posting; content inferred |
| Collaborative pair-programming session | A problem solved alongside the interviewer, likely money-movement logic: a ledger, an idempotent transfer, an enrollment state machine | Practice thinking out loud; model transactions and edge cases over array puzzles | Stage: Thatch job posting; content inferred from backend JD and peer loops |
| Systems-design interview | A benefits or payments pipeline with external integrations, retries, and reconciliation | Reason about partial failures, replay safety, and data models | Stage: Thatch job posting; content inferred |
| "How we work together" conversation with an engineer | Ownership, bias to action, cross-functional tradeoffs, comfort with ambiguity | Bring stories with real scope and decisions, using STAR structure | Stage: Thatch job posting; content inferred from "how we work" section |
| Final conversation with engineering and company leadership | Mission fit, judgment, closing signal | Be ready to say why Thatch specifically and how you make decisions | Stage: Thatch job posting; content inferred |

## The pair-programming session: think like a payments engineer

Thatch calls this a "collaborative pair programming session," and collaborative matters: the interviewer is a participant, not a silent proctor, so narrate your reasoning as you go. The problems would look less like the tree-and-graph gauntlet and more like correctness problems in business terms. A representative one: given a stream of payroll deductions and a set of carrier invoices, reconcile them and flag mismatches. Or implement a transfer that's safe to retry, so a network timeout doesn't charge an employer twice. Idempotency keys, deterministic ordering, and clean handling of the "we already processed this" case would likely be the point. If you're up for the Full Stack role, expect this same session to center on the enrollment UI instead: a plan-selection form with real validation, the client state behind a multi-step signup, and rendering that stays correct as an employee's allowance or eligibility changes mid-year. That track's systems-design round can lean frontend or backend, so ask the recruiter which to prep.

Data modeling comes up constantly, because ICHRA state is complicated: an allowance, a chosen plan, a premium, a payroll cadence, and eligible expenses, all changing over time. Expect to sketch tables and talk through them. If your SQL is rusty, sharpen it with a pass through common [SQL interview questions](/post/3233474463/sql-interview-questions-2025-window-functions-cte-joins-subqueries-indexing-query-optimization-transactions-normalization/).

### What good answers look like

Say the invariant out loud before you code. "No transfer is applied twice; every deduction maps to exactly one invoice line or an explicit exception." Then write to that invariant. Interviewers from a payments background reward candidates who name the failure mode first, rather than writing the happy path and bolting on error handling when prompted. Talk about what happens when the payroll provider's API is down mid-batch. That one question tends to separate people who have run production money systems from people who haven't.

## The systems-design interview

The most likely prompt is one Thatch would plausibly operate: design the pipeline that takes an employer's monthly payroll run, computes each employee's deduction and allowance, and pays the right premium to the right carrier by the due date. The interesting parts live in the failure and reconciliation paths, so drive the conversation there.

Reach for an outbox or ledger as the source of truth, and be ready to say why. A direct write to the carrier API from your request handler couples a state change to a network call: if the call fails after your database commits, or the database fails after the call succeeds, you land in an inconsistent state with no clean recovery. Writing the intended payment into a durable ledger in the same transaction as the state change, then letting a separate worker read and dispatch it, makes the state change and the event atomic together and safe to replay. A redelivered message hits an idempotency key and does nothing the second time. The catch worth naming out loud: many carrier and bank rails (EDI 834/820, ACH) expose no idempotency of their own, so the reconciliation job below, not the key, is the real safety net at the boundary.

Then describe the daily reconciliation job, and be concrete about what it compares. It reads three sources, your internal ledger of what you intended to pay, the carrier's statement of what they say they received, and the bank settlement of what actually moved, and it flags any row where those three disagree. On drift it shouldn't silently retry; it should quarantine the discrepancy for a human, because in a regulated money system a wrong automated correction is worse than a flagged exception. The [system design interview guides](/system-design-interview-guides/) hub goes deeper on durable queues and idempotent writes. What they'd be listening for: whether you treat correctness and auditability as first-class or an afterthought.

## The "how we work" and leadership conversations

Thatch's postings lean on ownership, moving quickly, shipping early, and working through ambiguity, and the engineer conversation and final leadership round would probe exactly that. Come with concrete stories where you owned something end to end, made a call without full information, and can explain the tradeoff you accepted. Vague "we" stories fall flat; they want to know what you personally decided. A quick pass through [the STAR method](/post/3233460379/behavioral-interview-questions-2026-star-method-amazon-leadership-principles-and-winning-answers/) keeps answers tight, and stories that show judgment in regulated or high-stakes systems are the closest signal to Thatch's daily work.

## Compensation, from the live job board

Thatch posts salary bands on its Greenhouse board, as California, Colorado, New York, and Washington pay-transparency law requires for these reqs. Under the label "Estimated Compensation Range," the Backend and Full Stack Software Engineer roles both list $161,000 to $230,000, and the Infrastructure Software Engineer role lists $180,000 to $250,000. All three are posted as Remote (US) or San Francisco. These are posted ranges, not offers, and the spread is wide because Thatch hires the same role across multiple levels. Source: Thatch's Greenhouse-hosted job board (boards.greenhouse.io/thatch), read September 2026.

A note on who this is for. The bands start at $161,000 and the reqs say Thatch hires engineers "across multiple levels," which reads as mid-level and up rather than new-grad; there's no junior or new-grad engineering posting on the board as of this writing. The postings list locations as San Francisco or Remote (US) with no mention of visa sponsorship, so if you need it, ask the recruiter early rather than assuming.

These are cash ranges, so equity is the part you actually negotiate, and it isn't on the posting. Model the full picture with a [total comp calculator](/total-comp-calculator/) before you counter, and read up on [salary negotiation](/post/3233474669/salary-negotiation-2026/) so you anchor on total value rather than just base. A $1B valuation with backers like Index Ventures, General Catalyst, and Andreessen Horowitz means the equity has a credible story, but it is still illiquid.

## How to spend your prep time

With three weeks, weight it toward the domain: one week on transaction-safe coding (idempotency, reconciliation, state machines, clean data models) in whatever language you're fastest in since Thatch doesn't require Ruby, one week on integration-heavy, correctness-first system design, and one week on behavioral stories with a light pattern refresh. A structured [study plan](/study-plan/) sets the pace.

The candidates who do well at a company like this aren't the ones with the fastest graph algorithm. They're the ones who, handed a money-movement problem, instinctively ask what happens when it runs twice.