Sardine builds a risk platform that banks and fintechs use to catch financial crime, profiling device, behavior, and transaction signals to return a risk score in real time without adding friction for legitimate users. In February 2025 it raised a $70 million Series C led by Activant Capital, with Andreessen Horowitz, Google Ventures, Nyca Partners, Moody’s Analytics, and Experian Ventures also taking part, money it said would expand its AI agents for fraud, compliance, and credit underwriting. A May 2026 $25 million extension led by National Bank of Canada took total funding to about $170 million. That agentic-risk direction shapes what the interview digs for.
The one round Sardine actually documents
Most companies this size keep their format private. Sardine is the rare exception: in a June 2025 engineering post, Reimagining Technical Interviews in the Age of AI, it laid out exactly how it changed its coding round. Author Kazuki Nishiura writes that “a leetcode-style coding interview is no longer the optimal way of interviewing candidates,” for two reasons: AI tools generate standard algorithm solutions in seconds, and Sardine’s own engineers use tools like Claude and GitHub Copilot every day, so an isolated puzzle doesn’t reflect the work.
The post describes the format as experimental and still being iterated, not a fixed script, so read it as direction rather than a guarantee. It works like this. You bring your own IDE, your own tooling, and your own AI coding assistant; search engines and AI assistants are explicitly allowed. Sardine provides a basic server implementation “in various languages,” so you do not need Go for this round and can work in a language you know, even though the production backend is Go. Together with the interviewer you build a payment risk API: it takes a list of payment transactions and returns a risk score. You add scoring logic as you go, checking total transaction amounts or calling a mock external API for extra data. Partway through, the requirements change, through new test data or a different algorithm, to mirror how real specs move. You share your whole screen so the interviewer follows your approach in real time rather than seeing only a finished answer. The post does not publish the round’s duration, the exact role scope, or a scoring rubric, so treat those as open.
What the format screens for matters most. Sardine says the point is to see how you operate close to the real job, treat AI as a tool rather than something to hide, and show “the human communication and problem-solving skills that AI can’t replace.” In practice that means reading your assistant’s output critically instead of pasting it blind, narrating your reasoning, and staying calm when the spec shifts. This is the applied side of AI-era interviewing: the interviewer assumes you have the tools and grades judgment on top of them.
The rest of the loop, and what is still unknown
Outside that one documented round, the public record is thin. Glassdoor’s Sardine page is low-n (a handful of reports, behind a login), too few to read as a reliable pattern, and third-party “process” pages are generic templates. So rather than invent a round-by-round script, here is the realistic shape for a fraud-and-compliance company of a few hundred people (Sardine was founded in 2020; check LinkedIn for a current headcount before you prep).
A loop like this would likely run a recruiter or hiring-manager screen, the AI-allowed technical round above, a systems-and-depth conversation on real-time scoring and data pipelines, and a behavioral round, plausibly four or five rounds over two to four weeks. Treat the count, order, and timeline as approximate rather than reported. Other fintech loops on this site give useful calibration for the bar, including Stripe and Plaid on the payments side and Vanta on the compliance side.
Fraud and risk questions the product implies
Sardine does not publish its question bank, so treat the following as topics the work points to rather than reported prompts. The central object is a risk score computed from many weak signals: device fingerprint, behavioral biometrics (how someone types and moves), velocity (how many transactions in how short a window), and known-bad lists. Be ready to reason about combining those into one decision and about where the thresholds live.
A strong candidate can talk through the asymmetry at the center of fraud work. A false positive blocks a paying customer and costs trust; a false negative lets fraud through and costs money and, for a regulated client, a compliance problem. That trade-off is why precision and recall, not raw accuracy, are the vocabulary here, and why a class-imbalanced problem (fraud is rare) breaks naive accuracy metrics. Expect to discuss feature engineering from transaction streams, why a model drifts as fraudsters adapt, and how you would catch that drift before a customer does. The agentic angle adds a newer layer: if an AI agent is taking or recommending risk actions, how do you keep a human able to audit and override it, and how do you evaluate the agent’s decisions against known-correct outcomes rather than trusting them.
Where fraud ML gets genuinely hard is the infrastructure underneath it. A velocity feature like “transactions in the last 10 minutes for this device” must be computed identically during offline training and online serving; if the two drift, you get training/serving skew and a model that looked accurate in the notebook but misfires in production. That consistency is what feature stores exist to provide, and being able to explain why it is the real engineering work, not the model choice, is a strong signal. Whether a risk-ML role gets the same build-an-API round or an added modeling round (take-home or ML-system design) is not published, so ask the recruiter which track your loop follows.
Real-time systems and data-pipeline questions
Scoring in real time is a systems problem as much as a modeling one, and a systems-and-depth round would lean hardest on this. Sardine’s backend is built in Go on Google Cloud and AWS, per one since-removed senior software engineer posting. A score has to return fast enough to sit inside a live checkout or login, which puts latency and tail behavior on the table.
Good areas to have real answers for:
- Keeping p99 latency low when a scoring call depends on a slow external lookup: caching, timeouts, and a sane default when the dependency is down rather than blocking the whole decision.
- Backpressure and rate control when event volume spikes. The reasoning overlaps directly with rate limiter design, so rehearsing token-bucket and sliding-window thinking pays off here.
- Computing velocity features (count and sum over a recent window per user or device) cheaply, which is a streaming-aggregation and windowing problem.
- Querying and joining transaction history for investigation and model features, where SQL window functions and sensible indexing decide whether a query returns in milliseconds or seconds.
If the backend portion goes deep, the Go concurrency patterns around goroutines, channels, and context cancellation are the tools you would reach for to fan out enrichment calls and enforce timeouts. The system design interview guides cover the rest of what recurs in a real-time pipeline.
Work one path end to end, since that is how a depth round pushes. A login or checkout fires an event, and you have maybe 200 milliseconds to return a decision: ingest it, enrich it with device and behavior history plus one external lookup, score it, and return allow, block, or step-up. The external lookup is the risk: wrap it in a tight timeout and cache, and when the dependency is slow, fall back to a score from signals you already have rather than blocking the decision. Make the scoring call idempotent so a retry does not decide twice, and log the features behind each score for investigation.
| Sardine interview stage | Focus | What it screens for | Publicly confirmed? |
|---|---|---|---|
| Recruiter / hiring-manager screen | Background, motivation, logistics | Interest in fraud and risk, fit for a remote-friendly fintech | No (inferred) |
| Technical coding round | Build a payment risk-scoring API in your own IDE, AI assistant and search allowed, requirements change mid-session | Judgment with AI tools, communication, handling shifting specs | Yes (Sardine’s engineering blog, described as something they have been trying) |
| Systems and depth round | Real-time scoring, latency, streaming features, data pipelines | Can you make a stateful, low-latency risk service correct and fast | No (inferred; Go-on-GCP/AWS stack from a job posting) |
| Behavioral | Ownership, collaboration, communication | How you work and handle ambiguity on a small team | No (inferred) |
Read that as a prep map; if a recruiter gives you a different sequence, trust them.
Compensation and what to ask
Get your numbers from data. The one Sardine senior software engineer posting I could read listed $170,000 base for a US remote role, a single data point rather than a full band; Sardine’s live postings are the best current source, since California and several other states now require a pay range on the req. To triangulate a real range for your level, check Sardine entries on levels.fyi and pull the base-salary figures from public H-1B labor condition applications, which employers must file for sponsored roles and which list exact bases by title. On sponsorship itself: Sardine has filed H-1B LCAs in the past, including for software and machine-learning engineer titles, but recent volume is thin and an LCA is not a guaranteed petition, so if you need a visa, confirm sponsorship for your specific role with the recruiter before you invest prep time. Run any full package through a total comp calculator before you react, since a private-company equity grant carries more upside and more risk than a public company’s and is hard to value from outside. Anchor your salary negotiation on your level and competing offers, and ask for the share count, strike price, current preferred valuation, and total shares outstanding so you can actually value the equity.
How to prep
Spend most of your time where this loop actually puts pressure. Build the thing it asks for: a small risk-scoring service that takes a list of transactions, computes a few features (totals, velocity, a lookup against a mock external API), and returns a score, and practice extending it live while someone changes the requirements on you. Do it with your real AI assistant on, because reading and correcting the assistant’s output under observation is the skill this round looks designed to test, and pasting its first answer unchecked reads as exactly the reflex this format is built to catch. Refresh the fraud fundamentals (precision and recall on an imbalanced problem, model drift, the cost asymmetry between false positives and false negatives) and the real-time-systems basics (latency, caching, idempotency, windowed aggregation), and keep your behavioral stories tight with a STAR structure aimed at times you owned something ambiguous and shipped it.
Useful next steps:
