1. I've 100% met with interviewers that felt like they were googling interview questions on the fly. YMMV which was the point of the "no standardization" argument. I've had interviews with no whiteboarding, some with whiteboarding, and some that simply felt like we both wasted our time.
2&3. I wish I could relate. I work in games, fwiw, so maybe it's simply more wild west than the other domains in such regardss. It's not even that I can't answer some of the questions, but if I'm asked a question on CPU architecture after I spent my time studying a bunch of C/++ trivia, I'm not going to answer the former as confidently since I'm pulling out knoweldge from a 3 year memory bank that I happened to work with at work.
>all the while YOU are the one benefitting from the system that cannot be changed.
I am? I'm a year out of a job and I sure wish I had a referral. My last studio shut down so those references scattered all over.
But for "whatever shall we do"... I don't have some magic perfect interview, but a few basic steps to save everyone's time:
1. we don't need 5-10+ rounds of interviews and 3 months just to make sure a candidate isn't a lemon. IMO if it's over 3 rounds (not including an HR call for basic alignment), there's some process that really isn't necessary. You dont need to speak to a CEO unless you're applying as a director or executive yourself. You don't need to meet every team member separately for their variation of an interview
2. Ghost jobs absolutely need to be regulated. I'm surprised it's even legal to lie to your shareholders and say "we're always growing" when half your postings have little intention of attracting a candidate. At the very least a job posting should delineate between urgent (hired withing 1-2 weeks of response), "normal" (2-4 week process), and "cold" (6+ week process, non-necessary role).
3. jobs should in fact give a general direction of what kinds of technical questions you expect to be asked for that portion. Who does it really benefit if one candidate happened to study leetcode (and the right kind of leetcode), but the other was focusing on system design, or questions about their specific industry problems solved? Or domain specific probblems?
Just a few ways to be honest, efficient, and bring out the best in candidates. Interviews shouldn't be so hostile to the labor the company clearly requires.
> if your questions can be memorized and recited by rote memory and the candidate can do well on it without the proctor knowing, then your questions are BAD or your proctor is a moron.
I agree in spirit. My only caveat sympathizing with interviewers is that most questions can indeed be "memorized", and arguably all questions/practices can be studied for. And there is some merit to trying to figure out how someone approaches a new problem. I think that approach is highly inefficient when you do in fact mostly want someone who "already memorized" the right domain knowledge, but I digress.
But people and their experiences are diverse. Without knowing their background (and again, some people seem to read the resume for the first time during the interview) you are never going to surprise 100% of your candidates with the same question bank. But that may be too much of a burden on trying to cater every inerview for every promising candidaet.