There is at least one serious misconception in this article.
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
Nope. The famous fizzbuzz test simply asks "can you actually write code at all?", because it turns out that some people applying for software development jobs basically can't. Even people with relevant-looking experience on their CV/resume. Even people who talk convincingly about what they've done.
(If you don't know about your preferred language's modulo operator but can do truncating integer division, you can do FizzBuzz that way instead. If you don't know how to do division, you can do it by having counters that count up mod 3 and mod 5, or one counter that counts up mod 15, and you don't need "mod" in your vocabulary to do any of that.)
Now, whether a candidate can write code -- like whether they know their language's modulo operator -- is also just one bit of information, but it's a really important bit of information that turns out to be tricky to get. This is also one reason for the "code on a whiteboard" tasks that many interviews use, which the author also doesn't like.
It may be that those are bad ways to get that one bit of information. But the author doesn't seem to appreciate what problem those things he criticizes are trying to solve.
1. Interviewing interns or new engineers while telegraphing the fact that your interviewers are absolutely uncreative.
2. Showing mid-senior interviewees that are a good fit that there is either a glaring hole in the recruitment team’s ability to filter out unfit candidates or that the interviewer thinks everyone is a dumbass but themselves.
You are correct, you do get the "can this person actually write _any_ code" info. More than that I think you get the "is this person good at writing trivial code".
I'm not sure the groups of people that "write good production quality code" and "write trivial interview code" intersect all that well.
Worse it would push for people that _excel_ at writing trivial interview code, which in my experience is inversely proportional to how much they are going to contribute to the success of the company. Though this is admittedly anecdotal.
Worse still you're going to be sending a signal to the interviewee that you are a kind of company that values trivial code. It's an interview both ways, the company gets evaluated too. The better the dev, the more offers they have so they might just not pick you based on stuff like this. They'll just get a _gut feeling_ that it's not a place they're going to like - that kind of thing.
As an interviewer, I personally don't think it's worth that bit of information, both in a game theory best outcome sense and just as a basic human decency.
Let's say you are an awesome C/C++ systems engineer.
Interviewer can pose a programming problem expecting an answer using recursion. But as you are C/C++ systems programmer, you know recursion is inefficient and you have never used it in production code.
So, it will not naturally occur to you to use recursion. You will go down the path of coming with a clever iterative solution with complex hand-crafted data structures etc. If the interviewer isn't well-versed in these low-level techniques then they may end up judging incorrectly. And usually such a low-level solution won't be easy to complete in a short 20-minute interview setting. whereas a recursive solve would be doable. which would lead to the interviewer feeling justified in judging negatively. That's how you can be good at production code and bad at trivial code :)
Well writing trivial code is still a skill, you could have been coding for 10 years and in your day to day work have managed to remove little annoyances and quirks, allowing you to express business logic concisely. I mean we usually don’t go about implementing linked lists and bubble sorts and such.
And this skill gets pushed down, forgotten.
It’s perfectly possible to write excellent battle tested and performant production code for years without encountering any of the stuff you see in the interviews.
And then they go to an interview and someone demands they wiggle out that piece of info from their long _long_ memory, in an unfamiliar env / os / periphery. With a huge time pressure...
Some people are good at that sort of thing, some people are good developers. Doesn’t mean they’re the same people.
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.
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.
"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.
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.
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.
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.
- 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.
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.
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, 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.
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).
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’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.
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.
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.
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.
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.
OK, I'll write your desired fizzbuzz in Haskell in a way that you won't be able to understand it for the next 30 years. You'll moreover piss me off and get a placement on my blacklist of companies to never work for and me actively spreading the news about your interview to anyone capable I know, hoping nobody is going to waste time interviewing for your jobs. Happy now?
No, not happy now. Your technical skills may be off the charts, and your criticism of fizzbuzz may be completely valid, but I don't want people with that kind of attitude anywhere near my team.
There's going to be stuff that isn't done the way you want, in the company policies, in the code base, in the architecture, in the way the team works. If you're going to respond in an I'm-above-this, salt-the-earth kind of way when that happens, then no, I don't want to hire you. Go destroy some other workplace.
As I said, this is orthogonal to whether your criticism of the use of fizzbuzz is valid. Your response may make you feel better, but it's showing me a lot about who you are, and it's not improving your hireability.
If I were asked fizzbuzz in an interview, I think I'd say something like "I'll answer that. But I expect the rest of the interview to be at a considerably deeper level."
You are making amazingly far-reaching decisions from very limited information, a quality I definitely wouldn't want to see in my superior. A dislike of a certain test must mean "to destroy some workplace". I am now wondering if all the issues we see with politics lately are happening because people are becoming single-dimensional, unable to even consider someone else's view if the way it's presented slightly deviates from what they demand.
As somebody who was often interviewing other people fighting for jobs at top companies I worked for, I would never ever offend them by throwing FizzBuzz in their faces; I don't have such arrogance in me. I would rather try to figure out what clicks with them and throw them something tasty where they can show off, then increase pressure to see what needs more work, then explain/discuss what could have been improved. I would respect their time and help them to learn something on that single interview they had with me. Never throw into their faces that they are frauds which is implied by employing FizzBuzz. One doesn't have to be a super psychologist, just simple empathy is sufficient to understand that people perform best when they are respected and treated as adults.
> > > You'll moreover piss me off and get a placement on my blacklist of companies to never work for and me actively spreading the news about your interview to anyone capable I know, hoping nobody is going to waste time interviewing for your jobs.
Now you say:
> A dislike of a certain test must mean "to destroy some workplace".
That was a bit more than "a dislike of a certain test". If we hired you and you reacted that way to something you didn't like, that would be in "destroy the workplace" territory.
You mean me employing colored words, even if they nowadays became pretty much colloquial without harsh emotional content? In that case I apologize, though at that moment when I was writing it I wanted to emphasize that I viewed this whole FizzBuzz charade insulting, basically treating interviewees as frauds. I think sometimes for the sake of proper behavior reinforcement the use of those words is vital and they fulfill their proper linguistic function when needed, otherwise they wouldn't have existed. They likely made you feel bad, which is exactly what I wanted to achieve whenever anything about FizzBuzz is mentioned; I hope this feeling stays with you and just for the sake of feeling good you would avoid FizzBuzz from now onwards.
Your words made me feel bad about you, not about myself or even about FizzBuzz. If your intent was to emotionally manipulate me into not using FizzBuzz, you utterly failed.
I was specifically addressing the FizzBuzz problem as stated in the original article a few years ago, not some random sanity checks for some positions. If you read that article and used it in interviews, you'd have demonstrated to me your disregard of experience, your lack of inventiveness, laziness, and far reaching arrogance, qualities I wouldn't want to see in my superior, so it's obvious it'd be better to avoid each other and maybe meet only on the golf course or as competitors/suppliers.
> You'll moreover piss me off and get a placement on my blacklist of companies to never work for and me actively spreading the news about your interview to anyone capable I know, hoping nobody is going to waste time interviewing for your jobs.
I think that sort of worldview puts you below the hiring bar, regardless of your technical ability.
So you are only willing to employ desperate people that allow you to literally walk over them in the interview? Like there is no other suitable exercise to give them, just the absolutely worst one to make them depressed?
Next time you need a lawyer (I am sure you will), ask them which new laws were enacted in the UK in the year 1648 and if they couldn't answer, don't hire them!
I hire people that can follow the process. I’ve had to establish processes for a department that the cowboy coder in me didn’t like and that I made myself follow.
I’ve also had to implement processes for some type of compliance reasons - most of the time HIPAA. The last thing I need is to be sitting in front of lawyer as Directly Responsible Individual, explaining why we weren’t in compliance.
OK, it makes sense in regulated industries; I had to pass some HIPAA-related exams to even process some medical data for Deep Learning so I understand that part. Still, it's premature to call anyone not willing to do FizzBuzz a cowboy coder, isn't it? ;-)
There are a lot of things that you aren’t going to want to do but we had to for various reasons - everyone has a boss. The last thing I need is someone who is going to fight the process the entire way.
How do you think bosses are made? Usually two ways - by kissing up and befriending managers or by improving processes & methods that are no longer functional and becoming detrimental to the future of the company. I would side with the latter even if it is way more difficult than to make somebody feel good about themselves.
But that’s what you don’t get. It’s much easier to get your ideas through if the manager and your coworkers like you and trusts you. You would be amazed at the processes and changes you can make just by having the interpersonal skills to do it.
What if I have those skills, can "make everybody love me" (...) & build a wonderfully harmonious company together, but I still hate FizzBuzz and avoid anyone who uses that on me, hard pass/hard filterish-way?
As you mentioned above, you treat it as a double Bozo filter, I treat the use of it as a Bozo indicator and as "passing the Bozo event horizon in this company right now"; and my decision to walk away is like getting out of a dangerous situation with a black hole next to me.
The FizzBuzz challenge is not aimed at good coders. It is aimed at bad coders. Assume you are in the hiring seat. You need a simple and quick way to find out if the person is completely B.S his resume, so that you can move to tougher questions, or end the interview.
For instance, if you said you were a skateboarding pro on your resume, the first thing I would ask you to do is an ollie.
That’s up to you if I needed “smart people” (tm) to solve “hard problems” (tm), you may be that special snowflake that could write the next PageRank algorithm, but if I am hiring for yet another software as a service CRUD app, finding “full stack developers” either locally or overseas is relatively simple.
- if when you looked at the job req and it said we were looking for C#/Java/Python/JavaScript developers and you wrote it in Haskell, that’s one signal that you probably won’t produce solutions that meet the customer’s need.
- if we are hiring Haskell developers and I can’t understand the code that means you write unmaintainable, over architected code and that you would still be a net negative for the company.
You didn't get it, linguistic gymnastics here is unnecessary. I could do the same in a language of your choice. But testing me with FizzBuzz without looking at my CV at all is putting you into "garbage employer" category and I wouldn't want to waste time with you. Did you get 5th grader questions on your university exams as well?
> But testing me with FizzBuzz without looking at my CV at all is putting you into "garbage employer" category and I wouldn't want to waste time with you.
This would concern me that you don't validate your input. Just because the contract says something doesn't mean that's what you are getting. Trust, but verify. I trust that your CV is accurate, so I'm giving you a test that won't take up too much of either of our time to verify that you can code. Why? Because I've seen enough CVs better than yours where people can't do FizzBuzz.
Not wanting to FizzBuzz is also concerning because if it's a proven method of validation, why spend extra time and resources on something more that will only tell you the same thing?
So, to me at least, your antagonism here is really you wanting to waste resources and/or not validate input. Neither are good signs.
> Did you get 5th grader questions on your university exams as well?
If a 5th grader question is good enough to answer something, why bother with a 3-hour exam?
> So, to me at least, your antagonism here is really you wanting to waste resources and/or not validate input. Neither are good signs.
No, I want you to give me properly challenging questions to prove you deserve to be my employer (as I will be doing the hard work to make you a gazillionaire). FizzBuzz tells me you read one article a few years ago, didn't think about it at all (why could that be a problem?), and now give it left and right to anyone that has the bad luck of interviewing with you. You are telling me you are arrogant, prideful and lazy.
That’s the easy stuff. Why waste time on the harder stuff if you can’t do the easy stuff? What does that tell me about your work ethic if you think you are too good to do FizzBuzz you probably also think you are too good to fix an off by one defect we found in production.
How can you be happy to have an off-by-one error in your code? Moreover, how can you come to a conclusion that a person that is not willing to do FizzBuzz would be happy to even ship something with off-by-one error?! Complete non sequitur... Let's wrap up this discussion for today.
No one is happy with bugs but bugs happen. If you aren’t willing to do a FizzBuzz type problem because it is too “simple” you also probably will think being assigned a simple reported defect is beneath you.
You realize you are only reinforcing the use of FizzBuzz as a test. If it gets rid of people like you applying, it's done its job. Wastes less of my time, and ensures I get the better hires. Thanks!
Have you considered that FizzBuzz is a warmup question to see if you're worthy of a properly challenging question?
The interviewer has multiple responsibilities, one of them is candidate experience. If I start with the "challenging" question and the candidate isn't ready, then I learn nothing other than they can't do it and the candidate suffers, completely lost.
But, if I start with a middle-to-low bar question, then I can always get data and easily extend or follow-up the question with something more challenging appropriate to your skill & experience.
Dunno, the first time I went to Google interview I had absolutely brutal one as my first question (a complicated dynamic programming on combinatorial problem without closed form solution), and I absolutely loved it and after some discussion with the interviewer came to a solution in about 20 minutes, all on whiteboards I hate. I am not sure why wouldn't you rather use the time for interview or something more meaningful than to test if somebody can do a programming equivalent of 1+2+3 when you can observe from their CV that they probably aren't complete beginners and you are interviewing to get somebody for a very senior job.
People lie on their resumes. I got tired of doing double duty as a developer and the “AWS Architect” and was finally able to get a req to hire someone. Plenty of people came in with certifications and “experience” up the wazoo but couldn’t answer simple architectural questions.
It's a real problem, I agree. However, from the point of view of a competent programmer you need to entice them to work for you, not the other way round. The competent one also has to filter out incompetent managers/companies; I'd suggest having FizzBuzz on the interview is one such a nice signal for competent coders to stop bothering and move on.
The equivalent of FizzBuzz for an AWS Architect is setting up a highly available website with a domain name, load balancer, autoscaling group, and the correct subnets, security groups.
Except for the autoscaling group, all of this is basically networking 101. Their “resume” said they were “certified” and had experience. If you can’t get through the easy questions, no need to waste time on the hard questions.
I wouldn't do something like that, but I have sympathy.
If they didn't lie, then they wouldn't have gotten as far as they did. Everybody wants self-starters and people who can learn new things, but the person who already has experience in a laundry list of X, Y, and Z is always going to be preferred before you find out if they are a fraud.
What I did, in order to start doing something new that I didn't have experience in, was (although I didn't exactly plan it this way) to get a job that was explicitly administrative and did not involve programming and start automating it.
I don't think it's right or wrong that some people find IT culture (including interviews) intolerable, but the flow of people out of it shapes it. The more you rely (even unwittingly) on getting and keeping people who are ignorant there's something better out there, the more the ignorant (and/or incurious) shape your organization.
I wouldn’t say they explicitly “lied” that would imply that they were all being intentionally dishonest. I think many of them thought they knew more than they did. I see this not only from people who are just starting out, but also from people working at BigCo.
Putting my developer hat on. I interview a “senior developer”
They say on their resume that they have “used AWS”. Come to find out that all they have done was remoted into some EC2 instances.
They say they have used a certain CI/CD platform. I ask them have they set a pipeline up from scratch. They say no - someone else did it, we are expected to “own the whole stack” including setting up our own pipeline for our microservice. Not a deal breaker. That can be learned in a day. We have plenty of samples they can copy from existing pipelines for almost every scenario.
They put down databases they are experienced with. I give them a scenario and I ask them to model a table schema with it. They can’t do it. They are usually handed a table schema by the “database developers” [sic].
So finally I start working my way up to the actual development and I realize that because they were just a cog in the wheel at BigCorp, they never got a chance to design or write anything from scratch. They never had the joy of creating a brand new repo and doing a git commit with the message “initial commit”. Not horrible, but at a small company, you don’t get any handholding. You’re expected to work directly with the semi-technical product owner or even the end user if you’re senior enough. You are the Directly Responsible Individual.
So now, it’s demo day. The “senior developer” is demoing his code to management who is asking him questions and he melts under pressure or he gets defensible about “his code” and interrupts the CxO.
I want to know his temperament before I hire him.
I know people are going to say it’s not “fair” to expect that from a developer. I’ve had to learn every level of the stack. At some point you can’t call yourself a “senior developer” if you don’t know anything about the underlying infrastructure for your code or how to deploy it.
The next pushback I get is that J don’t remember what’s its like being a junior developer. Six months into my first job I was told to write a distributed data entry system that was going to be used to create a new department in the company. I had to sink or swim by myself - this was over two decades ago.
"Six months into my first job I was told to write a distributed data entry system that was going to be used to create a new department in the company. I had to sink or swim by myself - this was over two decades ago."
This seems to not jibe with the rest of your comment. You were defending not giving someone a chance to dive in, and then you say you had to learn to swim on your own.
Now, perhaps your point is that such a person should have the humility to classify themselves as something less than a senior developer, and then get that experience similar to you.
However, I wonder if the issue is that anybody with more than a couple years of experience is considered to be a pariah if they aren't a senior developer, which goes hand in hand with everybody inflating their experience in a vicious cycle.
Well. I got lucky. I was hired as computer operator the year after I graduated based on an internship the year before at the company - I only accepted to get to $big_city.
I was the only one that knew how to program on staff.
So yeah, taking a job as a computer operator took a lot of humility. But, it was either that or be stuck in a small city doing COBOL programming.
Even today, it took a little humility to go from being the dev lead at one company, turning down a dev lead position at another company to become an IC who is officially under less experience team leads. But, I needed to fill in some gaps in my resume.
Off Topic: I think you are one of the few people on the internet that knows the word is “jibe” not “jive”.
That your response to the question revealed multiple important facts about your attitude and inclinations (many of which have been pointed out by sibling comments to mine) which would give me serious pause before hiring you.
Could it be that I am simply fed up with the infantilization creeping into our business everywhere, pushing everyone to standardize on the lowest common denominator, yet I am capable of "building rockets" in metaphorical sense and refuse to play this insane game? Maybe I wouldn't want to work for a person like you and am assessing your abilities during interview, coming to a conclusion that we aren't compatible and I would be just massively slowed down by your attitude instead of unleashing my full potential? I've wasted too much time on these types of people, it never led to anything, and my filters are now calibrated to identify and reject them quickly.
It certainly could be, and I don't know I'd even disagree with you. A fair proportion of us here have ambitions and a bit of an ego. But the ones I'd want to work with also have some empathy. I know I'm good, but the interviewer doesn't, so if it they ask me to show I can do 2+2 I'll tell them 4 because it costs me nothing and the only reason they're asking is that the last candidate talked the talk and then said -17 and burned them. I mean, it's been a long time now since I did an interview, but that's what I'd do.
Now that I think of it, why are you interviewing if you're such a hotshot? Shouldn't they be chasing you? Or was this purely hypothetical and you're already set for life?
I am beginning to be intolerant to anyone one-sidedly requesting my empathy; I did it for multiple years but it turned people into takers and I believe they need to grow up personally instead of expecting somebody to be nice to them when they aren't willing to be.
I don't leak personal info about me on HN; let's say I have my own clients and too little time to do more things, and from time to time I interview as a sport to keep me up-to-date in case I need it in the future. In the past year and something I turned down Mark Z's company a few times as well as I work on more interesting things for more $ and with more flexibility (travel around the world yay! studying part-time at top schools etc.) than I would have achieved there.
My desired fizzbuzz? I don't use fizzbuzz when giving interviews. "This person doesn't appear to understand why people use fizzbuzz in interviews" is not the same proposition as "Everyone should use fizzbuzz in interviews".
Anyway: If it somehow happens that I'm interviewing you and you write a fizzbuzz program in super-fancy Haskell designed to be incomprehensible (if it's not designed to be incomprehensible then no, I'm not going to be unable to understand it for 30 years), then from my perspective I've learned: (1) you can indeed write code, (2) you're very smart, (3) you're a bit of an asshole. That's actually quite a lot of information for five minutes of interview time. (If you're super-smart but it takes you more than five minutes to write that fizzbuzz program, then you're prioritizing being an asshole over doing the job, because for sure you could have done it way quicker if you'd wanted; might not be a good sign.)
And if it somehow happens that I'm interviewing you and you misinterpret something entirely different that I say as advocacy for fizzbuzz in interviews, and go off on a rant about how no one any good should ever work for my company: no hire, have a nice day.
Instead of considering me an asshole, maybe you could think of it as a silent protest done in an intelligent fashion. You are indicating I am a fraud by employing FizzBuzz on me, I am trying to maneuver out of it by showing you my dominance and the level of my abstract thinking you won't reach. Now who is a bigger asshole when it comes down to it? You started it... I'd have preferred a reasonable interview to be honest, but when it comes to responding to unreasonable requests, I can do my part... I value my time, you attempted to offend me, so in order to get something out of it for myself instead of writing off that time segment, I have some fun with your inability to understand. If this offends you, you were repaid in kind.
Once again, I am not employing fizzbuzz on anyone.
But it's not indicating you are a fraud, it's indicating that some people in your situation are frauds, which lamentably appears to be the case.
And your response to this situation where someone who at this point knows only what's on your CV and therefore hasn't yet ruled out the possibility that you might be a fraud gives you the chance to show you aren't one is ... to "show[] you my dominance"? Yeah, that's definitely a good idea in an interview situation.
No one "attempted to offend" you. (Well, I dare say people have from time to time. But if you interview for a job and someone asks you to write a fizzbuzz program, they are not doing it because they want to offend you.) They were in the unfortunate situation of having to hire someone in an environment where some candidates turn out to be much worse at the job than the readily available evidence suggests. They gave you a chance to show that you aren't one of those candidates. You took offence at that because somehow the interviewer was supposed to just know that you're one of the good ones, and reacted by trying to demonstrate your "dominance". I suppose the good news here is that everyone's glad you didn't get that job.
(As for "the level of my abstract thinking you won't reach", once again you are making assumptions that go beyond what you actually know. Like it or not, some people who are plenty capable of abstract thinking use fizzbuzz-like interview questions.)
We are talking in hypotheticals, don't know each other, so my "view of you" is just imaginary, don't take it seriously. Also, putting words in your mouth was again just an abstract linguistic device, "what if"... However, I simply object to the use of FizzBuzz; there are like millions other problems which I can get, but if somebody uses this one because "it was cool on Reddit/HN/etc.", it just leaves a very bad impression, and I was expressing my feelings here (as I am well aware of the original article and the trend it started since). If you created your own simple check, I wouldn't object (likely during phone screen?), but I would consider you an arrogant asshole if you gave me specifically FizzBuzz, as its use implies infamous "idiot"/fraud assumption and became a part of programming folklore with really ugly connotations attached.
As others have said, not being willing to do it fails the attitude test. It's not actually demeaning or difficult for most people, although for underprepared people from nontraditional backgrounds it can be a bit upsetting. So smile, write the answer, say thankyou and move on to the next question.
"If you don't know about your preferred language's modulo operator..."
Do you know your language's modulo operator? I went down a rabbit hole the other day porting some Python code to another language and discovered that modulo acts differently in different languages for rather subtle reasons.[1]
It took me, frankly, more time and iteration to implement Python style modulo correctly than I would have in an interview, or be able to muster while conversing with someone.
For Fizzbuzz purposes, you only need to know what happens when both numbers involved are nonnegative, which so far as I know is consistent everywhere.
(I deal with the other cases by making sure only to use % or similar on nonnegative numbers. If I ever encounter a case where I need to take remainders and performance is so important that I can't afford to do that, I'll double-check with the language documentation and leave a comment saying what the actual behaviour is. That's never happened yet.)
It's pretty common for people to be very focused on the trivia they know as a litmus test for judging other people, while dismissing trivia they don't know as irrelevant.
I don't have concrete reasons for thinking so, but my general impression is that this attitude is significantly more common in IT than other environments.
If I was interviewing someone I'd not count a mildly buggy fizzbuzz against them, especially if it's a whiteboard interview. Really all I'm looking for is for someone to conclude based on the problem description they at the very least need a for loop and a couple if statements. It's not a test to see if you can program well, it's a test to see if you can program at all.
I was searching for words to express why people may find FizzBuzz antagonistic...
People make mistakes on everything,[1] no matter how trivial. Therefore, it can be threatening to even a genuinely competent person to be judged on a really elementary task, because even though it is simple to do, the margin for error is correspondingly small. The easier it is, the less excuse for any hiccup.
Of course, you just said you are not judging on minor issues, but it's hard to believe even assuming your best intentions. The simpler a task, the more judgmental human nature compels one to be, and the more confirmation bias will work to magnify any later errors.
I am not against it at all. It opens the conversation to some technical aspects that can be very intersesting to talk about.
As a candidate I love getting technical in interviews because It allows me to see how my prospective manager thinks. If we have radically different ways of taking care of a technical problem it's a red flag for me.
In the same area, I like the "let's talk about your last project" question too.
So, I've had my share of technical interviews and here what I observed :
I am usually unable to produce good software when the specs I'm supposed to use are not precise enough. I don't mean not complete enough. I mean not precise enough.
Be it on the job or in interviews I seriously question the ability of some interviewers to produce good technical interview questions.
By good I mean precise, using the right vocabulary.
I do not mean complete. You can knowingly give an incomplete spec to the candidate to see what kind of questions he/she would ask to try and get the whole picture. (or if he/she goes head first into an unsolvable problem)
But the details that are given need to be explained in precise terms. Not in a shadowy weird dialect based on a model that only the interviewer understand.
I've had my share of technical interviews and most of my fail attempts at live coding were due to (my lack of skill but also) questions not precise enough or misusing technical terms (sometimes even not grammatically correct questions).
The latter usually make me feel awkward because I wonder if those interviewers simply lack the minimum intelligence to explain a simple feature with precise words.
Good engineers I have worked with always use precise words to describe precise concepts. Using wrong or imprecise vocabulary is proof of a lack of understanding of the job and/or a will to try and sound "smart" or "tech-savvy" to compensate for some kind of inferiority complex.
So maybe a good advice to interviewers would be : technical questions on interviews yes. But good technical questions.
It's kind of amusing you spend a lot of time trying to define the work precise. =) I understand what you mean though.
Have you ever considered that part of this is hoping that interviewees will ask questions seeking more precision? A lot of times on the job, you don't get such precision. There are unknowns you have to answer for yourself, and sometimes the right questions are more important than the technical approach.
That's why I insisted on the difference beetween imprecise and incomplete.
> I do not mean complete. You can knowingly give an incomplete spec to the candidate to see what kind of questions he/she would ask to try and get the whole picture. (or if he/she goes head first into an unsolvable problem)
I feel that using wrong technical vocabulary in a question is not a sign of a interviewer trying to make the candidate ask questions. Maybe it's just me.
also, it show if a candidate is actually a gung-ho code monkey or has some methods in his coding.
our fizzbuz variant asks to print numbers from 1-100, and basically everyone among the few that did the fizzbuz part right got that part wrong, mostly printing 0-99 but also had one 0-100 printed.
this doesn't immediately disqualify a candidate of course, because the are a lot of reasons behind the mistake including the interview stress, but on requisite driven project attention to details is a major benefit.
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
Nope. The famous fizzbuzz test simply asks "can you actually write code at all?", because it turns out that some people applying for software development jobs basically can't. Even people with relevant-looking experience on their CV/resume. Even people who talk convincingly about what they've done.
(If you don't know about your preferred language's modulo operator but can do truncating integer division, you can do FizzBuzz that way instead. If you don't know how to do division, you can do it by having counters that count up mod 3 and mod 5, or one counter that counts up mod 15, and you don't need "mod" in your vocabulary to do any of that.)
Now, whether a candidate can write code -- like whether they know their language's modulo operator -- is also just one bit of information, but it's a really important bit of information that turns out to be tricky to get. This is also one reason for the "code on a whiteboard" tasks that many interviews use, which the author also doesn't like.
It may be that those are bad ways to get that one bit of information. But the author doesn't seem to appreciate what problem those things he criticizes are trying to solve.