I once interviewed a "senior engineer" who was nearly twice my age. I was very intimidated; his resume indicated that he should be the one interviewing me, not the other way around.
We chatted for a while, and I felt really good about him. However, I had a gut feeling I should just check to make sure he could do the equivalent of fizz buzz. I said something like "Sorry for this formality, I know it might be seen as an insult to your experience... could we do a bit of coding?" His resume indicated nearly twice as many years of C++ experience than me.
I took out my laptop and produced three function signatures - one passing by reference, one passing by pointer, and one passing a pointer by reference. I asked him to explain the difference between the three. With a completely straight face and unshakable confidence he replied "no difference, they are all three ways of doing the same thing". I asked some clarifying questions, trying to probe the difference between pass-by-reference and pass-by-pointer. Again, he answered extremely confidently and coolly (but incorrectly).
"Err, no." I replied. "This ampersand here is a pass by reference, which means c++ handles the referencing and dereferencing of the pointer automatically. It's much safer than the other two, where you are ultimately dealing with a raw pointer and need to check for null pointers before dereferencing". Immediately he broke out into an uncontrollable sweat; it was really remarkable. Before asking the technical questions, I felt really good about him. I wonder how many companies he has fooled.
At this point everyone knows he's a fake. He's not involved in anything technical despite being a "senior dev". It was quite uncomfortable when he was programming and we had to review his code but at this point he's just hanging out in the office and sitting in on meetings.
I wonder about his psychological state. He doesn't seem happy.
It's a story I've been told. Candidate is being interviewed for a senior position, there are three employees conducting the interview: one HR rep, one (non-technical) manager and one senior engineer.
The engineer supposed to help with the interview arrived late so the HR rep and manager briefed him, basically telling him the interview was going well and that they were considering hiring him unless he had any objections.
Going back, he asked the candidate a simple Fizz Buzz question, something like finding the largest element in an array. All hell broke loose suddenly. He was outraged and started telling them that, back in his country he was a university professor and that this was beneath him. The interview ended with the candidate arguing for 10 minutes that he shouldn't have to do this test. If I recall, at this point the senior engineer just left the room and didn't bother with the remaining 15 minutes of the interview.
Needless to say they didn't hire him. HR was shocked as he seemed to be a great hire.
Fast forward a few years later, I'm the one interviewing and I systematically get great resumes who can't implement a simple version of word count in 30 minutes.
Yeah, which is why in-person coding challenges became a fashion in the first place. It's shocking to see the number of "software engineers" who manage to engineer for themselves careers where they don't actually engineer software.
If anything, my personal beef with the classic FAANG interview problem is that it's conflating two very different skills. These are "hard" problems, and require some reasoning and logic in addition to coding. What's constantly surprising to me is the extent to which these skills are decoupled. It's routine to find very smart people with excellent math skills who can't code, and the converse.
And the really mind-bending thing to me is that of the two, it's coding which is by far the rarer skill!
This statement applies to software developers of all ages and fortunately it is very easy to identify these kinds of developers.
However, using the write an algorithm test for this can be problematic as it can easily eliminate software developers who are very good at coding and problem solving, but have chosen not to spend their time memorising the inner workings of standard algorithms, in the hope that one day they will be asked about them in an interview situation.
I don't need to know how to write my own hash table to know how, why and when to use a hash table.
I don't need to implement my own sorting algorithm to sort my list of items.
These and many more standard build blocks come pre-built and ready for use as part of the software development kit.
It honestly is shocking. I tend to ask a question that I think would be an easy 101 homework assignment, and easily a third of candidates fail it so poorly I could end the interview right there. Another third fail, but close enough to where there's a bit of hope if they did the rest of the interview perfectly.
It's basically a word problem that can be solved with a for loop, and you wouldn't believe the number of people who hard code for the values in the list instead of just looping through it (think 10 if statements).
