Management Consultant Interview Questions

I would start by structuring the problem before touching any data. Profit is revenue minus costs, so I would split my initial hypothesis into two branches: is this a revenue problem, a cost problem, or both? For revenue I would look at volume, price, and mix. For costs I would separate fixed from variable and check whether unit costs have changed. I would then ask the interviewer for the data points most likely to confirm or rule out each branch quickly. In a real engagement I would map this into an issue tree on day one and align with the client before going deep on any single area. The goal is to spend the first 48 hours narrowing the hypothesis space, not analysing everything at once. Clear structure up front saves weeks of wasted analysis.

I lead with the recommendation, not the analysis. Senior executives want to know what to do and why it matters before they want to know how I arrived there. In practice that means my first slide states the recommendation clearly, the second covers the three strongest supporting arguments, and the third addresses the most likely objections. I keep charts simple: one message per chart, labelled so the takeaway is visible without reading the body text. I also anticipate the questions the CFO or COO will ask and build one appendix slide per key objection so I can answer immediately without leaving the room. I practise saying the recommendation out loud in one sentence before any major presentation. If I cannot do that, the thinking is not clear enough yet.

I treat it as the most valuable moment in the analysis. If the data contradicts the hypothesis, either the hypothesis was wrong or the data has a quality issue. My first step is to check the data: source, vintage, how it was collected, and whether it is internally consistent. If the data is sound, I update the hypothesis and communicate the change clearly to the team and the client. I do not hold onto a hypothesis because I am attached to it. On one project I had built a market sizing model showing significant growth potential, but transaction data from the client showed the opposite trend. Rather than smoothing over the gap, I dug into the discrepancy and found that the market data excluded a major distribution channel. That change shifted the entire strategy recommendation. Updating your view when the evidence changes is not a weakness.

At my previous firm I was working with a finance director who was openly sceptical of the project and pushed back on every interim finding. Rather than escalating, I requested a one-to-one meeting early in week two to understand his concerns directly. He told me the last consultancy had made promises they did not deliver and left the team with more work. I acknowledged that history and agreed to share a working document of our findings each Friday rather than waiting for a formal deliverable. Within three weeks the dynamic shifted: he started flagging data sources proactively and even vouched for our recommendation in the final board presentation. The lesson was that client resistance often comes from prior experience, not the current work. Addressing it directly and early changes the relationship.

During a cost transformation project, my analysis showed that the client's most profitable business unit was significantly subsidising three underperforming divisions. The CEO had publicly committed to growing all four divisions. I knew the finding would be uncomfortable. I prepared a concise one-page summary with the evidence, the financial impact quantified clearly, and two strategic options rather than a single "here is the problem" slide. I briefed the project sponsor privately before the board meeting so she was not surprised, and I framed the findings as choices the leadership team now had the information to make, not as a verdict on past decisions. The CEO later said that framing was the reason the board engaged constructively rather than defensively. Delivering hard news is about giving people agency, not just accuracy.

On a post-merger integration project, the operations team and the commercial team had fundamentally different views on which systems to consolidate first. Operations wanted to prioritise the ERP to cut costs quickly. Commercial wanted to keep their CRM untouched to protect client relationships during the transition. I mapped each group's core concern and the risk they were trying to avoid, then designed a sequencing proposal that ring-fenced the CRM for the first six months while beginning ERP consolidation in the back-office functions that had no client-facing exposure. I presented it as a risk-managed path rather than a compromise, showing the cost and timeline impact of each sequence. Both teams agreed. The key was making each group feel their primary concern had been heard and reflected in the plan, not traded away.

I work hypothesis-first. Before I request data I write down what I expect to find and what it would take to change my view. That discipline keeps analysis focused: I am testing specific claims, not mining for anything interesting. For quantitative analysis I typically build a model in Excel that traces from primary data to the final output, with every assumption documented and sensitised. I run at least two sensitivity scenarios so the client can see how the recommendation holds under different conditions. For qualitative data I use structured interviews with a consistent question set so I can identify patterns across respondents rather than relying on individual anecdotes. I always triangulate: one data source confirming a finding gives me a hypothesis, two independent sources give me confidence, three give me a recommendation I am willing to defend in a boardroom.

I structure a business case around three questions: what is the opportunity, what does it cost to capture it, and what are the risks. For the opportunity I quantify the addressable value using market data, internal benchmarks, or comparable case studies depending on what is available. For costs I separate capital expenditure from operating expenditure and distinguish one-time implementation costs from ongoing run costs. For the financial model I project cash flows over three to five years, calculate NPV and IRR, and include a payback period because that is often the metric executives focus on first. The risk section covers the two or three assumptions the entire business case rests on and what happens to the returns if those assumptions are wrong by 20%. A business case that does not show its own failure conditions is not credible.

MECE, mutually exclusive and collectively exhaustive, is the discipline I apply when building an issue tree. The goal is to break a problem into parts that do not overlap and together cover all possible causes. In practice I start by identifying the one or two dimensions that most cleanly separate the problem space. For a revenue problem that might be new customers versus existing customers, or product line A versus product line B. I then test each branch: if I addressed this branch fully, would I have explained a meaningful portion of the problem? If branches overlap, I redraw the tree. I also watch for branches that feel MECE on paper but collapse in practice because the underlying data does not separate cleanly along those lines. The issue tree is a thinking tool, not a presentation template: it should be stress-tested before you share it with a client.