stripe intern vo experience
Summary
I had a virtual onsite interview experience at Stripe for an intern position, which involved three progressively complex coding problems focused on calculating shipping costs based on various pricing rules and edge cases.
Full Experience
Stripe Intern Virtual Onsite Experience
My virtual onsite interview experience at Stripe consisted of three distinct levels, each building upon the complexity of the previous one, all centered around a shipping cost calculation problem. It was a rigorous assessment of my coding ability, logic, and edge case handling.
The first stage was relatively straightforward, designed to test my basic programming and data parsing skills. It quickly ramped up, introducing more dynamic pricing structures and intricate rules.
Level 2 was clearly the logical core, where the problem became much more dynamic and required careful thought to manage incremental costs and various product brackets. The final level, Level 3, added another layer of complexity by introducing different calculation modes, pushing me to integrate distinct logic paths within the same solution.
Overall, it was a challenging but engaging experience that thoroughly tested my problem-solving capabilities.
Interview Questions (3)
The first problem involved calculating the total price based on an order object and a country-specific flat shipping table. I needed to compute the total price by summing each item’s unit price multiplied by its quantity, and then add a flat shipping fee based on the country. For example, in the U.S., if a mouse has a unit price of 550 and a laptop is 1000, the total shipping fee for the U.S. might be 16,000. Canada would have similar logic. The main tasks were handling JSON parsing and basic loop logic to aggregate the costs.
Building upon Level 1, shipping costs were no longer a fixed price but dynamically varied based on quantity—an “incremental cost” model. Each product could have multiple cost brackets, defined by quantity ranges. My task was to determine which bracket the current item's quantity fell into, then multiply the corresponding unit price from that bracket by the quantity, and sum it up. The problem highlighted the need for clear logic and correct handling of edge cases, such as maxQuantity = null, which indicated no upper bound for a bracket. Correctly matching the rule and accumulating the price was critical.
This stage introduced a new layer on top of Level 2: a 'type' concept with two calculation modes—'fixed' and 'incremental.' The 'incremental' mode functioned identically to Level 2. However, the 'fixed' mode meant that within a specific quantity bracket, the total price for that item was fixed and did not increase linearly with the quantity. For example, if I bought two laptops and they fell into a 'fixed' cost bracket of 1000, the total charge for those laptops would be 1000, not 2000. The primary challenge was integrating both these pricing logics ('fixed' and 'incremental') within the same calculation loop while ensuring correctness.