BullionVault course · mission

mission

Mission

Why this course exists, and what being ready actually means.

Walk into the BullionVault Java Developer interview able to build and debug a commodities trading service out loud, under observation, without flinching.

The concrete goal

Tom has a live pairing / coding test for the Java Developer role at BullionVault (via Client Server Ltd), expected within 1–2 weeks of 2026-08-13. The success condition is not "knows Java" — it is:

> Given a half-working commodities service, find what is wrong with it, say why > it is wrong while someone watches, and drive the fix test-first.

Why this role, why this domain

BullionVault is the world's largest online marketplace for gold, silver, platinum and palladium — $7.9bn under custody, 130,000 users, 175 countries (from the spec). That scale changes what "correct Java" means:

• Money is not a double. Every rounding decision is somebody's money.
• Quantities are not floats either. Orders are placed in kilograms, traded in increments as small as 1 gram, while the spot market quotes per troy ounce — and that conversion does not terminate in decimal.
• Two clients can hit the same offer at the same millisecond. The order board is a shared mutable resource.
• Oracle is the system of record, so transaction boundaries and isolation are correctness, not performance trivia.

Their stack, verbatim from the spec: Java 25, Kotlin, Scala, TypeScript, Spring, Oracle, Redis, Postgres, React, Kubernetes, Docker, Linux, AWS, React Native.

Their stated responsibilities: solving complex problems with simple solutions; writing high-quality code; peer code review. All three are pairing-observable behaviours, not CV lines — the course is built to rehearse them.

What "done" looks like

Tom can, cold, in front of an interviewer:

1. Spot a money/quantity representation bug in unfamiliar Java and name the failure mode before running anything.
2. Convert troy-ounce spot prices to per-kilogram execution prices without throwing ArithmeticException and without silently losing pennies.
3. Implement price–time priority matching with partial fills, test-first.
4. Explain why a read-modify-write on shared state loses updates, and offer at least three fixes at different layers (JVM, Spring, Oracle).
5. Talk continuously and usefully while typing.

Non-goals

• Kotlin, Scala, React Native — listed on the stack but not what a Java developer is tested on. Ignore unless the interview signals otherwise.
• LeetCode-style algorithm puzzles. This is a domain-modelling shop, not a puzzle shop; the spec asks for simple solutions to complex problems.

Status

• Mission set: 2026-08-13
• Interview date: not yet fixed — update when known.