I've done a lot of screening interviews and cheating does happen. Some of my favorites:
* developer attempts to pass something off as video lag, as he attempts to lip sync someone else's answer.
* developer had printed all the 'common' answers on the wall behind his computer, and would look up to them for reference as we were talking. Then the tape came off and covered him in a a paper stack overflow.
* the glorious mechanical keyboard, as they google for an answer.
* interviewed one person and had a different one show up.
I let any of my interviewees know that it is ok to use google, I just want to know what they searched for. I'm not running a trivia contest, so if they forgot the name of something or need a little refresh, that's fine.
The way I combat this is by asking questions about their current jobs, then diving deep into the technical problems they faced. It requires a lot more preparation for each candidate, but it ensures it’s not a trivia test but a discussion.
One of my favorite interviews (as an interviewer) was when a SDET candidate provided a link to their website. When I visited it there was an issue loading some page. So I asked him about it and how he would troubleshoot, then asked him to come back on Monday with a solution. On Monday, the site was fixed, and he explained to me what happened in AWS, how he figured it out, etc. So he was hired, going on 2 years now and doing very well.
I don’t need robots who can recite what a b-tree is (ChatGPT can do that). I need people who will work hard, can understand the big picture and how to approach problems, while being a good personality on the team.
This.
My other favorite is very open-ended questions. I mostly do ops-y interviews, and my favorite question is "what happens when you type 'curl https://google.com' in a terminal and hit enter?"
The question is so broad there isn't a "correct" answer to Google, and it crosses enough domains that any article they find is going to be too long to skim. Then I ask them to really zero in on some aspect of it they feel comfortable with and give detail. What syscalls happen to start up curl? How does the OS know how to communicate with the local router? What's the entire flow to translate "google.com" to an IP?
It's also just fascinating to see which parts candidates latch on to. I had one person spend like 30 minutes just talking about TLS and PKI. Another person delved into kernel packet handling for a while.
That's what I do (instead of curl, with a browser).
MANY super cool convos spun out of this question (interviewed around 60 people). One of them never actually got to the network request part bc we went DEEP into event handlers in a GUI etc. Another candidate was all over the place with key exchange protocols and what and how can go wrong.
I usually don't ask further questions to "corner" them, let them go into any of the details they want.
Ah, I am so happy I am not the only one who invented this interview method :-)