3 ms·
This is very specifically a terrible idea. I passed an analogous interview to this once when I was much younger, and then subjected several applicants to it th
by motohagiography 7y ago
This is very specifically a terrible idea.
I passed an analogous interview to this once when I was much younger, and then subjected several applicants to it thinking it was a useful filter.
It's not, it's abusive psychological torture that rewards sadistic amateur psychologists and interview administrators. The only way to succeed is to submit to the interviewer by asking for help. It filters for people who know to implicate others in failure while taking credit for small successes, and bullies people into submission.
The interview I passed was a variation (I learned after) on the bridges of konigsberg, where instead of asking for help, I asked if it was impossible. The person administering it hired me on the spot, but even this was wrong because the place was full of people who thought the reason they were there was because they were intelligent - something they didn't have control over - and they acted
As pettily as psychotically as you would expect.
The problem on teams isn't individuals not asking for help, it's managers who don't have the confidence of their teams to ask.
If you are reading this and I put you through that exercise 15+ years ago, I apologise.
- dlkf 7y agoFrom the article: > I'd tell them that at the start, obviously. This isn't The Secret Rules For Getting Hired. > "I know you've never used Blender*," I'd say, "And this job doesn't require it. But we want to see how quickly and accurately you can learn to use something unfamiliar while under pressure."
- shantly 7y agoI don't think I've ever had to learn something very complex under the same short time constraints and high do-or-die pressure as an interview. Tiny things (think: new-to-me unixy commands), yeah, but nothing very complex. With as many unknowns as that introduces, should it ever come up in a real job situation with a very short time window available, my expert (I'm quite serious using that term here) advice would be that we should count on having it take quite a while, and immediately begin whatever mitigation is required to allow for that, rather than waiting to begin planning for and mitigating the harm that'll do and simply gambling that this complex thing won't surprise us and end up taking longer than we'd hoped (likelihood that it will: extremely high).
- hinkley 7y agoI end up doing a lot of technology selection and so I have to have these skills and the ability to ask hard questions. I don't for a second believe this should be the skillset of every member of a team. A team where everyone is adding new tools all the time is chaos. Learning new tools isn't really a goal. Getting better at your job is the goal, and learning new tools is either a means to that end or just moving the goalposts over and over so nobody knows what's going on.
- shantly 7y agoYeah, sure, I do evaluative work just fine, but I don't think "build [non-trivial thing] with [fairly complex software or tools you've never used] while we watch you, you have 50 minutes" resembles that very much. The closest I've seen is situations along the lines of "meeting's in 50 minutes, could you find out about [thing similar enough to other things you've done or worked with that you are qualified to evaluate it on short notice]? I just learned we'll be talking about it in there and your take on [a couple specific aspects of it] would be useful." Not "you've never used this, I want a demo of [more than hello-world] in 50 minutes, or it's your ass", ever.