A US fintech, mid-Series B, was building a real-time payments service handling card authorizations. They needed a senior Golang engineer with payments-rail experience — someone who understood the latency and idempotency demands of card auth at the network edge. Their existing backend was Java; the Go service was a greenfield project for performance reasons (Go's runtime characteristics fit the latency budget better than the JVM under their load profile). The hire would be the senior Go engineer on a 2-person team building this service in parallel with the rest of the org continuing on Java.
Go + payments is one of the narrowest specialty intersections in backend hiring. Most senior Go engineers have come up through infrastructure roles (Kubernetes, observability, networking) — not payments. Most payments engineers are on Java or Python. The candidates who sit in the intersection are usually employed at firms that have already made the Java-to-Go transition — Stripe, Adyen, Block — and they don't show up on the active market. The client knew this and had been searching for 9 weeks through their internal recruiting and one external agency, with one offer rejected and three failed live codings. The deadline was firm: the service had to go live before a Q3 partnership integration. The CTO came to us with a stipulation: don't waste my time on generic Go engineers. He'd rather see a small high-signal shortlist than a long one.
We started by narrowing the funnel aggressively before sourcing externally. The internal database surfaced 89 candidates with verified production Go experience at scale (verified through prior employment metadata at firms running Go in production). We added 228 external candidates from LinkedIn and from two Go-specific communities (Gophers Slack, golangbridge.org). Total funnel: 317. AI scoring weighted heavily on Go-production signal plus any payments-firm employment history. 142 passed. Senior recruiter screen surfaced 38 candidates with substantive payments-domain exposure (defined as: shipped a service that handled card auth or settlement at a firm where that was the primary product, not as a side feature). 18 of those completed a 4-hour Go written assignment: design an idempotent payments-API endpoint with at-least-once semantics, Postgres + Redis backing, p99 under 80ms simulated. 8 cleared. The 8 each got 90 minutes with the client's CTO. The winning candidate (Bengaluru-based, 6 years experience, previously at a Singapore payments firm running Go in production) walked through the latency budget with the right trade-offs called out — the other three finalists were strong on Go but missed the idempotency layer detail.
Offer day 7. Accepted within 24 hours. Started day 9 with onboarding compressed by pre-provisioning during the offer-acceptance window. First service endpoint shipped to staging week two of the engagement. The full real-time payments service went live two weeks ahead of the Q3 partnership deadline; first-month transaction volume came in clean (zero p99 latency violations, zero idempotency-related reconciliation events). The engineer became the de-facto Go tech lead for the team's continued Go expansion (a second Go service started six months later). 30% conversion lift on the partnership product post-launch versus the prior Java-based attempt — partly because of better latency, partly because of cleaner error handling. The engineer is still with the team 14 months in.
Two-hour call with the client's CTO. Reviewed the service's latency budget (p99 under 80ms), the auth-retry semantics, and what 'good' looked like for the existing team. Locked our rubric.
Talent OS's internal database had 89 verified Go-at-scale candidates; we sourced an additional 228 from LinkedIn + niche Go communities. Final applicant pool: 317.
18 candidates completed a 4-hour Go assignment: design an idempotent payments-API endpoint with at-least-once semantics. 8 cleared. The CTO ran 90-minute live coding with the top 4.
Offer day 7. Started day 9 (compressed onboarding to hit the project timeline). Shipped the first service endpoint to staging in week two.
Niche-stack searches (Go + payments, Kotlin + reactive, SAP BASIS + S/4HANA migration) should always start with internal-database narrowing, not external sourcing. The candidates who fit the intersection are usually known to us already from prior screening rounds — they passed our bar at a previous engagement and stayed in the database. Skipping the internal-database step and going straight to LinkedIn outreach burns the client's time on candidates who look right on paper but don't have the verified depth. Second lesson: for greenfield projects where the new hire will be the senior on the team, the founder/CTO should sit in on at least one live coding round. The cultural-fit and decision-making signal from a 90-minute working session matters more than reference calls for a sole-senior role.