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.
Like, say...how to design a monopoly implementation? :) http://weblog.raganwald.com/2006/06/my-favourite-interview-q...
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.
- Requirements analysts are making complete sense but it's making you realize how much work is ahead of you, so naturally you hate them outright
- Scrum masters are quietly reciting the differences between waterfall and agile while rubbing a golden chalice
- ETC is an actual department in your organization but no one knows what exactly they do
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?
In the first case, requiring candidates to be lucky is fine.
function combine(x,operator,y) {
if(operator === "+") {
return x+y;
}
if(operator === "-") {
return x-y;
}
if(operator === "") {
return 10*x+y;
}
return 0;
}
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?
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.
Excellent suggestion, thank you!