I've found bad interview questions fall into one of three camps:
1. The interviewers aren't subject matter experts themselves but are hiring managers, so they've taken their questions from someone else.
2. The company gets far more good candidates apply than they can hire, so the process is less about removing bad candidates and more about having some arbitrary way of whittling down good candidates.
3. The interviewer is trying to prove how clever they are or the company is. Sometimes for their own ego but more often because they think it might make the company more attractive to work at.
If there is a theoretical question I'd normally Google / DDG instead of memorise then I'd usually be honest in the interview and say "it's something like xyz but in truth this is something I double check these days as, pragmatically speaking, it is not a problem that comes up frequently. However it is something I have done before [cite example]".
If the questions is asked because of reason 1 or 3 from above, then usually they're happy with that answer. If they ask it because of 2, well as much as I might disagree with their interview process, I'm still not the candidate they're looking for. So we still part of good terms.
In an interview, they gave me access to their codebase and asked me to fix an actual (small) bug. The interviewer showed me where the codebase was, how to replicate the bug, all of that took less than 10 mins. Then he left, told me to give a shout once I am done. Took me about half hour to do it, another 10 mins to explain what I did to fix the bug.
There were no other questions - no white board stuff, no algorithm questions, no stupid questions like "where do you see yourself in 5 years?" etc. I still remember the interview nearly a decade later.
Obviously this won't work for all jobs, but this will work surprisingly well for a large number of jobs, because most jobs are ordinary. One doesn't need to know complex algorithms to do these
My entire "interview" at Netflix was me helping their top database people solve a severe performance problem in their operational systems. In the two hours I was there, I diagnosed the root cause and showed them how to fix it doing something they did not know was possible. Best and easiest job interview I've ever had.
They tested it after I left (a >100x improvement apparently) and called me the next day to ask when I could start.
I did something similar and loved it but a friend pointed out That he will fall over with an anxiety attack in such a situation. I always thought the best case would be to offer a choice to the candidate among 2 or 3 different ways to do the interview.
>I did something similar and loved it but a friend pointed out That he will fall over with an anxiety attack in such a situation.
I might, too, but I frankly might do the same to an even more extreme degree for a particularly challenging real-time 1-on-1 interview question from someone staring at me.
All things considered, I think I'd prefer being left alone in a room where I don't feel them over my shoulder while constantly wondering what they might be thinking with each passing second. I can take a few minutes to relax a little, look over the code, and try to figure it out.
I don't understand why this would give someone anxiety attack - it would suck if the interviewer sat next to me and watched my every keystroke, it wasn't that in my case. He just set me up and left to do his job. I was on my own, until I finished and called him over to show the bugfix.
I have anxiety issues when an interviewer asks me some obscure syntax option for grep command or some b-tree stuff that I learned in college decade ago (and never used in real life).
I don't understand why that grep stuff would give you anxiety. It is a dumb trivia question, just say you don't know.
But I don't understand because I am not you. Different things give different people anxiety. Anxiety isn't something you reason your way into or out of.
I'm not OP, but I imagine the concern is doing work for the company (i.e. fixing a bug in their codebase) without getting paid at least minimum wage for it.
Ah, I assumed it was just a realistic looking exercise. If they actually used code written by the applicant, I can definitely see all kinds of problems!
If I were designing this question I would probably use a real bug that we recently fixed. We'd already have a sense for how hard of a problem it was, and there's no worry about unpaid work.
4. Interviewer did not have time set aside to prepare for the interview, and sort of has to wing it. I was surprised to realize how often this happens.
1. The interviewers aren't subject matter experts themselves but are hiring managers, so they've taken their questions from someone else.
2. The company gets far more good candidates apply than they can hire, so the process is less about removing bad candidates and more about having some arbitrary way of whittling down good candidates.
3. The interviewer is trying to prove how clever they are or the company is. Sometimes for their own ego but more often because they think it might make the company more attractive to work at.
If there is a theoretical question I'd normally Google / DDG instead of memorise then I'd usually be honest in the interview and say "it's something like xyz but in truth this is something I double check these days as, pragmatically speaking, it is not a problem that comes up frequently. However it is something I have done before [cite example]".
If the questions is asked because of reason 1 or 3 from above, then usually they're happy with that answer. If they ask it because of 2, well as much as I might disagree with their interview process, I'm still not the candidate they're looking for. So we still part of good terms.