What Fintech Companies Actually Hire For (What Fintech Companies Actually Hire For)

This 22-part series covered the technical architecture of a production payment engine from start to finish. The final part answers a different question: how do you position this knowledge in your career? What do fintech companies actually look for in interviews?

The short answer: not knowing how to integrate a PSP's SDK. SDK integration is a learnable skill — you can do it in a week reading documentation. What companies want is the thinking model underneath the SDK: what happens when a payment fails, when a webhook arrives late, when the same message arrives twice?

What interviews actually test
  ❌ 'I used the Stripe SDK'
  ✓ 'Exactly-once doesn't exist; I built effectively-once via defense in depth'
  ✓ 'I resolved orphan charges with correlation id and evidence-driven runbooks'
  ✓ 'I made drift measurable with a reconciliation worker'

Where the concepts first show up

📦 Failure thinking
The habit of pairing every happy-path scenario with 'what if this step fails'.

📦 Evidence-driven engineering
Decisions resting on an evidence table (step log, PSP query, audit), not assumption.

📦 Operational maturity
The system isn't just working — when it breaks, it's visible and recoverable.

📦 Transferable pattern
An architectural pattern applicable to the distributed payment problem, not a specific PSP.

In fintech interviews, 'which SDK did you use' is a wrapper for 'which questions did you ask and which trade-offs did you consciously choose'.

SDK integration is a starting point, not a differentiator

Integrating a PSP SDK is the most visible but least distinguishing skill in payment systems. Every fintech company does it at some point; what creates interview differentiation is what you thought about beyond the integration.

Level 1: SDK integration
  → charge API works, webhooks arrive

Level 2: Failure handling
  → timeout vs decline distinction, retry taxonomy

Level 3: Distributed thinking
  → idempotency, lease, outbox, reconciliation

Level 4: Operational ownership
  → observability, runbook, worst-day scenario

Companies write Level 1 in the job posting; they search for Level 3–4 in the interview. This series bridges Level 2 to 4.

Five thinking patterns that distinguish candidates

1. Failure taxonomy: Instead of 'a payment failed', ask: business decline, timeout, 429, or 5xx — and a different action for each. The essence of parts 11–12.

2. Idempotency beyond API: An idempotency key doesn't just protect the API request; webhook consumers, async workers, and DB constraints must work together. You don't promise exactly-once; you build effectively-once.

3. Reconciliation as design, not afterthought: Reconciliation isn't 'a cron job we added later'; it's the measure of the system's honesty. Drift count doesn't show how well the system runs — it shows how honest it is.

4. Evidence over assumption: For an orphan charge, not the reflex to 'refund immediately' — but correlation id → step log → PSP query → decision. The safest action in a panic is waiting until you find evidence.

5. Boundaries that survive a PSP swap: The orchestrator never sees a PSP SDK; semantic events reach downstream in business language, not as raw payloads. Three years later, when you swap providers, the orchestrator code shouldn't change.

Translating to CV and interview language

Series concept	CV/interview language
Provider abstraction	'Built PSP-agnostic payment orchestration layer'
Failure taxonomy	'Designed retry policies differentiated by failure category'
Idempotency + dedup + uniqueness	'Achieved effectively-once charge outcomes via defense in depth'
Reconciliation worker	'Built automated drift detection reducing manual payment review by X%'
Step event log + payment id correlation	'Implemented payment lifecycle observability enabling sub-minute incident triage'
Evidence-driven runbook	'Authored operational runbooks for orphan charge and duplicate finalize scenarios'

The numbers (X%) must be real; this series gives you the concepts, you supply the metrics.

Junior vs senior: what changes

Junior roles may only require SDK integration and basic API knowledge. Senior and staff roles ask a different question: 'What's the worst-day scenario when you take this to production, and are you ready for it?' The answer is the checklist from part 21 of this series.

Junior interview question
  → 'How do you receive a webhook?'

Senior interview question
  → 'What happens if the same webhook arrives twice?'
  → 'PSP says Captured, local says Expired — what do you do?'
  → 'Can you guarantee exactly-once?'

If the answer to the last question is 'no, I build effectively-once', you've understood this series.

Distinctions that get blurred

❌ Fintech = payments SDK knowledge
✓ Fintech = distributed systems thinking + payment domain knowledge

❌ More PSP experience = stronger candidate
✓ Transferable pattern knowledge = stronger candidate

❌ This series is only for backend engineers
✓ Operational maturity is sought in platform and SRE roles too

What isn't sought vs what is

Not sought	Sought
Specific PSP certification	Failure/reconciliation thinking
'I wrote a charge API'	'I'm ready for the worst-day scenario'
Exactly-once claim	Effectively-once evidence
Raw webhook pass-through	Semantic events + translation layer

Career positioning checklist

1. Does your CV include at least one 'failure handling' and one 'reconciliation/drift' item?
2. Can you answer the 'exactly-once' interview question with effectively-once?
3. Can you walk through an orphan charge or duplicate finalize scenario with evidence?
4. Do you describe provider abstraction as 'the orchestrator doesn't know the PSP', not 'I defined an interface'?
5. Have you applied this series' checklist (part 21) to your own projects and identified gaps?

What to take away for your career

1. Fintech companies want failure/reconciliation/idempotency thinking, not SDK integration skills.
2. This series' 22 parts cover all five thinking patterns that distinguish candidates in interviews.
3. The right answer to 'can you guarantee exactly-once' is 'no, I build effectively-once'.
4. Production readiness is being able to answer the worst-day question — the checklist is how you measure that.

The sentence that wins a fintech interview isn't 'I used the Stripe SDK' — it's 'I resolved orphan charges with correlation id and an evidence-driven runbook'.

This is the final part of the Distributed Payment Engine series. The single fact we've defended across 22 parts hasn't changed: a distributed payment system doesn't aim for perfection — it aims for controlled, observable inconsistency — and that way of thinking is your most valuable career asset.