Delivery Cost Tracker with Effective-Dated Rates
Reported by candidates from Rippling's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The mistake that sinks a first attempt on this Rippling OA, reported September 2026, is recomputing old delivery costs when a rate changes. The problem says cost is finalized at record time, and people miss it. You're building a tracker with effective-dated driver rates, delivery recording, a pay cutoff, and two running totals. It's a design and simulation problem with a lookup inside. Nothing exotic, but the details bite. If you blank on the rate lookup or the money math mid-assessment, StealthCoder runs invisibly on screen and gives you a working solution as a safety net.
The problem
Build a delivery-cost tracker whose driver rates can change at specified effective times. Operation Format Process the rows of operations in order. Driver identifiers and timestamps are encoded as decimal strings. Return one formatted cost for every query operation, in query order. ["ADD_DRIVER", driverId, hourlyRate]: add a driver with an initial hourly rate effective from timestamp 0. ["UPDATE_DRIVER_RATE", driverId, newRate, effectiveTime]: add an effective-dated rate version. If the same effective time is updated again, the later operation replaces the earlier version. ["RECORD_DELIVERY", driverId, startTime, endTime]: record a delivery. Use the submitted rate version with the greatest effective time not after startTime. The delivery's cost is finalized now and is never revised by a later rate update. ["GET_TOTAL_COST"]: return the total cost of every recorded delivery. ["PAY_UP_TO", payTime]: mark every delivery with endTime <= payTime as paid. ["GET_UNPAID_COST"]: return the total cost of all currently unpaid deliveries. Cost Rules A delivery's cost is hourlyRate * (endTime - startTime) / 3600. Overlapping deliveries are billed independently. Format every returned cost with exactly two digits after the decimal point. Every judged delivery produces an exact cent value, so no additional rounding rule is needed. Function trackDeliveryCostsWithRateHistory(operations: String[][]) → String[] Examples Example 1 operations = [["ADD_DRIVER","1","12.00"],["RECORD_DELIVERY","1","0","1800"],["UPDATE_DRIVER_RATE","1","18.00","1000"],["RECORD_DELIVERY","1","1000","2000"],["GET_TOTAL_COST"],["GET_UNPAID_COST"]] return = ["11.00","11.00"] The first delivery uses the initial $12.00 rate and costs $6.00. The second starts when the $18.00 rate is effective and costs $5.00. Both remain unpaid. Example 2 operations = [["ADD_DRIVER","7","24.00"],["UPDATE_DRIVER_RATE","7","30.00","3600"],["RECORD_DELIVERY","7","0","1800"],["RECORD_DELIVERY","7","3600","7200"],["GET_TOTAL_COST"],["PAY_UP_TO","2000"],["GET_UNPAID_COST"]] return = ["42.00","30.00"] The two deliveries cost $12.00 and $30.00. Paying through timestamp 2000 marks only the first delivery as paid. Example 3 operations = [["ADD_DRIVER","3","10.00"],["UPDATE_DRIVER_RATE","3","20.00","100"],["UPDATE_DRIVER_RATE","3","30.00","100"],["RECORD_DELIVERY","3","100","460"],["GET_TOTAL_COST"]] return = ["3.00"] The later update replaces the earlier rate at timestamp 100. A six-minute delivery at $30.00 per hour costs $3.00. Constraints 1 <= operations.length <= 100000. 1 <= driverId <= 10^9, and every referenced driver has already been added. Rates are USD decimal strings from 0.01 through 1000000.00 with at most two fractional digits. 0 <= effectiveTime, startTime, endTime <= 10^9, startTime < endTime, and each delivery lasts at most 86400 seconds. An effective rate exists at every recorded delivery's start time, and the total cost fits in a signed 64-bit integer number of cents. Every judged delivery cost is an exact number of cents.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The core trick is per-driver rate history stored as a sorted list of effective time and rate pairs. On RECORD_DELIVERY, binary search for the greatest effective time <= startTime, compute the cost, and store it. Never touch it again. Same effective time on update means overwrite, so a map keyed by time plus a sorted structure works, or insert with a replace check. Keep money in integer cents. Parse the rate strings into cents, then cost in cents is rateCents * duration / 3600, which the problem guarantees is exact. Format at the end with two decimals. For PAY_UP_TO, keep deliveries in a min-heap by endTime, pop while endTime <= payTime, and subtract from the unpaid total. Pitfalls: floats, rate lookups using endTime, and updates arriving out of time order. If you freeze live, StealthCoder is the hedge that gets you a clean answer.
Drill it cold or hedge it with StealthCoder. Either way, don't walk into the OA hoping you remember the trick.
You can drill Delivery Cost Tracker with Effective-Dated Rates 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. Made for the candidate who got the OA invite this morning and has 72 hours, not six months.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Rippling's OA.
Rippling reuses patterns across OAs. Made for the candidate who got the OA invite this morning and has 72 hours, not six months. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Delivery Cost Tracker with Effective-Dated Rates FAQ
What's the trick in the Rippling delivery cost tracker?+
Finalize each delivery's cost at record time using the rate version effective at startTime. Later rate updates must never change it. Store per-driver sorted rate versions, binary search at record time, and keep running totals for all cost and unpaid cost.
How should I handle money to avoid rounding bugs?+
Convert every rate string to integer cents on input. Cost in cents is rateCents times duration seconds divided by 3600, and the problem guarantees exactness. Sum in 64-bit integers. Only convert to a string with two decimals when returning results. Avoid floats entirely.
How do I implement PAY_UP_TO efficiently?+
With up to 100000 operations, scanning every delivery per payment is risky. Push deliveries into a min-heap keyed by endTime. On payment, pop while endTime <= payTime and subtract each cost from the unpaid total. Each delivery is popped once, so it's amortized fine.
What happens when the same effective time is updated twice?+
The later operation replaces the earlier version. Example 3 shows it: rates 20 then 30 at time 100 means a delivery starting at 100 uses 30. Use a map per driver, or check for an existing entry on insert and overwrite it.
How do I prepare for this in 48 hours?+
Practice a binary search for the last entry <= x on a sorted list, a min-heap with pop-while loops, and integer-cents formatting. Then write this tracker once from scratch against the three examples. Test edge cases: equal effective and start times, and paying before any delivery ends.