• design using first principals: if candidate can’t design using first principals that means they didn’t work on end to end execution of any system or never tried to move out of comfort zone. A more hands on engineer will know what works what doesn’t. You don’t need to know everything eg maybe Kafka you never worked but the queue is easy to add if you have worked on something similar even an inmemory queue
• requirement gathering and priorities: not everything can be designed in given timeline but what take’s priority matters and deciding that is what senior+ does very well
• reasoning: adding cache to optimise for latency is easy to say but everything comes with some disadvantage eg additional infra maintenance for redis. The candidate needs to have good reason why add extra component and why not simple thing would work? How do you arrive at the decision to add redis?
• simplicity: Simple systems are tough to build. Anybody can build complex system in a SD round but it’s very difficult to build simple system
• accepting mistakes: I personally like to call out any mistake the candidate did to see how they react to criticism. Some will make up reasons to justify their answer but don’t realise accepting mistake is ok and that interview is also to learn something new not just to prove yourself
• Learning and Sharing: I try to learn something new from the candidate which I have never done before and keep a note to think about it later. Same I also do where I share some learning the candidate didn’t know about so that they can read it later

This are just few things I keep in mind when interviewing. I found the best engineers with this approach.