4 ms·
90 of it is probably that they're thinking there must be a more involved solution than something a 7yr old could solve, otherwise no reasonable person would use
by BoiledCabbage 6y ago
90 of it is probably that they're thinking there must be a more involved solution than something a 7yr old could solve, otherwise no reasonable person would use it to differentiate candidates with a university degree for a professional position.
As an option, you could try prefacing the game with saying "the solution to this might be very easy", and see how many more solve it.
Then you'd know you're likely not making a decision based on any signal of skill or ability at all, and just on them trying to make a prediction on what you're looking for.
Edit: I had to come back to this, because the more I think about it the more it's mind boggling to me. You interview is very likely filtering out the smartest candidates and selecting for the rest.
A typical strong candidate, that's prepped on interview questions, has maybe had other interviews at companies with challenging problems is going to look at it and think "This is a problem this interviewer uses to differentiate between top tier candidates and those who don't get offers. There is no way they're asking me a question that's so easy that any 7 year old child can answer it. There's gotta be something I'm missing." And keeps digging into it.
And a very weak candidate will say think "This is my 10th interview, and sweet, finally a question I can answer!"
These absurd backwards mindgames are exactly (one of the many things) thats wrong with software interviewing.
- lmilcin 6y agoFirst of all, this was many, many years ago. Nowadays my interview is half an hour of (hopefully) nice chat, followed by half an hour of technical questions followed by half an hour to an hour of coding exercise with real IDE. We all learn on mistakes, my interviewing process evolves as I learn which things do and which don't work. Second, one of the goals of the interview is to see whether you can deal with the problem analytically. I am purposefully setting up problems that do not require (much) prior knowledge to observe the process of how the candidate deals with the problems. While our knowledge of particular topics changes, our general approach to solving problems is almost set in stone for similar/related categories of problems. If you are developer who does not predict how the code is going to work but rather rely on running it umpteen number of times and reshuffling instructions until you happen to make it work, this isn't just a sign of your lack of knowledge but rather your general approach to dealing with them. I bet, and I have observed it many times, that the person will do roughly the same when faced with a number of varied problems.