Oh how I agree with this post. And I've been the asshole on the hiring end before - but I (hope) have learned my lesson.
I recently interviewed with a consultancy (role was UK-based) that is desperate (quite literally) to hire experienced developers in the technical area I have experience in. I came highly recommended by a recent senior hire of theirs (he had been my manager).
The technical filter question in the face-to-face interview was (paraphrased and simplified): "write an algorithm on the whiteboard to check for mismatched braces".
I described an approximate solution aloud, but did not complete the solution in the interview.
As it happens I solved it in my sleep the following night - but of course they will never, ever know that.
Now everyone will have their pet theories as to why this is a good or bad question, but these are frankly moot because I am confident the hiring developer had no idea what he was testing for with it. He may have a vague "I know the answer, so he should too" mindset, but not much more.
What does this question, presented verbally in an interview really test? A recursive solution sprung to mind, but I can recall implementing recursive solutions in production code only a few tens of times over a ten year career. The question does not test for experience with the technology they are hiring for. It certainly filters out developers who cannot come up with an algorithm while standing at a whiteboard infront of a hostile audience. I could go on, but the biases implicit in this question are as numerous as they are irrelevant.
After a few years in the industry you typically get to work direct with these so-called "top end" consultancies anyway, so you get to know what these kind of questions don't filter for. I can say with confidence and from experience they don't filter for ability to create high quality software.
The thing is, this 'clever' 'does he know recursion?!' question is almost insultingly trivial when compared to the type of problems most development teams face.
Like the fact that although "Joe" has an IQ of 150, he speaks in sentences so impossibly convoluted he may as well be mute. Or "Alice" the sole domain expert, who begrudges her position in some way and will only communicate after you have negotiated the massive chip on her shoulder.
Hell, most organisations can't even provision accurate testing environments and force their developers to run underpowered Windows laptops.
> A recursive solution springs to mind, but I can recall implementing recursive solutions in production code only a few tens of times over a ten year career.
If you are not comfortable with recursion, just remember: Recursion is really just a free stack. To use your example:
Whenever you see an opening brace, push onto the stack. (Or, make a recursive call, which goes onto the call stack...)
Whenever you see a closing brace, pop off the stack. (Or, return from the recursive call, which then pops off the call stack...)
If the stack isn't empty at end of input, then there are mismatched opening braces. If you ever try to pop from an empty stack, then there are mismatched closing braces.
Thank you for the helpful comment. I can't help but feel you miss the point of my post though. I can solve the problem. Verbally, (but admittedly less eloquently and less complete) I approximately gave your answer in the interview. Give me a quiet Monday morning, a pair of headphones and a compiler/interpreter and I can solve it well.
It's the fact that it is being used as a filter when the person filtering doesn't know what is being filtered in and out.
All in all, it's a spectacular waste of time and money.
I understood your post. I didn't comment on your other points because I didn't feel I had anything to add. I was just trying to be helpful in regards to the particular problem you posted, and for anyone having trouble with recursive problems in general.
I recently interviewed with a consultancy (role was UK-based) that is desperate (quite literally) to hire experienced developers in the technical area I have experience in. I came highly recommended by a recent senior hire of theirs (he had been my manager).
The technical filter question in the face-to-face interview was (paraphrased and simplified): "write an algorithm on the whiteboard to check for mismatched braces".
I described an approximate solution aloud, but did not complete the solution in the interview.
As it happens I solved it in my sleep the following night - but of course they will never, ever know that.
Now everyone will have their pet theories as to why this is a good or bad question, but these are frankly moot because I am confident the hiring developer had no idea what he was testing for with it. He may have a vague "I know the answer, so he should too" mindset, but not much more.
What does this question, presented verbally in an interview really test? A recursive solution sprung to mind, but I can recall implementing recursive solutions in production code only a few tens of times over a ten year career. The question does not test for experience with the technology they are hiring for. It certainly filters out developers who cannot come up with an algorithm while standing at a whiteboard infront of a hostile audience. I could go on, but the biases implicit in this question are as numerous as they are irrelevant.
After a few years in the industry you typically get to work direct with these so-called "top end" consultancies anyway, so you get to know what these kind of questions don't filter for. I can say with confidence and from experience they don't filter for ability to create high quality software.
The thing is, this 'clever' 'does he know recursion?!' question is almost insultingly trivial when compared to the type of problems most development teams face.
Like the fact that although "Joe" has an IQ of 150, he speaks in sentences so impossibly convoluted he may as well be mute. Or "Alice" the sole domain expert, who begrudges her position in some way and will only communicate after you have negotiated the massive chip on her shoulder.
Hell, most organisations can't even provision accurate testing environments and force their developers to run underpowered Windows laptops.
Let's walk before we can run yeah?