Kalshi runs a prediction-market exchange: you trade binary contracts on whether a real-world event happens, from a Fed rate decision to a weather outcome, and each settles at $1 if it occurs and $0 if it does not. Prices trade between 1 and 99 cents and read as the market’s probability. With no public question bank, the product is your best study guide: the engineering is an exchange (order book, matching engine, market-data distribution, settlement) under the audit and reporting obligations of a CFTC-regulated venue. The Hudson River Trading interview guide and the quant firm interview guides share some matching-engine and markets intuition, but Kalshi builds the venue rather than trading on it, so the interview rewards exchange-systems thinking over alpha-generation puzzles.
The roles cluster around backend, full-stack, and platform engineering, with the trading-platform team closest to the matching engine. A posting-derived read of the work is low-latency order handling, a deterministic matching engine, real-time market-data feeds, and the settlement and compliance plumbing a regulated exchange cannot get wrong. For how Kalshi sits against other NYC fintech employers, see the broader company guides.
What Kalshi is, and why the funding tempo sets the bar
Kalshi is a CFTC-designated contract market for event contracts, and its growth this past year put it on most engineers’ radar. The funding ladder has been steep: a $300 million Series D at a $5 billion valuation in October 2025, then a $1 billion Series E at an $11 billion valuation led by Paradigm in December 2025 (per Crunchbase), and a $1 billion Series F at a $22 billion valuation led by Coatue in May 2026 (per The Block; Sequoia, a16z, and Morgan Stanley also in). The Financial Times then reported talks to raise at roughly a $40 billion valuation, a round it said could close as early as the third quarter but which names no investors and was not finalized as of this writing, so treat the $40 billion as a reported target, not a fact. On IPO, The Information reported Kalshi is in early talks with banks and has passed $2 billion in annualized revenue, while CEO Tarek Mansour has said one is under consideration but will not happen in 2026.
The volume behind those numbers is documented: The Block’s data dashboard logged more than $21 billion of Kalshi volume in a single month. For an engineer the signal is throughput. Volume at that scale is a problem that lands on the matching engine and the market-data path, exactly where the system-design round goes.
The interview loop, round by round
The strongest single source is DesignGurus, compiling scattered Glassdoor, 1Point3Acres, and Blind reports: a phone screen, a live-coding technical phone round, and a final set covering a coding round, a system-design round, a past-work walkthrough, and a manager interview. Some stages rest on a single report and order varies by role, so weight the skills over the exact stage count. A 1Point3Acres write-up (login-walled) adds an online technical test plus a one-hour coding interview for a full-time SDE role. A Blind reply DesignGurus cites is worth carrying: at a team this size, candidates are judged partly on whether the team needs their background, so a strong one can still be passed over for fit, not performance.
On logistics, DesignGurus cites Glassdoor data showing roughly two weeks from application to offer for software engineers (small sample), though others report rounds spaced weeks apart. The early screens are remote by phone or video, while BuiltIn lists Kalshi’s New York engineering roles as in-office, often five days a week, with the occasional posting marked remote. No public source documents a fixed onsite length, so confirm the cadence and final-round format against the specific listing.
Kalshi engineer interview loop at a glance
| Stage (candidate-reported via aggregators and inferred from exchange peer norms, Oct 2026 — not a Kalshi-published loop) | What reports and the peer pattern suggest | How to prep |
|---|---|---|
| Recruiter / phone screen | Background, motivation, a direct “Why Kalshi?” | A crisp answer tying your interest to regulated event markets, not generic fintech |
| Technical phone (live coding) | Practical coding in a shared editor; expect to state time and space complexity | Clean, runnable code; narrate trade-offs; know your complexity cold |
| Coding round | Implement a class or data structure; interviewer probes hash map vs. heap vs. sorted structure | Design-flavored data-structure problems, API reasoning under time pressure |
| System design | Exchange-shaped: order book, matching, market-data feeds, settlement | Design an order-matching path end to end; reason about determinism and throughput |
| Past-work walkthrough + manager | Ownership on a real project; operating with little direction | One project you can narrate end to end, with a genuine hard call in it |
One caveat on the table: the online technical test comes from a single unconfirmed report, so treat an online assessment as possible but unverified, not a guaranteed gate.
The coding bar: what to actually practice
The coding rounds reward craft over cleverness. One Glassdoor-sourced example in the DesignGurus writeup is to implement a class that handles efficient queries, where several solutions are valid and the interviewer wants you to reason about the trade-off between a hash map, a heap, and a sorted structure: a design-flavored medium problem, not an esoteric dynamic-programming grind. Drill the coding patterns catalog so that hash maps, heaps, intervals, and two pointers are reflexes, and make your Big-O analysis automatic, because the interviewer will ask for the complexity of each approach. For the live phone round, code that compiles and runs with a test or two beats a clever one-liner with no error handling.
Because this is an exchange, data-structure questions carry a latency subtext: for a running best price, a top-k, or an ordered set of resting orders, the interviewer is checking whether you reach for the structure with the right worst-case behavior, not the first that works on the example.
System design for an exchange
This is the round most worth over-preparing, and the exchange product gives it a clear spine. A likely prompt: design the path from a client placing an order to that order matching and the resulting trade settling. Start with the order book, which is the structure holding every resting buy and sell order, matched by price-time priority: the best price wins, and among orders at the same price the one that arrived first fills first. For a binary event contract, YES and NO are complements, so a YES bid at 60 cents is economically a NO offer at 40 cents, and a strong answer either models that symmetry explicitly or shows awareness that crossing logic has to account for it. Now name the central tension out loud: strict determinism (so a regulated exchange can replay and audit exactly what happened) pulls toward a single sequential writer, while throughput pulls toward parallelism. You resolve it by partitioning per market: each market runs its own single-threaded matching loop in strict sequence, and you scale by running thousands of markets in parallel, not by threading one book. Ground it in the venue class: Kalshi is a retail-facing regulated exchange, not a colocated high-frequency venue, so you target correctness and sub-second to low-millisecond responsiveness at retail order rates, not the nanosecond race of equities market-making.
From there the standard system design toolkit applies to the exchange’s specific patterns. Market data fans out to many clients at once, so talk about a publish path that broadcasts book updates and trades without coupling them to the matching hot loop. Persistence wants an append-only event log of every order and fill, which is both the audit trail and the way you rebuild book state after a restart; indexing and querying that log is the same muscle as database indexing, applied to append-heavy, time-ordered writes. Then the parts that separate a strong answer from a textbook one. How do you stop one client from flooding the gateway and starving everyone else? You reach for a rate limiter and per-account quotas at the edge, before the matching engine sees the traffic. How does settlement work when an event resolves? Every open position pays out $1 or $0 in one deterministic batch tied to the official resolution, and you want that path idempotent so a retry never double-settles.
What they screen for beyond code
The manager round and past-work walkthrough lean on ownership and comfort with ambiguity, which fits a company scaling this fast. Prepare one project you can narrate end to end, with a real decision and a real trade-off in it, and keep it tight with the STAR method. Some domain fluency goes a long way: be able to say what an event contract is, why prices read as probabilities, and why CFTC regulation makes correctness and auditability non-negotiable in a way a casual trading app never faces.
Comp, with the usual caveats
Kalshi publishes no compensation bands, and the posting-derived numbers disagree, so anyone quoting you a single figure is guessing. A job-board aggregator (Zero G Talent) lists New York software-engineering roles, including product and trading-platform, at roughly $200,000 to $280,000 total compensation (base, equity, and bonus, from active postings). A different aggregator (Recruiting From Scratch) reports a median near $175,000 across 21 public postings, but flags that as base only, so the two are not comparable: one is total comp, the other base. There’s no Kalshi-specific Levels.fyi page as of October 2026; its general New York software-engineer median near $190,000 to $195,000 is only a city baseline. The realistic read is a mid-level NYC offer in the $200,000 to $280,000 total-comp range with equity as the live variable, and at a company this freshly repriced, the equity is where the negotiation sits. Check Ramp and other NYC fintech peers, model your own number with the total comp calculator, cross-check comparable NYC roles on Levels.fyi and the H-1B LCA filings below, and treat the equity grant as the center of any salary negotiation. On sponsorship, third-party H-1B trackers (per Ellis) show Kalshi has filed only a handful of Labor Condition Applications, all for New York and including software-engineer roles, so sponsorship happens but is not routine, and with no public policy stated, ask the recruiter early if you need it.
Kalshi interviews like a fast-growing exchange that happens to be a hot fintech name: medium coding with a design flavor, a system-design round that rewards real exchange thinking, and a read on whether you actually want this problem. Study the matching-engine and settlement path until it is boring, and have a one-sentence answer for why regulated prediction markets are what you want to build.
Practice the behavioral round:
