Capital One Senior Software Engineer Interview Experience (2025) - Fraud Detection System Design, Offer

Problem: Design the backend for a real-time fraud detection service that ingests every card authorization, evaluates it against a user's behavioral history, and returns allow or block within 100 milliseconds. The load was stated as "tens of thousands of transactions per second at peak."

I framed the problem in two halves. The read-side decision path had to be fast and mostly cache-local, and the write-side behavior model could afford to be eventually consistent. For the decision path I proposed a per-user feature store keyed by cardholder ID, populated from a Kafka stream of historical authorizations and maintained as a sliding window over the last 24 hours and the last 30 days. Each record held running aggregates (count, sum, geographic centroids, merchant category histograms) plus a few compact sketches for velocity features. On an incoming auth, the service fetches the user's feature row, applies a small rules engine plus a cached model score, and returns a decision.

The interviewer pushed hard on the 100-millisecond budget. We walked through where the time goes: p99 Redis fetch, feature assembly, model inference, write-ahead log for the audit trail. I argued that the model call should be an embedded scorer rather than a remote service, and that the audit write should be fire-and-forget with a durable local buffer. He asked what happens when a user swipes in New York and Los Angeles within five minutes. I described a velocity rule using haversine distance between consecutive geocoded authorizations plus a time delta, short-circuiting the model entirely for the clear-cut cases.

The scaling discussion got into shard strategy (hash by cardholder ID), hot-key mitigation for celebrity accounts, and how to handle the feature store during a Redis failover. I suggested a fail-open fallback to a cached global risk policy and a separate fail-closed mode for high-value transactions.

The coding portion took the last 20 minutes. He asked me to implement a structure that tracks each user's rolling count and sum of transactions over the last N minutes in amortized constant time. I wrote a per-user deque of (timestamp, amount) pairs with lazy eviction on query. The follow-up generalized it to longest-run tracking, similar to [[problem/850?company=44|Longest Consecutive Sequence Tracker]]. We also sketched a version of [[problem/856?company=44|Memory Allocation System]] for how the feature rows are laid out in a fixed-size arena.

Round 2: Behavioral, Leadership and Cross-Team Conflict

This was a 45-minute round with a tech lead manager and it was heavier than a typical behavioral. The anchor scenario was exactly the one people on forums warn you about: you are the tech lead on a cross-functional project, a frontend counterpart is repeatedly slipping on the interface you both agreed on, your backend launch is at risk, and the PM is not stepping in.

I walked through a real situation from two jobs ago. First move was to reset the conversation one-on-one and ask what was blocking them instead of pushing for a new date. A staffing change on their side had eaten most of their capacity, and they had been trying to absorb it without escalating. Once I knew that, I rewrote the integration plan around a thin mocked contract that unblocked my backend rollout, and I took the paper trail to the skip-level on both sides so the staffing issue became visible. After the launch we documented the mock-first integration pattern in our team runbook, and I ran a small post-mortem with both leads.

The interviewer pushed on two things specifically. One, how did I avoid the situation becoming a public blame exercise. Two, what did I do to rebuild trust with the frontend engineer afterward. The second question was the harder one and I think the answer he was looking for was some version of "I kept pairing with them on the next project and made sure they got credit in the launch email," which is roughly what I said.

Round 3: Product and Cross-Functional, Credit Card Repayment Reminders

Problem: Users are missing card payment due dates at a rate that is hurting both them and the business. Design a multi-channel, user-aware reminder system, and propose how to measure whether it is working.

I started from the user. Not everyone misses payments for the same reason: some people forget, some are cash-flow constrained and timing matters, and some genuinely do not know the due date because they only use the card occasionally. The reminder system should segment on that and not blast everyone with the same push at 9am.

From there I walked the data flow: a behavior model that ingests payment history, app open patterns, and notification interactions; a channel selector that picks App push, Email, or SMS based on last-engagement recency per channel; and a scheduler that picks the "most appropriate" reminder window by learning from each user's past response times. I proposed a small ladder of reminders (seven days out, three days out, same day) with channel escalation only for users who have historically ignored softer nudges.

The interviewer pushed on two angles. One, how do I avoid annoying users into disabling notifications entirely. Two, how do I measure business impact without confounding it with macroeconomic factors or seasonal payment cycles. On the first, I described a per-user frequency cap and an explicit preference center with sensible defaults, plus a daily global cap that degrades gracefully under regulatory or operational constraints. On the second, I proposed a geo-randomized holdout group rather than a pure A/B, because card usage is heavily regional and a straight split would leak on the test. Metrics were on-time payment rate, late-fee incidence, and net promoter among the reminded cohort, with a guardrail on unsubscribe rate. The privacy-aware bonus question I answered with an on-device personalization layer for the scheduling piece so the sensitive parts of the signal do not have to leave the phone.

Result

Offer came nine business days after the onsite. The band matched what I had seen reported and the sign-on was reasonable after one ask. I accepted.

Tips

1. Treat the combined coding plus system design round as a design round first. The coding portion is the last 15 to 20 minutes and the bar is clean, not clever. Spend your prep on being able to talk through tradeoffs in a fraud or payments context, not on grinding new algorithms.
2. Have a real cross-team conflict story ready and make it specific. Capital One's behavioral round goes deeper than most. They will ask about rebuilding trust, not just resolving the blocker. Vague answers fail here.
3. The product round is not a PM round. They want to see that you can reason about users and measurement, but the answers that land are the ones that include technical detail about how you would actually implement the segmentation or the experiment.
4. Know the 100-millisecond budget cold. When they ask about latency, have a real mental model of where the time goes: network, cache, model inference, write-through. The good candidates narrate it out loud.
5. Do not oversell machine learning. Their fraud systems are rules-plus-model hybrids and they will respect a candidate who reaches for the simple rule first and adds the model where it actually earns its keep.
6. Ask about the team during the loop. Capital One runs a team-match process after the offer and the more signal you give during the rounds about what you want to work on, the better placement you get.