go test ./... then go test -race ./... · RN → npm test (or npm run watch)~/codeaza-interviews/2026-08-09/<candidate>/. Tests start red; they implement the // TODOs.Score each on: Availability ✅/❌ · CV-verified ✅/⚠️/❌ · Code 1–5 · Communication 1–5 · Wallet-fit 1–5 → verdict: yes / maybe / no. Rank as you go; don't anchor on the first person.
| Time | Segment | What to do |
|---|---|---|
| 0–3 | Warm-up | Put them at ease. "Walk me through what you're building right now." |
| 3–8 | Logistics gate | Confirm the deal-breakers first, no negotiation: start within 2 weeks · fully remote · 6am PKT start (AU overlap) · rate in band. Hard no → keep it short. |
| 8–15 | Verify the CV | Probe the 2–3 specific claims on their card. Ask how, not whether — real builders give texture, fakers get vague. |
| 15–38 | Live coding | Share the repo. "Implement the TODOs so the tests pass — think out loud." Run the tests as they go. These are senior-level tasks (see below), not toy CRUD — watch: do they read the tests first? handle edge cases? reason about failures? |
| 38–43 | Design chat | One real question (see bank below) about working in a codebase they didn't write / money-movement correctness. |
| 43–45 | Close | Their questions + "we'll come back this week." Don't commit on the call. |
The exercises are deliberately senior — this is what they must handle
| Repo | What it really tests (beyond "make it work") |
|---|---|
| Go — wallet ledger | Idempotency (same key applied exactly once — the core payments concept), atomic transfers with an append-only double-entry ledger, and correctness under concurrency — incl. the same idempotency key fired from 200 goroutines and cross-transfers under -race. A mid dev makes the happy path pass; a senior gets idempotency + atomicity right under load. |
| RN — wallet client | Optimistic updates with rollback (pending → confirm/fail, immutably), and a single-flight token refresh: when many requests 401 at once, refreshToken() must run exactly once and all retry (a refresh stampede is the classic mid-level miss). Plus money formatting. |
What "good" looks like
Transfer atomic. RN: immutable reducer + a shared in-flight refresh promise.Warm-up / signal
Logistics gate (ask first, no negotiation)
Design / architecture (38–43 min)
Close
Per-candidate CV-verification questions are on each card below — those are the ones that separate real from inflated.
Ask 2–3 that fit the candidate. Under each is what a strong answer covers — if they hit most of it unprompted, that's a senior. Vague/buzzword answers without the mechanism = downgrade.
Go / backend
"A client retries a transfer request (timeout). How do you guarantee it isn't applied twice?"
Strong answer: Idempotency keys — client sends a unique key per operation; server records applied keys and returns the original result on a replay. In a DB: a unique constraint on the key + the whole operation in one transaction (or a dedicated idempotency table). Never "check-then-act" without a lock. In memory: a seen-set guarded by the same lock as the mutation. (This is exactly the Go live test.)
"Two concurrent transfers A→B and B→A — how do you avoid deadlock and keep balances correct?"
Strong answer: a single serialized writer / one lock (simple + correct on one node), or per-account locks acquired in a canonical order (e.g. sorted by id) so no cycle forms. In Postgres: a transaction with SELECT … FOR UPDATE in consistent order, or serializable isolation + retry. Never hold a lock across I/O.
"Why not store money as a float?"
Strong answer: floats lose precision (0.1+0.2≠0.3). Use integer minor units (cents) or a decimal type; all arithmetic in integers; format only at the edge.
"How do you keep an audit trail and reconstruct balances?"
Strong answer: append-only double-entry ledger (debit + credit per movement, summing to zero); balance = sum of entries (or a maintained balance + the journal). Immutable history; reconcile against provider statements. (The Go test's Entries() models this.)
"Reliably notify a payment provider / publish events?"
Strong answer: outbox pattern — write the event in the same DB transaction as the state change; a worker publishes it; consumers are idempotent → at-least-once + idempotency = effectively once.
React Native / mobile
"Where do you store the auth token / sensitive financial data on device?"
Strong answer: the secure enclave — react-native-keychain (iOS Keychain / Android Keystore), not AsyncStorage or plaintext MMKV for secrets. Biometric gate; short-lived access token + refresh token, rotated. SSL/cert pinning, no secrets in logs, root/jailbreak detection for high-risk flows.
"User taps Send on a slow network — how do you keep the UI snappy AND correct?"
Strong answer: optimistic update — show the debit immediately as a pending txn, then confirm or roll back on the server response. Idempotency key on the mutation so retries don't double-charge. Offline queue that flushes in order with backoff; cache via React Query / RTK Query. (This is the RN reducer test.)
"The token expires and 5 requests 401 at the same time — what happens?"
Strong answer: single-flight refresh — the first 401 starts one refresh; all in-flight requests await the same promise, then retry with the new token. Prevents a refresh stampede / refresh-token invalidation; if refresh fails → log out. (This is the RN API-client test.)
"Keep a long transactions list at 60fps?"
Strong answer: FlashList/virtualization, memoized rows + stable keys, no inline objects/fns in render, heavy work off the JS thread, Hermes, MMKV for fast reads, and the New Architecture (Fabric/TurboModules/JSI) to cut bridge overhead.
"How would you structure the RN app on our existing Go backend?"
Strong answer: a typed API layer (generated from the backend's OpenAPI), React Query for server state + a small store (Zustand/Redux) for UI state, feature-based folders, a secure-storage module, retry/offline boundaries, Detox e2e, and shared, tested money-format/validation utils.
System design — if there's time (either role)
"Sketch the wallet MVP end-to-end."
Strong answer: RN app → Go API (JWT + refresh) → Postgres double-entry ledger. Transfer endpoint is idempotent (key + one DB tx + row locks). Payment provider via signed webhooks + outbox; a reconciliation job. Observability (Sentry, structured logs, metrics). Encrypted at rest/in transit, least-privilege, minimise PCI scope (tokenise cards, never store the PAN).
Screening: ~5 yrs, claims all-Go + DeFi/fintech (Vaultera, Bout-it AU). GitHub is real but small/toy — production depth unproven. Already works AEST hours (plus). Notice + rate were blank in the CV.
Watch the concurrency test (go test -race ./...): a real Go dev reaches for a mutex and keeps Transfer atomic. Green + clean = genuine. Struggles with the mutex = the "senior Go" claim is thin.
Screening: PUCIT (T2). Strong RN — Turbo Modules / JSI native bridging + a crypto wallet (MetaMask) MVP. No GitHub on file → live code is the verifier.
Watch the immutable reducer and the token-refresh async — his level shows fast. No GitHub means the code IS the evidence.
Screening: NUST (T1). Writes custom Swift/Kotlin native modules, built a fintech trading app, verified GitHub. Reads a bit backend-heavy.
Strong profile — check the code matches the NUST + verified-GitHub signal. If he drifts to backend framing, confirm real RN depth.
Screening: NUST (T1), best all-round — real wallet + payments (Paystack + Fasset crypto, ~1k txns/day), deep native (Fabric/TurboModules/MMKV), verified active GitHub, immediate. Ask is 500K (top of band, but affordable — you cleared this).
This is the one to close if he delivers. Be ready to move fast — confirm immediate start and lock next steps internally.
Screening: Actually built a wallet + POS + PCI-DSS (Kuickpay) — the closest real wallet experience in the whole pool. 1-wk notice. Weak university + no GitHub → live code is decisive.
If the domain experience is real and he codes cleanly, he's a serious contender despite thin pedigree. Great CV + weak live code = the CV was the sell; downgrade.