Hiring for payments engineering: what to test

A generic backend engineering interview loop misses the specific skills that make a good payments engineer. The generic loop is fine for finding good engineers; a targeted loop finds the ones who will make good decisions on financial-grade systems.

Written April 2026 from hiring across several teams.

What generic interviews miss

• Correctness under partial failure. Payments systems have to be correct when things break. A generic system-design question doesn't probe this.
• Idempotency thinking. Understanding that retries and duplicates are the norm, not the exception.
• The willingness to be paranoid. Some questions have no "correct" answer, only "less wrong". Do they know that?

What to add

• A design question involving a reversal. "Design a refund flow that survives a partial network failure between the merchant and the acquirer." Watch for who assumes success and who models the failure modes.
• A code review of a race condition. Show them code that looks correct but has a subtle race. Do they see it? Can they describe the fix without being led?
• A discussion of a real incident. Not "tell me about a hard bug"; describe a specific incident to them and ask how they'd have prevented it. See what they focus on.
• Explicit questions about scope. "This is out of scope for the assignment, but I want to know: what would you do if the scope were larger?" The answer reveals whether they understand what they didn't build.

What to weight less

• Pure algorithmic complexity. Payments engineering rarely needs to invent algorithms; it needs to combine well-known patterns correctly. Complexity puzzles filter for the wrong signal.
• Speed of coding. A payments engineer who codes fast without thinking produces incidents. Someone who takes time to consider the edge cases is who you want.

Hiring for payments is hiring for judgement more than raw skill. Design the loop to see judgement.