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.
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.
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.
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 :-)
Thing about "Google.com" (I used Facebook/Gmail) is that when server side stuff is of interest (as it was for this cloud engineer job), then I also want to hear about geo DNS, reverse proxies, LBs, CDNs, eventual consistency, distributed storage, etc, all the complexity that is happening once that cat video appears in the browser.
Then again we can go back to JS, CSS, JIT and others' space
We were hiring students for a temp position. We're a Controls Engineering company, but my department is dealing with more traditional languages for supporting applications and needed extra help for a bigger project. I know the tech we use isn't standard in the university so the interview was asking students about how they approached their major projects and their methodology for learning new tools/languages.
The first guy who straight up said "I already know enough of C++ and Java, I suppose I'd just google how to do x in c# and branch from there" got the job. Because...yeah, that's about it. We talked about a 4th year project and what his responsibilities in the team where, problems faced, solutions found, etc.
Researchers' fields/interests are too narrow, by far, for companies to find enough candidates. Machine learning departments go from low thousands (FANG) to maybe a dozen individuals on the low end (small regional banks, ...). That adds up to let's say 40.000 jobs worldwide.
Plus there's the non-cheating cheating. The majority of conferences (including ICLR/NIPS/CVPR) are still presentations by companies about how they "innovated" by letting an intern use 10-year old techniques, in an established library (ie. not pytorch, but an "integrated" solution, sometimes going as far as an Oracle tool) to look at their own proprietary data (in medical, social sciences, sometimes chemistry). This then delivers them a "paper", goes into the conference proceedings, and they make sure this delivers dozens, sometimes hundreds of citations for all individuals involved.
Don't get me wrong. Delivering a major paper at those conferences is a major, incredible accomplishment that's beyond me, for example. But there's 20-30 people on a yearly basis that "really"/honestly do that and over 5000 total presentations at those conferences. And there's 10000 or more candidates needed to fill positions at companies.
And then the question is: who would you rather hire? A math phd, or frankly even a CS master with no relevant machine learning papers, or that intern?
I had several bad experiences right out of school - I would regularly do programming exercises for recruiters and wasted a lot of my time I will never get back. Some of those exercises would take 3 to 5 hours, and I was told I was one of the faster candidates :/
Once I was able to build a resume and show off projects I told myself I would never go through that experience again.
I don't know if this comment will help you at all, but good luck to you! If you are in the Midwest area I know of a recruiter or two that are great people and can help get you pointed in the right direction. My email is in my profile.
Interviewing is a bit different, since there's no book, but when we looked for a junior dev, the applicants got a laptop with VS Code, the common browsers, internet access and an empty (macOS guest) account, and a few (short!) tasks to show if they understood the questions and were able to start formulating an answer. We also looked for a personality match (we're a small company) and signs of general intelligence. Worked out reasonably well.
I really dislike the more extreme approaches to interviewing that one sometimes comes across, like leet code scores. That's just too disconnected from the actual work. Unless you need your employee to grind leet code questions, of course.