[gervase]

When I was running hiring at a previous startup, we ran into this issue often. When I proposed adding FizzBuzz to our screening process, I got a fair amount of pushback from the team that it was a waste of the candidates' time.

Once we'd actually started using it, though, we found it filtered between 20-30% of our applicant pool, even when we let them use literally any language they desired, presumably their strongest.

However, it usually only filtered fresh grads (CS students from top-10 schools). Those with previous work experience almost never had a problem.

[cs02rm0]

When I proposed adding FizzBuzz to our screening process, I got a fair amount of pushback from the team that it was a waste of the candidates' time.

I've had the same, I was a contractor and not usually involved in the hiring process but I'd been asked for a question they could take to a candidate.

One of the team at the time was a young Maths grad, super bright but prone to being over confident. So I wrote a clear FizzBuzz question, passed him the pen and paper and asked him if he was sure when he was done. There was some minor issue, a boundary issue one think and he was livid with himself. So they took it to the candidate and apparently it was a bit of a disaster.

Personally, the first time I came across it was in an interview and I quite enjoyed it - simple enough to not be threatening but I guess sufficiently able to show I could write code as they offered me the role. They asked some extra questions too with some extensions and about how you could unit test it.

Beats having to implement red-black trees by remembering the crib sheet you read the day before.

[crispyambulance]

The interesting thing to consider is that before implementing the screen, did you hire some people that would have failed fizzbuzz? It makes me wonder how valuable the fizzbuzz screen actually is if people can just do it after a little bit of work experience.

I suspect that candidates who are otherwise fine (and not misrepresenting themselves on their CV's), fail fizzbuzz because they overthink the problem, stumble on the not-so-frequently-used modulo operator and then paint themselves into a corner where they can't just loosen up, take a breath and figure out the solution.

[blunte]

Exactly. If a company hires a programmer who cannot solve fizzbuzz, then the company utterly failed at interviewing. And in my opinion, this may indicate that the company will fail in other important communication areas.

You should be able to have a 10 minute conversation with someone and know if they can solve fizzbuzz (without even posing the problem).

[crispyambulance]

That 10 minute conversation is potentially far more nuanced than a go/no-go fizzbuzz quiz. It's a different thing altogether.

The fact is companies hire people all the time, without using fizzbuzz, probably hiring some number of people that would not have passed fizzbuzz if it were given to them. Were all those people definitely bad hires? I think not. The parent commenter's company had "survived" without it, and many do now.

It's understandable to want to have the ultimate "gotcha" interview question, the response to which screens out a candidate. It's not totally wrong, but there's a lot more to an interview. I think the onus should be on the hiring managers to develop their behavioral interviewing skills so that they're able to evaluate a candidate more fully than by using toy problem quizzes.

[jerf]

Speaking at least for myself in an interview role, I consider the modulo operator a bit of trivia that many programmers have no reason to encounter, and if you build a "divisible_by_5" function that works in some semi-sensible manner, I'd probably be happy.

[gwbas1c]

I would strongly oppose Fizzbuzz. Why?

It's so well known that everyone uses it to study for their interview. You'll end up hiring someone who just memorized the solution.

Instead, come up with your own unique programming challenge that the candidate hasn't seen before. It should be about as easy / hard as Fizzbuzz.

Related: I once interviewed a candidate who came across as knowing my questions ahead of time, and delivering a well-reheased answer. I made up a question on the spot, and got a "this wasn't supposed to be on the test" tone of voice in the answer. I rejected the candidate.

Technical interviews aren't things that the candidate should memorize and rehearse. That's why I'd never ask Fizzbuzz.

[theamk]

I don’t think anyone need to “memorize and rehearse” Fizzbuzz, the whole idea is it is so trivial that one can solve it on the spot without prior knowledge.

If one is concerned about people memorizing answer, it is pretty simple to change the question a bit to make it non-recognizeable,

[crimsonalucard]

That's the thing... you feel fizzbuzz is effective but the fact that it filtered out CS students from top 10 schools says more about the test then it does the student.

Think about it, it takes way more work, way more intelligence to get into and graduate from a top 10 school then it does to learn how to pass a fizzbuzz test.

I can 100% tell you that ALL CS grads from top 10 schools can pass fizz buzz given a day to do it. That being said I can also say literally most of your coworkers who are administering the fizz buzz test will not be able to ever attend a top 10 school given a lifetime to prepare.

It is incredulous to me that people can literally dismiss an MIT candidate because he didn't pass a fizzbuzz test. Do you not realize that it is 100x easier to learn programming then it is to get into MIT?

People need to get it through their heads. Programming is actually really, really easy. That's why there's so many people who can learn how to do it without going to college. But instead I see most people thinking that they are so intelligent they didn't need to go to college because they can just learn programming.... That may be partially true, but most of what I see is actually just people learning programming because they COULDN'T get into university.

But it still begs the question... what is making an MIT student fail a fizzbuzz test? It's like failing to recite a paragraph out loud with zero stuttering to an audience who is judging your future career. How could one possibly be so stupid and not stutter? If you stutter it must mean you can't speak english, just like how if you fail a fizzbuzz test is must mean you can't program.

To be honest I don't know why so many programmers fail. But I'm honestly pretty sure fizzbuzz is so dreadfully easy that there is some other factor that is influencing this high failure rate.

[gwbas1c]

> To be honest I don't know why so many programmers fail.

Because many people are not capable of programming.

More importantly, the school you go to has nothing to do with your capability of a programmer. I worked with quite a few people in my CS department who couldn't program their way out of a paper bag. Most were still very bright people who I assume figured out successful careers.

I suspect a lot of the recent CS grads who can't do fizzbuzz end up following careers that don't require programming.

It's also important to understand that Computer Science is not Software Engineering. Computer Science is fundamentally a mathematical field. Don't conflate the two.

[crimsonalucard]

>Because many people are not capable of programming.

You think too highly of the field. Programming is easy. Everyone, and I mean everyone can do it and eventually become good at it, especially fizz buzz.

>I suspect a lot of the recent CS grads who can't do fizzbuzz end up following careers that don't require programming.

Nah, more than likely they learn the fizzbuzz question and still become programmers because programming is easy. It takes time to learn programming like it takes time to become good at basic algebra or calculus, but literally anyone can do it.

>It's also important to understand that Computer Science is not Software Engineering. Computer Science is fundamentally a mathematical field. Don't conflate the two.

The two fields are intricately related. Most junior devs who lack the academic rigor like to separate the fields into a dichotomy and use this dichotomy as an excuse to justify the lack of expertise on the academic side.

After a certain amount of time you'll realize that all of programming is rehashing the same concepts over and over again just in a new framework/language. To gain deeper insight into the nature of computer programming and engineering and to actually become better, the dichotomy must be eliminated. In the upper echelons of Software engineering, people will realize that computer science and software engineering merge to become the same thing. Juniors have yet to realize this.

Take this for example. Did you know that a unit test does not guarantee correctness of a function? To guarantee correctness of a function you'd have to write a unit test for every possible input of a function. Did you know that computer science offers a way to do prove your program 100% correct without writing a single unit test? This is an example of a merger of engineering and theory. A computer is a deterministic machine amenable to proof yet we choose to treat it like a black box and test it as it was a chaotic system that needs to be tamed. There are advantages and disadvantages to both methodologies but I illustrate this here to show you that SE and CS are in fact different aspects of the same thing.

[gwbas1c]

Computer Science has very little to do with unit testing.

Look at things like theoretical computer science and category theory. The word "class" comes right out of basic category theory. (You don't need any category theory to program a computer, but it directly influenced object oriented programming.)

And, if you think programming is easy, consider yourself lucky. Take the time to learn some soft skills. Maybe you'll understand your downvotes.

[crimsonalucard]

> Take the time to learn some soft skills. Maybe you'll understand your downvotes.

lol, I'm not here to win votes. This is the internet. This comment alone shows a lack of soft skills on your side. Except for when the person I'm communicating with chooses to get personal I never get personal when I talk about things on the internet and I never hold back either, that's part of the appeal of being here. I can tell what I believe to be the truth without concern for your feelings. Despite the lack of concern for your feelings I do make deliberate effort to not attack YOU directly. I am aware that the things I say may piss people off but in all I'm just here to talk about the topic at hand without worrying about real world stuff like your feelings.

>Look at things like theoretical computer science and category theory. The word "class" comes right out of basic category theory. (You don't need any category theory to program a computer, but it directly influenced object oriented programming.)

OOP was invented before anyone knew that category theory had anything to do with computer science. Class most likely comes from set theory. Also if you work with category theory or languages that implement the theory you'd know that the morphism is central to the theory not the object. In other words it has much more to do with Functional programming then it does with OOP. OOP has virtually no theoretical basis and it fits into category theory in a very awkward way.

>Computer Science has very little to do with unit testing.

It does. I'm literally talking about how it does have to do with theory.

In computer science there are two ways to verify 100% correctness of a function. You either prove it correct given an initial condition and a final condition. Or you unit test every possible input with the associated output. Software Engineering chooses to go with neither approach. Software engineering chooses to go with a tiny subset of all possible unit tests and hopes that the correctness of that subset of tests correlates with the correctness of the entire domain. This is a more applied math (aka statistical) approach to verification that increases confidence but does not verify the program to be correct. (This is also debatable how much statistical rigor unit tests have as its a usually done with a very ad-hoc approach... unit tests are usually too few in number and highly biased).

All of this is part of Computer Science. You will note that the paragraph above uses the word "unit testing" Software Engineering is simply application of said theory or application of no theory but they can be one in the same.

>And, if you think programming is easy, consider yourself lucky.

I hear parents talking all the time about trying to teach their kids programming. Internet tutorials are all over the place. It's easy in the sense that mostly everyone can learn it. It's not easy in the sense that it does require a lot of effort.

What's hard is quantum physics. You ever hear of an internet tutorial that will teach you all of quantum physics? An udemy course that will cover all you need to know? Ever hear parents trying to teach their kid about quantum physics? Quantum physics is hard, programming is not.

[AnimalMuppet]

Computer science != software engineering.

> Programming is actually really, really easy.

Perhaps. Software engineering is hard, though, and it is not the same as CS. We turn out these CS degrees, and then we expect that they can do software engineering.

That said, fizz buzz may not be the best way to tell if people can do software engineering, either...

[crimsonalucard]

Software engineering is easy. Most people are familiar with it as an aspect of canned design principles to ensure safety and scalability. You can read about it all in books or internet articles and come up with it on your own.

Have unit testing, have integration testing... make it modular... SOLID, write layers, yada yada yada also very easy.

I always hear people say that Computer science != software engineering but really it's the same thing at the upper echelons. Rather than using your gut and all these anecdotal "principles" spewed out by people like Martin Fowler, design pattern books, or books on testing and agile you can actually use theory and science to guide your software engineering decisions.

Let's put it this way. Software engineering is the only engineering discipline where people can get away with not knowing science and mathematics and still build systems that can run. The effective and elite software engineer lets theory and science guide his decisions as well to make systems that are better.

I do agree with you that fizzbuzz is missing something.

[AnimalMuppet]

This is so over-the-top that I can't tell if it's parody, trolling, or just horribly mistaken.

In case you're serious, though, you clearly have no clue what software engineering is. Yes, it includes some of the things you mention. No, it's not the same thing as CS at the upper echelons. Yes, you should include theory and science in your software engineering decisions, but no, just (CS) theory and science isn't going to be enough.

BTW, because I don't know how to contact you to tell you this: Your HN profile says "Actively searching for opportunities. email me if interested", but doesn't actually provide an email address.

[crimsonalucard]

>This is so over-the-top that I can't tell if it's parody, trolling, or just horribly mistaken.

I'm totally serious. Not trolling at all.

>In case you're serious, though, you clearly have no clue what software engineering is.

The term is so hand wavy. You can read this: https://www.wikiwand.com/en/Software_engineering

Just go to the "Subdisciplines" section in the wiki

Literally every example I mentioned is covered by a "subdiscipline" of software engineering. I'll quote the part that covers my examples:

"Software design:[1][23] The process of defining the architecture, components, interfaces, and other characteristics of a system or component. It is also defined as the result of that process. Software construction:[1][23] The detailed creation of working, meaningful software through a combination of programming (aka coding), verification, unit testing, integration testing, and debugging. Software testing:[1][23] An empirical, technical investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software maintenance:[1][23] The totality of activities required to provide cost-effective support to software."

What happened here is that I never had a strict definition of software engineering in my head. I do know that a big aspect of it usually has little to do with the theoretical side of things, so in my example I just mentioned all the "technical" terminology people throw around that has little basis in rigor or theory. Then when you said I have no idea what it is, I looked it up, and the definition literally covers almost everything that has to do with software including my examples.

There is literally zero chance you could have known that I have "have no clue what software engineering is" because my examples are covered by the definition stated in the wiki. That is zero chance unless you have no clue yourself.

A more accurate explanation is this: "software engineering" is a vague hand-wavy term. Sort of like how "Science" doesn't always involve the "Scientific method." You have some super clear definition of the term in your head, but clearly from this wiki not everybody thinks about it that way.

>Yes, you should include theory and science in your software engineering decisions, but no, just (CS) theory and science isn't going to be enough.

When did I say only CS theory is enough? Many aspects of software and the real world don't have any science or theory to describe it. Usually when you encounter such an aspect of the real world the vernacular changes from "deriving" a solution to "designing" one. My emphasis is that many engineers are "designing" things that are ultimately covered by theory and ultimately can be "derived," they simply turn to "design" either because they are unaware of theory or the theory is too hard.

We are in agreement on the point you mentioned, but I never said all you need is theory. Humanities theories about the universe are prove-ably incomplete and unprovable in general, therefore we have no choice but to exit the theoretical world for many engineering problems.

>No, it's not the same thing as CS at the upper echelons.

By upper echelons I mean you've basically learned most of it, the only thing left is the theoretical part. The theoretical part is harder and usually something a software engineer gets into once he's figured out how the rest of the non-theoretical parts work. You'll note that "mathematics" encompasses "software engineering" as defined in the wiki. I'm also not sure why you disagree with me nor am I clear about your own definition of software engineering, so please explain if you can.

>BTW, because I don't know how to contact you to tell you this: Your HN profile says "Actively searching for opportunities. email me if interested", but doesn't actually provide an email address.

Thanks. I think at one point I had it up there. I forgot why it was removed. I never got a contact from here anyway.

[sn9]

I feel like you and everyone else are missing the obvious explanation: people who claim to be from a top 10 CS program who can't solve FizzBuzz in a few minutes lied about their background.

I find it hard to believe that anyone who has spent more than a week programming couldn't solve FizzBuzz. Even if they somehow weren't familiar with the modulo operator, you could just explain how it worked.

FizzBuzz is a way of easily filtering con artists.

[crimsonalucard]

You could be right. At the same time as unrealistic as it may be, I feel during interviews smart qualified people just screw up and have brain farts all the time.

An interview is almost like public speaking combined with an intense time based coding competition without allowing you to use an IDE.

I think a good number of these guys are lying. I agree with you. But I also think a good number are honest and actually failing.