Tips for navigating low level design interviews

I'd read Gang of Four or, the more readable version, Head First Design Patterns.

I'd also look at your current APIs and object models and try to reason about why they are the way they are. Thinking about the pros and cons of the current choices and running some thought-experiments on how the alternatives would fare can be very fruitful exercises. If you have a trusted buddy at work that's more senior/tenured, having a discussion with them can be more additive than doing this by yourself.

I generally think that these interview questions give better signal than L4/L5 sys design questions as most engineers won't get to design a system at that level until later in their career. More often, they will work on a part of a large WIP system and will need to add/modify APIs or write new features. Honing your API design and object-modeling skills has more immediate returns on your day job as well, so it's worth investing in them.

Ah, the elevator OOP question is such a classic.

Unlike LeetCode, OOP is real and is something software engineers actually do and should know. If a company does Java for example (my primary language historically), then it should do OOP, that's the main point of the language.

This makes preparation quite straightforward. Just write OOP code: https://www.jointaro.com/course/ace-your-tech-interview-and-get-a-job-as-a-software-engineer/object-oriented-programming-oop/

Side projects are great for this if you can connect an OOP use-case to an actual product, but OOP is something that can be done in isolation on Replit or something.

On the scale of abstraction, it's not nitty gritty like Leetcode questions where you need to write the logic for every part of your code and actually run code...

You often don't need to run the code in an OOP interview, but to really practice, I think you ideally should. For example with the elevator problem, you can write APIs like elevator.takeInPeople(people: List<People>) and then call them. After the APIs are called, you can print out state like number of people in the elevator and make sure that the state is correct.

The closer something is to real life, the better the practice is. This is why I haven't studied for an OOP interview for 8+ years. I just got really good at OOP writing Java for my jobs and side projects that solving an OOP problem feels natural.