In my experience, this just isn't a real problem. If someone has any sort of track record in the industry, I've been able to correctly conclude that they can code. The only time I've found sample code useful is for people who are brand new.
Just like leadership and managerial tasks are not related to actual coding, talking about and evangelizing some library or technology does not mean you're a competent software engineer. They are very different skills.
Sounds like you've found yourself in an interviewing rut.
It’s just a widespread, deep culture problem in tech interviewing. The questions and evaluation procedures are set up to be pedantic oneupsmanship trivia, and are not rooted in psychologically healthy realities of the way people work or demonstrate skill or communication patterns.
Yet, he would have far higher chance to land in your company than me, because he would be super happy to pass FizzBuzz, whereas I would just walk away the moment you give it to me and make myself off for a month on Bora Bora to wash away the disgust I felt over your arrogance and pride you demonstrated on the interview.
Also, to address one more point in your reply - the inability to understand was a result of their incompetence, not the difficulty of the program (some standard C code).
"Whenever you find yourself on the side of the majority, it is time to pause and reflect." - Mark Twain
But if it was code that didn’t follow a process - especially C code - it could have had all sorts of security vulnerabilities. What if their process was never to use the “unsafe” variants of the C string and memory standard library functions?
At $JOB I feel bad that a lot of the talent on our team is squandered because they lack the self-confidence to speak up and question the status-quo.
I want to work with other people who have a deep-seated desire to do the right things, rather than only ever doing what they were explicitly asked to do.
So, kudos to you. Keep on fighting the good fight.
This person has actually thought about the effectiveness of FizzBuzz as test for overall programming skill. S/He will likely be an asset to the company due to having demonstrated a capacity for correctly assessing practices that are broken and having shown a willingness to refuse to continue following said broken practices.
There are three levers of power in an organization - relationship, expert, and role - in that order. If you don’t know how to build relationships and prove expertise and come into an organization like a bull in a china shop, you aren’t going to be effective - you are going to be disruptive.
I want someone who questions the effectiveness of broken practices, but you do that after you get the job, you have shown that you have a better way and you have built the relationships to push your ideas through.
I self demoted (responsibilities not pay) from a dev lead at one company to an IC at my current company. I have to bite my tongue repeatedly about things that could be done better but aren’t worth the effort to fight for. But on the other hand, I have to use “soft power” to change things and convince people about the things that are important to the organization.
Secondly, if all interviewees, say 5+ refuse to do the test on the basis of irrelevance, that would presumably change your opinion, would it not? It would certainly make me question the validity of my interviewing tests. Some people would probably blame a bad batch of interviewees.
Thirdly, some organisations need people to be disruptive as otherwise practices will never change.
Having said that, it really all comes down to how it's articulated. If candidate is polite and explains the reasons then that's fine. If candidate throws toys out of the pram then yes, I agree with you, not going to work.
People have widely varying approaches to relationships. I think it's beyond doubt that almost everyone who fails an interview at your (or any) company goes on to be employable somewhere else. So, it is valid to say they didn't know how to build a relationship with you, but then, you didn't know how to build a relationship with them. There is no correct answer to "which person is to blame for that", because each of them had the option to decide they don't want a relationship and therefore neither one controlled the outcome.
"I want someone who questions the effectiveness of broken practices, but you do that after you get the job"
If the broken practice is part of the interview, and a person has enough experience with interviewing at different places to know it's not the way everybody else does things, then they may have no reason to put up with it.
A danger in general of a single universal ("one true") standard, no matter how much sense it makes, is that you risk the people who have experienced different ways of doing things rejecting you for your chauvinism, without informing you that's what they are doing.
What ends up happening is that you offend the people you were hired to manage and they may follow the process changes grudgingly but they will “work to rule”, they won’t go the extra mile for you and they will not have your back when things hit the fan.
If I wouldn’t come in as a lead and immediately tell people the equivalent of “this is why you suck”, I’m definitely not going to do it during the interview.
I can see being scrupulously polite and tactful as having the potential pitfall that you lose sight of whether you really want the job. Psychological inertia in individuals and organizations can have a devastating impact.
If I came in to manage such a team. I would absolutely say so in no uncertain terms.
I have actually been in a similar situation but I did have the backing of senior management, in fact that was the main reason they hired me. They wanted somebody with experience in the industry to drive best practices so that they could show investors in order to attract investment (they had had two investors pull out after some due diligence showed that from a technical POV the company was in dire straits)
- it tells me whether I need to waste my time on doing harder questions.
- it tells me about your attitude when it comes to doing the grunt work that it sometimes take to push things over the finish line of whether you think you are too good to be assigned minor defects.
Both types of problems require a person be comfortable with arrays and iteration. It wouldn't be fair to give either of them to someone who can't get a simple for-loop right.
- those who are too bad for it
- those who are too good for it
If you're writing Spring Boot applications, tell me about which jars you include in your build to do that. Oh you only use Spring initializr? Okay, well, then tell me about which jars you added to your project after that initial setup. You say you use Kafka in your current role, tell me what jars allow you to set up Spring Boot Data for that. Oh, you don't use that approach? Interesting. We looked at doing that, too. And then, hopefully, you get to understand what they are doing and what they know.
Interviewing for Angular: What is your least favorite thing about working with Angular? What packages are you using in your application? Have you had trouble with your CI builds in Jenkins (or whatever they say they use?) I listen to them and I ask questions that ought to be relevant to them.
I typically start "hard" and then if I don't get anywhere, I ease back. You stated that you write REST services? Tell me, what Java library do you use for making a REST call from inside your application? Oh, okay, another team did that, I see...
And so on. It becomes very obvious whether the person is bullshitting you. I recently interviewed someone for a tech lead role who says he had been a tech lead at another company but I was astounded by not only how bad his answers were but also by how little he appeared to know about the business of coding. Either the guy was lying to use completely or he was in a real creampuff kind of lead role where you don't need to know anything about coding, anything about the architecture of the system you are responsible for, or anything useful at all, really. How do I get that job?
If you're doing this frequently enough, you probably have a template of which "jars" (dependencies) you generally use, so you probably don't remember.
If you're doing this infrequently, you probably googled what you need to include for what you want to achieve and forgot about it.
So you're filtering out efficient (templated a standard process) and competent (figure stuff out on the fly without guidance) people, and filtering in people who... remember the name of the dependencies they're using to implement things?
You're being ridiculous. Being able to converse with other developers is part of being able to do the job. A very common topic of conversation is "what libraries are you using on your project? Why are you using X instead of Y?"
I expect every engineer I work with to be able to talk about the tradeoffs of using (or not using) any library in any project they've ever worked on. Knowing what's in your application is important with regards to size, speed, understandability, modifiability, etc. I consider this information far more important than if you can reverse a binary tree.
> So you're filtering out efficient (templated a standard process) and competent (figure stuff out on the fly without guidance) people, and filtering in people who... remember the name of the dependencies they're using to implement things?
People who remember the dependencies they're using to implement things and can explain why they are using them are both efficient and competent. Most likely, anyway. It's not the only signal I use when hiring, but it's an important one.
edit: for clarity.
The first time I was given this problem on an interview it took me two attempts to get it right. That is, I wrote the code, ran it and it failed to do multiples of 15 properly
I went back and fixed it.
Would you count that as a failure?
I think it’s because many developers just call one API and send the result to another API - they never have to write any actual logic themselves, so they don’t know how.
One example: Declared themselves to be an experienced Pythonista of N+ years. Couldn't write a `for i in range(100)` loop in Python without hints. They probably could've done it in a different language, but I didn't want to have anything to someone who misrepresents experience in their CV. It's fine to say you don't know it and instead show me that you can learn it.
I'd love to see more openings saying "we use these tools, but we're open to work with anyone who can show they can learn them and be a solid team member".
I am curious as to how they would do with fizzbuzz.