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.
FizzBuzz is good for one of two things:
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.
How can you be good at writing production quality code, but bad at trivial code?
No one is looking for people who can write fizzbuzz the fastest, or optimal in any way. They are looking for you to clear a low bar filter.
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.
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?
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.
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.
In the great-grandparent, you said:
> > > 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 have interviewed candidates for Senior DBA positions who didn't know to write a simple JOIN statement.
Reading this thread only 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 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.
Well that tells me two things.
- 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!
I wouldn't want to live in your bubble when it comes crashing down and you have to face reality of your competitors.
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.
You can put anything you want on your resume. People lie all of the time.
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”.
I think in your case the test worked perfectly.
Help me to decode your statement please. Your point was ...?
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.
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.
 https://en.wikipedia.org/wiki/Modulo_operation (see the table on the right)
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, 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.
 https://en.wikipedia.org/wiki/Muphry%27s_law aka Skitt's law
About technical interview questions :
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.
Yes I thought about it.
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.
It’s also a good warm up for those who can code but have a few interview jitters.
I’ve recently learned via a few interviews at tech companies that interviewing for tech companies is a completely different skill to working at one. I’m sticking to contracting for now I guess.
Do you not have to go through the same interviews for contract work, assuming you are programming?
Usually it’s a lot more straightforward. Contracts can be terminated at very short notice if you’re not delivering so it’s not usually worth spending a lot of time interviewing.
The problem with contracting is that you end up interviewing even more, not less!
Anecdoctal, but while we are discussing narrow scope interviews... I just finished a physics PhD and applied to a finance firm. Before I get a chance to speak with a human, they send me a 15 problem 20 min timed exam. Some of the questions were easy and some required thought, unless you’ve been sitting around practicing riddles and LSAT questions all day. I timed out halfway through the exam. It wasn’t even clear a priori how to navigate the exam, or if I could skip questions or how I would be graded. The company effectively canceled my application based on the 50% score.
Now, I’ve probably taken 100+ math exams in my life and I’d be happy to provide data from any one of them. Why trump all that data with 15 questions? Viewing the application process as a pure machine learning problem, their decision seems crazy.
Totally agree. I hadn't seen this article until now, and I'm thankful for it because I think this is a message that needs repeating from many points of view. Engineering hiring is a farce through much of the industry.
I've written two articles along these same lines:
I can't say I agree with everything here. I've found live coding to be a useful way to gauge how someone thinks. Prior to the in-person interview, a 10-15 minute phone screen has already been done as well as a easy programming problem that takes most senior developers 5-10 minutes to solve it. So when we bring them in, we think they should be able to "pass" the interview.
When they arrive on site, we give them a 90% completed program that needs 2-3 lines of code to finish. We tell them they can use the web to look up anything they need to. We're mainly looking to see how the candidate thinks, and we discuss what they're doing and why. We're more concerned about the why than the what.
Once this is done (about 15-20 minutes in), we have a reasonable understanding if someone would be able to do the work. Next we try to figure out how much they would need to learn to be productive, and try to see if the candidate would be a good fit culturally.
We had one candidate who a minute or two into the live coding exercise said "Geez, I really don't think I can do this." I reminded him we weren't looking for a correct answer and to just give it a try, and he wouldn't. I thanked him for his time and ended the interview.
If this (finishing a program missing only a few lines of code) were all most coding interviews were, I don't think there'd be anywhere near as many complaints about them. That's very similar to what you'd actually be doing on the job.
It's coming up with what you took in your data structures/algorithms class a decade ago on the spot and write full functions about them, especially on a whiteboard, that gets really annoying, and makes programmers feel like they have to refresh their knowledge of an entire class (plus a bunch of other trivia from across CS) every time they want to find a new job.
I like this. Of course I enjoy reading code so that may be why. On the other hand I’ve met a fair number of devs who either can’t read code or just wont. I wonder if the person in your example would have passed had you simply given him a problem to code from scratch.
I agree entirely with the premise of the article.
One nit, though:
> The famous fizzbuzz test simply asks "are you aware of the modulo operator?"
FizzBuzz also tests basic programming skill, and it's surprising how often people fail that part. FizzBuzz isn't necessarily the best test of that; I know one interviewer who instead uses "write a function to swap two numbers". But some test of basic programming skill does help, albeit it should happen long before the in-person interview.
How would you swap two numbers?
std::swap<>? CMPXCHG? LDREX/STREX?
The XOR trick is cute but you shouldn't use it on anything larger or more modern than a Cortex-M0. Just put it through a temporary variable and let register renaming deal with it.
(Perhaps a more interesting question would be a multi-threaded examination of swapping two numbers...)
It's interesting because this is a real answer that will get you hired. It demonstrates knowledge of: the "correct" way to do it, basic asm awareness, programmer culture, and computer architecture. This probably checks off like 6 boxes for most technical interviewers in one answer.
Finally it implies it could have asked a better interview question ;)
Thankyou. I try to strike a balance with these things - showing off is mandatory in interviews, but needs to be done politely. You don't want to go full "Hexing the Technical Interview": https://aphyr.com/posts/341-hexing-the-technical-interview
This is basically the perfect answer to that question.
Part of the point of the question is to get people thinking about that, solving it on the fly, and explaining their reasoning. One of the lightbulb moments is when they realize the function needs to take pointers or similar (and typically ask if that's OK).
Have you, as part of your day job, ever written a function solely for the purpose of swapping two numbers?
Yes, for code in languages that don't have it as a built-in library function. I've also written functions to swap strings, and implementations of various standard library functions.
Also: have you, as part of your day job, ever written code to solve a specific word puzzle? (Based on an actual interview question I've answered.) An interview question is supposed to be representative; that doesn't mean every interview question must come directly from a specific problem encountered in production code. You ask questions to prompt people and see how they think and how they communicate.
There are a couple of reasons why the 'function that swaps numbers' question is, in my opinion, a bad interview question.
1. it's a very simple thing to do, so why bother with a function? It's like asking someone to write a function that takes an integer value and returns an array of that length. 2. if you really do need a function that swaps numbers, then you probably also have some special edge cases that you will have to deal with that the candidate likely won't know about 3. each solution is language dependent
Maybe those aspects are why you consider it a good question, but when I have been asked those types of questions in the past I felt that the interviewer was missing an opportunity.
Would you consider solving an algebraic expression that was a string as a word problem - ie
Of course it involved variable substitution, converting it to rpn, and then using the “Shunting Yard Algorithm”. I’ve had to do that twice. The second time I was maintaining a proprietary compiler/VM/IDE written in C++ for Windows CE. Yes, that was a dark time in my life.
“$x * (5/25) + 10 * $y”
(Without detracting from the fun anecdote, I think we're firmly astray from the original question or the further questions down-thread. The latter was about interview questions versus real-world problems. And no, I wasn't talking about algebraic expressions; I was talking about word games or puzzles, as given in interview questions.)
It depends on what your “world” is. If I’m being hired to write yet another software as a service CRUD app, then algorithm questions aren’t the “real world”. But, when I was being hired to do low level cross platform C without any third party libraries that we didn’t write ourselves or to maintain a compiler - algorithm type questions were appropriate.
In fact, we were writing custom document creation software and outputting to industrial printers at the first job where we were doing a lot of text processing.
Not being able to use third party libraries in no way prevents you from using third party algorithms.
I have written code that swaps numbers as part of a larger function.
https://en.wikipedia.org/wiki/XOR_swap_algorithm is always a fun trick
My favorite way is using the xor operator:
a = a ^ b
b = a ^ b
a = a ^ b
The above syntax works well in Python, but of course Python also had the much simpler tuple unpacking:
a, b = b, a
The XOR trick looks cool, but requires three CPU instructions to execute. My favorite way to swap variables is to use:
tmp = a; a = b; b = tmp
When a compiler generates code, it maintains a mapping from variables to registers. So when the source code refers to the variable 'a', the compiler might map this to register %eax, and 'b' to %ebx, and it will use this to generate assembly code (or IR or bytecode or whatever).
A good compiler will recognize the three-line variable swap above, and optimize it so that the mapping simply changes at that point. So any references to the variable 'a' before the swap will refer to %eax, and after will refer to %ebx.
This requires zero instructions, and zero is less than three :)
That doesn't necessarily work if you're doing the operation in a loop, unless the compiler also unrolls the loop to some degree (which isn't a zero-instruction change). It also only applies to local variables, and doesn't apply when swapping global or in-memory data.
I've rarely encountered a "swap" operation on local variables in straight-line code, as opposed to a loop, or a swap of global/in-memory values.
If I ever saw the xor trick in a workplace environment I'd flip out. Python's tuple unpacking is fair enough, but whatever happened to good old
tmp = a, a = b, b = tmp?
Sometimes I do have time constraints fixing a bug. In fact most of the time that constraint is imposed by me, because I have pride in my work. But at the same time I hope my manager understands that staring over my shoulder for 45 minutes doesn't help. Hopefully in my next interview I can get these ideas across respectfully.
There are different levels of distraction. Staring over my shoulder is one. Having a conversation with me about what I need to fix is another.
For some reason, I find it impossible to figure things out when I am looking over someone else's shoulder, or in a meeting, but when I am seated at my desk, it is vastly easier.
Thank you for posting this. Not sure how many times these same points need to be repeated for it to sink in.
You're welcome. I'm not sure either. I think my main take-away from this article is that hiring is a human activity first and a technical one second.
There seems to be an attitude of "I had to go through this, so I don't see why new hires shouldn't" hidden under a thin layer of justifications but in fact we're playing a game with very limited information. We probably don't even have the tools to know if we're doing good or bad hires except in extreme cases. We almost certainly don't know if we're rejecting the wrong people. Still we pretend like it's working.
To me, it seems overly rigid, pattern-matching against a too-narrow idea of what a good developer/employee/team member is. So much could be improved by just adding some flexibility, but maybe we're afraid of losing the illusion of having a Process and Objective Criteria.
Maybe I'm naive, but aren't we looking for what people are good at and what they might bring to the table? Maybe someone likes programming puzzles and whiteboards, let them do it, but don't insist if it freaks another person out. Maybe someone else would rather do a take-home assignment, but don't insist on it if someone else don't have the will to do several hours of unpaid work. Others might prefer pair-programming in person, technical quizzes, Codility-style problem solving online, actual paid work on a project basis.
One self-defeating pattern is having different parts of the interview process filter out different types of people, so that neither one can make it through the whole process.
Sometimes (well, maybe even typically) the beginning and ending of an application process are with different groups, and types, of people.
I agree that it is best to hire people that will evolve as that is the crucial part of being a good engineer, but you still need people that know how to start, your company is not a school. The problem FizzBuzz test is trying to solve is not to find the good candidate, but to weed out the vast majority of applicants that can't code at all.
Depending on where you put your job postings you can get really swamped by them.
"to weed out the vast majority of applicants that can't code at all."
I think one ought to consider the possibility that if the vast majority of interviewees can't code at all, there is something wrong with the company/process. I mean, I'm not saying it necessarily follows, but the question is worth considering.
I have never been asked to implement FizzBuzz, so I can't buy the claim that "everybody does it".
Rightly or wrongly, if I was asked tomorrow, I wouldn't have the preconception that it was appropriate or necessary, and thus wouldn't necessarily choose to continue if I thought it was indicative of culture. If other people react similarly, it doesn't necessarily matter if it is a reasonable standard of competence; you're still skewing the pool in other ways than you intend.
I think FizzBuzz is an example, when I was interviewing I mostly got questions in this vein during first or second telephone screen (some companies use an online multiplayer notepad or some other method).
When I was doing interviews I was always mostly discussing motivation. Most of the time the hires turned out very good, but I did happen to have one bad one and it cost us quite some time.
I have had the experience of doing well on the programming test at the beginning of the process and being rejected for other reasons. Maybe counter-intuitively, that made me less interested in doing such tests, since in that case it wasn't determinative. It's possible that many or most places feel that to ensure someone doesn't cheat on a take-home, they must demonstrate their ability in the in-person interview. Which is logical, but it also makes me think that going through a process starting with a take-home is a waste of my time, as long as it's not a universal requirement.
What you describe is normal. Assignments usually go from easy to hard because usually it is faster to solve the easy problems and usually these questions can be also asked by less technical people. Several companies I have interviewed with had the first programming questions asked by recruiters (who clearly had CS background, but most probably just shifted careers)
What I'm talking about had a much more involved test than Fizzbuzz at the beginning, IIRC something like 5 small projects, but with your choice of language, and a generous amount of time (days). During the interview, it was simpler, but in an environment I'd never used before and a language which I had disclosed up front I didn't have recent experience in. It seemed like they were only interested in hiring new college grads at the end, but perversely the process started by senior people referring me and screening me. While I admit it sounds like sour grapes, I thought later that the organization probably had communication/coordination problems that would've made it unpleasant to work for.
In some organizations, they start by recruiting people they think have talent in general, and then the interview is about finding where you fit in.
In others, they have a very specific need and they focus on winnowing down the pool to get the (hopefully) best person for it.
The place I'm talking about seemed to have a split personality.
Also, I've had enough interviews, both successful and unsuccessful, to be clear that there is no "normal". Every place is unique, as was this.
"No Assholes policy"
The golden question being "who gets to decide who is an asshole"
Ironically a paragraph down they say:
"You are NOT hiring for "team fit""
Right? It's the same age old question as "Whose code is the worst?" Not surprisingly it's always someone else's code.
As pointed out in the article, fizzbuzz doesn't test "can you code at all", it tests "can you code under interview conditions, including highly unnatural ones like on a whiteboard".
On the other hand, "hiring for future potential" sounds great but is really vulnerable to personal bias since it's inherently about the unknown future. If you want to run a deterministic interview process you need to have a standard set of questions and a rubric for assessing answers, written up in advance.
I don’t have to code under interview conditions on a daily basis, but I often have to architect under interview conditions. I’m an IC in a small company but I’m often in meetings where they give me high level business requirements and I’m expected to white board ideas about how to design a system that will meet those needs.
It doesn’t have to be perfect, I don’t have to be completely right, and after going and doing a proof of concept, I might be completely off base or realize there is something so didn’t think about. But I am expected to “pseudo-architect” on the fly.
If you can't write fizzbuzz in a few minutes on a whiteboard, even in pseudocode, then you can't code.
I can't write fizzbuzz in a few minutes on a whiteboard under interview conditions, but I've shipped multiple products over three decades. Several of them are from 50% to 100% code written by me.
The syllogism you're proposing overlooks some human variables.
Interpersonal interaction tends to completely occupy my cognitive capacity, the moreso if the other person is a stranger, or if they are challenging me in some way (such as, for example, posing puzzles and evaluating the quality of my answers). I can't think about logical operations under those conditions. I require peace and detachment from human concerns in order to think that way.
This is, of course, a personal quirk, or, if you prefer, disability, and nobody should have to bear the burden of it but me. But I've been an actual 10X programmer on a shipping product, as verified by DVCS statistics. I submit that as evidence that I can, in fact, code. I just can't do it in interview conditions.
I also can't navigate while interacting with someone. I can drive just fine; I can operate a vehicle safely. I just can't navigate. Everyone in my close family is aware of this limitation. When my daughter was a teenager, she exploited this quirk for laughs. I have to admit, I thought it was pretty funny, too. In particular, I remember a pause in a conversation where I looked around and realized that I was parked at a Safeway in Capitola, California, and had no idea how I got there. My daughter and I both laughed when I realized what had happened.
But if you want me to drive, and you want to reach a specific, predictable destination, you have to leave me alone to navigate.
Similarly, if you want me to be a 10X programmer, or indeed any kind of working programmer, you have to leave me alone to do it.
Maybe I'm not the only one.
I won't argue that you should accommodate me, or people like me. Maybe you don't need us. That's okay. I've found other ways to get by--being hired by people already familiar with my other work, for example, or making my own products. It's maybe a less predictable career path than the usual, but it's worked so far.
But for obvious reasons, I can't agree with your claim.
I can code in interview situations. But I still think it's a waste of time. Ask me about my real work. Tell me about what your challenges are. Let's figure out whether it makes sense to work together.
There's always an exception that proves the rule. I'm sure, though, if you could provide an explanation like this and then provide and walk them through some already-written code examples, that would also be acceptable?
I'd take someone who says "I can't live-code while talking about it, but here's an example of my code and I can explain how it works" over someone who tries to BS me.
Yep, I can do what you suggest, and I've done it before. It can go a little sideways, though, depending on the questions you ask. If your question requires me to do what I can't do in an interview setting, then neither you nor I will be happy with the result.
Don't get me wrong; you as an interviewer are not under any obligation to adapt your hiring process to my quirks.
On the other hand, I'm not under any obligation to participate in a hiring process I don't like, either. I stopped participating in hiring processes I don't like around two decades ago, and I've survived anyway.
I think next time I interview someone I'll ask them to fizzbuzz:
- if they are confident and fail, I'll pass on them
- if they are nervous and we'll fail, we'll talk about it, and move on with the interview
- if they succeed, I'll move on w/the interview
- if they refuse, I'll hire them immediately and recommend them for promotion
You lost me at Joel Spolsky.
Hosting a tech Q&A site doesn't make you the canonical source of how to structure interviews.
The live coding interview style was a toxic and negative contribution to the tech industry as a whole, IMO.
Sorry, but I strongly disagree with you. Reading the cited book (Smart and gets thing done) was an absolute eye opener for me, and for every person that I have recommended it to.
Really, you should read it (unless you were only trolling). It is a very fast read and full of insight.
Also, "tech Q&A site " is a huge mischaracterization of Joel's blog. He has really insightful articles like "Evidence based Scheduling", or the ones about (not) rewriting-code.