Some of these are great tips and I agree wholeheartedly. However, in personal experience, I've found that this works much better with more experienced develope

Some of these are great tips and I agree wholeheartedly. However, in personal experience, I've found that this works much better with more experienced developers rather than with junior engineers. Why? Because for some reason, a lot of junior engineers have been pavlov-ed into thinking every interview is for something at Google/Facebook scale (no matter where they are interviewing) and they start describing extremely convoluted designs using tech that they are also not completely familiar with just because they want to come across as knowledgeable. Something that I struggle with in these cases is reining in the dev back to the "what" rather than the "how", because I've seen even good engineers go into this "let's add a system-bus for everything" way of thinking. Constraining problems explicitly tends to devolve into the "Interviewer-Interviewee information asymmetry" which is the same with most DSA problems (At least with DSA, most constraints are known by both parties). On the other hand, almost every time I've picked an actual problem we have with a system, be it a bug or a new product or something else, as an interview question with an experienced interviewee, I feel like I've come out understanding the problem space AND solution space better just through the process of discussion and in multiple cases, actually ended up using a lot of ideas from these discussions, so interviewing feels much more "natural" and a "dominant strategy" in game theoretic sense.