Management Consultant Interview Questions

I would build it top-down and sanity-check it bottom-up. Top-down: total two-wheeler sales in India per year, the share that is electric today, and a penetration path driven by price parity, charging access, and policy. Bottom-up: households in the target income bands in the cities where charging is viable, replacement cycle, and realistic conversion. I would state my assumptions as I go so the interviewer can redirect me. The strongest answers end by naming which single assumption the estimate is most sensitive to.

I would find out what is driving it, because a client asking for a specific answer usually has a constraint they have not said out loud — a commitment already made, or an internal position they need to defend. Then I would show what the analysis supports and what it would take for their preferred option to be right, rather than simply refusing. If they proceed anyway, I would document the risk clearly and stay useful. A strong answer neither caves nor turns it into a confrontation about being right.

I would start by mapping the cost base and finding where the money actually is, because effort spent on small lines is wasted regardless of how easy they are to cut. Then split it into structural cost, which needs a decision at the top, and operational waste, which the business can fix itself. I would size each opportunity with an implementation difficulty and a time to realise. The strongest answers include what should not be cut — the spend that is currently producing the growth or protecting the licence to operate.

From the structure of the problem and whatever is already known: what the client believes, what the economics of that industry usually look like, and what pattern similar situations follow. A first hypothesis is a way to make the analysis efficient, not a conclusion — it tells me which three things to test first instead of boiling the ocean. I would state it as something falsifiable, so the first piece of data can kill it. A strong answer shows willingness to abandon it quickly.

I would work out whether the gap actually changes the answer, since a lot of missing data is not decision-relevant. Where it matters, I would triangulate: a different internal source, an industry benchmark, a sample collected directly, or a bounded estimate with a stated range. Then I would show the conclusion under both the optimistic and pessimistic assumption, so the recommendation stands or falls visibly. A strong answer never quietly fills a hole with a number that later gets quoted as fact.

I would not deliver it cold in a large meeting. I would socialise it first with the person whose area it touches so they are not ambushed in front of peers, lead with the evidence rather than the conclusion, and separate the finding from any implied blame. Then I would come with options, because a finding without a path forward invites the room to attack the analysis. A strong answer accepts that being right is not the objective — the decision changing is.

Four weeks buys one question answered well, so the scoping conversation is about choosing that question and explicitly parking the rest. The workplan is front-loaded, relies on data the client already has, and produces a decision rather than a strategy. Six months allows genuine discovery, primary research, and implementation support, so the risk shifts from scope to momentum — keeping the client engaged and the workstreams honest. A strong answer names the failure mode of each: superficiality on one side, drift on the other.

I would run the analysis that could change the recommendation and skip the one that only makes it more confident. Before starting each, I would ask what result would make us act differently — if there is no such result, it is decoration. Under time pressure I would also prefer the analysis that is quick and directionally right over the one that is precise and late. A strong answer admits which analyses they skipped and what risk that leaves in the answer.

I would test it against capability, capacity, and incentive: does the organisation have the skills, does it have the people and money free rather than committed, and does anyone with power lose if it succeeds. Most strategies fail on the third one. I would also look for the smallest real-world test — one region, one product line — that would show whether the assumptions hold before the full commitment. A strong answer treats implementation capacity as part of the strategy rather than as someone else’s problem.

I would fix what I can inside the team first — resequencing, reallocating, cutting an analysis that is not decision-relevant — and set myself a date by which it has to be back on track. If it is not, the client hears it from me early and in the routine update rather than as a crisis, framed with the impact and the options. Hiding it is what turns a manageable slip into a trust problem. A strong answer is specific about the point at which they stop absorbing it.

I would name the dynamic rather than pretend it is not there, be clear about what the work is and is not, and be honest that I cannot promise outcomes I do not control. Then I would ask about their work in a way that treats them as the expert, because they usually are, and follow up on something they said so they can see it mattered. A strong answer recognises that guarded answers are rational and does not treat the person as obstructive.

I would define what would change if the benefit were real, then find the nearest measurable proxy for that — time spent, error rate, rework, churn among the affected group. Where nothing exists, I would build a defensible estimate from a small sample or a structured expert view, and present it as a range with the assumptions visible. The point is to make it arguable rather than to make it precise. A strong answer says what evidence would move the estimate, so the number can improve rather than becoming folklore.

In my last Management Consultant project, I found a repeated bottleneck in structured thinking, analysis, recommendations, and executive communication and turned it into a focused improvement plan. I defined the baseline, aligned the team on the metric, shipped the change in two iterations, and reviewed the result after launch. The strongest version of this answer names the exact metric you moved, the decision you owned, and the tradeoff you made to get the result without hiding team contributions.

I would describe a situation where I needed buy-in from a peer team or senior stakeholder, then show how I earned trust with evidence rather than pressure. A strong answer explains the other person’s concern, the evidence I used to reduce their risk — in Management Consultant work that usually means something concrete drawn from structured thinking, analysis, recommendations, and executive communication — and the compromise that moved the work forward. The outcome should show influence through clarity, not title power.

I would pick feedback that changed a real work habit, not a harmless weakness. For example, I once received feedback that my updates were too technical for business stakeholders, so I started sending one-line context, impact, risk, and next step summaries before deeper detail. For a Management Consultant the feedback worth choosing is one that changed how you handle structured thinking, analysis, recommendations, and executive communication. The answer should end with evidence that the change stuck, such as faster decisions, fewer clarification meetings, or better stakeholder confidence.