Carnac the Magnificent(raganwald.com)
raganwald.com
Carnac the Magnificent
http://raganwald.com/2015/05/08/carnac-the-magnificent.html
5 comments
> try out their questions on their peers and get feedback.
Excellent suggestion, thank you!
Excellent suggestion, thank you!
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 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.
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):
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?
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?
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?
It's common practice to put a summary/conclusion at the end of a long article, and this one happened to label it with "tl;dr."
You could argue that finding out hidden possible requirements in a high-stress situation is also part of a developer's job.
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.
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.
Like, say...how to design a monopoly implementation? :) http://weblog.raganwald.com/2006/06/my-favourite-interview-q...
Like, say...how to design a monopoly implementation? :) http://weblog.raganwald.com/2006/06/my-favourite-interview-q...
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.
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?
- PM is busy coming up with a feature that you'll solve with an application global variable just because you want it to go away
- 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
- 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
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.