For the Love of God, Ask FizzBuzz
brianbrunner.com
brianbrunner.com
Like someone else said, we wax poetic about DRY all the time, yet you're asking me to take time out of my day to repeat things I already know when that data has already been provided for you. Sigh.
You should be able to have an idea of whether I'm a suitable candidate or not before you even call me, and you should know whether I can code or not before you even bring me into your office.
Entry level position? FizzBuzz all day long. It's the only way you'll find out.
Mid- to Senior-level position? There are better ways to figure out my competency level.
My two cents.
FizzBuzz provides a great level setter for folks who lack a clearly searchable, well-known code repository.
One half-joking suggestion to anyone using your GitHub repo as a resume: make yourself a FizzBuzz project. You can include basic one so the box can be checked, but as a hiring manager, it'd be fun to see novel and humorous solutions to it that show cases your particular background (e.g. front-end developer? Show me the CSS3 solution.)
Having done hundreds of interviews, I'm sorry to say that even seemingly "senior-level" people (people with years of programming "experience" on their resume) have shown an inability to do basic coding from scratch. It seems there's a subset of developers who cobble stuff together and code-and-fix to make things work. This is ironically less of a problem with entry-level people.
Yes, if you have a public repo of code, I'll ask you about it, but I want to see you live code something, both to see the code you write and your thinking process about solving the problem. If you feel that's a waste of your time (and if you're truly senior-level, it really won't take very long at all), that's fine, but I will continue to do it.
I wouldn't have believed you a few months ago (and your statement is still stronger than my experience), but I've finally seen people who are so maintenance-bound, that even though they're good at _that_, they've never managed to learn the language (the corners, idioms, and semantics) they've been maintaining. It's probably a sign of heroism that they picked up enough to do so on the fly, but, you wouldn't hire them to write new code.
I don't agree about DRY; the whole point is that the data has not been adequately provided until you see it. You do see people with apparently great CVs who are unable to demonstrate the skills in person.
As a leader, a senior developer needs to be capable and willing to do anything that gets done underneath his area of responsibility if that's the key thing that needs to be done right now and everybody else is busy doing the thing that they need to be doing. If they're not willing to do whatever it takes, then they're not the kind of senior leader I need.
The larger the organization, though, the more room there is for people who are too good to do various kinds of work. But smaller teams, where the highest productivity is, need flexible people.
From the employer's point of view, it's all about determining the most effective way of finding out if you're a fit or not. In my personal experience and confirmed by the research I've done, asking basic coding and simple problem solving is the most effective way to eliminate applicants on which you don't need or want to waste your time. Most common "exception" is if one is interviewing what he considers a superstar, but then we are not actually talking about an interview, but rather a sales pitch.
I find that Brian has put it perfectly in the last paragraph: "A solid answer to FizzBuzz is like a firm handshake when meeting your new boss or like opening the door for your date. It’s an introduction that sets a minimum bar and guarantees that neither the interviewer nor the candidate is wasting the other’s time."
And then you ask for Github, resume, whatever-you-find-relevant.
So far, only 30% of applicants manage to go pass this point.
It's actually quite hard to believe. Guys who claim to have multiple apps under their belt simply cannot write code. I often question them on what they did in their past and what was their actual contribution to their team. The two most common scenarios are either the so-called technical manager who got promoted there become of lack of coding abilities or the self-taught programmer who was hired by the technical manager. By self-taught, I mean someone who can write HTML and copy/paste JavaScript code from somewhere.
Just to read it and say what it did. This eliminated the vast majority of the applicants:
void strcpy(char x, char y) { while(x++ = y++); }
/* Copy SRC to DEST. */
char *
strcpy (dest, src)
char *dest;
const char *src;
{
char c;
char *__unbounded s = (char *__unbounded) CHECK_BOUNDS_LOW (src);
const ptrdiff_t off = CHECK_BOUNDS_LOW (dest) - s - 1;
size_t n;
do
{
c = *s++;
s[off] = c;
}
while (c != '\0');
n = s - src;
(void) CHECK_BOUNDS_HIGH (src + n);
(void) CHECK_BOUNDS_HIGH (dest + n);
return dest;
} #ifndef USE_AS_STPCPY
# define STRCPY strcpy
#endif
void strcpy(char *x, char *y) { while(*x++ = *y++); } void strcpy(char *x, char *y) { while(*x++ = *y++); }
I can implement fizzbuzz in < 30 seconds in half a dozen languages (in vim, maybe < 60 seconds on paper/whiteboard). I don't really take offense to being asked to blow 30 seconds; I understand where the interviewer is coming from the same way I understand where a cashier asking for my ID is coming from.
I have asked this question before and a lot of people don't know the mod operator and so they struggle and eventually it occurs to them to divide and check the remainder. This usually leads to kinda sloppy looking code, but, I find it to be very revealing about their problem solving abilities. Some people just give up. Some people ask for help. Some people get angry or flustered. All of these scenarios are extremely revealing and help you to understand the candidate's approach to problems.
When the candidate already knows FizzBuzz then the results are usually less interesting - but sometimes they may solve it is some really unusual way which is cool to see.
I remember trying to explain binary addition to people in a circuits class when we were implementing ripple-carry adders. I was explaining how binary addition is the exact same as decimal addition except you carry at 2 rather than 10. The guy I was explaining it to asked "What is carrying?". He hadn't done addition by hand in so long he had entirely forgotten. And this is a guy who can code up a functional, decent looking PHP based website in a matter of minutes. I suppose it's even more believable that people would forget long division, remainders, and modulus.
It turned out that 3/4 of the people applying for the job _could not code at all_. They weren't just bad coders - they had never coded anything in their lives.
It's _those_ people that FizzBuzz catches out.
#include <stdio.h>
int f0(unsigned int x) { return x? (x&(1<<31)? f1(x<<1) : f0(x<<1)) : 1; }
int f1(unsigned int x) { return x? (x&(1<<31)? f3(x<<1) : f2(x<<1)) : 0; }
int f2(unsigned int x) { return x? (x&(1<<31)? f0(x<<1) : f4(x<<1)) : 0; }
int f3(unsigned int x) { return x? (x&(1<<31)? f2(x<<1) : f1(x<<1)) : 0; }
int f4(unsigned int x) { return x? (x&(1<<31)? f4(x<<1) : f3(x<<1)) : 0; }
int t0(unsigned int x) { return x? (x&(1<<31)? t1(x<<1) : t0(x<<1)) : 1; }
int t1(unsigned int x) { return x? (x&(1<<31)? t0(x<<1) : t2(x<<1)) : 0; }
int t2(unsigned int x) { return x? (x&(1<<31)? t2(x<<1) : t1(x<<1)) : 0; }
void main() {
unsigned int i;
for(i=1; i <= 100; i++) {
if(t0(i)) printf("Fizz");
if(f0(i)) printf("Buzz");
if(!(t0(i)|f0(i))) printf("%u",i);
printf("\n");
}
}I'd never be insulted by Fizzbuzz questions, it takes maybe a minute to solve and you can move from there to more interesting questions very easily. If Fizzbuzz is the closest thing to a time waste during the interview process, you're in pretty good shape.
My personal experience has been that most of us in the industry aren't well equipped to make that determination reliably among each other. The most successful interviewees I've ever seen are those with excellent pattern recognition and recall. Only a few of those are decent programmers (not even excellent.) But they're all very talented in describing ways of thinking.
In spite of information at hand, I rarely see those in hiring roles ever go away from "does this person think about this the way I do?" It is a very subjective task, so I don't fault those in these positions for following that process. But I think there's a perception in "understanding how a person thinks about a problem" that is flawed.
Problem 1 is basically a fizz buzz and its funny to try alternative algorithms.
So, yeah, brute force its pretty obviously a for loop with a subtotal, two mod tests connected by an or, you get the idea. And that is the first way to do it in a new language.
So you wanna try recursion? I feel fuzzy at this time but something like you call recurse(1000) and it calls recurse(999) and so on until it hits 0 and stops. Now from memory my weird design was the return was returning the (the returned subtotal from calling recurse(x-1)) + x when x is a mult of 3 and not a mult of 5 + x when x is a mult of 5 and not a mult of 3 + x when x is a mult of 15 (15 is 3 and 5 at the same time)) Yeah or something like that. (edited what the heck was I thinking? I'll leave this as unedited, but thats not right. This is a good fizz buzz example of give them the question, a wrong answer, and ask them to debug it.)
Another one to demonstrate your ability at screwing around with arrays is simply make an array size 1000 all zeroed out and a for loop to run thru all indexes of that array (now try not to fall off either edge) and if the array index is a mult of 3 or a mult of 5 then set that array value to the array index. Finally add together all the values of the array.
Hmm so you've got a minor parallel processing cluster on hand and everyone runs some language you're unfamiliar with and has access to a shared NFS dir so all 100 of your hosts run the worlds dumbest program that checks to see if 1000 files exist, if not, it picks a psuedo-random number between 0 and 1000, checks to see if its already been calculated, if not, it decides if that number is a mult of 3 or 5 and if it is, then a filename "random-number" appears using dd if=/dev/urandom of="random-number" and you copy 1K blocks equal to the number of blocks in the random number (so file 14.crazy is zero bytes long but 15.crazy is precisely 15K in length) then given 100 workers randomly selecting a random number less than 1000 you have to run way more than 10 rounds but eventually all the shell scripts simultaneously terminate on all the worker nodes because ls | wc -l returned 1000 aka all 1000 results have been calculated. Then you run cat * > result and du -k result to see how many K are used which is the sum of all the mults of 3 and 5 between 0 and 1000... I did this to torture test a small cluster and its NFS server and its network and disk IO a long while back. I remember it took more rounds than you'd guess to test all 1000 digits and of course if varies, unless your psuedo-random number generator is screwed up. Or you could intentionally use a screwed up RNG to see if its any good. Also I did my run using M not K although a motivated lunatic would use G, I suppose, to really torture a NAS. Isn't this a diabolically insane and funny way to solve the problem?
On a simpler level, or a differently crazy level, you can do all your math in octal, just because. It won't really change anything but it looks entertaining. And why not write your own octal-dec conversion routine, to print out the result, just because?
The point is not to do it the fastest or most obvious way but to screw around with odd ideas, not the same old boring fizzbuzz.
Graphical is hilarious instead of using a boring old array. So what happens if you use a PNG graphics image to store your table of multiples? So 15 is 15 black pixels? This is an interesting way to test your ability to squirt out and in pixels. Also does your PNG library interface like 1e6x1 graphics images and how scalable is it when you access the same graphics image 1e3 times does it scale?
There is a tiny problem that someone who thinks this is hilarious might use hilarious designs in production code.
Yeah, it guarantees that only the interviewer is wasting the candidate's time. If you're hiring off the street I could possibly see some value in FizzBuzz, even though it's going to turn off any actual A player you happen to interview, but if I sent in a portfolio/past project/etc and you FizzBuzz me, I'm walking out. If you distrust a candidate that badly I can't imagine how micromanaged your employees must be.
FizzBuzz both saves you time by filtering out incompetent people, and saves actual competent people time by demonstrating that you're not willing to do what it takes to attract great hires. There's no shortcut to real interviews.
I think this is the use case that they're referring to. If you're getting a job referral from someone you trust, you probably shouldn't do it. It's also not that much time. I've never done any professional coding in my entire life, and I could write fizzbuzz in at least three languages in less than 10 minutes.
Edit: 10 minutes EACH. I'm not that good.
The exception is when a company is approaching you directly - then it would be insulting. However, if an outside recruiter approaches you, and then hands over to the company... again, you need FizzBuzz or such, because some recruiters are cheaters and will even help hopeless candidates fake their portfolios.
Wasting people time hurts - but accidentally hiring someone who'd fail FizzBuzz hurts orders of magnitude more.
If so it sounds like FizzBuzz may still serve as a valuable filter!
If you insist on just working where they have evolved perfect routines to weed out the incompetents before interviewing, you'll miss out on most new places with smart people.
Being a productive team member requires trust, and FizzBuzz is a really low standard to start at when attempting to gain trust. I'd be openly suspicious that anyone who can't be bothered to run through FizzBuzz in an interview would be the type to complain that whatever task they are working on (that needs to be done) isn't RealProgramming(tm), and is beneath them.
Treating the person on the other side of the table is a fake works both ways. Don't underestimate how actually offensive a FizzBuzz question to a qualified developer is.
FizzBuzz is a necessary but not sufficient standard for acceptable technical skill.
As a hiring manager, I'm not just amazed by how many people can't do FizzBuzz, but by how many people haven't even heard of it before I ask it.
This is very true. I've often thought of pulling it from the list of questions just because of the visibility that it gets - I mean, I do actually feel, to an extent, embarrassed asking it. Surely anyone who spends 30 whole minutes preparing for a job interview can find it on Google.
It still manages to be difficult for some people, though. And, really, that's something that I want to know quickly.
You don't see any value of FizzBuzz because you are only thinking about it from one limited perspective.
It filters out a surprising number of people, including those with what appear to be very impressive resumes. I don't know what your definition of "hiring off the street" is, but if it means that the people interviewing you don't know anything about you prior to the interview, then that's pretty much all hiring for any company of any size (i.e., non-startups).
FF24/Mint 15 looks fine to me (bit small maybe).
To reiterate: necessary, but not sufficient.
I would certainly hope that the barrier to entry for every job I applied for wasn't something so standardized (and quite frankly, useless). I would eventually point to a github repo with it done already. We wax poetic about DRY yet you're gonna ask me to repeat myself? Seems pretty hypocritical to me.
>We wax poetic about DRY yet you're gonna ask me to repeat myself? Some people can wax poetic pretty effectively without being effective at implementation. I've written a 1 line fizzbuzz python generator in less than 2 minutes. If one is too arrogant/uncompromising to take the two minutes to satisfy this (if asked), or unable to turn it into something interesting ("This is done with generators. I might never do it this way in practice, but the question you asked me was so mind-numbingly boring I had to do it this way to entertain myself"), then one probably won't work that well on an effective team.
Yet I easily forgot the person with a masters degree that could not pass, was hired anyway, and subsequently fired 3 days later for not improving an iota. I think my frustration is that people like this exist, forcing companies to give the same test to weed them out with no way to skip the question if you can faithfully prove you're not that person.
If it seems so simple and useless to you because it's easy, then you are not one of the people who will ever be weeded out by a fizzbuzz style question.
Put it this way... Would you want to work with somebody who was unable to handle fizzbuzz?
Degrees don't count for much in terms of experience. I've seen people with electrical engineering degrees (from good universities) ask which way the strips are connected on a breadboard. Many, many people go through university and get a good chunk of theory in their minds without any practice.
As for companies - if someone is leaving a well known company, you should ask why. Almost always there is a good reason for it, like moving to warmer climes, family commitments and so on. However, there should always be a fizzbuzz check to make sure the person wasn't let go because they were inept.
As an aside, a long list should also give warning signs if it's in a short period. If I'm hiring a 20-something and they've been through 5 companies I'd be wary. They may be a top notch programmer, but do I want to hire someone who will most likely jump ship in a year or two? Probably not.
To me, it is absurd that people believe in FizzBuzz because I see this mindless ritual of asking FizzBuzz question can be best described as Cargo Cult Science as coined by Richard Feynman (http://neurotheory.columbia.edu/~ken/cargo_cult.html), where in this context of hiring, recruiters are hoping that by asking FizzBuzz he will definitely filter out all incompetent programmers/engineers so he won't have to waste time finding out if the candidates are actually suitable for the position and the team.
If FizzBuzz is the ultimate filter for the position he is applying for, or if it should be considered universal, then why wouldn't university teaches them to memorize all possible variations of them in their introductory programming classes? Also wouldn't you think people who are not good programmers would cheat his/her way out by simply memorize the solution? Then aren't you still wasting time asking FizzBuzz questions?
Either way, you're wasting an hour of eng time at most.