That's how we do it: - 30 minutes of basic theoretical questions: SOLID, design patterns, DDD, clean architecture etc. just to get an overview of what they kno

That's how we do it: - 30 minutes of basic theoretical questions: SOLID, design patterns, DDD, clean architecture etc. just to get an overview of what they know and what their experience is, and if we'll have to assign them some courses later - 30 minutes of a practical task: they're given a very bad piece of code (1 screen), and their task is to review it. Things like: SQL injection, lack of transactions (data consistency), lack of locks, bad variable names, bad program structure etc. The review is interactive where the interviewer can give tips. Usually it gives a pretty accurate picture of their actual experience/skills, and weeds out 99% unfit candidates. If all is well, there's then 1 hour interview with CTO to check the soft skills: motivation, corporate culture fit, they also negotiate the salary (based on the previous interview) We don't do leetcode and don't ask to write a test project. Observations: - many candidates who are good at theoretical questions completely fail the code review: i.e. they simply memorized it without deep understanding - there are candidates who are not good at theory but pretty good at spotting most problems during the code review. For us, it's usually OK. It's often good self-taught engineers.