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.
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?
Comments
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.
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.
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