Below are two examples of recent preparatory information given to me before interviews with two different companies. These are samples. I did not spend a few hours on each of these examples, but a few hours in total for each company. I probably spent <45 minutes of prep specifically on the examples below. I hope these are helpful to illuminate my point, that prep info can be acted on usefully in some amount of time measured in low-single-digit hours and can improve the interview experience for everyone.

Example 1:

"This interview is for your cultural fit. The interviewer will ask a series of 'tell me about a time when' questions. The core values of the company are x, y, and z."

So I spent a few hours reviewing those core values, and making sure I had anecdotes to cover each that represent me and my experience well. I rehearsed these answers, and made sure that I could articulate how my answer aligned with a specific value. I didn't have to flail around on the spot with no understanding of what the interview would be about. I didn't waste time in my answers talking about technical details that aren't relevant to an interview that is focused on personality and experiences outside of the technical.

If I did not know what the point of the interview was, I could easily respond to, "Tell me about a time you had a disagreement with a teammate and how you resolved it," by focusing on a technical challenge, and giving background on the technical details. If the interviewer weren't too good, or was just having an off day, they might not press to get details about the soft skills involved in solving disagreements that was really the point. This could easily become a failed interview question where they consider me obtuse and focused on the technical details at the expense of interpersonal ones.

With expectations firmly set and my own prep to make sure I had that story and that focus locked and loaded, I can make sure to focus on how I made sure all parties were heard, and that how I helped to foster a productive conversation, and how I made sure that I could back my side up with facts and figures, and how we had a reasoned discussion, and how we made a good decision in the end.

Then the interviewer doesn't have to keep digging when I gave an answer all about technical domain challenges. Then I don't have to feel defensive because the interviewer is digging. So we both have a better time in the interview. And I avoid being marked as "do not hire" for answering the question wrong without knowing.

Example 2:

"This interview is a high level technical interview, focusing more on systems architecture than code. You will be expected to whiteboard but not write code. Our interviewers will have several scenarios to choose from that focus on the following topics: a, b, and c."

So, I looked at that company's product offerings (this was for a customer-facing engineer role), in order that I might be conversant in their technologies. I looked for any whitepapers or blog posts about the topics, and made sure I was familiar with the architectural challenges of the topics provided. I made sure I understood how their products could fit together in a larger architecture, or where integration with third party systems was viable. These are not topic areas unfamiliar to me, so I'm not embarking on a full curriculum to understand these, but focusing my time on the topics I know will be covered.

I didn't waste time grinding leetcode, or even reviewing anything algorithmic for this interview.

When the interviewer presents a scenario, I don't waste time in answers that include fine technical details, such as how to configure the various services involved, or how one might program a solution to the scenario presented. I know I'm expected to whiteboard, so I make sure to illustrate as I am talking.

Again, my prep makes sure I'm on topic, so I don't depend on my interviewer guiding me to the right level of answer. A poor interviewer might let me go on for a long time, so that we can't finish in time. I would blow my chance by spending too much time in the weeds to get through everything they wanted to.

Even if I have a good interviewer who gets me back on track, if I've focused on grinding leetcode for this interview, I don't have systems architecture on my mind. I'm flailing around trying to refocus. Even if I get back on track, I'll have a much poorer showing than if I answer the questions appropriately (note, appropriate <> correct) to start with.

Separately from the examples given, there is another question of how well the interview topics fit the job. I am opposed to algorithmically-focused coding interviews for positions where it is not expected that the person in the role will have to implement algorithms as part of their day-to-day responsibilities. That said, if you are applying for a role where deep algorithmic experience is required as part of the day-to-day, then I would expect any decent candidates to not need to grind leetcode. If you're already doing this stuff regularly, then it should be a matter of brushing up, rather than grinding.