Chargebee-Style Machine Coding Round: Format, Tips & Practice Problems
Written and reviewed by Sahil Srivastav
Subscription billing is the rare domain where the hard part is arithmetic that has to be defensible. A customer upgrades eleven days into a monthly cycle, adds two seats, applies a coupon, and later cancels — and the invoice must be explainable line by line to a finance team. Machine coding rounds in the style of Chargebee live in exactly that space.
The second axis is lifecycle. Trials end, renewals run, payments fail and enter dunning, subscriptions pause and resume. Each of those is a state transition with money attached, and the round grades whether your transitions and your arithmetic agree. This page covers the format, the evaluation criteria, and Gronex repositories with the same mechanics.
What a Chargebee-style machine coding round looks like
The common build is a subscription service with plan changes: create a subscription on a plan, change plans mid-cycle with proration, add or remove quantity, apply a discount, and generate the invoice. Statements are explicit about the proration policy — usually day-based credit for the unused portion and a charge for the remainder — because the whole point is whether you implement the stated policy exactly rather than an approximation you find intuitive.
Invoices are expected to be line-item structures, not totals. The reviewer wants to see a credit line for the unused old plan, a charge line for the new one, a discount line, and a total that is the sum of its parts in integer minor units. A design that computes a single number cannot answer "why is this ₹347?", and that question is asked more or less verbatim.
The lifecycle half brings idempotency in through the back door. A billing run for a given period must be safe to re-execute — the classic scenario is the job that crashed halfway — which means invoices are keyed by subscription and period, not created blindly. Dunning adds a retry schedule with state, and the follow-up commonly asks for pause-and-resume, which tests whether your cycle dates were derived or scattered.
How you’re evaluated
Proration exactness
The stated policy implemented to the minor unit, with a declared rounding rule and credits that never exceed what was charged.
Line-item invoices
Charges, credits, discounts, and taxes as separate lines whose sum is the total — so any amount can be explained.
Idempotent billing runs
Invoices keyed by subscription and period, so a re-run of a crashed job produces no duplicate charge.
Lifecycle transitions
Trial, active, past-due, paused, cancelled — legal transitions only, with dunning state that advances on a schedule.
Common mistakes that fail this round
- Computing proration as a single float multiplication and losing the audit trail with it.
- Producing an invoice total with no line items, which makes every follow-up question unanswerable.
- Creating invoices on each billing-run invocation, so a retried run bills the customer twice.
- Deriving the next renewal date by adding 30 days, then failing the month-boundary case the reviewer tests.
- Treating cancellation as deletion, leaving no record for the final prorated invoice.
Quick tips for the room
- Build invoices as lists of lines; compute the total last.
- Key invoices by (subscription, period) so re-runs are no-ops.
- Use a real date library for cycle arithmetic, never day counts.
- State your rounding rule aloud and apply it in exactly one place.
How to prepare
Implement one plan change end to end with line items and integers, then re-run your billing job twice in a test and assert that the second run changes nothing. Those two exercises cover most of the rubric. Add a discount and a quantity change afterwards, since both are near-certain extensions.
The repositories below map cleanly: the billing engine is the round itself, the coupon engine covers discount eligibility and stacking, the SaaS seat problem is quantity management with reclamation, the wallet problem drills refund and credit caps, and the validation problem (free) is a short, sharp reminder of the input rules a billing API needs.
Practice problems in the Chargebee-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.
Subscription Billing & Proration Engine
The round itself: mid-cycle plan changes, proration, idempotent invoicing, and dunning state.
Open the challenge →Coupon Application Engine
Discount mechanics: eligibility, stacking rules, caps, and redemption that burns exactly once.
Open the challenge →SaaS License Seat Allocation
Quantity as a concurrency problem: seats assigned, reclaimed, and never over-allocated against the licence.
Open the challenge →Wallet Transaction & Refund System
Credits, debits, and cumulative refund caps with a ledger that explains every balance.
Open the challenge →API Debugging: Validation & Error Envelope
Reject bad billing input at the edge with a consistent error shape instead of corrupting state. Free to try.
Open the challenge →FAQ
Were these problems asked at Chargebee?
No. They are Gronex originals in the style of subscription-billing rounds — the kind of problem asked in rounds like Chargebee’s. Gronex is not affiliated with Chargebee.
How precise does the proration math need to be?
Exact to the minor unit, matching the policy in the statement. Reviewers compute the expected number by hand and compare. Integer paise and one rounding helper are what make that survivable.
Is dunning usually part of the build?
More often part of the discussion. Knowing the shape — a schedule of retry attempts, a state per attempt, and a terminal action after exhaustion — is normally enough, and it is better spent time than a half-built implementation.
What makes billing rounds harder than they look?
Date arithmetic and re-runs. Month-end renewals, leap years, and a billing job that crashed after three of ten invoices are the three places where a confident-looking implementation quietly breaks.
Related
Gronex is not affiliated with, endorsed by, or sponsored by Chargebee. 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 Chargebee.