McKinsey Interview Questions (2026): Real, With Answers

McKinsey Solve is a self-directed, game-based assessment you complete on your own computer before any live interview, built originally by Imbellus and still referred to by some candidates by that older name, or as the Problem Solving Game. Instead of a person walking you through a business scenario, you are dropped into a simulated environment, an ecological or exploratory scenario depending on which module you draw, and asked to make a series of decisions under a time limit.

The scoring is not just "did you get the right answer." The system logs every click, how you sequence your investigation, whether you revise an earlier choice, how efficiently you gather information before committing. That means two candidates who reach the same final answer can score differently based on how they got there. Treat it like a structured problem, not a puzzle to guess your way through, and narrate your logic to yourself as you go so you stay disciplined about testing one hypothesis before jumping to the next.

Most candidate reports put total time around 45 to 90 minutes depending on how many modules you are assigned, sometimes one scenario, sometimes two. There is no live proctor watching over video in most cases, but the platform monitors for irregular behavior through its own telemetry.

Retake policy varies by region and recruiting cycle, and McKinsey does not publish a universal rule, so the safest assumption is that you get one attempt per hiring cycle. Treat it accordingly: do a couple of practice runs on the current module types before your real attempt so the interface and pacing are not a surprise on test day.

Stable revenue with falling profit means the story is almost entirely on the cost side, so I would say that out loud first rather than spend time re-verifying revenue is flat. From there I would split costs into fixed, rent, corporate overhead, equipment leases, and variable, cost of goods sold, hourly labor, shipping, and ask which bucket grew.

A retail chain specifically points me toward a few likely culprits before I even see data: rising input costs passed through from suppliers, wage inflation in a tight labor market, or new store openings whose fixed costs haven't been offset by ramped-up sales yet. I would ask for a cost breakdown by category and by store vintage, newer stores versus mature ones, before guessing further, since new-store drag is one of the most common reasons revenue holds steady while margin erodes.

Price increases only work if volume doesn't fall enough to offset the higher margin per unit, so the first thing I'd want is a sense of price elasticity for this product or category, either from historical data on past price changes or from how substitutable the product is for customers.

I'd also check competitive pricing before recommending a 10 percent move. If competitors hold prices flat, a 10 percent increase risks real volume loss to substitutes. If the whole category is raising prices due to a shared cost pressure, like input inflation across the industry, a matching increase is far less risky. The framework is straightforward, price times quantity has to net out higher than before, but the actual recommendation depends entirely on elasticity and competitive context, not on the arithmetic alone.

I'd start from population, not from coffee shop counts, since a top-down demand estimate is usually more defensible than trying to estimate supply first. Take the city's population, estimate the share who are regular coffee drinkers, maybe 60 to 70 percent of adults, then estimate average take-away purchases per week for that group, distinguishing daily habitual buyers from occasional ones.

I'd state my assumptions out loud as I go, population, coffee-drinker share, purchase frequency, rather than silently plugging in numbers, since the interviewer is scoring the structure of my logic as much as the final figure. I'd also sanity-check the result against something tangible if I can, a rough sense of how many coffee shops the city plausibly supports at that volume, to see if my demand estimate and a supply-side gut check land in the same neighborhood.

A standalone sizing question is testing your estimation logic and mental math in isolation, the interviewer usually doesn't care much about the specific business implication of the number, just whether your structure and arithmetic hold up. Inside a larger entry case, the sizing exercise is a means to an end, feeding directly into whether the market is big enough to justify the client's investment.

The practical difference in how you should answer: in a standalone question, spend more time being explicit about every assumption, since that structure is the entire point being evaluated. Inside an entry case, move faster through the sizing math and spend your remaining time connecting the resulting number back to the client's specific investment threshold or growth target, since that connection is what the interviewer is actually listening for at that point in the case.

I'd split it into standalone value and synergy value. Standalone value asks whether the target is a good business on its own merits, its financial health, competitive position, and growth trajectory, independent of who owns it. Synergy value asks what changes specifically because this particular acquirer is the one buying it, cost synergies from combined operations, revenue synergies from cross-selling, or capability transfer in either direction.

I'd push the interviewer to separate these two buckets early, because a target that looks mediocre standalone can still be a great deal if the synergy case is strong, and a target that looks great standalone can be a bad deal if the acquirer is overpaying for synergies that never materialize. Most candidates conflate the two and end up with a muddier recommendation than the case actually calls for.

The instinct is to pick the most dramatic story available, but McKinsey's follow-up structure rewards a story with a lot of concrete, defensible detail more than one with high drama and thin substance. Pick a situation where you can answer 15 to 20 specific follow-up questions without contradicting yourself, what exactly you did, in what order, what alternatives you considered and rejected, what the actual measurable outcome was.

The most common failure mode isn't a weak story, it's a story told at too high a level, "we restructured the team and things improved," that collapses the moment an interviewer asks what specifically you personally did versus what your team or manager did. Practice narrating your story at a level of detail where you're describing your own individual decisions and actions, not a team's collective outcome.

The interviewer is looking for your actual decision process under pressure, not just that you made a decision and it happened to work out. Walk through what information you did have, what you explicitly decided not to wait for and why, and what your fallback plan would have been if the decision had gone wrong.

A strong answer acknowledges the risk you were accepting by moving without complete information, rather than presenting the decision as obviously correct in hindsight. Interviewers specifically listen for candidates who can articulate the tradeoff they were making in the moment, since that's a better proxy for judgment under real consulting pressure than a story where the right call was obvious from the start.

This is usually a Connection-dimension prompt, and the strongest answers are specific about what made the message difficult, delivering bad news, translating something technical for a non-technical audience, disagreeing with a group consensus, rather than a generic "I had to communicate clearly" framing.

Be ready to describe how you adjusted your approach for the specific audience, not just what you said, and what signal told you the message had actually landed, versus just that you delivered it. Interviewers listen for that verification step specifically, since delivering a message clearly and confirming it was understood are two different skills, and only the second one demonstrates real communication judgment.

Candidate reports converge on preparing somewhere between 8 and 20 distinct stories, enough to cover multiple angles of each of the four dimensions, Connection, Drive, Leadership, Growth, without needing to reuse the same story twice within a single round. Since each round typically has two interviewers who may compare notes, reusing a story across your two interviews in the same round can read as having a thin bench of real experiences.

The practical approach is to map your stories against the dimensions ahead of time, ideally two stories per dimension, rather than memorizing a fixed script for each one. The follow-up questions will pull you in directions you can't fully predict, so what actually matters is knowing your own experiences well enough to answer honestly from any angle, not having a rehearsed narrative that breaks the moment a follow-up steers off-script.

The core of this is a straightforward string-parsing problem, but interviewers are watching how you handle malformed input, missing delimiters, duplicate IDs, extra whitespace, not just the happy path. I'd split the input on the record delimiter first, then split each record on the field delimiter, and explicitly decide what happens on a duplicate ID, last write wins, first write wins, or raise an error, rather than leaving that behavior implicit.

def parse_catalog(raw: str) -> dict[str, str]:
  catalog = {}
  for record in raw.strip().split(";"):
    if not record.strip():
      continue
    parts = record.split(":", 1)
    if len(parts) != 2:
      continue # skip malformed record rather than crash
    product_id, name = parts[0].strip(), parts[1].strip()
    catalog[product_id] = name # last write wins on duplicate ID
  return catalog

Naming the duplicate-ID decision out loud is the detail that usually separates a pass from a borderline result here, since interviewers specifically ask what happens if the same ID shows up twice if you don't address it first.

A common table expression names an intermediate result set so a complex query reads as a sequence of clearly labeled steps instead of nested nested subqueries. It doesn't inherently guarantee a performance change, most modern query planners, Postgres, SQL Server, and recent MySQL versions, treat a CTE the same as an equivalent subquery or temp table at the implementation level and optimize accordingly, though a few older engines used to materialize every CTE regardless of whether that helped.

WITH monthly_totals AS (
 SELECT customer_id, DATE_TRUNC('month', order_date) AS month, SUM(amount) AS total
 FROM orders
 GROUP BY customer_id, DATE_TRUNC('month', order_date)
)
SELECT customer_id, month, total
FROM monthly_totals
WHERE total > 1000;

The honest answer to the performance question is "it depends on the engine," and saying that instead of confidently claiming a universal performance rule is usually the more accurate, more senior response.

A data warehouse stores structured, already-transformed data optimized for fast analytical queries, schema defined upfront, data cleaned before it lands. A data lake stores raw data in its native format, structured or not, schema applied later at query time rather than at ingestion.

I'd recommend a warehouse when the primary use case is business intelligence and reporting against a known, stable set of questions, since the upfront schema pays off in query speed and simplicity. I'd recommend a lake, or increasingly a lakehouse that combines both, when the organization needs to retain raw data for future, not-yet-defined analyses, or when the source data includes unstructured formats, logs, images, free text, that a rigid warehouse schema can't accommodate cleanly.

A weak answer stays generic, "McKinsey is the most prestigious firm," which tells the interviewer nothing about you and signals you haven't done real research into what actually differentiates McKinsey from Bain or BCG. A strong answer names two or three specific, personal reasons, a type of engagement work you're drawn to, a value or working style you've heard about from actual McKinsey consultants you've spoken with, or a specific practice area that fits your background.

Mentioning a real conversation with a current or former McKinsey consultant, and what specifically they told you that resonated, tends to land better than reciting facts from the firm's website, since it shows you've actually done the legwork of talking to people rather than just researching from a distance. Keep compensation out of the answer entirely, even though it's a real factor, since leading with it signals the wrong priority to an interviewer evaluating retention intent.

Candidate reports describe final-round cases, typically conducted by partners or senior partners, as more open-ended than first-round cases. Instead of a tightly scripted sequence of sub-questions, the interviewer is more likely to let you drive the structure yourself and probe your business judgment on ambiguous tradeoffs rather than testing whether you can execute a known framework correctly.

The format itself, case plus PEI in the same session, stays the same, and the PEI carries the same weight it did in round one. What changes is the depth of follow-up on both halves. A partner interviewer has seen thousands of cases and tends to ask sharper, more targeted follow-up questions on whatever assumption you gloss over fastest, so the margin for a hand-wavy answer is smaller in the final round than in the first.

Two modules dominate current candidate reports: Redrock, an ecological simulation where you investigate why a plant or animal population is declining, and Sea Wolf, a resource and territory management scenario. A third, older module called Ecosystem Building, where you selected species to build a self-sustaining food chain, was phased out starting in mid-2025 and now shows up mostly in older prep guides rather than live reports.

The practical upshot: if you are prepping from a guide written before 2025, you may be practicing a scenario you will not see. Confirm which modules are current before you spend hours drilling the wrong one, and expect the newer modules to weight process efficiency and hypothesis discipline more heavily than the older ecosystem game did.

Process matters as much as outcome, arguably more. The assessment tracks your full interaction history, not just your final submission, so it can reconstruct how methodically you explored the problem space. A self-sustaining ecosystem or a stabilized population you arrive at through scattered trial and error scores worse than one you reach by testing a clear hypothesis, ruling it in or out, and adjusting deliberately.

This is the same evaluation logic McKinsey applies in live case interviews, structure and hypothesis-driven thinking over raw pattern matching, just captured through click data instead of a human interviewer's notes. Candidates who treat Solve as a speed test and rush tend to underperform candidates who slow down enough to work through a logical sequence, even when the slower candidate finishes with less time to spare.

The reward structure favors narrowing the problem space early rather than exploring everything available. In a Redrock-style ecological scenario, that looks like forming an early guess about which variable, a predator, a resource shortage, a habitat change, is most likely driving the outcome you are seeing, then gathering just enough evidence to confirm or rule it out before moving to the next candidate cause.

Candidates who instead try to inspect every available data point before forming any hypothesis tend to run out of time and submit a rushed, under-informed final answer. The efficient path mirrors real MECE structuring in a live case: pick a lens, test it, discard or keep it, move on, rather than boiling the ocean.

I lay out a simple tree, revenue drivers on one branch, price and volume, cost drivers on the other, fixed and variable, and ask the interviewer for one piece of data at a time rather than guessing which side matters more before I have anything to go on. The first number I usually ask for is the revenue trend itself, because if revenue is flat or growing while profit falls, that already tells me to weight my time toward the cost branch, and the reverse if revenue itself is declining.

What separates a strong answer here is resisting the urge to dive into cost detail before confirming which side of the equation moved. Interviewers specifically watch for candidates who jump straight to "let's look at variable costs" without first establishing, from the topline numbers, that costs are actually where the story lives.

Breakeven units equal fixed costs divided by contribution margin per unit, where contribution margin is price minus variable cost per unit. I would ask for each of those three inputs explicitly rather than assuming round numbers, since a candidate who plugs in guessed figures and gets a clean answer often gets the framework right but the arithmetic wrong.

Once I have the breakeven number, the real value is comparing it against a realistic demand estimate for that product, not just reporting the figure. If breakeven sits above what the market can plausibly absorb in year one, that changes my recommendation from "launch as planned" to "launch at a lower fixed-cost footprint" or "delay until demand justifies the fixed investment." The number by itself is not the answer, what you do with it against a demand estimate is.

I'd structure this around four questions: is the market attractive, size, growth rate, profitability; what does the competitive field look like, how concentrated, how price-sensitive; does the client actually have a right to win here, brand recognition, existing supply chain, price point fit; and if the first three check out, what's the best entry mode, build a local operation, acquire a local player, or partner with an existing distributor.

India specifically is a market where price sensitivity and an entrenched set of domestic and Chinese competitors matter enormously, so I'd push hard on the "right to win" question before getting excited about market size alone. A large, fast-growing market that a foreign entrant can't actually compete in on price or distribution isn't a real opportunity, it's just an attractive-looking number. Given that roughly 60 percent of failed entries trace back to underestimating competitors, I'd weight the competitive analysis more heavily than the market sizing.

The decision usually comes down to speed, capability gaps, and regulatory friction. Organic entry makes sense when the client already has a transferable playbook and time isn't a constraint, but it's slow and exposes the client to a steep local learning curve. Acquisition is faster and buys existing distribution, regulatory relationships, and local knowledge, but it's expensive and carries integration risk.

A joint venture is usually the right call specifically when local regulation requires it, some markets mandate local ownership stakes for foreign entrants, or when the client needs a local partner's distribution network more than it needs full control. I'd ask the interviewer directly whether the target market has foreign-ownership restrictions before recommending a mode, since that single fact can eliminate two of the three options immediately.

A large, growing market is necessary but not sufficient. The red flags I'd weight most heavily are a fragmented or price-driven competitive set where the client has no clear differentiation, high customer switching costs that lock in incumbents, and regulatory or distribution barriers that would take years to clear regardless of how much capital the client commits.

The one candidates most often miss is underestimating how competitors will react once the client actually enters. A market that looks open today can close quickly if an incumbent responds with aggressive pricing or a rushed product launch specifically to defend share. I'd ask what the interviewer knows about historical competitive responses to new entrants in this market before finalizing a recommendation either way.

I'd anchor on households rather than population here, since light bulb purchases track housing units better than they track individuals. Roughly 130 million US households, an average number of light fixtures per home, maybe 30 to 40 including lamps, ceiling fixtures, and outdoor lighting, and an average bulb lifespan that determines replacement frequency, LED bulbs lasting years versus incandescent lasting months.

The replacement-rate assumption is where this estimate lives or dies, and it's also the piece most candidates rush past. If the housing stock has shifted heavily toward LED, which last far longer, the annual replacement volume is meaningfully lower than it would have been a decade ago, and I'd flag that shift explicitly as part of my answer rather than using an outdated replacement assumption by default.

I'd compare the offer price against a standalone valuation, using a multiple appropriate to the industry, revenue or EBITDA multiple depending on the sector, and then separately quantify the synergy value the deal is supposed to unlock. The premium the acquirer is paying above standalone value should roughly match the risk-adjusted synergy value, not exceed it.

Where deals actually go wrong, and where I'd focus follow-up questions, is in how confidently the synergies are estimated. A price that's justified only if every projected synergy materializes on schedule is a much riskier deal than one where the standalone value alone nearly covers the purchase price. I'd ask the interviewer what assumptions underlie the synergy estimate before accepting the premium as reasonable.

With headcount off the table, I'd focus on procurement spend, energy and utility costs, equipment downtime and maintenance efficiency, and process waste on the production line itself. Procurement is usually the fastest lever, renegotiating supplier contracts or consolidating vendors rarely requires headcount changes and can move quickly.

I'd also ask about capacity utilization across facilities, since underutilized equipment or facilities running well below capacity often hide real cost savings through consolidation or better scheduling, again without cutting people. The 20 percent target is aggressive enough that it likely requires combining several smaller levers rather than one silver bullet, so I'd want to size each lever's contribution before committing to a specific mix.

Cost cutting is usually framed around a specific target, reduce spend by X percent, X dollars, often with a deadline attached, and tends to focus on what to stop doing or spend less on. Operational efficiency is framed more around throughput and process, how to produce the same output with less waste, time, or rework, and the savings are often a byproduct of the efficiency gain rather than the stated goal itself.

The distinction matters because a pure cost-cutting mandate can tolerate short-term pain, a one-time vendor renegotiation, a temporary facility closure, in a way an efficiency mandate usually can't, since efficiency gains need to be sustainable to matter. I'd ask the interviewer early which framing applies, because it changes whether I should be looking for one-time versus recurring savings.

This question is testing the Connection and Drive dimensions together, whether you can read another person's actual objection rather than just repeating your point louder, and whether you pushed through resistance instead of dropping the idea at the first sign of pushback. A strong answer names the specific objection the other person raised, not a generic "they were skeptical," and describes what you changed about your approach once you understood it.

Avoid stories where the resistance dissolves too easily, "I explained it clearly and they came around," since that reads as either an exaggerated account or a genuinely low-stakes example. The interviewer's follow-ups will probe exactly this, asking what the person's specific concern was and how you addressed that concern rather than just repeating your original pitch.

This maps most directly to the Drive dimension, but a story that's purely about personal hardship without a concrete action sequence tends to underperform. The interviewer wants a specific decision point, the moment you chose one path over another under real constraint, not a narrative arc where things simply improved with time.

I'd structure the answer around what specifically made the obstacle hard, resource constraints, opposition from a specific person, a skill gap you didn't have yet, then the specific sequence of things you tried, including anything that didn't work before you found the approach that did. Interviewers probe for that failed-attempt detail specifically, since it's evidence you adapted rather than getting lucky on your first try.

This targets the Leadership dimension directly, and the follow-up questions will focus heavily on how you specifically influenced the team's behavior, not just what the team collectively accomplished. Be ready to describe individual team members' initial reactions or resistance, and what you did, one on one or as a group, to move them.

A common weak spot here is defaulting to a story where you had formal authority, a direct report situation, which is a valid story but slightly less impressive than one where you led without formal authority, since McKinsey's evaluation of leadership potential weighs the latter more heavily. If you have a genuine example of leading peers or people senior to you without a title backing you up, that's usually the stronger story to bring.

This tests Connection and Leadership together, whether you can read the interpersonal dynamics driving the conflict, not just the surface disagreement, and whether you took action rather than waiting for someone else to resolve it or letting it resolve itself. Name the actual root cause you identified, a miscommunication, competing incentives, an unclear ownership boundary, since a vague "there was tension" answer gives the interviewer nothing to probe.

Be ready for a follow-up asking what you'd do differently if a similar conflict arose again. This is one of the more common probes on conflict-resolution stories specifically, and an answer that says "nothing, it worked out" reads as a lack of self-reflection, one of the traits McKinsey explicitly screens for in PEI follow-ups.

This targets Growth directly, and it's one of the few PEI prompts where candidates most often play it too safe, picking a "failure" that's actually a disguised success, "I failed to delegate enough, so I learned to delegate more," told in a way that makes the candidate look good throughout. Interviewers see through this pattern constantly and it tends to read as evasive rather than self-aware.

A genuinely useful answer names a real failure with a real cost, something that actually went wrong for you, your team, or a client, and then focuses most of the answer on the specific, concrete change you made afterward, not a vague lesson like "I learned to communicate better." The follow-up will almost always ask how you've applied that lesson since, so have a second, smaller example ready that shows the change actually stuck.

This is a sweep-line problem. Convert each project into two events, a +1 at the start time and a -1 at the end time, sort all events by time, and walk through them keeping a running count, tracking the maximum count seen. The subtlety most candidates miss is tie-breaking, when a project ends at the same instant another begins, whether that counts as an overlap depends on whether the interval is treated as inclusive or half-open, and I'd ask the interviewer to clarify that before coding.

def max_overlaps(projects: list[tuple[int, int]]) -> int:
  events = []
  for start, end in projects:
    events.append((start, 1))
    events.append((end, -1))
  # process ends before starts on ties for a half-open interval convention
  events.sort(key=lambda e: (e[0], e[1]))
  running = max_count = 0
  for _, delta in events:
    running += delta
    max_count = max(max_count, running)
  return max_count

Getting the O(n log n) sort-based approach is table stakes. What signals seniority is proactively raising the tie-breaking edge case before the interviewer has to point it out.

This is a classic rank-within-group problem, which is exactly what window functions exist for instead of a self-join or subquery per region. RANK or DENSE_RANK partitioned by region, ordered by total spend descending, then filter to rank three or below in an outer query, since window functions can't be referenced directly in a WHERE clause on the same query level.

SELECT region, customer_id, total_spend, spend_rank
FROM (
 SELECT
  region,
  customer_id,
  SUM(amount) AS total_spend,
  RANK() OVER (PARTITION BY region ORDER BY SUM(amount) DESC) AS spend_rank
 FROM orders
 GROUP BY region, customer_id
) ranked
WHERE spend_rank <= 3
ORDER BY region, spend_rank;

The detail worth mentioning unprompted: RANK leaves gaps after ties, two customers tied for second means the next rank is four, not three, while DENSE_RANK doesn't. Which one is correct depends entirely on how the interviewer wants ties handled, and asking that question shows you understand the difference rather than picking one at random.

The first step isn't picking an imputation method, it's understanding why the values are missing, missing completely at random, missing at random conditional on other features, or missing not at random because the value itself correlates with why it's absent. That distinction changes the right approach entirely, and skipping it is the most common mistake I'd flag in an interview setting.

If the missingness looks random, mean or median imputation for a numeric feature, or a model-based imputation like k-nearest-neighbors for something more structured, is usually defensible. If missingness correlates with the outcome itself, a customer who didn't report income might systematically differ from one who did, imputing naively can introduce bias, and it's often better to add a separate binary flag for "was missing" alongside the imputed value so the model can learn from the missingness pattern itself rather than have it erased.

Bias is error from a model too simple to capture the real pattern, it underfits both training and test data similarly poorly. Variance is error from a model too sensitive to the specific training data, it fits training data well but generalizes poorly, showing a large gap between training and validation performance.

The diagnostic is comparing training error against validation error directly. High error on both, with a small gap between them, points to bias, and the fix is usually a more expressive model or better features. Low training error with a much higher validation error points to variance, and the fix is regularization, more training data, or a simpler model. I'd want to see both numbers before recommending a fix, since guessing which one is the problem without checking that gap is a common mistake even from candidates who can define the terms correctly.

The honest answer is that from outside the firm, the differences between MBB firms are more about culture and emphasis than a fundamentally different methodology, all three use structured, hypothesis-driven problem solving. Where I'd point to a genuine difference, based on what's publicly known, is McKinsey's heavier investment in internal knowledge infrastructure and cross-office expert networks, letting a case team pull in specialized expertise from elsewhere in the firm quickly.

I'd be careful not to overclaim a difference I can't actually back up, since interviewers who've worked at competing firms can tell when a candidate is repeating recruiting marketing rather than a genuinely informed view. A more credible answer acknowledges the similarity in core methodology and focuses the differentiation on culture, scale of internal resources, or specific practice-area depth relevant to your own background.

The instinct to defend your original framework at all costs is usually the wrong move. McKinsey interviewers frequently push back specifically to test coachability, whether you can genuinely take feedback and adjust, versus whether you'll dig in defensively. I'd acknowledge the specific point they're raising, ask a clarifying question if their pushback isn't fully clear, and then genuinely reconsider whether my original structure holds up, rather than performing agreement while quietly keeping the same approach.

The distinction interviewers are watching for is between someone who caves immediately without thinking, which signals a lack of conviction, and someone who thinks through the pushback and either adjusts with a clear explanation of what changed their mind, or holds their position with a specific, well-reasoned justification. Either outcome is fine. What isn't fine is an unexamined reflex in either direction.

By the final round, the interviewer has almost certainly already read your resume and case-team notes from round one, so a walk through your resume chronologically usually wastes time they've already spent elsewhere. What's more useful at this stage is a tighter narrative connecting your specific background to the specific kind of work you'd actually be doing at McKinsey, and why that connection is genuine rather than convenient.

Partners are also listening for how you talk about yourself under less structure than a first-round interviewer might provide, since the final round is partly testing executive presence, can you hold a room's attention with a concise, well-organized answer without over-explaining. Keep it under two minutes, lead with the throughline rather than a chronological list, and let the details come out through their follow-up questions rather than trying to front-load everything into the opening answer.

I would break variable cost per unit into its own components, materials, direct labor, and any per-unit logistics or packaging cost, and ask which of those grew the most in percentage terms, since a 20 percent blended increase could come from one component spiking or several rising modestly together.

From there the diagnosis branches by cause: a materials spike usually traces to a supplier price increase or a shift to a more expensive input, a labor spike usually traces to wage inflation or lower throughput per worker, hour, and a logistics spike usually traces to fuel costs or a change in shipping mode. I would ask the interviewer for cost-per-component trend data before proposing a fix, because the right lever, renegotiate supplier contracts versus improve labor productivity versus consolidate shipping, depends entirely on which component actually moved.

In most offices, yes, functionally. Solve is used as a gate before a human ever reviews your case-interview readiness, so a poor score typically ends the process without a live interview at all. This is different from failing a live case, where at least one interviewer has seen you think out loud and can advocate for a borderline result.

A few candidate reports describe exceptions, referral-heavy pipelines or specific regional offices where a recruiter manually reviewed a borderline Solve score before deciding, but this is not something to count on. The honest takeaway is to treat Solve prep as seriously as case prep rather than as a formality to click through quickly.

Flat total revenue with declining per-store revenue is a strong signal that store count is growing faster than same-store sales, so before touching pricing or cost structure I would ask for the store count trend over the same period and calculate same-store sales growth separately from total revenue growth.

If new stores are cannibalizing existing ones, opening too close to established locations, that shows up as declining per-store revenue with flat aggregate revenue almost exactly the way this case describes it. I would ask for a map of new-store locations relative to existing ones and for revenue trends segmented by store vintage. The fix, if cannibalization is confirmed, is not a pricing or cost lever at all, it's a real estate and expansion-pace decision, which is a different recommendation than most candidates default to when they hear "declining revenue" and reach straight for a pricing analysis.

Before touching market size, I'd want to understand the regulatory environment for feed additives in China specifically, since agricultural inputs, especially anything framed around altering animal composition, tend to face far stricter and slower approval processes than consumer products do. A large addressable market is irrelevant if the product can't clear regulatory approval within a reasonable timeframe.

Past that gate, I'd look at how Chinese poultry producers currently source feed additives, through domestic manufacturers, through established international suppliers, or through a fragmented mix, because that tells me whether this client would be introducing a genuinely new capability or competing head-on with entrenched local suppliers on price. I'd also ask about the client's existing relationships or lack thereof with distributors in the region, since agricultural inputs in China often move through long-standing regional distribution networks that are hard to break into from outside.

I'd build the decision around three factors per product line: unit cost of production at each plant, given labor, energy, and logistics costs specific to each location, proximity to that product's primary customer base, since freight cost scales with distance, and each plant's existing equipment specialization, since retooling a line to produce something it wasn't built for carries a real capital cost that a simple unit-cost comparison would miss.

The trap here is optimizing purely on current unit cost and ignoring the one-time cost of moving production. A plant with a two percent cost advantage on paper might not be worth the retooling investment if the volume being shifted is small, so I'd ask for both the ongoing cost delta and the one-time transition cost before recommending a full reallocation versus a partial one, keeping some overlap in place where the switching cost doesn't pay back quickly.

This is one of the harder PEI prompts because it asks you to demonstrate influence upward, a genuinely different skill from persuading a peer. The follow-up questions typically dig into how you approached someone with more authority without simply deferring to their initial position, and what specifically shifted their view, new data, a reframed argument, a demonstration rather than an assertion.

Avoid framing this as "I proved I was right," since that reads as combative rather than collaborative, a quality McKinsey weighs under Connection. The strongest versions of this story show you understanding why the senior person held their original view before you tried to change it, then addressing that underlying reasoning directly rather than just repeating your counterargument more forcefully.

Accuracy is close to useless here, a model that predicts the majority class every time can post a 95 percent accuracy on a dataset that's 95 percent one class, while catching zero instances of the minority class that actually matters. I'd move to precision, recall, and F1 for the minority class specifically, and look at the full confusion matrix rather than a single aggregate number.

Beyond the metric choice, I'd also ask what the actual cost of each error type is to the business, since precision and recall trade off against each other and the right operating point on that tradeoff depends on whether a false positive or a false negative is more expensive in this specific context, a fraud model and a churn model usually want very different points on that curve. Precision-recall AUC is often more informative than ROC-AUC on severely imbalanced data, since ROC-AUC can look deceptively strong even when the minority-class precision is poor.

I'd separate what I'm confident about from what I'm genuinely uncertain about rather than presenting the whole recommendation with uniform confidence, since a partner interviewer can usually tell when confidence is performed rather than earned. Naming the specific assumption I'm least sure of, and what additional data would resolve that uncertainty, reads as more credible than defending every part of the recommendation equally hard.

This connects directly to how McKinsey evaluates coachability at the partner level. A candidate who can say "I'd stand behind the core direction, but I'd want to validate this one input before committing resources to it" is demonstrating exactly the kind of calibrated judgment a partner is looking for, distinguishing a well-supported conclusion from a genuinely open question, rather than either blind confidence or reflexive backpedaling the moment pushback arrives.

I'd split this into an ingestion layer, a streaming aggregation layer, and a serving layer, rather than trying to compute aggregates directly against a transactional database, since that database wasn't built for high-frequency read-heavy dashboard queries. Events land in a message queue, Kafka or a managed equivalent, a stream processor consumes them and maintains rolling aggregates in a fast key-value or time-series store, and the dashboard reads from that store rather than touching raw events on every page load.

The design decision I'd want to talk through explicitly is the tradeoff between exact and approximate aggregation. Exact counts require careful handling of late-arriving or duplicate events, deduplication keys, watermarks, while approximate structures like HyperLogLog trade a small, bounded error for much lower memory and computation cost at scale. For a customer-facing dashboard where the number needs to be directionally right but not audited to the penny, I'd lean toward the approximate approach and say so explicitly, since defaulting to "exact everywhere" without weighing that cost is a common gap in candidates who haven't operated a system like this at real scale.

The design decision that matters most here is whether the pipeline is idempotent, whether rerunning the same transformation on the same input twice produces the same output rather than duplicating or corrupting data. If it isn't idempotent, a bug fix requires manually tracking what's already been processed and carefully avoiding double-counting, which is fragile and error-prone at scale.

I'd design the pipeline around a versioned transformation logic and a replay mechanism from raw, untransformed source data, so fixing the bug means bumping a transformation version and re-running the pipeline against the same raw inputs, producing a clean, deterministic re-derivation rather than a patch applied on top of already-corrupted output. Keeping raw data retained long enough to support this kind of replay is a cost tradeoff worth raising explicitly, since some organizations discard raw data too early to make this kind of clean recovery possible.