A capable general engineer can learn fintech, and the gap is not intelligence, it is a set of instincts about money that are expensive to acquire on your system. Representing amounts correctly, making operations idempotent, treating reconciliation as a feature and knowing that some screens carry legal text are all habits rather than knowledge.
Money has a correct representation and most people get it wrong
Ask how a candidate stores monetary amounts, and listen for integer minor units rather than floating point. Ask how they handle rounding when splitting an amount, and what they do about currencies with different minor unit conventions. Ask what happens if a payment request is retried after a timeout, and listen for idempotency keys. These are small questions that reliably separate people who have built financial systems from people who have built systems.
Reconciliation is a feature, not an accident
In financial systems the question is never whether something will disagree but what happens when it does. Ask how they would detect that their ledger and a payment provider have diverged, what an automated reconciliation job would check, and how a correction is recorded. The right instinct is that you never edit history, you post an adjustment that explains itself. A candidate without that instinct will build something that cannot be audited.
Some interfaces carry legal obligations
Anything touching credit brings Regulation Z at 12 CFR part 1026 into the interface, with rules about the content, timing and prominence of disclosures. A fintech engineer should know that certain screens are not freely redesignable and that compliance belongs in design review rather than at sign off. A candidate who treats required disclosure as legal text to be dropped in at the end will cost you a redesign.
Security that can be examined, not just asserted
Financial institutions are expected to oversee their providers and to run a documented security programme, and 16 CFR 314.4 sets out the shape: a named accountable individual, written risk assessment, access controls, encryption in transit and at rest, multi factor authentication, secure development practices, logging, periodic testing and incident response. Ask how a candidate has worked under those constraints, because working inside an examinable environment is itself a skill.
Questions people ask about hire fintech developers
What separates a fintech developer from a good general developer?
Instincts about money: integer minor units rather than floating point, idempotent payment operations, reconciliation designed in from the start, and the knowledge that some screens carry disclosure obligations. These are habits acquired expensively on someone else's system.
What is the best single interview question?
What happens if a payment request is retried after a timeout. The answer should involve idempotency keys and a clear account of how duplicates are prevented. It is a small question that reliably identifies real experience.
Do fintech developers need to know the regulations?
They need to know which parts of the product are constrained, particularly that credit disclosures under 12 CFR part 1026 have content, timing and prominence rules, and that security is examinable along the lines of 16 CFR 314.4. They are not your compliance function, but they must know where the boundaries are.