First of all I would like to thank you.
Everything you produced about consulting (video tutorials, emails, etc.) has been helpful in leading me towards receiving multiple job offers - eventually accepting an offer from McKinsey Milan, Italy.
Your materials have been helpful in many different ways, from the psychologic preparation to the technical approach to solving the case.
In my particular experience, your guidance was essential to me in revealing the personality behind the much-feared recruiter and interviewer.
Let's start from my technical preparation in business cases, for the record I'm 24 years old and I hold a MSc in chemical and bio engineering, with no business background whatsoever.
I made use of documents/case method guides such as those from HBS, Kellogg school, Vault WetFeet, your videos and few others.
After a brief look at the frameworks, I started practicing.
I would like to highlight how frameworks were helpful to approach almost any problem, then I found out that I developed my own "decisional analytical reasoning tree."
[VC: I think this person is referring to an issue tree.]
It was a way for me to better handle the dynamic nature of the case compared to the initially-static framework.
[VC: In case interviews, often the problem you think you are solving at the start of the case ends up being quite different by the end. I think this person is referring to this particular aspect of the case which is dynamic and evolves as the case progresses.]
Needless to say: practice, practice, practice! Live, written, creating cases for yourself.
Having said that, what really made a difference was the understanding and insight you gave me about the consulting profession.
It made me much more confident about dealing with the non-case part of the interview. I knew better who the person in front of me was, and what he/she was looking for.
I engaged in more conversation, waiting less "to be interviewed" and looking more for a match between me and the firm.
I found myself thinking of the interview as a way to establish a business contact, rather than looking for a final mark at any given question.
When I did this, interviewers were much more willing to collaborate in cracking the case rather than observing me doing it.
Most interviews ended with them smiling and wishing me good luck. I was happy to spend time with them as well, which I thought was a good sign.
Before receiving the offer from McKinsey, I received one from LEK and one from Bip (a Deloitte strategic spinoff).
I had already decided that Bip was a much better fit over LEK, even though I would have forgone a big name on my consulting resume.
Interviews gave me the chance to evaluate my future colleagues (since both were rather small offices) and work environment.
My recommendation on the non-case part of the interview is to show sincere interest and to look for a true match - since it's going to be a rather tough job.
Engaging in conversation by picking up something personal, debating on interests or career paths, and asking for suggestions worked well for me.
Sooner or later, I will be spending my lunch breaks with that person, so it would be good if we liked each other.
I'm looking forward to doing my best in my career start from next week on!
Your emails will be helpful as always, and I'll keep on reading.
I'd be happy to join the HSMC group, so please let me know whenever you would like to have any reference from Italy.
Congratulations on your LEK and McKinsey Milan offers. I'm glad my materials on case interviews were helpful to you.
Since you found my thoughts on the nature of the consulting business helpful to you, I thought I would elaborate on that topic for others.
During the interview process, it is very easy to forget why the firm is interviewing you in the first place.
From the firm's standpoint, the goal is not to give the best candidate an offer. The ultimate goal of recruiting (from the firm's perspective) is to bill more revenues!
Don't ever forget that!
While most candidates focus on figuring out how to ace the case, what the firm really wants is someone who knows how to "ace the client."
The case interview is simply a heavily time-compressed approximation of doing client work.
When you consider many of the things you mentioned about your recruiting process in this context, it makes perfect sense.
For example, you mentioned that rather than letting yourself be "evaluated," you acted more like a colleague having a two-way, joint problem-solving conversation.
Do McKinsey consultants sit back in a subservient position waiting for clients to evaluate them?
They definitely do not.
They try to engage clients in a collaborative style -- joint problem-solving.
The reason your style of behavior worked well in your interviews is that it is exactly the style that the consultant who is interviewing you will be taking the next day with his or her client.
When you demonstrate this ability in the interview, it is not at all difficult for the interviewer to imagine that you will very likely behave the same way with clients.
The golden rule of thumb on determining if anything you do in a case interview is a good idea can be based on the following question.
If you did this with a client, would it work out well?
So in your case, you mentioned you started off your case interview preparation using frameworks. Then you evolved into using something you called "decisional analytical reasoning tree" which I suspect is the same thing as what I call an issue tree.
You did so because you felt frameworks were very static and didn't capture the dynamic and evolving nature of the case (which not surprisingly is also true of real-world client work).
You ended up using an approach that was still analytical, but more tailored to the case than a framework.
Using the rule of thumb I mentioned before, would it be a good idea to use an analytical problem-solving approach that is more tailored to the client's situation than a "standard" framework?
Therefore, it is a reasonable and even desirable thing to do in a case interview too.
One of the best ways to keep many of these perspective shifts in mind during an interview is to deliberately forget the interviewer is interviewing you.
Think of the interviewer as a consulting colleague looking for your perspective on a particular client (this happens weekly in real life at a consultant firm) or think of the person across the table from you as the client.
Keeping this context in mind, it is also much easier to understand why certain mistakes you might make in a case are considered such big errors.
If you make a major math mistake, in most firms the interviewer has no choice but to reject you. Here's why. If you made a major math mistake in front of the client, would it look bad?
You bet it would. The question the client will ask herself will be, "Why am I paying these consultants $2 million per month when they can't even add or subtract correctly?"
That's not good for creating more billable work.
The same rationale applies to appearing excessively nervous in an interview. Would it be okay if you were excessively nervous in front of a client?
If you were, the client would wonder if you really believe in your own recommendations or not. After, if you were nervous, it would imply (and does imply) that you are uncertain about your conclusions.
Is this good for revenue?
So, this perspective is a useful one to keep in mind.
Before I wrap up, let me circle back to another suggestion that I have made on only one or two occasions that works really well in a case interview (in large part because it works really well in a client meeting).
When drawing out your "decisional analytical reasoning tree" or issue tree, after you draw it out on your pad of paper, turn the pad of paper around 180 degrees and show the client (ahem... I mean interviewer) what you are doing.
This allows the client, I mean interviewer, to do two things:
1) follow your logic in a visual way (Keep in mind that in my experience, 60% of clients are visual learners.)
2) engage in a more collaborative (let's solve this problem together) kind of way, as opposed to a "let me judge you to see if your firm is worth $2 million per month" kind of way.
For example, in my Look Over My Shoulder® program, there are several examples of issue tree diagrams.
You will notice several things about these diagrams.
First, I drew them by hand. They are not diagrams drawn up on some computer program. They were written out by hand with my own handwriting.
Why did I do this deliberately? So, you could see how consultants have meetings with clients... which is the same as how a candidate should have a meeting with an interviewer.
Second, you will notice that the issue diagram shows what the diagram looked like at the end of the interview. The diagram had several branches to it and you will notice that most branches had a big X mark at the end of the branch.
What you did not see from the diagram itself was when, how and why I drew the X mark in each branch of the issue tree.
In terms of when, I put the X mark on a particular branch when I used process of elimination to determine that the root cause of the client's problem was not in that particular branch.
I made a deliberate show of this by showing the client (a.k.a. interviewer) that I was X-ing out this branch. The client could then see that there were still three more branches left.
Next, I tackled the next branch, worked through it until I determine that it too was another dead end. And I drew an X in that branch too.
And the client (or interviewer) can clearly see there are only two more logical branches left. I want the client to visually see this process of eliminating one branch after another until there is one branch left -- which is the root cause of the client's problems.
Clients quite commonly misunderstand their problems. They will mistake a visible result that they do not like (such as a decline in sales or profits) and incorrectly assume the visible issue is the problem... often not realizing the visible issue is actually just a symptom of the underlying problem.
But if you just tell a client that they are wrong, they will often resist and not believe you. It is just like if you tell an interviewer the answer to the case involving a profitability problem is to "fix pricing" before you actually did any analysis, they would not have confidence in your answer (even if your answer is right).
Incidentally, this is why the analytical problem-solving approach is so desired in consulting (as opposed to an intuitive problem-solving approach... think: Steve Jobs).
Both are equally valuable when running a business, but only the analytical problem-solving approach is useful in advising a business operator.
If you are an intuitive problem-solver, this does not help the client much because they probably already have a lot of intuitive problem solvers on staff. Each has their own opinion.
The problem is that they need someone to be a tie-breaker.
Not only that, they need everyone to agree on the tie-breaking decision too.
It is one thing to recommend something to the client, it's an entirely different thing to have the entire client team agree to it. It would be wise to remember this.
So, if you involve all the clients (or interviewers) in your approach... showing them how you are systematically tackling each branch of an issue tree and systematically X-ing out certain branches as you eliminate them, you end up involving them in the process.
This process is very important to not only convey to clients but preferably to include in the process.
If they agree with you that X and Y is not the problem, then by the time you eliminate all the possible root causes to the client's problem except for "Z," then the client really has no choice but to accept the final conclusion (even if it is a conclusion they are not fond of).
I recently did this with a client and one of the clients observed, "it was very interesting how you did not just tell us the answer, but rather you led us to the answer."
I did so deliberately so I could include the client (by client, I mean multiple individuals within the client organization who do not always agree) in the process, so they were more likely to respect, accept and hopefully embrace the output of the process.
People support that which they help build. (That is worth writing down.)
If you involve the client in what you do, they are more likely to support your conclusions.
If you involve the interviewer in what you do, they are more likely to support your conclusions.
One final comment.
As you have probably figured out by now, I have a lot of thoughts and perspectives on the case interview and consulting.
It is surprising even to me that I've written close to 300 articles on this topic, all posted on my blog.
Clearly, I must be opinionated on this topic.
I don't think I am especially opinionated, but even I can't ignore the factual evidence on this one.
I am amused by many of the success story emails I receive.
The ones I find most amusing are the ones where the person followed my advice exactly and, much to their surprise, they got one or more job offers - often at firms more prestigious than they thought themselves capable of getting into.
I find it amusing because they are so surprised that it actually worked!
Here is my big secret in all this.
The reason why my advice works in case interviews is that I simply look at what works with clients and then suggest you do the same thing with interviewers.
That's the secret. That's it.
That is all there is to this business.
Get clients. Serve them really, really well. Bill them a lot.
End of story.
Once you get this general idea, everything else tends to make a lot more sense.