Stripe·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

May 2026

Summary

Stripe coding screen for a software engineer role, one question but it had three layers that kept getting harder. The progression from flat pricing to tiered to a hybrid base-plus-tiers felt reasonable on paper but the off-by-one stuff at tier boundaries genuinely tripped me up mid-session.

Questions Asked (1)

Implement a shipping cost calculator in JavaScript with three progressively complex pricing models (flat per-unit, tiered per-unit, and a flat base fee for the first N items plus tiered pricing beyond that), driven by a config object keyed by destination. Define the function signature and describe edge case tests including quantity 0, exact tier boundaries, unknown destinations, negative inputs, and floating-point handling.

Algorithms & Data StructuresTechnical Trade-offsPricing & Monetization

Author's notes

I got the first two parts pretty fast.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the function signature and config schema, then implement a single calculator that dispatches on the destination's pricing model. Walk through each model with concrete examples, and finish by enumerating edge cases and how you'd test them, emphasizing correctness and maintainability.

Pro tip: Treat the config as a data-driven strategy map: each destination maps to a pricing function, so adding a new model doesn't require changing the core calculator. Also, explicitly state your assumptions about rounding and floating-point handling (e.g., work in cents or use a rounding helper) to show production awareness.

1. Clarify signature and config schema

Define the function signature (e.g., calculateShipping(destination, quantity, config)) and show the config structure for each pricing model. Confirm assumptions about units, currency, and whether config is passed in or global.

2. Implement the three pricing models

Write a helper for each model: flat per-unit, tiered per-unit, and base fee + tiered beyond N. Use a dispatch mechanism (e.g., switch on config.type) to select the correct helper.

3. Walk through examples for each model

Trace through a sample quantity for each model to verify the math, including exact tier boundaries. Explain how tiered pricing works (e.g., first 10 units at $2, next 10 at $1.50).

4. Enumerate edge cases and tests

List the required edge cases: quantity 0, exact tier boundaries, unknown destinations, negative inputs, and floating-point precision. Describe expected behavior and how you'd test each (e.g., unit tests with assertions).

5. Discuss trade-offs and extensibility

Mention how you'd handle floating-point issues (e.g., integer cents, rounding), validation strategy, and how the design supports adding new pricing models without modifying existing code.

Key Points to Mention

Function signature and config schema: clearly define inputs, outputs, and the shape of the config object keyed by destination.
Tiered pricing logic: explain how to compute cost when quantity spans multiple tiers, including exact boundary behavior.
Edge case handling: quantity 0 returns 0, unknown destination throws or returns error, negative inputs throw, and floating-point rounding strategy.
Testing approach: unit tests for each model, boundary tests, and property-based tests for invariants.
Floating-point handling: use integer cents or a rounding function to avoid precision errors, and document rounding rules.
Extensibility: use a strategy pattern or map of pricing functions to make adding new models easy without modifying core logic.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.