Concurrent Discounted Card Purchases
Reported by candidates from Brex's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Brex reportedly put this one in front of candidates in September 2026, and the trick is that there's no fancy structure at all. It's a simulation over a tiny fixed-size state: five gem balances, five owned-card counts, and one version number. If you've got a Brex OA coming, expect a wordy prompt that hides a simple loop. Read the three return codes carefully, because that's where people lose points. If you blank on the order of checks during the live assessment, StealthCoder runs invisibly as a safety net and gives you the walkthrough.
The problem
A player has gem balances in the fixed color order [B,W,G,R,Y]. Each row cards[i] is [rewardColor,costB,costW,costG,costR,costY], where rewardColor is an index from 0 through 4. The player may own multiple copies of a card. Before a purchase, each already-owned card of color c discounts that purchase's cost in color c by one gem, but a cost never falls below zero. Each request is [expectedVersion,cardIndex]. Requests are serialized in array order for this player. Return -1 for a version conflict, 0 when the discounted card is unaffordable, and 1 after an atomic purchase. Only a successful purchase deducts gems, adds the card, and increments the version. Return all request status codes followed by the final version, five final gem balances, and five owned-card counts, all in [B,W,G,R,Y] order. Function processPurchases(gems: int[], cards: int[][], requests: int[][]) → int[] Examples Example 1 gems = [3,3,0,0,0] cards = [[0,2,1,0,0,0],[1,2,2,0,0,0]] requests = [[0,0],[0,1],[1,1]] return = [1,-1,1,2,0,0,0,0,0,1,1,0,0,0] The first purchase succeeds and advances the version to 1. The stale second request conflicts. The last request uses the blue-card discount and succeeds. Example 2 gems = [0,0,0,0,0] cards = [[4,1,0,0,0,0]] requests = [[0,0]] return = [0,0,0,0,0,0,0,0,0,0,0,0] The card is unaffordable, so every part of the player state remains unchanged. Constraints gems.length = 5 and 0 <= gems[c] <= 10^9. 1 <= cards.length, requests.length <= 10^5. Every card row has six integers; its reward color and every request card index are valid. Every base cost is between 0 and 10^9. Every expected version is between 0 and the number of requests.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The hinge is plain arrays of length five. Keep gems[5], owned[5], and an int version. For each request, check the version first. If expectedVersion doesn't match, push -1 and touch nothing. Otherwise compute the discounted cost per color as max(0, cost[c] - owned[c]). If any discounted cost exceeds gems[c], push 0 and change nothing. If all five pass, subtract, increment owned[rewardColor], bump the version, push 1. Each request is O(5), so the total is O(n) with n up to 10^5. The pitfalls: applying the discount from the card's own reward (it isn't owned yet), deducting gems before the full affordability check, and forgetting the output order: statuses, version, gems, then owned counts. Values reach 10^9, so use 64-bit if your language needs it. StealthCoder is the hedge if the live OA rattles you on the output layout.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Concurrent Discounted Card Purchases 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 by an Amazon engineer who passed his OA cold and still thinks the filter is broken.
Get StealthCoderYou've seen the question.
Make sure you actually pass Brex's OA.
Brex reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Concurrent Discounted Card Purchases FAQ
How hard is the Brex Concurrent Discounted Card Purchases problem really?+
Easy on algorithm, tricky on reading. There's no graph, DP, or heap. It's a straight simulation with five-element arrays. Most failures come from misordered checks or a wrong output layout, not from complexity. Write the three cases down before coding.
What's the trick to getting the discount right?+
Discount each color by the count of owned cards of that color, floored at zero. Use the owned counts as they are before this purchase. The card you're buying doesn't discount itself. Compute all five discounted costs first, then compare against gems.
Does a failed purchase change the version?+
No. Only a successful purchase deducts gems, adds the card, and increments the version. A version conflict returns -1 and an unaffordable card returns 0, and both leave the full state untouched. Check the version first, then affordability.
What should the returned array look like?+
Request status codes in order, then the final version, then five gem balances, then five owned counts, all in B, W, G, R, Y order. With three requests, Example 1 gives three codes plus 11 more values, 14 in total. Count your length against the examples.
How do I prepare for this in 48 hours?+
Practice writing state-machine simulations with strict ordering rules. Re-derive both examples by hand, especially the stale-version case. Then code it with a helper that computes discounted cost, and test an all-zero-cost card plus a cost smaller than the discount.