**Question:**

Firstly, thank you for the vast amount of material that you have put up on the website - more especially that the majority of it is free. On this note, also thank you for recently updating the LOMS program for the McKinsey's "Interviewer-Led" cases - of which I just had two yesterday with McKinsey. I found it quite helpful in my last week of preparation and I believe it might have contributed to the great feedback - with one exception though - that I received from the interviewers.

The feedback was that the structure and the use of the issue tree was great - I did demonstrate logic and structure in my responses. However, I made a minor mistake on the numbers such that I was about 300% off from the correct number. The interviewer asked whether the figure made sense to me given the issue at hand and I had some ideas on the issues but failed to address the critical one that the figure was just too little and far off from the correct figure. One of the problems I had is that I was saying the right things and saying out loud the right approach but I did not do the calculations correctly - instead of multiplying, I divided, and you can imagine what kind of effect that could have had on the final figures.

Based on that, the feedback was that I will need to do another interview in order to assess my ability to sense check figures before they could recommend to the final rounds of interviews. The challenge now is that I don't know what I should be doing or what kind of cases I should be looking out for in order to improve this skill over a short period of time. I was wondering if you might be able to assist in this respect.

Your immediate response - hopefully before this third round interview - would be highly appreciated.

Once again, thank you very much for your contribution to my success thus far.

**My Reply:**

You must have done exceptionally well on the rest for them to allow you another interview, given the math error. Ninety-nine percent of the time, the math error would result in a rejection.

Two things to be aware of for next time:

1) On the math, *slow down *and be sure you're correct on your math.

If you re-listen to my commentary of the interviewer-led cases, you might recall my suggestion on writing out the formula in words before doing the computations.

As in (over simplified):

Line 1) Profit = Revenue - Cost

Line 2) Profit = $10 - $5

Line 3) $10 - $5 = $5

Most candidates immediately jump to Line #3, but I generally recommend taking the extra effort to write Line #1... mostly to prevent yourself from being confused.

For example, when you spot check the following line:

Line 3) $10 + $5 = $15

It's much harder to notice the error, because the actual computation you did was correct. $10 + $5 does after all = $15.

But, if you write the extra line, it is much easier to spot the error. Here's an example:

Line 1) Profit = Revenue - Cost

Line 2) Profit = $10 + $5

Line 3) Profit = $15

By writing out the extra step.. especially Line #1, you can do a reasonable test very quickly.

You would look at the computation, but then you'd conclude that Profits *exceed* Revenue... wait a minute, that's not possible in the real world.

That would in theory prompt you to re-check your work, and as you compare Line #2 to Line #1, you could easily notice the change in the - sign to a + sign.

2) Moving on to the other skill of testing "Reasonableness" of a number, there's a brief blurb in the 2nd candidate, Case 7 or 8 where I talk about checking reasonableness. It is the one with the female candidate.

At all times, you should have some ballpark sense of how many zeros you expect in the answer.

For example, if the market size is $100 Million, and competitor #1 has 17.9% market share, I'm expecting the competitor's sales to be around $20 million.

If there's a competitor #2 that's a little smaller than this, I'm guess the number should be in the mid-teen millions... say $13M - $19M range.

So if I do a calculation where I compute revenues from competitor #2 as $500,000, I say, "Wait... that doesn't seem reasonable, given the other data."

This is known as "triangulation" -- you try multiple approaches to calculate a number, or a reasonable range for a number. If you calculate a number three different ways, and you got the same approximate answer, then most working consultants would deem that number "reasonable."

The "reasonable" test is usually applied to making estimates, as in: estimate the market size of X product. We might use three different methodologies to estimate and see if they all give us the same answer.

For the kinds of computations you'll see in a McKinsey interviewer-led case, you can use a similar approach.

One of the techniques used in determining reasonableness is "bracketing." Bracketing is a way of confidently determining a number that you're certain is *above* the actual number... and one that is definitely *below*.

It is the process of establishing a high / low range for a particular number.

For example, let's say you're working on a case where you're asked to compute the impact of changes in the client's pricing strategy and how it would impact profits.

If you lower the price, you would expect the new profit to be *lower* than the profit with the previous price.

If you lower the price by 10% on a product which originally had a 22% profit margin (defined as profit / price), you should ideally notice two things while doing this calculation slowly:

Observation #1: By dropping the price, you're actually dropping the profit margin by around 50% or so.

Observation #2: The # units sold would have to approximately double for profits to stay the same.

So if the scenario is: "client drops prices by 10% and volume increases by 250%," before you even do the actual math calculation, you would expect that overall profits would be higher than under the original scenario.

Here's the secret to doing this type of reasonableness checking well:

You need to *think holistically* during the case... *not just do what you're told*.

Observations 1 & 2 above are things you should ideally notice if you're "thinking" during the case. But most likely in such an example, the interviewer will not explicitly ask you about #1 and #2.

If I were to venture a guess, I would say that your mindset going into the interview was to "solve the case," when in many ways it should have been to "serve the client."

The former involves answering the explicit interview questions asked. The latter involves being thoughtfully analytical and bigger picture oriented *while* answering the explicit questions.

In addition, when you synthesize a case, you want to answer the explicit questions asked, and then mention the other issues you notice that if time permitted would be interesting to examine further.

Again, this is just an educated guess based on my experience. I don't mean to imply you weren't thinking at all during the case, but I suspect you weren't thinking broadly enough about the case. If you had, you should have been able to have some sense of what to expect for the final computation... and notice when the math resulted in an answer that deviated from this expectation.

Incidentally, the reason McKinsey cares so much about this skill is because it potentially risks embarassing the firm with a client.

Analysts and Associates *do *make mistakes from time to time. The key is that with a McKinsey analyst and associate, it's expected that you would be able to notice and catch your own mistakes before a client ever sees your work.

So when you say you don't know how you would check the reasonableness of your answers, what the interviewer hears is "I do not know how to double-check my numbers to see if they seem right. Therefore my analysis can never be trusted. A manager must always double check my math every time."

That's not what you said, but I guarantee you that's how the McKinsey interviewer interpreted your answer.

For practice, I suggest going through the *transcripts* of the interviewer-led LOMS cases, and this time do so with the intent of doing a reasonableness check for each case. By getting accustomed to this process, you'll be better able to do it in an interview.

In addition, if an interviewer ever says, "is this number reasonable?" or "how would you determine if this number is reasonable?"...*never* say you have no idea.

If you must, *stall* for time and figure out some way to cross-validate your number. Seventy percent of the time, this comment from an interviewer is a hint that you made a math mistake. Thirty percent of the time they want to test your confidence level in your answer, and to observe how you determine whether that confidence is justified. And in both cases, they want you to do a reasonableness check.