To vet nearshore developers for a fintech team, test five things in order: whether you'd want to work with them, core coding skill in their main language, whether they understand how a lending business makes and loses money, whether they can code money logic like interest correctly, and how they do in your own interview.
Here's why the money part matters.
Recently we inherited a "make a payment" flow at a fintech client. It had no idempotency key, the unique ID sent with a request so that retrying it can't create a second payment (Stripe's docs explain the pattern well). So a customer who clicked the button a few times in quick succession could trigger more than one payment, with nothing much standing in the way.
We found it while redesigning that page. We write tests for every ticket we create, unit and end-to-end, and the automated tests caught it. It was a near miss, not a production incident.
The gap wasn't general coding ability. It was the instinct that money requests get retried, double-clicked and replayed, and that the system has to stay correct when they are.
Most guides to vetting nearshore developers test whether someone can code. In fintech you also need to know whether someone can be trusted with money. I've spent 20 years as a product manager, mostly at digital-only startups that originate and service financial products, and that's the lens we vet through at Amplify. Below: how we do it, the two questions that tell us the most, and what you should still do yourself even when a partner has screened people for you.
The short version: a vetting checklist
Start with the person. Would you enjoy working with them every day?
Test core coding skill with a take-home in their primary language.
Test business understanding with a real fintech problem.
Test domain engineering: interest, amortization, an integration.
Check written English and agree on working hours.
Verify identity and employment history.
Run your own final interview, even if a partner already vetted them.
Why vetting for fintech is different
A UI bug annoys a user. A money bug turns into a reconciliation break, an angry customer, and an uncomfortable conversation with your bank partner.
The standard take-home in most vetting guides is "build a REST endpoint with authentication and validation." It's a fine test of general competence. It has no retries, no interest, no ledger and no defaults, so it can't tell you whether someone understands what happens to money when things go sideways. You have to test that on purpose.
Our vetting process, stage by stage
Of every 100 engineers who apply, the field narrows to 40, then 18, then 8, then 3, all before a client interviews anyone. Read that as the overall funnel, not a count per stage. Our screens are just our part: we run the first four stages, and the client runs the fifth. (For the longer argument on why a partner should be a filter and not a résumé pipe, see buying a trusted filter.)
Per 100 applicants, the field narrows to 40, 18, 8 and 3 across our four screens. Client interviews come after.
1. "Are you a person I'd like to work with?"
Run by: Peter
Tests: Would we enjoy working together every day?
Result: cuts about half
2. Take-home (TestDome)
Tests: Core coding skill in their primary language
What trips people up: Taking too long to solve the problem
3. Fintech business case
Run by: Our team
Tests: How the business makes and loses money; do they care about this work?
What trips people up: Not asking what "default" means; assuming a default costs only the interest
4. Technical case
Run by: Our team
Tests: Money logic in their own stack: interest, amortization, core banking integration
What trips people up: Inclusive day count; treating interest as charged mid-cycle
5. Client's own interviews
Run by: The client
Tests: Culture fit and the client's own tests
1. "Are you a person I'd like to work with?"
The first interview isn't technical. I really care about enjoying spending time with the people we work with, and this conversation cuts roughly half of candidates.
2. A take-home coding test in their primary language
Next is a take-home on TestDome, tailored to the candidate's primary language. A Java engineer gets a Java test. It's unpaid, takes about 30 minutes, and AI tools aren't allowed. What TestDome really catches is people who take too long to solve the problem. That generally means they don't understand it.
3. The fintech business case
We give the candidate a real fintech business problem and ask them to solve it. We're checking that they understand the business, and that they actually care about the type of work they'd be assigned. One question we use is below.
4. The technical case, in the tech of their choice
Then we have them solve that kind of problem in code, in whatever stack they're strongest in. The cases often mirror real work: interest calculations, amortization schedules, core banking integrations.
5. The client's own interviews
The candidates who pass all four go to the client, who runs their own interviews: culture fit, their own coding or technical tests, or both. Clients pick.
If you'd rather start with engineers who've already passed the first four, see how staff augmentation works.
The loan portfolio question
There are 100 loans in a loan portfolio. We charge $15 in interest per loan. If there's a 20% default rate, is this portfolio making money or losing money? How much?
It sounds like a word problem. It's really a test of whether the candidate asks questions before computing.
A common wrong answer: "+$1,200"
20% of 100 loans default, so 80 loans pay $15 each, so the portfolio earns $1,200. The hidden assumption is that when a loan defaults, you only lose the interest. You don't. You also lose the principal, the money you lent.
The strong answer starts with questions
Strong candidates ask before they calculate: What does "default" mean here? What's the collections process? Are there any recoveries after default? How big is each loan?
When they ask, we tell them: each loan is $100, and assume you lose all principal and interest.
Weak answer: first move: Computes immediately; math: 80 × $15 = +$1,200; verdict: "Making money".
Strong answer: first move: Asks what "default" means, about recoveries and loan size; math: +$1,200 interest − (20 × $100) principal = −$800; verdict: "$800 down".
The 20 defaulted loans never pay their $15 either, so the portfolio is $800 down, not $1,200 up. That's a $2,000 swing on a portfolio that lent out $10,000.
The common trip-up isn't the subtraction. It's not asking enough upfront about what default means.
The technical case: credit card interest
For the technical round, a common case is credit card interest. We expect people to know and understand these concepts, and I point them to the U.S. Bank explainer on how credit card interest works. The math itself is simple: APR divided by 365 (or 360, per the card's terms) gives a daily rate, applied to each day's balance. Many issuers calculate interest daily (CFPB), and it typically compounds daily (U.S. Bank).
The tricky part is that interest accrues daily but only posts at statement close. Ask your card company mid-statement what interest you've been charged and the answer is zero. Ask what you'd need to pay off the card today and the answer includes interest accrued so far. So the system has to know accrued interest up to today, for payoff quotes and balances, without posting it until the right moment each month. And the grace period decides whether it posts at all: pay the statement balance in full by the due date and you generally aren't charged interest on new purchases. Grace usually covers purchases only, and losing it typically means interest from each purchase date (CFPB on grace periods).
Candidates who blur the two haven't modeled how the product works.
Interest builds daily but isn't charged until the statement closes on April 30: $33.00 if a balance is carried, $0.00 with the grace period.
The other classic trip-up is the day count. April 1 through April 30 is 30 days, not 29. Subtract the dates and you're a day short: on $2,000 at 20% APR, $31.90 instead of $33.00. And pick a rounding rule: our example rounds each day's interest to the cent ($1.10 a day); rounding once at the end would give $32.88. Never use floating point for money (Fowler's Money pattern).
A short illustration in Java:
import java.math.BigDecimal;
import java.math.RoundingMode;
import java.time.LocalDate;
import java.util.Map;
import java.util.NavigableMap;
import java.util.TreeMap;
/**
* Illustration only: simple daily interest, each day's amount rounded to the cent,
* no daily compounding.
* Real issuers differ (many compound daily); the cardholder agreement defines the method.
*/
public final class StatementInterest {
private StatementInterest() {}
/**
* Interest accrued from cycleStart through asOf, inclusive.
* Used for payoff quotes; not posted.
*
* @param balancesFrom balance in effect from each date onward
* (absolute balances, not deltas)
* @param apr annual rate as a fraction, e.g. 0.20 for 20%
*/
static BigDecimal accruedToDate(LocalDate cycleStart, LocalDate asOf,
BigDecimal openingBalance,
NavigableMap<LocalDate, BigDecimal> balancesFrom,
BigDecimal apr, int daysInYear) {
BigDecimal accrued = BigDecimal.ZERO.setScale(2);
// Inclusive: Apr 1 through Apr 30 is 30 days, not 29.
for (LocalDate d = cycleStart; !d.isAfter(asOf); d = d.plusDays(1)) {
Map.Entry<LocalDate, BigDecimal> entry = balancesFrom.floorEntry(d);
BigDecimal balance = (entry == null || entry.getKey().isBefore(cycleStart))
? openingBalance : entry.getValue();
// A credit balance earns the cardholder nothing;
// don't let it offset interest.
BigDecimal owed = balance.max(BigDecimal.ZERO);
// Round each day's interest to the cent (RoundingMode.HALF_UP).
// Issuers vary; the agreement decides.
BigDecimal dailyInterest = owed.multiply(apr)
.divide(BigDecimal.valueOf(daysInYear), 2, RoundingMode.HALF_UP);
accrued = accrued.add(dailyInterest);
}
return accrued;
}
/** Runs once, at statement close. Grace period intact means no interest posts. */
static BigDecimal postAtCycleClose(LocalDate cycleStart, LocalDate cycleEnd,
BigDecimal openingBalance,
NavigableMap<LocalDate, BigDecimal> balancesFrom,
BigDecimal apr, int daysInYear,
boolean graceApplies) {
if (graceApplies) {
return BigDecimal.ZERO.setScale(2);
}
return accruedToDate(cycleStart, cycleEnd, openingBalance, balancesFrom,
apr, daysInYear);
}
public static void main(String[] args) {
LocalDate start = LocalDate.of(2026, 4, 1);
LocalDate end = LocalDate.of(2026, 4, 30);
BigDecimal apr = new BigDecimal("0.20");
BigDecimal opening = new BigDecimal("2000.00");
NavigableMap<LocalDate, BigDecimal> noChanges = new TreeMap<>();
// Apr 15: nothing has posted, but a payoff quote needs this. Prints 16.50.
LocalDate apr15 = LocalDate.of(2026, 4, 15);
System.out.println(accruedToDate(start, apr15, opening, noChanges, apr, 365));
// Apr 30, carrying a balance: interest posts. Prints 33.00.
System.out.println(postAtCycleClose(start, end, opening, noChanges,
apr, 365, false));
// Apr 30, grace period intact: nothing posts. Prints 0.00.
System.out.println(postAtCycleClose(start, end, opening, noChanges,
apr, 365, true));
}
}
For April, that prints 16.50 accrued through April 15 (posted so far: zero), 33.00 posted at close when the cardholder is carrying a balance, and 0.00 when the grace period applies. It isn't production code (no daily compounding, no trailing interest, no separate cash-advance balance), but it shows the instincts that matter: BigDecimal, an inclusive day count, explicit rounding, and a clear line between accrued and posted.
How to vet LatAm developers' English and written communication
Every LatAm vetting guide mentions English, and most cite country rankings. The EF English Proficiency Index 2025 puts Argentina at #26 globally ("High" proficiency), Uruguay at #34, Brazil at #75, Colombia at #76 and Mexico at #103. That measures the general population of test-takers, not senior engineers, so test the individual.
Written English matters most, because a distributed team runs on PR descriptions, ticket comments and incident notes. A simple test is to ask for a short written explanation of something money-related for a non-engineer, such as why the loan portfolio above is losing money. Grade it for clarity, not accent. We assess English throughout every interview, and all of our interviews are done in English.
Time zones: work in yours
There's no minimum-overlap rule: our LatAm developers work in whatever US time zone the client wants (Eastern, Central, West Coast, or none in particular). Get the working hours in writing, in your time zone, and ask about local holidays before they surprise you. More on geography in how location affects staff augmentation.
Identity and background checks
Remote hiring has a fraud problem, and it isn't specific to Latin America. A Gartner survey of 3,000 job candidates found 6% admitted to interview fraud, either posing as someone else or having someone pose as them, and Gartner predicts that by 2028 one in four candidate profiles worldwide will be fake. The FBI's guidance for employers is practical: require video with an unobscured background, cross-check ID documents, and ask the person to wave a hand in front of their face, which can break AI-generated video. Ask any partner, including us, how they verify identity. We run criminal background checks and verify previous employment.
Take-homes and AI tools
There's a running argument about whether take-homes still mean much in the AI era; at least one LatAm staffing firm now calls them the weakest filter. Our answer: keep it short (about 30 minutes), keep AI out (we prevent it), and make it one stage of five, followed by a business case and a technical case, both live conversations. What happens after the hire matters too; our onboarding playbook covers the first days on a client team.
Red flags worth ending a process over
These follow from the questions above and from the sources cited in this post:
Answers the loan question without asking a single question first.
Counts a 30-day cycle as 29 days and can't see why it matters.
Uses floating point for money.
Asks for production customer data or broad access by default.
Avoids video or an ID check, or the location story shifts.
Can't explain their own take-home.
Even with a partner's filter, run your own interview
Our screens are just our part. You should still interview on your own bar, and use it to test the domain your product actually needs. If you don't have a format, a simple one: have them walk through a past system that touched money, ask one domain question like the loan portfolio or an interest calculation, get a few written sentences explaining a decision, and leave time for their questions.
If you're a non-technical founder, bring in someone who can run the domain part with you: your CTO, a trusted engineer, or a fractional product leader. That's part of what we do in product consulting.
FAQ
How do you vet nearshore developers for a fintech team?
Vet in stages. First decide whether you'd want to work with the person, then test core coding skill in their main language, then test whether they understand how the business makes and loses money, then have them code money logic such as interest or amortization. Check written English, working hours, identity and employment history, and always run your own final interview.
How do you vet Latin American developers?
The same way you'd vet any senior engineer, plus two checks that matter more at a distance: written English, tested with a real writing task rather than a country ranking, and working hours, agreed in writing in your own time zone. Country English rankings measure the general population, not engineers, so test the individual.
What questions should you ask a fintech developer in an interview?
Ask questions that involve money going wrong. A loan portfolio with defaults shows whether they ask about principal and recoveries before computing. A credit card interest calculation shows whether they handle day counts, rounding and when interest posts. Strong candidates ask clarifying questions before writing any code.
What does a 3% acceptance rate mean?
At Amplify, it means that of every 100 engineers who apply, the field narrows to 40, then 18, then 8, then 3, before any client interview. A pass rate tells you little on its own, so ask any partner what each stage tests.
Should you still interview developers a partner has already vetted?
Yes. A partner's screens are only their part. At Amplify, clients run their own interviews with their own questions and bar, and that final stage is their own filter. Use it to test the domain your product actually needs.
Do you allow AI tools on the coding test?
No. AI tools aren't allowed on our 30-minute TestDome take-home, and we prevent their use. The live cases that follow show whether the understanding is real.
How long does it take to vet and hire a nearshore developer?
Our published timeline is a scoping call on day 0, a candidate slate with code samples by day 2, interviews around day 5, and a first commit around day 10.
Want engineers who've already passed our four screens?
If you're building lending, deposit or payments products and want senior Latin American engineers who've cleared these screens before you meet them, here's how our staff augmentation works. You still interview, and you still pick. Or just get in touch.
Peter Hwang is the founder and CEO of Amplify Tech Labs. He's spent 20 years as a product manager, mostly at digital-only startups that originate and service financial products, and now places senior Latin American engineers with US fintechs and works as a fractional CPO.