I call these types of questions "stump the chump".
It is the most common major flaw in tech interviews I see and I try to teach interviewers to avoid these types of questions by having them try out their questions on their peers and get feedback.
There is a famous story of a hiring manager who divided the pile of resumes on his desk into two piles. "If you want to work for me, you need to be lucky," he said, and dropped one of the piles into the trash.
I bring that up because from the perspective of the hiring manager, it might not matter that interview questions are fair, simple, and clear. The point is to find a good candidate; as long as you do that, eliminating other good candidates along the way is acceptable.
Consider it this way: let's say your interview question requires your candidates to read your mind to some extent, or at least intuit what you mean, or at least share your assumptions. Isn't it possible that those attributes would be helpful in a new hire?
Absolutely. Are they more helpful than the other attributes you're disregarding in searching for the mind-reader, though? I'd suggest that people who can communicate clearly and don't put up with being asked to read minds are desirable candidates.
It all depends on whether your goal is to find one of the adequate candidates mixed into a sea of weak candidates, or if you need to find an extraordinary candidate mixed in with all the others.
In the first case, requiring candidates to be lucky is fine.
I haven't interviewed for quite a while, but I might do so pretty soon. What surprises me in this blog post is not the question itself - I find it quite reasonable - but the pickiness of the interviewer. If I was asked this, I suppose that I would come up with some kind of bruteforce, like writing a function to combine two numbers and an operator (the empty string can be an operator):
And then getting the 3^8 possible combinations of 8 operators linking the number together and picking the ones that give 100 as the final result.
While I am sure this solution is not completely efficient, I would expect it to show that I can write Javascript. Would that get me rejected for the job?
I was not saying that the interviewer is picky, only that when asked a question like this, we don't know if the interviewer is picky, and that is stressful for the candidate in a way that is sub-optimal for the interview process.
Rejected? Not yet. Let's first see if you can get operator precedence right. If plus or minus is followed by the empty string, "10* x+y" must be done first, or what?
Is it common practice to put the summary or "tl;dr" at the end of a long article? I thought the point of tl;dr was to give an overview or summary before the long article?
Of course you could. Just as you could argue that wasting time asking a bunch of questions about hidden requirements for a simple “fizzbuzz” question is indicative of a candidate that prefers talk to action.
Remember, the stated purpose of the question was to filter non-programmers from programmers. If the real purpose is to evaluate a candidate’s proficiency at eliciting hidden requirements, I suggest that there are much better problems to pose.
For example, a design problem that is closer to the actual company’s domain.
> If the real purpose is to evaluate a candidate’s proficiency at eliciting hidden requirements, I suggest that there are much better problems to pose.
You could argue that any interview reflects the organisation doing the interviewing.
For instance, if situations like this one happen often in the organisation, then that might be a negative symbol for the job as it indicates a lack of rigour in gathering and specifying requirements. An interview question like this could prove to be telling, and have a negative impact on hiring.
Likewise if the interview is unfocused and rambling, or the interviewer is looking for a particular answer (not just a working answer), or the interviewer just talks about themselves, etc.
These are all hypotheticals, of course: it's up to the interviewee to determine how likely these are for a particular organisation. It's useful to keep in mind when interviewing, though.
I'd argue back that if we're suddenly in a high stress situation where I need to divine the requirements are, I'd ask what the hell were the project managers, requirements analysts, scrum masters, etc, all doing before this point?
It is the most common major flaw in tech interviews I see and I try to teach interviewers to avoid these types of questions by having them try out their questions on their peers and get feedback.