Strategy & Operations interview prep

Give a reason that points forward, not away. Most strong answers say: I liked structuring problems, but I want to own the outcome after the recommendation.

Back it with one moment: a project where you saw a client fail to implement, or where you ran the change yourself and enjoyed it.

Then tie it to their business: the metric or problem on this team you would want to own first.

S&O has no direct authority, so this is the core skill. Pick a story where the other team had a real reason to say no.

Walk through it: what you proposed, who resisted and why, what you did to understand their incentive, and how you changed the proposal or the evidence. Data alone rarely wins; a small pilot or a shared metric often does.

End with the result and how the relationship stood afterwards.

Choose a process that solved a measurable pain: slow approvals, missed hand-offs, a weekly report nobody trusted.

Cover the before (how slow, how many errors), how you designed the new process with the people who would run it, how you rolled it out, and the after.

Add what you did so it kept working without you: an owner, a dashboard, a review rhythm.

Show that you can decide, and that you know what you do not know.

Describe the decision and the deadline, the data you had and the gap. Then explain how you bounded the risk: a range of outcomes, a proxy metric, a reversible first step.

Close with what happened and what data you set up so the next call was easier.

Pick a metric you were accountable for, not just one you reported. State its level and target.

Walk through how you noticed it going wrong, the analysis that found the cause (segments, cohorts, a funnel step), and the change you drove.

Give the number before and after, and how you kept watching it.

Stay calm and get specific. First, ask which number they doubt and why; sometimes they know something you do not.

Then walk through your source and method briefly. If you made an error, say so at once and say when you will send the corrected figure. If you did not, show the check that confirms it and offer to reconcile with their source.

The goal is the right number, not winning.

Lead with the decision you wanted, not the method. A good structure: the answer in one sentence, the two numbers that prove it, the one chart that shows it, and the ask.

Describe how you cut the analysis down and what questions came up. Mention how you handled a question you could not answer on the spot.

End with the decision the audience made.

Swap in any company; the shape is the same. Show you understand how the business makes money and where it is pushing next.

For Stripe: the business grows with the payment volume of its users, so S&O work is about growing and serving those users efficiently. Name a product or market you read about and the operating problem it creates.

End with why your background fits that problem.

Clarify first: how much, since when, everywhere or some cities, and is it the average or the slow tail?

Then split delivery time into its parts: restaurant prep time, wait for a courier, courier travel to the restaurant, and travel to the customer. Find which part grew. Check internal changes (a new dispatch rule, app release, incentive cut) and external ones (rain, traffic, a festival, a competitor paying couriers more).

If courier wait is up at peak, you have a supply gap: shift incentives to peak hours in the affected zones and test it against similar zones. Track on-time rate and cost per order.

First check the maths: if many new users join, the average retention falls even if nothing broke, because new users churn more. Compare cohorts of the same age, not the blended rate.

If like-for-like cohorts also retain worse, ask where the new users came from. A promo or a new channel may bring low-intent users. Then check the experience: first-trip quality, ETAs, cancellations and prices for the new cohorts.

Recommend by cause: fix the acquisition mix, or fix the first-order experience, and measure 30-day cohort retention.

Cover both sides and the match between them.

Demand: active riders or customers, orders per user, retention. Supply: active drivers or partners, hours online, earnings per hour, churn. Matching: time to match or ETA, fulfilment rate (requests that complete), cancellation rate, surge or wait frequency.

Then economics: take rate and contribution margin per order. Pick one north-star (completed trips, for example) and explain which two numbers you would watch daily.

Draw the journey as steps and give each a metric: app open → search (search-to-menu rate) → cart (add-to-cart) → checkout (checkout conversion) → restaurant accepts (acceptance rate, prep time) → Dasher assigned (assignment time) → pickup (wait at restaurant) → drop-off (travel time, on-time %) → after the order (ratings, refunds, reorder within 30 days).

Then pick the step with the biggest drop or delay, based on data, and propose one fix with a test. Say which metric would prove it worked.

Define the gap first: which hours and zones lack Dashers, and how much demand goes unserved or late.

Causes split into fewer Dashers online (cold, snow, holidays) and higher demand (people order more in bad weather). Levers: peak or weather pay for the worst hours, scheduling that guarantees earnings for committed shifts, recruiting part-timers before the season, and on the demand side, wider delivery times or temporary radius limits.

Test pay boosts in matched zones and watch cost per order and on-time rate.

Compare the area with similar areas: is it slower at the restaurant, waiting for a rider, or on the road?

Check what changed there: new restaurants with long prep times, a road closure, a rider shortage after an incentive change, a map or address problem with a new housing society.

Fix by cause: re-time prep estimates for slow restaurants, add rider supply at peak, or correct addresses and pin locations. Re-check the area’s on-time rate a week later.

Think in capacity. Each rider can do a certain number of orders an hour. If orders rise faster than riders online, waiting time grows sharply once utilisation is high, not gradually.

Estimate: current orders per hour, riders online, orders per rider per hour, and the utilisation after the rise. If it goes above roughly 85–90%, delays climb.

Mitigate with more riders at those hours (incentives, borrowing from nearby zones), batching two orders per trip where routes match, and temporarily limiting the delivery radius.

Agree on success before the launch. One primary metric linked to the goal (for example conversion or orders per user), two or three guardrails (cancellations, support contacts, cost per order), and the minimum change worth shipping.

Check the test itself: was assignment random, is the sample big enough, did it run long enough to cover weekdays and weekends?

Then read results by segment (new vs repeat, city) and decide: ship, iterate or stop.

Start from revenue per order: delivery fee, service fee, small-order fee, commission from the restaurant, and advertising.

Then variable costs per order: courier pay and incentives, payment processing, customer promotions and refunds. Revenue minus these is contribution margin per order.

Below that sit fixed costs: support, marketing, tech and overheads. Say which bucket you would attack first in a loss-making city, usually incentives and promotions, and how you would test it.

Build it top down and check it bottom up.

Top down: households in the city × share who order delivery × orders per month × average order value. Use census and survey data for the first three.

Bottom up: restaurants in the target area × likely partner share × orders per restaurant a day, using a similar city you already serve as the benchmark.

If the two are close, you have a range. Then add what decides the launch: competitor presence, density (orders per square km) and expected margin per order.

Pick a small dense area first, not the whole city. A marketplace works when supply and demand meet in the same few square kilometres.

Sequence: recruit supply first (drivers or restaurants) so the first customers get a good experience, then turn on demand with targeted offers to the densest neighbourhoods, offices or campuses. Spend on the side that is short each week.

Set launch gates: wait time under a target, repeat rate above a target. Expand to the next zone only when the first zone passes.

Do not match by reflex. First measure: are drivers actually leaving, in which cities and hours, and do they earn more per hour there after counting fewer trips?

Drivers care about earnings per hour, not the split. If you have more demand, your drivers may earn more despite the lower split; show them that.

Responses: targeted incentives in the cities and hours where you are losing supply, better utilisation (less idle time), and non-cash benefits. Model the cost of matching against the cost of lost supply before deciding.

Structure: is it attractive, can we win, and how do we launch?

Attractive: grocery orders are frequent but baskets are bigger and margins thin. Can we win: Uber has drivers, customers and a delivery app; it lacks store partnerships and in-store picking.

Launch: partner with large grocers in a few cities, use drivers in off-peak hours when rides are slow (which raises their utilisation), and measure order accuracy, delivery time and margin per order. Expand if those pass.

Clarify the scope: money spent by app developers on ads to get installs, across the main Southeast Asian countries, per year.

One path: smartphone users × new apps installed per user a year × share of installs that are paid × cost per install. Another: number of active app developers who advertise × average yearly ad budget, split into large and small developers.

Do the maths with round numbers, compare the two paths, and say which assumption moves the answer most.

Work from what a rider needs and what an order can pay.

Rider side: a fair monthly income for the city, plus fuel and phone costs, divided by working hours gives a target earning per hour.

Order side: orders a rider can do per hour at peak and off-peak, times pay per order, plus incentives. Check that the pay per order fits inside the delivery fee and commission per order.

Recommend a structure, such as base per order plus distance plus peak bonus, and say what you would test.

Find the bottleneck first: is it ordering, prep, cooking, packing or hand-off to riders? Output is limited by the slowest step.

Levers: prep high-volume items before the peak using demand forecasts, trim the menu at peak to the items that cook fastest, add a second shift or station only at the bottleneck, and separate packing from cooking.

To avoid waste, forecast by hour and item from past orders and prep in small batches. Track orders per hour and waste as a percentage of food cost.

Expansion in quick commerce means new dark stores. Each store covers a small radius, so the question is which neighbourhoods have enough orders per day to make a store profitable.

Score areas on household density, income, existing order data from nearby stores, and competitor coverage. Open where a store can reach break-even orders per day fastest, then grow the range in the best stores.

For “why quick commerce”: talk about the operating problem you find interesting, such as forecasting thousands of items per store, not just growth.

Define retention: share of a month’s new customers who order again within 30 days, by cohort.

Find where customers drop: after the first order (bad first experience: late, missing items, out of stock) or later (prices, range, a competitor). Pull complaints and ratings for churned customers.

Fix by cause: improve item availability in top stores, fix first-order delivery promise, and test a second-order offer only for the segment that needs it. Measure 30-day repeat rate by cohort.

Choose the comparison that matters for the decision. For grocery: price on a basket of common items, delivery promise, range, minimum order and fees, and where each player is strong (metros vs smaller cities).

Gather it yourself: build the same basket on each app in two or three cities and record price, fees and delivery time.

Summarise in one table and end with “so what”: where we can win and the one move you would test.

This tests whether you always carry a recommendation. Answer first: “We should do X, because Y, and the first step is Z.”

Then give your confidence and the one piece of evidence that would change your mind.

In a case, practise saying your current best answer at every stage, not only at the end. It shows you are driving the problem, not waiting for it to finish.

Clarify what “TV business” means: hardware, a TV operating system, streaming content, or ads on TV.

Then test each option on market size and growth, Google’s right to win (Android, YouTube, ads, data) and what it costs.

A strong answer narrows to one option, such as growing the TV operating system and YouTube on TV, where Google already has assets, and explains what it would not do and why.

Clean first: check duplicates, blanks and time zones, and write down what each column means. Then size the problem: error rate overall and over time.

Group errors by code, merchant, integration type, time of day and order size. Usually a few codes or merchants cause most errors; show that with one ranked chart.

For each top cause, give a fix (validation before submission, a retry rule, a merchant setup change), the expected reduction in errors, and an owner. Present the answer first, then the evidence.

Treat it like a consulting deliverable. Slide 1 is the answer: three insights and three recommendations. The next slides prove each insight with one chart and one sentence headline.

Insights that land: concentration (top 20% of customers or merchants and their share), trends over time, and a segment that behaves differently.

End with next steps and the size of the prize. Keep the Excel tidy with inputs, calculations and outputs separated, because some panels open it.

Required riders per hour = forecast orders per hour ÷ orders one rider can complete per hour, plus a buffer for no-shows and uneven demand.

Forecast orders by hour and day from past data, adjusting for weather and events. Orders per rider per hour depends on trip time, which rises when you promise a tighter delivery time.

Turn it into shifts that cover the peaks (lunch and dinner) and check cost per order. Show what happens if demand is 20% higher than forecast.

Pivot: rows are zone, columns are hour, values are count of orders, with a filter on status (delivered, cancelled). Add a second value for average delivery time. Then read it aloud: which zone and hour has the most cancellations?

VLOOKUP: bring a value from another table using a shared key, such as adding each rider’s zone to the orders table using rider ID. Mention that the key must be unique and that INDEX-MATCH or XLOOKUP is safer when columns move.

Interviewers want speed and a sentence of insight, not just the mechanics.

A pivot table summarises a large table by groups, such as orders per store per hour, without formulas. Give a one-line example from their business.

Quick commerce delivers a small range (a few thousand items) from dark stores close to customers in minutes. E-commerce delivers a huge range from large warehouses in a day or more.

The operating difference: quick commerce lives on store-level forecasting, stock availability and rider density; e-commerce on range, logistics networks and returns.

Read a query in the order the database runs it: FROM and JOIN (which tables, joined on what), WHERE (which rows), GROUP BY (which level), HAVING (filters on groups), SELECT (what is shown), ORDER BY.

Point out risks: a join that duplicates rows, a missing date filter, averages of averages.

For your experience, give one real analysis you wrote, the tables, and the decision it supported.

Clarify the conversion (first order? merchant sign-up?) and today’s baseline per week.

Work backwards from the funnel: if 5% of visitors convert, you need about 20,000 qualified visitors, or a higher rate. List the fastest levers: warm leads already in the pipeline, an offer to users who reached checkout but did not finish, partners or referrals, a focused outbound push.

Estimate what each lever yields and costs, and run the cheapest ones first. Track daily and add levers if you are behind by mid-week.

Start with the people closest to ready: applicants who dropped out mid-onboarding, inactive drivers, and drivers on other platforms. Message them with a clear earnings offer for the next few days.

In parallel, ask current drivers to refer friends for a bonus, and run local job ads in the target zones.

The constraint is usually onboarding (background checks, documents), not interest, so check what can be done in 24 hours and staff the onboarding desk. Track applicants, activated drivers and first trips by the end of the day.