Risk Limits and Inventory Skew
Reported by candidates from Millennium's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Millennium reported this one in September 2026, and it looks easy until you read the last paragraph. Quote a market-making request: accept, widen, or reject, based on liquidity-scaled inventory limits. There's no clever algorithm here. It's a simulation with ordered rules and a precision trap. The inputs are decimals with up to seven digits, and the output must round half upward to six places. If you blank on the exact arithmetic, StealthCoder runs invisibly during the live assessment as a safety net. Know the trap first.
The problem
Decide whether to accept, widen, or reject one market-making quote request while respecting liquidity-scaled inventory limits. Use these values: hard = baseLimit * liquidityScore soft = softFraction * hard signedQuantity = -quantity for BUY and +quantity for SELL projected = currentInventory + signedQuantity Apply the rules in order: If abs(projected) > hard, return ["reject", "null"]. Otherwise compute skew = -skewCoefficient * currentInventory. The base BUY quote is reference + halfSpread + skew; the base SELL quote is reference - halfSpread + skew. If abs(projected) > soft, the action is widen and one extra halfSpread is added for BUY or subtracted for SELL. Otherwise the action is accept. Every decimal input is exact and has at most seven digits after the decimal point. Return a two-element string array [action, quote]. A non-rejected quote is rounded half upward to six decimal places and serialized with exactly six digits after the decimal point. Function decideRequest(currentInventory: int, side: String, quantity: int, reference: double, halfSpread: double, liquidityScore: double, baseLimit: int, softFraction: double, skewCoefficient: double) → String[] Examples Example 1 currentInventory = 0 side = "BUY" quantity = 100 reference = 100.0 halfSpread = 0.05 liquidityScore = 1.0 baseLimit = 50000 softFraction = 0.6 skewCoefficient = 0.0001 return = ["accept","100.050000"] The projected inventory is -100, which is inside both limits. Current inventory is zero, so skew is zero and the base BUY quote is 100.050000. Example 2 currentInventory = 300 side = "BUY" quantity = 50 reference = 100.0 halfSpread = 0.05 liquidityScore = 0.5 baseLimit = 1000 softFraction = 0.3 skewCoefficient = 0.001 return = ["widen","99.800000"] The hard and soft limits are 500 and 150. Projected inventory is 250, so the request is widened. Skew is -0.3; the base quote 99.75 receives one extra 0.05 on the BUY side. Constraints -10^9 <= currentInventory <= 10^9 side is either BUY or SELL. 1 <= quantity <= 10^9 0 < reference <= 2 * 10^8 and 0 <= halfSpread <= 10^6. 0.1 <= liquidityScore <= 1. 1 <= baseLimit <= 10^9 and 0 <= softFraction <= 1. 0 <= skewCoefficient <= 10^3. Each decimal input has at most seven digits after the decimal point. Every non-rejected quote is positive and at most 10^12.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The input size rules out nothing because there's no loop. It's O(1). The real constraint is exactness. Values reach 10^9 inventory, 2*10^8 reference, and 10^3 skew coefficient, so skew can hit 10^12 and floating-point doubles will drift. Parse every decimal as an exact value, scale by 10^7, and use BigInteger or BigDecimal. Compute hard, soft, and projected, then check rules in order. Reject first, so return ["reject","null"] with the string null. Widen if abs(projected) exceeds soft. Note BUY adds the extra halfSpread and SELL subtracts it. BUY signs the quantity negative, which is easy to flip. Round half up, not banker's rounding, and always print six digits. Parse from the string form of the doubles, not raw binary values. If the exact decimal handling stalls you mid-assessment, StealthCoder is the hedge.
The honest play: practice the pattern, and have StealthCoder ready for the one you didn't see coming.
You can drill Risk Limits and Inventory Skew cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. Built for the candidate who saw this exact problem leak two days before his OA and wondered if anyone had a play.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Millennium's OA.
Millennium reuses patterns across OAs. Built for the candidate who saw this exact problem leak two days before his OA and wondered if anyone had a play. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Risk Limits and Inventory Skew FAQ
What's the trick in the Millennium Risk Limits and Inventory Skew question?+
Exact decimal arithmetic. The logic is a few ordered if-checks, but comparisons at the boundary (abs(projected) equal to soft or hard) break with floating point. Use BigDecimal or scaled integers, and compare strictly greater than, as the rules say.
Why does BUY reduce inventory in this problem?+
The statement defines signedQuantity as -quantity for BUY and +quantity for SELL. Example 1 confirms it: a BUY of 100 from zero gives projected -100. Copy that sign convention exactly. Don't apply real-world intuition about who is buying.
How should I round the quote?+
Round half upward to six decimal places, then print exactly six digits. With BigDecimal use RoundingMode.HALF_UP and setScale(6). Avoid String.format on doubles, since it can round differently and the inputs can be large, up to 10^12.
What does a rejected request return?+
Return the two-element array ["reject","null"] where the second element is the literal string null. Check this rule first, before computing skew or quotes. The hard limit is baseLimit times liquidityScore, compared against abs(projected).
How do I prepare for this in 48 hours?+
Write the function once with BigDecimal and test both examples by hand. Add edge cases: projected exactly at soft, exactly at hard, zero softFraction, and a SELL widen. This is simulation, so careful reading beats algorithm study.