Microsoft Machine Learning Engineer Interview Experience — A Pizza Pricing Function and Microservice Follow-ups

I just finished a VO (virtual onsite). The question was to write a function that calculates a pizza price.

Problem

Write a function to calculate the price of a pizza:

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

Rules:

• small $5, medium $10, large $15
• every topping is a flat $2
• if premium_crust=True, add $5
• if size is invalid, return None
• toppings can be empty

What I wrote

def calculate_pizza_price(size, toppings, premium_crust):
    base_price_map = {"small": 5.0, "medium": 10.0, "large": 15.0}
    topping_unit_price = 2.0
    premium_crust_price = 5.0
    if size not in base_price_map:
        return None
    total = base_price_map[size]
    total += len(toppings) * topping_unit_price
    if premium_crust:
        total += premium_crust_price
    return total

A few points I thought were worth saying out loud first:

• I put the price table in a dictionary with clearly named constants, so if prices change later I only change one place.
• I validate size first and return None right away if it is invalid, then continue with the calculation.
• I multiply len(toppings) by the unit price instead of looping. len is O(1) for a list, so time and space are both O(1) overall.

Then I walked through some examples myself:

Follow-up 1: if this were a real pizza shop, how would you improve it?

The gist of what the interviewer asked: suppose I really own a pizza shop and want my staff to use a screen to calculate the price and display it, how would I do that?

My answer was to separate the pricing logic from the UI:

• Keep this function as the backend pricing logic, since it is simple and easy to test.
• Build a simple separate UI where staff pick the size, toppings, and whether it has the premium crust. The UI calls the function and displays the price.
• Add input validation, unit tests, and clear error messages.
• If there are later changes like different topping prices, discounts, tax, or promotions, put those rules into config or a separate component instead of cramming everything into one function.

One thing I didn't say at the time but thought was worth mentioning afterwards: in a real setting, money is better handled as integer cents or Decimal to avoid floating point errors. Proactively thinking of real-world pitfalls like this is usually a plus.

Follow-up 2: would you build a small microservice to serve the pricing?

There is no standard answer to this one, the interviewer is looking at the reasoning behind your trade-offs. My answer was: it depends on scale.

• If pricing has to be shared by multiple apps or multiple stores, I could build a small pricing service: the client sends size, toppings, and crust over an API and the service returns the price. The upside is that the rules are centralized and easy to update.
• But if it is just one small shop, I would not start with a microservice, because it brings in networking, deployment, and operations costs.
• I would start with a simple backend function and only split it out once the business need proves it is necessary.

Takeaways

• The value of an easy question is often in the follow-ups. Don't just finish writing and call it done because the problem is simple. Proactively talk about testability, extension points, and edge cases.
• When asked something like "would you split this into microservices", start with the simplest solution for now, then say under what conditions it would evolve. That is much safer than piling on architecture right away.
• Small habits in the code (naming constants, validating before calculating) are things the interviewer can see.