Sure, that's a risk, but that's part of the purpose of an interview - both to discover what they claim to have done, and to assess how accurate that is. This is the purpose of asking about decision making processes, alternatives, architectural summaries and deep dives, etc - if they really did everything they claimed then all relevant details should come rapidly and fluently.
The problems with the alternative - interviewing based on problem solving and coding challenges are:
1) For the most part it doesn't work. Companies like Google, that have reflected on and assessed their own interviewing success, have come to the conclusion that there is little correlation between how well people interviewed in this style do on the interview vs how well they perform on the job. This is a pretty low bar to beat!
2) If you are interviewing for 10-20-30 year senior with a track record of success and adding value, how can you possibly hope to assess that via problem based challenges, especially if conducted by a less senior developer who doesn't themself have the skill set and track record you are hiring for? How do you know if the person just talks a good game and can throw around high level concepts, or can actually deliver?
I do think there is some value to problem solving as a small part of the interview process, but certainly not if this comes at the expense of ignoring the candidate's actual experience and accomplishments which is the best indication of what they are capable of.
I have zero confidence in the ability of interviewers to reliably and repeatable parse out subtle characterological details in candidates. Like I said, the interviews you're talking about are essentially random functions.
Google has notoriously one of the worst hiring processes in the entire tech industry.
Many people's understanding of "Google's hiring processes" is from a few articles over a decade ago. They had done numerous studies, switched things up, and now have a pretty solid approach to interviewing. This is one of the articles that was going around back then, and most of the conclusions are how Google still interviews: https://www.workforce.com/news/laszlo-bock-just-google-him
I work with many ex-Googlers that did a lot of interviewing and they process has been pretty consistent for many years now, and seen largely successful.
> Like I said, the interviews you're talking about are essentially random functions.
Only if you are REALLY bad at interviewing !
And what's the alternative - you want to hire someone to head up your infrastructure modernization based on acing LeetCode challenges and drawing a few diagrams on the whiteboard ?
The problems with the alternative - interviewing based on problem solving and coding challenges are:
1) For the most part it doesn't work. Companies like Google, that have reflected on and assessed their own interviewing success, have come to the conclusion that there is little correlation between how well people interviewed in this style do on the interview vs how well they perform on the job. This is a pretty low bar to beat!
2) If you are interviewing for 10-20-30 year senior with a track record of success and adding value, how can you possibly hope to assess that via problem based challenges, especially if conducted by a less senior developer who doesn't themself have the skill set and track record you are hiring for? How do you know if the person just talks a good game and can throw around high level concepts, or can actually deliver?
I do think there is some value to problem solving as a small part of the interview process, but certainly not if this comes at the expense of ignoring the candidate's actual experience and accomplishments which is the best indication of what they are capable of.