As a 60+ year old guy who has been at the same employer for the past 20 years, I thankfully evaded all that leetcode crap. My interview style has always been of the sort described -- ask in depth questions about something they have worked on.
The telltale sign of a padded resume is when the person acts like a cork -- you try to push down deeper and they always pop back up to surface level answers. Some give up the game quickly and admit that they were on the team that did the thing in question, despite their resume saying they did the thing. Other people are very practiced and unflappable and just bob back up over and over without shame.
For new engineers with say three years of experience or less, I can forgive the overstating their experience and I'll shift to asking them to describe their part of that project. But for the people with a few years on their resume, then that behavior is definitely a deal breaker.
Another line of questioning I take for people with experience are questions like: what are the tradeoffs of directed testing vs random testing? When do you have enough confidence in your testing that you say the product is ready to ship? What are some examples of where bugs made it out the door, and what was your process after that happened? What are some reasons why every part of a design might pass their unit tests, but the total design has failures?
These should be easy to discuss for anyone with experience, but there are a surprising number of people who fall flat. Similarly, I am shocked at how often I ask someone to write some code in any language they want to, even pseudocode, for a simple problem and are unable to do it. Eg, given a stream of numbers, maintain the largest two numbers seen so far.
The telltale sign of a padded resume is when the person acts like a cork -- you try to push down deeper and they always pop back up to surface level answers. Some give up the game quickly and admit that they were on the team that did the thing in question, despite their resume saying they did the thing. Other people are very practiced and unflappable and just bob back up over and over without shame.
For new engineers with say three years of experience or less, I can forgive the overstating their experience and I'll shift to asking them to describe their part of that project. But for the people with a few years on their resume, then that behavior is definitely a deal breaker.
Another line of questioning I take for people with experience are questions like: what are the tradeoffs of directed testing vs random testing? When do you have enough confidence in your testing that you say the product is ready to ship? What are some examples of where bugs made it out the door, and what was your process after that happened? What are some reasons why every part of a design might pass their unit tests, but the total design has failures?
These should be easy to discuss for anyone with experience, but there are a surprising number of people who fall flat. Similarly, I am shocked at how often I ask someone to write some code in any language they want to, even pseudocode, for a simple problem and are unable to do it. Eg, given a stream of numbers, maintain the largest two numbers seen so far.