Engineering IC interview prep.

A senior SWE IC at a payments firm is judged on technical depth (system design + distributed systems + production debugging) AND the correctness bar payments raises: money cannot be silently lost or double-spent, settlement deadlines are hard, partner integrations break, and PCI-DSS / SCA / SOC...

What interviewers look for

  • Can the candidate run a senior payments system-design loop end-to-end: clarify, estimate, API, data model, architecture, correctness story, deep-dive - not just draw boxes?
  • Do they treat idempotency, exactly-once-effects, and recoverability as first-class - or do they hand-wave money-movement correctness?
  • Do they pick consistency + storage primitives to the use case (strong + ACID for the ledger, eventual + scalable for analytics, audited for compliance) and explain the tradeoff?
  • Do they treat PCI-DSS, PSD2 SCA, and SOC 2 as design inputs (tokenization, scope reduction, audit log) rather than 'compliance team's problem'?
  • Can they debug production end-to-end: the four golden signals, the partner-integration angle (issuer / acquirer / network / processor), the reconciliation lens - and validate the fix without losing or duplicating money?
  • Do they show senior behavioral signals - technical influence, disagreement-and-commit, ownership of a money-impacting incident, communication across risk / compliance / partner teams?

Behavioural questions to expect

  1. Walk me through your CV.

    What it tests: Story coherence + genuine fit for senior payments / fintech IC work. Teams want evidence of progressive technical scope (feature -> system -> cross-team money-movement architecture), production ownership of something that mattered to customers' money, and any payments / financial-services / regulated-domain exposure - not just years-of-service.

  2. Tell me about your most impactful technical project.

    What it tests: Depth + ownership + the willingness to defend a technical choice. In payments, this loop probes the correctness story specifically: idempotency, recoverability, audit trail, reconciliation. Tests whether the candidate frames problem -> approach (with tradeoffs) -> correctness story -> result (quantified) -> lessons, not just describes a feature.

  3. Tell me about a weakness, a failure, or feedback you've received and worked on.

    What it tests: Self-awareness + production discipline. Cross-role canonical. Fake weaknesses downgrade immediately. Senior payments SWE mistakes (a missing idempotency key, an under-tested reconciliation path, a held incident, a partner-integration that broke on retry) shape teams; honesty about a judgment error and the process fix matters more here than in non-money domains.

  4. Why payments / fintech engineering - and why this firm's segment vs general SaaS or pure infra?

    What it tests: Authentic fit for the payments / fintech engineering seat: real money, real customers, hard correctness, partner integrations, regulatory frame. Tests whether the candidate is drawn to the constraints specifically - not just 'I want to work on a hot company'.

  5. Which engineering team or technical area would you want to work on, and why?

    What it tests: Genuine fit + grasp of how payments engineering areas differ. Tests whether the candidate has a reasoned preference (payments-core / risk-fraud / ledger / partner-integration / data-platform / developer-experience) rather than 'wherever you put me'.

  6. Why this firm?

    What it tests: Whether the candidate has done the homework. Bar: firm-specific evidence from the product, segment, engineering culture, stack, customers, scale, and people - not generic 'great fintech'.

  7. How would you describe this firm's engineering organisation and architecture in your own words?

    What it tests: Whether the candidate has internalized HOW the firm builds - org shape, stack, architecture, scale, correctness model - not just that it 'has engineers'. Tests whether they've read the engineering blog + can speak to specifics of a payments engineering org.

  8. How does engineering actually drive value at a payments firm like this firm?

    What it tests: Whether the candidate understands payments-engineering economics: reliability that customers measure in 9s, auth rate that drops to revenue, fraud + chargeback engineering that protects margin, platform investment that scales velocity, and PCI / regulatory engineering that unlocks segments.

Technical concepts to master

Idempotency + exactly-once semantics for money

Idempotency keys
A client-generated unique key attached to each write request; the server records the (key, response) pair and returns the cached response on any retry with the same key.
At-least-once delivery + dedupe
Producers retry until acknowledged; consumers dedupe by event ID using a dedupe store (or upsert + unique key on the target).
Sagas + compensating transactions
A long-running money flow split into local transactions; if a later step fails, earlier steps are rolled back by explicit compensating actions (refund, reverse-transfer).
Outbox + transactional event emission
Write the business row + an event row inside the same DB transaction; a separate publisher reads the event table and emits to the bus, guaranteeing atomicity between DB state + event.

Double-entry ledger design

Double-entry basics
Each business event posts at least two ledger entries: one debit + one credit; the sum across all accounts per asset is always zero.
Immutability + append-only
Entries are never updated or deleted; corrections post compensating entries (e.g. a 'reversal' transaction) with a reason code linking to the original.
Balance computation - rolled-up vs derived
Rolled-up: maintain per-account balance row + atomic update with each entry. Derived: compute on read by summing entries. Hybrid: snapshot + delta.
Reconciliation - internal + external
Internal: invariant checks across the ledger (sum-per-currency = 0; subledger to GL match). External: match internal ledger against partner / acquirer / bank statements + flag drift.

PCI-DSS scope + tokenization

PCI-DSS scope - what's in
Any system that stores, processes, or transmits cardholder data (PAN, track data, CVV) is in PCI scope and subject to the full PCI-DSS control set.
Tokenization
Replace the PAN with a non-sensitive token at the earliest possible point; only the tokenization vault holds the PAN, dramatically reducing scope on every other service.
Network tokens vs vault tokens
Vault tokens: issued by your vault, opaque to networks. Network tokens: issued by Visa / Mastercard, auto-updated when the card is re-issued (lifts auth rate ~50-100bps).
Compensating controls + segmentation
Where scope cannot be eliminated, isolate the CDE via network segmentation + strict access controls; everything outside the CDE is out-of-scope (or in 'connected-to' scope).

Webhooks + partner-integration patterns

Webhook delivery - signed + retried
Outbound webhooks must be signed (HMAC with a shared secret + timestamp) and retried on a backoff curve up to 24-72 hours, with idempotency on the receiver side.
Inbound webhook handling
Verify signature first; persist the raw payload + event ID for dedupe; ack quickly; do the work async. Never trust the payload without signature verification.
Circuit breaker + fail-safe partner posture
Wrap every outbound partner call in a circuit breaker that opens on sustained errors / latency; on open, fail-fast or route to a fallback partner.
Replay + reconcile after partner outage
When a partner recovers, replay any held / failed operations from a durable queue; reconcile their final state against the partner's view to confirm convergence.

Practical drills

  • this firm's auth API receives 20M card transactions / day, average payload 3KB, with a target P99 of 600ms (incl. issuer) and 99.97% availability. Settlement batches run nightly. (a) Average + peak auth TPS. (b) Daily + annual storage growth for the auth log. (c) If reads on the dashboard / reconciliation side are 5x writes, peak read TPS? (d) Settlement batch: 20M transactions to process in a 4-hour window - required throughput? (e) How many app servers (assume ~300 TPS / server for an auth-heavy mixed workload)?
  • Design a multi-currency payment authorisation service for this firm that supports card auths in 30+ currencies, with idempotent retries, fraud-scoring in path (target <50ms), ledger writes on success, and webhook notifications to merchants. Walk me through it.
  • Customer support escalates: 12 merchants report a total of $480K in payments that were authorised + the customer was charged, but the merchants never received the payout. Ledger shows the debits + credits both posted. The merchants haven't received the settlement file entry. Walk me through how you'd diagnose + fix.

Smart-question anchors

  • Team + scope - the team's surface area, the money-movement system the role would own in 6-12 months
  • Stack + architecture - the current stack, ledger model, recent architecture changes, where the engineering team thinks it's heading
  • Correctness + reliability - on-call rotation, SLO posture on the auth + settlement paths, reconciliation cadence, recent incident learnings
  • Partner integration - which issuers / acquirers / networks the team integrates with, partner-engineering posture, fallback + redundancy
  • Regulatory + PCI posture - PCI-DSS scope, tokenization strategy, SCA / PSD2 coverage, how engineering partners with compliance + risk

Related roles

Sourced from

Ready to Generate Your Own Prep?

Drop your CV and a job description on the home page. A couple of minutes later you get a report with everything you need to land the job.

Generate my first prep