When it comes to meeting new people who present themselves as knowledgeable, I have a philosophy. I believe in giving them enough rope to hang themselves or parade themselves, especially in situations like screening interviews where people tend to over-inflate their resumes. This is particularly true when a person's career progression seems out of sync with what you would normally expect for the role they're being hired for.<p>To gauge their actual knowledge, I go through their resume and pick out key pieces of their technology stack. Then, I have them explain how it works, how it interacts with other components, etc. This works even better if it's a technology stack I'm familiar with, since I'm aware of the competitors within that space and can find a better tool to use next time around.<p>To catch people who are lying or exaggerating their experience, I ask them to reiterate a tech stack that's not DNS (which is often overplayed) or a familiar tech stack that I can quiz them on. By doing this, I can test their knowledge both in print and in their own words. I look for people who can both talk the talk and walk the walk, rather than just talk a good game.<p>My goal is to hire people who are considered peers or adjacent to my current team, rather than those who are too junior to onboard quickly. Unfortunately, sometimes someone slips through the cracks and the team regrets it.<p>Likewise, when in a coding interview, most people aren't 100% code perfect on the whiteboard, so I don't require them to be exact. When I first learned how to code out of the back of a Compute! magazine, I was reading it... learning how BASIC in magazine print turned into BASIC the instructional code interpreted by a computing machine. Therefore, most all who code can read that or even Pseudocode down to the level that are able to reiterate the logic and function which is something that ChatGPT doesn't even have correct (how often does it produce buggy examples?)<p>But if a person can show me how their logic is processing by talking it through with descriptions - and they can do the same on shared desktop remote interviews as well, and I am able to understand when I question them or add in new features I ask for and can confidently interpret their answer, then I feel confident enough that with google, they will likely be successful building a solution just on rote description.<p>A person does not need to get my solution, they need to get a solution that works to solve the problem.