More depth

Hi there,

Honestly structuring is the hardest thing to solve on your own. I highly highly recommend a coach because there's nowhere else you can get direct feedback/advice based on your specific frameworking/structuring. If you have already failed 2 interviews, something is wrong that needs targeted training!

Think about it: What if you had invested in yourself prior to the McKinsey interview? What would you do now, in hindsight, to ensure you got the offer?

If a $150k/yr job isn't worth a $1k coaching investment, I don't know what is.

I've collated some of my past advice on structuring/problem-solving here, which I hope can help you regardless of coaching or not!

Note: Take a look at this Q&A where I get into a fun/lively discussion with Tyrion. It should help: https://www.preplounge.com/en/consulting-forum/hypothesis-in-case-interview-15948

Frameworking/Case Driving

First, remember that casing isn't just about memorizing every step, industry, case type, etc. It's about learning how to be adaptable and nimble. So, always be prepared for the unexpected.

1. All cases are structured, wheather you realise the structure or not. It's your job to keep it organised and keep it to a good flow/framework!

2. Figure out what data/information you need and ask for it: The interviewer won't just give it to you (just like your client won't know what you need from them). Use your framework to dive into areas! If your interviewer insists they don't have data in that area (after you've gone specific), then go into another area of your framework (or expand out).

3.In this case try and keep a mini framework in your head. You can write as you talk as well.

When you say "not those kinds of questions an interview-led style would ask" this shows me that you're limited in your preparation....don't come in expecting a certain format/style! Be ready to drive your own case if needed. Think if you were on a real life project and asked to lead it...this is what they need you to demonstrate!

Frameworks

If there's anything to remember in this process, is that cases don't exist just because. They have come about because of a real need to simulate the world you will be in when you are hopefully hired. As such, remember that they are a simplified version of what we do, and they test you in those areas.

As such, remember that a framework is a guide, not a mandate. In the real-world, we do not go into a client and say "right, we have a framework that says we need to look at x, y, and z and that's exactly what we're going to do". Rather, we come in with a view, a hypothesis, a plan of attack. The moment this view is created, it's wrong! Same with your framework. The point is that it gives us and you a starting point. We can say "right, part 1 of framework is around this. Let's dig around and see if it helps us get to the answer". If it does, great, we go further (but specific elements of it will certainly be wrong). If it doesn't, we move on.

So, in summary, learn your frameworks, use the ones you like, add/remove to them if the specific case calls for it, and always be prepared to be wrong. Focus rather on having a view, refering back to the initial view to see what is still there and where you need to dive into next to solve the problem.

Framework Advice #2

Now, in terms of tips, #1 most important thing is to be objective-driven. Not hypothesis-driven, but objective driven. Remember that there are 2 objectives: 1) the objective of the case (what is the question I'm trying to solve) and 2) The objective of the client (what are their needs, wants, desires. What does "good" look like)

Furthermore, If there's anything to remember in this process, is that cases don't exist just because. They have come about because of a real need to simulate the world you will be in when you are hopefully hired. As such, remember that they are a simplified version of what we do, and they test you in those areas.

As such, remember that a framework is a guide, not a mandate. In the real-world, we do not go into a client and say "right, we have a framework that says we need to look at x, y, and z and that's exactly what we're going to do". Rather, we come in with a view, a hypothesis, a plan of attack. The moment this view is created, it's wrong! Same with your framework. The point is that it gives us and you a starting point. We can say "right, part 1 of framework is around this. Let's dig around and see if it helps us get to the answer". If it does, great, we go further (but specific elements of it will certainly be wrong). If it doesn't, we move on.

So, you should absolutely be prepared to either enter a new piece of your framework or change your framework altogether as new information comes in. How do you handle this?

Well, first, you can really just articulate what you're doing. You can say "Oh, interesting, so if looks like we have some information on y. I don't want to forget about x, but let's see what y brings us first. Ok, looks like it's about..." Then, when you've "finished" with y, you can check to see if there's any info on x. If there isn't, move to z :)

Second, you can re-summarize/iterate where you are. This is especially useful if you have the change the entire framework. Say "Ok, so it looks like now we actually need to look a 3 key things to solve this"

So, in summary, learn your frameworks, use the ones you like, add/remove to them if the specific case calls for it, and always be prepared to be wrong. Focus rather on having a view, refering back to the initial view to see what is still there and where you need to dive into next to solve the problem.

HOW to learn/think in the right way.

1. Frame based on the objective: Identify exactly what the objective is, then think about the areas you would look at to solve the problem.
2. Think of buckets as "building blocks" - understand the 10-odd buckets that exist out them (Market, Product, Company, How to Enter, etc.). Learn these, and what their used for, then think of them as ingredients that you then pluck out and tailor to your framework.
3. Practice with Introduction, then End, then framework:
   1. ​ Practice a number of cases where you hear just the introduction, then build a framework.
   2. THEN, look at the end of the case and what conclusion was made, and re-do your framework.
   3. THEN, look at what framework(s) was/were proposed as the answer.
4. Read the Economist religiously: The Economist is an excellent, longer-term base knowledge/thinking resource for you. I've found that reading the Economist over the years has been instrumental in helping to shape my thinking and holistically understand problems, whether political, economic, social, or anything in between. Feel free to throw in the Financial Times or BCG Insights into the mix!

Hello,

Great question! In my experience, many candidates who get feedback around increasing depth stick a little too close to cookie-cutter frameworks, and don't try to delve deeper into the specifics of the case. I'd suggest the following tips:

• Make sure you are always incorporating case specifics into your framework. To do so, make sure you fully understand the business model or any additional specifics and goals you are presented with in the case, and ask clarifying questions if something is unclear. 
• When you practice case interviews, try build out the branches to 1 extra level of detail than you usually do. This might seem messy and time-intensive at first, and there certainly is a limit to how much detail you want to go into in the actual interview. But given the feedback you received, I would use practice sessions as an opportunity to work on providing more nuance and detail in all parts of your framework. As you keep doing this more and more, some of it will come more naturally, and with some practice you should be able to arrive at a more comfortable middle ground where you are providing more detail but it is not taking up too much time.
• Providing examples is a great idea! For instance, in your second bullet point ("moving all revenues to online channels and closing all stores vs. providing online channels as optional addition to physical stores; and everything in between"), there are tons of options for streamlining revenue that you could consider here. Instead of trying to list them all out, you could come up with a few examples within each branch that you think would be most suitable for the business. E.g., something along the lines of “streamlining revenue: this could involve providing online channels in addition to physical stores, focusing on the physical footprint but closing lower performing stores, or moving all revenues to online channels and closing all stores. The first option in particular could be particularly attractive for our client since it is a well-established brand whose physical stores have many loyal customers”, or something like that. 

I know this advice seems a bit general, and unfortunately it's hard to get too specific without actually seeing you do a case. I would be happy to help you with this more directly if you are interested in getting coaching to help here - even one session can be helpful for pinpointing what exactly could be improved and how to work on it. Best of luck in your prep!

Great question – and easily something you can add to make yourself stand out as a candidate. 

When it comes to the framework step, you don't want to ramble for too long but want to provide great first-level hypotheses. After you've laid out your framework, I'd recommend sharing some questions that would fall in each bucket/tier and why you're interested in answering them (make this one sentence – “We might ask a question around the company's historical performance in this vertical because it could give perspective on whether this is an isolated case requiring further probing”). About 2-3 additional statements for each bucket/tier is sufficient. 

I hope that helps!

Dear candidate, this is a common questions and important to grasp.

First, alternatives are, in case it is still challenging:

A) super overall handling of the case, even if no outstanding answers given

B) uniquely stand out in the interview mentioning specific elements you stand for so that there is an early clarity in the interview that you are a great candidate. Some experienced hires for example get away with this as they are great at overall performance, have expertise but may not be as familiar in handling cases.

3) if you have time to tackle before your interview, the following really helps: a) practice after each of your statements end with the so-whats, the suggestions of what this means for the overall case solutions and what routes you would go next and why. Also specifically suggest options that go beyond the standard OR that cone from your own experience, so you can stand out and solve the case your own way

2) throughout the case show that you understand the context and use industry examples and situation examples so it becomes interesting. For example if it is a flour producer then don't just answer : they could sell more products or innovate in technology, but state they could sell more products, for example expand into bread baking mixes, sweets like cake mixes and potentially also mill other products such as couscous, seeds etc.

3) another option that helps if you practice cases is to ask your interviewer to do the interview such that both of you pause after your individual answers and discuss them, improve them and then move on to the next question. This why you gain a lot of experience on this in creativity and sometimes more feedback than if you do interview-styke (both styles great depending on occasion). I personally much like the first mentioned coaching style to help candidates grasp great casing and would suggest you try it out.

Best regards,

Hi there,

in addition to what you say (branch out tree, provide examples). It is very important to make your structure industry/case specific. Do not use a generic structure. This requires some practice. Happy to help.

Cheers

Hi there, 

One exercise that I often recommend is to practice without a timer. 

Take the first question from a case and instead of the usual 1 minute thinking time, take unlimited time. Basically only stop to check the answer when you feel like you've come up with the best structured, most exhaustive, most elegant answer you could possibly come up with. Then try to understand from the solution in the case book whether there is anything that you've missed out on. 

Then gradually re-apply the time pressure. 

Best,
Cristian