Hi there,

This is super super hard. Well done identifying how important this is as well as your limitations.

Luckily, I work with a ton of candidates from your region of the world (yes, I know where you're referring to!) and they ARE able to fix this. 

Hard work and no ego are critical to learning this.

Now, I would honestly love to work with you because this does take time (and I've developed learning techniques and a tested process to build you up in this step by step).

Regardless, here's how I describe this thinking below (but it's almost impossible to read text and immediatedly understand/action it):

==========================================

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.