Carnac the Magnificent

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?

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):

    function combine(x,operator,y) {
        if(operator === "+") {
             return x+y;
        }
        if(operator === "-") {
             return x-y;
        }
        if(operator === "") {
             return 10*x+y;
        }
        return 0;
    }

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?

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?

You could argue that finding out hidden possible requirements in a high-stress situation is also part of a developer's job.