Question:
Thank you for creating the Case Interview Secrets videos and Look Over My Shoulder® program. It is the most practical and intuitive resource on the market, in my opinion.
My question is related to note-taking during the interview. What I am struggling with is keeping up with the interviewer, and still trying to note down key facts. In addition, I don’t seem to structure the information very well on the page.
What is your advice on how to get this right and how to strike a balance between just listening to the interviewer versus noting all the facts down?
Do you have examples of how the problem could have been structured on paper from your Look Over My Shoulder® program that you could share?
My Reply:
In the Look Over My Shoulder®, see the PDF files on issue trees. These are examples of the note-taking approach I recommend during a case study interview.
In general, I take two sets of notes in an interview, one is for general facts & computations. The other is for the structure of the case (this is the issue tree and this is the set of notes you would show the interviewer).
When I hear information in a case, I am at the same time making note of the key facts and processing how this new information is or is not relevant to the case.
This is primarily in the opening of the case where there tends to be a lot of information coming at you at once (at least relative to the latter parts of the case).
Once you’re into a candidate-led case, the data tends to come in small pieces by request only. Rather than trying to write everything down, I’m mainly thinking about what my hypothesis is and whether or not the new information proves or disproves the hypothesis — which is basically the issue tree note-taking structure I mentioned earlier.
This is how I filter information — based on relevance to the hypothesis. All information you receive in a case is not created equally. Some information is more important than others. The hypothesis is how I filter what is important vs. not.
Once a branch of an issue tree has been eliminated as a possible issue, I mentally push all the data that I needed to determine that mini-conclusion to the back of my mind.
So, if in a profitability case, I explore cost and sales… and determine costs are not the cause, then I tend to stop trying to remember cost information.
I hesitate to say I just forget the information because I don’t. I sort of stick it in my passive memory so that if the interviewer (or client) says something that is related to that cost data, it acts as a “trigger” to pull it out of passive memory into active memory.
The other thing I notice is when the information presented is totally opposite of what I was expecting, given my hypothesis.
More often than not, you’re on the verge of a big insight into the case and that is the moment where the great candidates explore what they found to be unusual, whereas the other candidates notice it is unusual but don’t actually do anything different in the case.
You will notice this a lot in the audio portion of Look Over My Shoulder®. The candidate says with a very particular voice inflection, “Ohhh… Hmmm.. that’s interesting.” That is often the signal of the magical three seconds in the case where the case is either about to be totally solved or totally missed.
If you have been reading the transcript version of Look Over My Shoulder®, you will totally miss this point because it is more of voice inflection than a particular phrase.
Literally, every candidate I interviewed, whether they did well on the case or poorly… everyone was able to grasp the “Ohhh… that’s interesting” moment.
Every candidate noticed the unexpected piece of information as something a little unusual. And it is that precise second where great case performers vs. average performers diverge in their performance.
The average performer pauses momentarily, then continues onto the next question in the standard list of framework questions. Big mistake.
(This is what interviewers mean when they complain a candidate is overly framework driven… they are so focused on the framework that they don’t even realize they just uncovered the key to solving the entire case.)
(This is also why case interview practice helps so much — once you practice the general case interview and framework skills enough, you can devote your mental energy to listening for those breakthrough moments in the case.)
The great performer immediately stops and figures out what’s going on. When I did case interviews years ago, and I do client phone meetings today, I have a very specific behavior that I do when I discover one of these unexpected pieces of data.
I am a relentless, analytical pitbull that absolutely positively would not quit until I figured out why and how the business works to produce a numerical result that I found unusual.
For example, if I discover the client has 45% profit margins but all the other competitors have 30% profit margins… Ding Ding Ding… the alarm bells go off and I start asking why does the client have higher margins?
How does their manufacturing process work such that it has a lower cost structure? Why are customers willing to pay so much more for the client’s product, but not anyone else’s?
In other words, I shift from seeking to analyze, to seeking to understand.
(In my opinion, that last sentence is probably the key to my success in cases… and in my current consulting work.)
A business metric is only unusual if you don’t understand the business. So anytime I saw a number that seemed unusual or counterintuitive, I intuitively recognized it as a signal that, “I really don’t understand how and why this business works.” — and would take the time to ask questions to figure it out.
I cannot emphasize enough how much of a big deal this is.
Notice how all these questions are qualitative in nature. This is where a lot of PhD-type candidates make a big mistake. They grasp all the math but sometimes miss the qualitative. You need to be relentless at both.
When there is case interview math, you need to drill down into the numbers. When your quantitative analysis uncovers something counter-intuitive, you need to drill down qualitatively too.
Great case interview performers are able to do both well.
Going back to my note-taking approach, I find I tend not to take too many notes. I definitely do not write everything down. I will write down key numbers to avoid making a mistake, but I tend to memorize most qualitative information and usually write down a few keywords to trigger the memory.
In my head, I do not take business notes as a collection of facts… but rather I paint a picture in my head of how this business works. So, like a photographer who instead of remembering a particular person’s eyes, ears, nose, and cheeks, remembers a person’s “face”… I do the same thing.
My memory is of the whole, not the sum of the parts, if that makes any sense.
(Keep in mind this is how I do it, and I fully recognize there are multiple ways to be effective in terms of note-taking and memory style.)
The main reason for this fairly light note-taking approach is I’m spending most of my time listening to what is being said in the case and seeking out that counter-intuitive piece of data that cracks the code of the case.
In a 40-minute case, I will probably have one to three pages of notes. Some of the candidates I interviewed for Look Over My Shoulder® had nine pages of notes in a 40-minute case. If you have this many pages of notes, it’s impossible to find anything.
For a candidate that tends to do this, most likely they recorded all the details of the case, but few of the insights. Details vs. Insights — they are not the same thing.
If you want to see what this voice inflection/turning point moment sounds like and to see the actual notes used during a case, see cases #2, #4, and #5 in Look Over My Shoulder®.
In giving cases to around 20 candidates for Look Over My Shoulder®, I ran into a problem that for a few of my cases, nobody got the case exactly right. Keep in mind the audio recordings in Look Over my Shoulder®, were real candidates — not actors.
So, the problem I had was for some cases, I was missing a “best practices” version of how a candidate solves a case.
In a weird twist, I had to actually interview myself and use the computer to edit the interview so it sounds natural.
In these cases, where I essentially interviewed myself, you will see my handwritten notes on how I took notes as a candidate. In addition, you will see the language pattern, the voice inflection, and the “drill down” analysis following a key insight.
In addition, you can compare the “best practice” version of the case to candidates who did not do as well and see for yourself the differences between the two.
Here’s another interesting exercise. Listen to the “best practice” case and without referring to any of my documents, see if you can draw an issue tree outlining the structure and logic the candidate is using.
You will notice in most cases the process is quite easy. The candidate says there are three key areas they want to focus on, you draw an issue tree with three issues. The candidate explores branch 1 and determines it is a dead end and is now moving on to branch 2. This makes it very easy for you to draw out the issue tree and follow in the footsteps of the candidate.
Now, try to do the same issue tree note-taking exercise with the candidates who did not do as well on the case. In almost every case, you find out it is impossible.
The candidate doesn’t know how many issues he wants to explore, so it’s impossible to draw the issue tree. The candidate starts off in branch 1, doesn’t finish branch 1, and jumps to the middle of branch 3. Then the candidate gets a pet idea and wants to add a new branch to the case — branch 4.
In comparison to the clean lines of the “best practice” issue tree, an attempt to draw an issue tree around the words used by a candidate that is not strong will look like a bunch of tangled wires.