> My golden rule for technical interviews is that, "Every step, conversation and question must be pertinent to the day-to-day of the role." While this may be ob

> My golden rule for technical interviews is that, "Every step, conversation and question must be pertinent to the day-to-day of the role." While this may be obvious, I am sure that many hiring managers are still expecting candidates to arrive at technical interviews with Computer Science books memorized. This form of technical interviews should be made obsolete. Here's the core of the article right here. The "regurgitate LeetCode-style problems" interview fails to be relevant to the day to day of pretty much any SWE job (unless, maybe, you're applying to work for LeetCode, and one of the duties is to create solutions to problems in under 40 minutes, without outside resources). Take the author's golden rule and layer on a structured interview process, and now you've got an interview process that will be more predictive of whether a candidate is a good hire than any "throw a random engineer in a room with the candidate and have them answer random algorithm problems" type interview. Even better, since you have an actual process, you can tweak it to be even more predictive of a good hire. Why don't companies understand this?