I actually interviewed a candidate once who regularly spoke at tech conferences. This person certainly had an industry track record, yet they failed spectacularly with FizzBuzz and did even worse on the questions about simple data structures. It's possible they were having a bad day, but it's equally plausible that we had encountered someone who could just talk really convincingly about things in very general terms.

If you skipped FizzBuzz and went with another programming exercise, e.g. giving some simple dynamic programming or reordering lists etc., would FizzBuzz actually be useful at all? From my point of view FizzBuzz is about asserting dominance right from the start ("oh, you want a job you lowly peasant? here's what you need to do!") and not about actually interviewing anyone. It's a complete waste of time and filters out all candidates that respect themselves that walk away/decline offer, you ending up only with desperate ones.

If you think you are too good to go through the interview process, that also sends a signal. That you are probably going to be a cowboy if we hired you and not follow processes.

There is a cure for companies with your attitude, it's called competition, resulting from letting those "other" people to join/create your competitors that then in due time push you out of your markets.

No company of any size - even with as few as 10 developers needs cowboy coders. Someone has to maintain your code, we have a CI/CD process that means you don’t just push your code to production from the IDE for a minor code fix, etc.

I still remember when I helped a friend at another "famous company" not to get kicked out due to incompetence and wrote some program for him overnight. His colleagues weren't able to understand what it was doing for over a month, it made it to the software core of devices they shipped and he received a yearly innovation award for it. A year later I met him and he was sarcastically pointing out a small bug in the code he found (well, since then I try not to help).

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.

Thanks for making this comment. I'll be sure to ask FizzBuzz in every interview I ever give, just to weed out people with such a horrifying attitude.

"No good goes unpunished"-style? I definitely wouldn't want to work for a person with perverted views of justice as you imply, so you'd make all us a favor by exposing yourself right away.

For what it's worth, I have a strong reverence for those that see their own value, and I wish more people were like you.

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.

And this gets back to my main point. If you wrote code that no one can understand, you wrote unmaintainable code that was a net negative to the company.

Yet that piece of code that made me altruistically sleep deprived and for which I didn't get anything proved to be extremely valuable to company, its customers, to my friend and his colleagues that could learn something useful. Yet it didn't follow any process, so it better not happened :D

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).

So I’m sure you’ve heard that once you think everyone is wrong - you might need to look at yourself. That’s just like if I hear someone who has been married four times and complain about how each one of their wives were horrible people and since have gotten remarried and have happy lives, they probably weren’t the problem.

"The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." - Marcus Aurelius

"Whenever you find yourself on the side of the majority, it is time to pause and reflect." - Mark Twain

I’m not saying your opinion is wrong because you are in the minority. I’m saying if $x number of engineers who work at the target company and are producing code everyday can’t understand your code, it is more likely that your code was obfuscated than that they were incompetent.

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?

It featured a simple callback and they couldn't wrap their head around it. Now it sounds laughable, it made me feel sick at that time and I avoided that "leading" company since, and it unfortunately skewed my view of anyone who ever worked there. I know it shouldn't have, but I am a limited human being as well and have to use some decision heuristics.

Another way of looking at it would be:

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.

But at the point of the interview, I don’t know you from Adam.

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.

"If you don’t know how to build relationships"

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.

Even when you come into a job as a manager, it’s almost universally bad to start criticizing processes and to make big changes before you understand the reasoning for a process and talk to people.

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.

In general this is true, there are always reasons for bad practices but what if the some teams in the company don't use a source control system, they just use folders on a network drive?

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)

Well, there's no reason to tell people "you suck" in an interview (as the interviewee), but that's more a matter of personal pride and style.

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.

Firstly, I was just drawing attention to the fact that you can draw different conclusions from the same information.

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.

The person at the interview isn’t part of the organization yet.

Fizbuzz qualifies as an "interview process" now? The exercise is pointless, it wastes everybody's time and only an amateur would use it.

It’s a double Bozo filter.

- 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.

>If you skipped FizzBuzz and went with another programming exercise, e.g. giving some simple dynamic programming or reordering lists etc., would FizzBuzz actually be useful at all?

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.

Well, you can cleverly hide FizzBuzz in some list/DP-related operations; that would probably make me laugh and I'd give you creative plus. Still, the original one (I read the original article that started this silly trend a few years ago) would make me think very low of you.

Reading this thread solidifies my desire to ask for FizzBuzz, so that I weed out 2 types of candidates :

- those who are too bad for it

- those who are too good for it

I believe you. It's just that assuming they made it through the whole process, showed up, and couldn't do the work, I think the thing to do is just sit down and say "this isn't working", part ways, and on to the next one.

To me, this says more about the failure of interview questions about data structures than about that (probably perfectly competent) candidate.

I've met and had the misfortune of working with folks who have gotten jobs via beers-and-handshakes interviews. Supposed "lead" and "senior" engineers who couldn't comprehend basic control flow, who wanted, and attempted(!), to write their own Rails clone, Flux clone, etc.

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.

Nah, this type of anecdote is overblown, usually by people with a vested interest in keeping leetcode-like interview puzzles as a gatekeeper barrier to hiring and internal advancement.

Well that’s just a false dichotomy. One can provide a coding challenge that isn’t a lame “gotcha” puzzle.

In theory sure, it just doesn’t happen in tech interviewing though.

Well, anecdotally, it absolutely does happen in tech interviewing, and I'm saying that both as an interviewer and someone presently interviewing for a job.

Sounds like you've found yourself in an interviewing rut.

No, been in the same job happily for a while & not currently interviewing. I am also an engineering manager and happy to be out of the hell of rank and file engineering interviewing in my career.

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.

Fizzbuzz is a leetcode puzzle?

Huh?

Every substantial program uses at least one data structure. The problem isn’t asking about data structures or even algorithms. It’s about asking leetcode.

I agree. Maybe to a limited extent I’d also say not accommodating the candidate’s working requirements (introvert vs extravert, choice of editor, time pressure) is another big part of it.

In my experience, it is. I've done technical screens with _failed_ fizzbuzz-grade problems to people whose CV said that they have been coding for years, and those people were looking for (Senior) developer roles (not management, 'architect', just plain developer).

In what way did they fail?

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’ve spoken to people who get about as far as writing a loop and printing the number but just have no idea how to go any further with the fizz and buzz logic at all, even with lots of hinting.

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.

> In what way did they fail?

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.

OMG can I come work for you? Been coding for my entire life, just don't have the resume text to back up the fact that I can learn just about any language/tool/framework/gizmo that I come across, so trying to get hired to any particular place, who all require "proven track record, 1+ years in X,Y,Z,ZZ and ZZZ", is almost impossible.

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".

One of the customers I work with is currently looking for backendy/devopsy people who want to work with Go/Python/Kubernetes/Bazel and make things better. There also exists also some frontend stuff that needs work. Basically, we're looking for generalists. Get in touch if this sounds like your sort of jazz :).

That's interesting. It hadn't occurred to me that some of the failures might be down to people trying to code in a language they are not familiar with.

If you can't screen those people out in the introductory phone call then your hiring process is broken.

How would you structure such a call so that this candidate would be filtered out?

Ask them to write fizzbuzz over the phone?

This was over a phone/internet call (first technical screen after a non-technical recruitment call). Or are you saying our non-technical recruiter should be asking potential candidates to write a fizzbuzz?

I am interviewing candidates in the Fortune 10. We get a lot of fraudsters that have found a way to lip sync Webex interviews and do all manner of silly things to get marginal people hired into roles they aren't suitable for. After 25+ interviews, and hundreds over the last nearly 20 years of my career, I can tell you in just a few minutes whether I want to work with that developer or not. I don't have to ask them to code, I just have to ask them things about our day to day work that only real developers know, for example:

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?

>tell me about which jars you include in your build to do that

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?

> 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.

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.

I've interviewed many people with years of impressive-looking developer experience on their resumes who couldn't write FizzBuzz. There are lots of them out there. They do other kinds of developer work: speccing middleware, designing database schemas, negotiating APIs with customers, organizing data assets, leading scrum meetings. Valuable work in its context. But if you want to hire people who can actually code you should test for it.

I've worked with people who had been working in programming jobs for some years, and didn't have any instinct for coding. Give them a detailed spec, or some detailed business logic, and they could write code to match it. But when left to their own initiative they would fail completely.

I am curious as to how they would do with fizzbuzz.

So either you’re in a niche or someone is phone screening before your interview. Or we live in different worlds.

Sometimes I do the initial screening, sometimes someone else does it. Generally, I find if I do a good job of explaining what we do and need, people tend to resonate, or not. Most people don't want to show up to a job they can't do successfully.