Pizza Price Function, Then a Shop Pricing Screen and the Pricing Microservice Question

Read the full interview experience this question came from →

Quick Overview

Implement a Python function that prices a pizza from its size, its toppings and an optional premium crust, returning None for an invalid size, then extend it into a pricing screen for a real shop. It tests clean validation, money handling, separating pricing logic from the interface, and reasoning about whether a pricing microservice is worth building.

Pizza Price Function, Then a Shop Pricing Screen and the Pricing Microservice Question

Company: Microsoft

Role: Machine Learning Engineer

Category: Software Engineering Fundamentals

Difficulty: medium

Interview Round: Technical Screen

Write a function that prices a pizza, then discuss how you would turn it into something a real pizza shop could use. The function is short; most of the discussion comes from the follow-up questions about the real shop. ### Clarifying Questions - Must `size` match exactly, or should `"Medium"` or `" large "` also be accepted? - If the same topping appears twice in the list, does it count twice? Are topping names checked against a menu? - Can `toppings` be `None` rather than an empty list? ### Part 1 — Implement the price function ```python def calculate_pizza_price( size: str, toppings: list, premium_crust: bool, ) -> float | None: ... ``` Rules: - The base price depends on the size: `small` costs \$5, `medium` \$10 and `large` \$15. - Each topping adds a fixed \$2. - `premium_crust=True` adds \$5. - An invalid size returns `None`. - `toppings` may be empty. | `size` | Number of toppings | `premium_crust` | Price | | --- | --- | --- | --- | | `medium` | 2 | `True` | `19.0` | | `small` | 1 | `False` | `7.0` | | `large` | 4 | `True` | `28.0` | ```hint One place for every price Think about where each price should live so that changing it later touches exactly one line, and what the function should check before it adds anything up. ``` #### What This Part Should Cover - Correct base, topping and crust arithmetic, checked against the three sample orders - Validating the size before calculating, and returning `None` for an invalid size - Prices held as named constants or a lookup table, and the time and space complexity - How money is represented, given that the signature returns a `float` ### Part 2 — Make it usable in a real pizza shop Suppose a pizza shop owner wants employees to use an interface to work out an order's price and show it on a screen. How would you build that, and what would you improve in the function? ```hint Who is allowed to compute Decide which layer owns the pricing arithmetic, what the screen is responsible for, and what an employee sees when the input is incomplete or wrong. ``` #### Clarifying Questions for this Part - Is this one shop with one counter screen, or several terminals or locations? - Who changes prices, and how often? Will toppings get different prices, and will discounts, promotions or tax apply? - Does the screen only display a price, or does it also record the order? #### What This Part Should Cover - Separating the pricing logic from the user interface, and the contract between them - Input validation and clear error messages, on the screen and in the pricing code - Where prices and future rules (different topping prices, discounts, tax, promotions) live, so that adding them does not mean rewriting the function - Unit tests, and an exact money representation for real payments ### Part 3 — A pricing microservice? Would you build a small microservice that provides pricing? There is no single correct answer: the interviewer is looking for the reasoning behind your trade-off. ```hint Name the trigger Weigh what a separate service buys against what it costs to build and run, and name the concrete change in the business that would flip your answer. ``` #### What This Part Should Cover - What a central pricing service gains, and which clients would share it - What it costs: network calls, deployment, operations, and a new way for ordering to fail - The simplest option to start with, and the conditions under which to evolve - If the service is built, its interface and how clients behave when it is slow or unavailable ### What a Strong Answer Covers - Clean, validated code with named constants that reproduces the sample prices - Raising real-world concerns unprompted: money precision, testability, input validation and extension points - A layered design in which pricing is pure, testable logic and the interface only collects input and displays results - A scale-dependent microservice answer that starts with the simplest working option and states when to evolve - Carrying the discussion past a working function instead of stopping once the code is correct ### Follow-up Questions - Toppings now have different prices, and some cost more on a large pizza. How does your price table change? - The shop runs a promotion: the second large pizza is half price on Tuesdays. Where does that rule live, and how do you test it? - A price changes while an order is open on the screen. Which price does the customer pay? - The shop adds a website and a phone app for ordering. Does your microservice answer change?

Overview: Implement a Python function that prices a pizza from its size, its toppings and an optional premium crust, returning None for an invalid size, then extend it into a pricing screen for a real shop. It tests clean validation, money handling, separating pricing logic from the interface, and reasoning about whether a pricing microservice is worth building.

Read the full Microsoft Machine Learning Engineer interview experience this question came from

Microsoft logo
Microsoft
Jul 31, 2026
mediumMachine Learning EngineerTechnical ScreenSoftware Engineering Fundamentals
1
0

Write a function that prices a pizza, then discuss how you would turn it into something a real pizza shop could use. The function is short; most of the discussion comes from the follow-up questions about the real shop.

Clarifying Questions Guidance

  • Must size match exactly, or should "Medium" or " large " also be accepted?
  • If the same topping appears twice in the list, does it count twice? Are topping names checked against a menu?
  • Can toppings be None rather than an empty list?

Part 1 — Implement the price function

def calculate_pizza_price(
    size: str,
    toppings: list,
    premium_crust: bool,
) -> float | None:
    ...

Rules:

  • The base price depends on the size: small costs $5, medium $10 and large $15.
  • Each topping adds a fixed $2.
  • premium_crust=True adds $5.
  • An invalid size returns None .
  • toppings may be empty.
sizeNumber of toppingspremium_crustPrice
medium2True19.0
small1False7.0
large4True28.0

What This Part Should Cover Guidance

  • Correct base, topping and crust arithmetic, checked against the three sample orders
  • Validating the size before calculating, and returning None for an invalid size
  • Prices held as named constants or a lookup table, and the time and space complexity
  • How money is represented, given that the signature returns a float

Part 2 — Make it usable in a real pizza shop

Suppose a pizza shop owner wants employees to use an interface to work out an order's price and show it on a screen. How would you build that, and what would you improve in the function?

Clarifying Questions for this Part Guidance

  • Is this one shop with one counter screen, or several terminals or locations?
  • Who changes prices, and how often? Will toppings get different prices, and will discounts, promotions or tax apply?
  • Does the screen only display a price, or does it also record the order?

What This Part Should Cover Guidance

  • Separating the pricing logic from the user interface, and the contract between them
  • Input validation and clear error messages, on the screen and in the pricing code
  • Where prices and future rules (different topping prices, discounts, tax, promotions) live, so that adding them does not mean rewriting the function
  • Unit tests, and an exact money representation for real payments

Part 3 — A pricing microservice?

Would you build a small microservice that provides pricing? There is no single correct answer: the interviewer is looking for the reasoning behind your trade-off.

What This Part Should Cover Guidance

  • What a central pricing service gains, and which clients would share it
  • What it costs: network calls, deployment, operations, and a new way for ordering to fail
  • The simplest option to start with, and the conditions under which to evolve
  • If the service is built, its interface and how clients behave when it is slow or unavailable

What a Strong Answer Covers Guidance

  • Clean, validated code with named constants that reproduces the sample prices
  • Raising real-world concerns unprompted: money precision, testability, input validation and extension points
  • A layered design in which pricing is pure, testable logic and the interface only collects input and displays results
  • A scale-dependent microservice answer that starts with the simplest working option and states when to evolve
  • Carrying the discussion past a working function instead of stopping once the code is correct

Follow-up Questions Guidance

  • Toppings now have different prices, and some cost more on a large pizza. How does your price table change?
  • The shop runs a promotion: the second large pizza is half price on Tuesdays. Where does that rule live, and how do you test it?
  • A price changes while an order is open on the screen. Which price does the customer pay?
  • The shop adds a website and a phone app for ordering. Does your microservice answer change?