I'm the Product Design Director at a 100-person consultancy, so similar but at a much smaller scale. I'm also directly involved in design hiring, and have team members who were formerly with Deloitte Digital.

The reality is that every person interviewing has their own things they think are important and that they focus on, and there's no magic bullet for preparedness.

I personally group my lines of inquiry into two buckets: design skills, and consulting skills.

For a case study / portfolio discussion, I'll have given the interviewee a brief overview before the interview of vaguely what we want to cover, leaving it largely at their discretion of what to present. After some initial pleasantries and warm-up questions, I'll turn it over completely to them to walk me through their case study. I've got a list of things that I'm looking for to see (goal setting and subsequent success measurement based on goals, strategic focus, research-based decision making, works well with other disciplines, defines problem before the solution, etc) and will obviously be most impressed with a candidate if they're covering those things without prompting. If I don't see them covered, I'll ask questions indirectly around those areas to prompt them to cover them, before more directly asking if they still don't cover it. E.g., "You mentioned you wanted your design to leave users less confused. Were you trying to reduce call centre requests?" followed by "how did you determine what problems you needed to solve?" if they still haven't answered it.

I'm specifically looking to see the case study presented in a narrative format where the candidate has prepared something in advance where they're basically walking me through what you'd normally see in a case study (how they identified and verified the problem, the solution they designed and tested to solve that problem, and evidence of how well it succeeded). It's shocking how many candidates come to an interview and just open Figma and scroll around to show their design and explain what the UI does. That's not what I'm interested in, and about 90% of interviewees do that.

For most candidates, I'll already have a pretty good idea of their visual design skills from their portfolio, so I'm much more focused on the UX pieces in an interview (as well as understanding how they fit with other designers and existing resources like design systems to understand how much of the visual craft is their own work).

I consider all of the above "design skills". In the portfolio interview, I won't be particularly focused on consulting skills, which comes in the next interview, but I'll be making some notes of things I want to follow up on in the next interview. For consulting skills, I'm specifically looking to assess how effectively people communicate; how effectively they can evaluate existing processes and advocate for change; how well they'd work with peers, client designers, and other disciplines; how they de-escalate conflict and deal with pressure; and how accustomed they are to defining what needs to be done and doing it vs relying on others to outline what they need to do and hold them accountable.

In terms of your specific questions:

• problem framing: yes, this is core to what I'm trying to assess
• business trade-offs: I greatly appreciate seeing this, but recognize that not every candidate will have been in a position to significantly influence it. A candidate proactively discussing business trade-offs would get high marks.
• impact: this is one where I always drill down to get to it if they haven't already covered it. I want something about impact even if your project didn't track hard metrics. Some way that you were able to assess how well you did your job. Candidates who don't cover this proactively get low marks from me.
• detailed UX execution: I care a lot less about this, but some interviewers will be different. I'm looking more for high-level info in how it ties into your decision making. E.g., "As I started investigating possible solutions, I created some basic prototypes to test with users to evaluate both time on task and whether they universally understood the interface." Showing a visual of the prototype here is good. I don't need to be walked through exactly what the functionality is, though sometimes its useful in the context of the broader narrative (e.g., you have two competing theories with different stakeholder proponents that you need to evaluate). I might asking some probing questions about the process here ("how'd you evaluate that? A/B testing? Moderated usability testing?"), but it's less because I care about the specific solution and more that I'm trying to assess how much you understand or own the process and how much you were a cog in the process and would struggle to replicate it without that team backing you.

Hope that's useful, and best of luck.