smallcase-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
A portfolio product converts an intention — "hold these instruments in these weights" — into a set of orders placed through brokers it does not own, then keeps proving that what the customer holds matches what was intended. Machine coding rounds in the style of smallcase are built on that conversion, and it is a genuinely distinct problem from either broking or payments.
The interesting mechanics are weight arithmetic that must total exactly, a diff between current and target holdings, and a batch of orders that can partially succeed. This page covers the reported format, what evaluators weight, and Gronex repositories that train the same diff-and-reconcile discipline.
What a smallcase-style machine coding round looks like
A typical statement asks for a rebalance service: given a basket definition with target weights and a customer’s current holdings and cash, compute the buy and sell quantities that move them to the target, then execute them as a batch and report the outcome. Constraints are concrete — whole-share quantities only, a minimum order value, weights summing to exactly 100 per cent.
The rebalance diff is where correctness lives. Because quantities are integral and prices are not, the naive computation leaves residual cash and weights that do not quite match, so the statement always fixes a rule — floor the quantities, keep the remainder as cash, never exceed available cash — and the round checks that you applied it rather than something that looked equivalent. Selling before buying, so the proceeds fund the purchases, is the sequencing constraint most often missed.
Partial execution is the second half and the more interesting one. Four of six orders fill; the portfolio is now in an intermediate state that is neither the old basket nor the new one. A correct design records the rebalance as its own entity with per-order status, is resumable, and can recompute the remaining diff instead of replaying the original plan against changed holdings. Rounds in this style ask what a second rebalance triggered while the first is incomplete should do.
How you’re evaluated
Exact weight arithmetic
Targets that sum to the stated total, integral quantities under the declared rounding rule, and residual cash accounted for rather than lost.
Correct order sequencing
Sells before buys where proceeds fund purchases, and no plan that spends cash the customer does not have.
Resumable rebalances
The rebalance as a first-class entity with per-order status, safe to resume, and recomputing the diff rather than replaying a stale plan.
Holdings reconciliation
A comparison between intended and reported holdings that detects drift and proposes a correction instead of overwriting.
Common mistakes that fail this round
- Computing target quantities with floats and shipping fractional shares the broker cannot accept.
- Placing buys before sells and failing on insufficient cash even though the plan was funded.
- Treating a batch as atomic when the downstream is not, leaving no representation for four-of-six filled.
- Replaying the original plan on resume, so already-executed orders are placed a second time.
- Overwriting local holdings with the broker’s view on mismatch instead of reporting the drift.
Quick tips for the room
- Make the diff a pure function of (holdings, targets, prices, cash) and test it alone.
- Sequence sells first and say why out loud.
- Store the plan with per-order status; resume from status, not from scratch.
- Report drift; never silently overwrite the customer’s holdings.
How to prepare
Write the diff function first and test it against awkward inputs: a weight change that requires selling one instrument entirely, a target that cannot be met with available cash, and a price that makes the whole-share rule bite. Then wrap it in a rebalance entity with per-order status and make resume recompute rather than replay. That pair is the round.
The repositories below drill the same muscles: the connector reconciliation problem is intended-versus-reported state, the pandas join problem is the fan-out bug that corrupts holdings joins, the SQL window problem (free) is per-portfolio aggregation done correctly, the queue-consumer problem is the partial-failure retry path, and the ledger problem is the cash accounting underneath.
Practice problems in the smallcase-style round format
Each is a real backend repository with a failing test suite — the same working-code standard the round applies. Open the brief and read the full problem, no signup required.
Connector Record Reconciliation
Intended state versus an external system’s truth: matching, drift detection, and a safe resync path.
Open the challenge →Join Fan-out & Deduplication
The grain bug that silently doubles holdings when a join is not unique on the key you assumed.
Open the challenge →SQL Window Partition Bug
Per-portfolio aggregation that leaks across partitions — the wrong-window bug. Free to try.
Open the challenge →Queue Consumer Idempotency & Retry
Partial-batch failure handled properly: idempotent retries, backoff, and a dead-letter path.
Open the challenge →Payment Ledger Consistency
The cash side of a rebalance: append-only entries that still reconcile after a half-executed batch.
Open the challenge →FAQ
Are these actual smallcase interview questions?
No. They are Gronex originals in the style of portfolio and wealth-tech rounds — the kind of problem asked in rounds like smallcase’s. Gronex is not affiliated with smallcase.
Do I need markets knowledge for this round?
Only the vocabulary. Weights, holdings, and prices are all supplied; what is graded is the diff arithmetic under the stated rounding rule and your handling of a batch that partially succeeded.
Why is partial execution emphasised so much?
Because it is the state the real system spends time in and the state candidates rarely model. A rebalance entity with per-order status is a small amount of code that changes the entire conversation.
What should I do about fractional quantities?
Apply the statement’s rule exactly — usually floor to whole shares and keep the remainder as cash — and assert the invariant that spend never exceeds available cash. Inventing a smarter allocation than the one specified is a common way to fail tests.
Related
Gronex is not affiliated with, endorsed by, or sponsored by smallcase. All company names and trademarks belong to their respective owners. The problems on this page are Gronex originals written in the style of such interview rounds — not actual interview questions from smallcase.