This reminds me of the time in high school that a gym teacher had to fill in for a math teacher and even make up test questions. One test question involved calculating the volume of a container and figuring out how much it would weigh if filled with water. I approached him during the test and explained that no one can answer this without knowing how much water weighs. He got up and asked the class to disregard that question.
The problem when interviewers ask these questions isn't just that we might not know the answers. It's the simultaneous, uncomfortable realization that the interviewer doesn't understand what the job actually entails, and is therefore incapable of evaluating your ability to perform it.
Not only is it awkward, but it suggests that either no one in the organization does know what questions to ask, or those who do aren't interested in who gets hired. It makes me question what sort of team I'm interviewing to join, and those concerns are usually well-founded.
I prefer slightly more open-ended questions that allow someone to express themselves, like
What makes code difficult to unit test?
When would you declare an interface (.NET)
What makes code easier to read?
If you want to measure their technical understanding
Ask them to describe some of the work listed on their resume.
Ask them to describe a few common, relevant design patterns. It's not about the precision of their answers, but whether they've ever heard of them or thought about them.
Ask about a few things you don't know about. If they don't know, so what? Neither do you. But maybe they get a chance to impress you, and it avoids using yourself as the measuring stick.
Throw in a few simple concrete technical questions that most developers would know.
Show them some obviously defective code and see if they can spot the problem.
Ask them to write something simple. Not a complex coding challenge, but enough to see if they can actually string together a dozen or so lines of code.
But in order for all of this to work the interviewer must be able to understand the questions and most of the answers.
It also helps to look over some lists of common interview questions on the internet. When you realize how many you can't answer after writing software for years it's a little bit humbling and you're less likely to measure someone else's skills by whether or not they can answer a trivia question.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This reminds me of the time in high school that a gym teacher had to fill in for a math teacher and even make up test questions. One test question involved calculating the volume of a container and figuring out how much it would weigh if filled with water. I approached him during the test and explained that no one can answer this without knowing how much water weighs. He got up and asked the class to disregard that question.
The problem when interviewers ask these questions isn't just that we might not know the answers. It's the simultaneous, uncomfortable realization that the interviewer doesn't understand what the job actually entails, and is therefore incapable of evaluating your ability to perform it.
Not only is it awkward, but it suggests that either no one in the organization does know what questions to ask, or those who do aren't interested in who gets hired. It makes me question what sort of team I'm interviewing to join, and those concerns are usually well-founded.
I prefer slightly more open-ended questions that allow someone to express themselves, like
If you want to measure their technical understanding
But in order for all of this to work the interviewer must be able to understand the questions and most of the answers.
It also helps to look over some lists of common interview questions on the internet. When you realize how many you can't answer after writing software for years it's a little bit humbling and you're less likely to measure someone else's skills by whether or not they can answer a trivia question.