I will just say again like I always do, there is no solution to the problem. You hire, you try, and if no good, you fire.
I have some thoughts regarding possibly giving the interviewer some more leeway (like for engineers, don't start off with solve this first) but haven't thought enough about that.
Not necessarily - it's quite possible that the kind of reasons that get a 'no hire' at this stage will show up consistently in this environment and consistently be a problem for employers.
I'd say pedantic and difficult to work with, but agreed, no hire.
The correct answer would be to write a simple solution and note your assumptions and point out the edge cases - but not in such an antagonistic manner.
But similarly, quickly coming to the conclusion to not hire is just as fallacious.
If someone burns out as a result of the bungled planning, then the project can potentially be doomed without hiring (or even doomed anyway) - one should almost immediately reevaluate when one comes into this situation unless there was some sort of agreement beforehand.
That makes no sense because, presumably, the alternative is to have no-one. If you don't hire someone because you are worried about the team, you don't need to hire anyone (this risk is, also, not avoidable anyway...if your product is so fragile, the risk isn't making a hiring mistake).
I've hired a couple of people who claimed to never have problems and/or pointed out to me in the interview that the test situation I ask them to diagnose "could never happen", even when I'm drawing on personal experience.
Each time, the person in question turned out to be a terrible hire and never lasted more than a month.
If you can't come up with a disaster in your career, you've never had a career.
"The candidate has a myopic focus on documentation and best practices, as demonstrated by his failure to apply a simple solution to a simple problem. No hire."
reply