I'm a developer with a CS degree and have work experience doing development in a number of languages for almost 3 years.

Today I had an interview, overall it went quite well, I prepared for most of the questions and felt ready for anything. At the end of the interview, they gave me ONE programming question...a problem like FizzBuzz (without the print the number part). I believe I made too many mistakes and thus have "failed" it. Is all hope lost for me?

Here is my code:

  void FizzBuzz()
    for(int i = 0; i <= 100; i++)
      bool isThree = i % 3;
      bool isFive = i % 5;

     if (isThree)
         print "Fizz\n";
     else if(isFive)
         print "Buzz\n";
         print "FizzBuzz\n";

As you can see I messed up the bools which should have the syntax i % 3 == 0; If I'm remembering the question right I also put an else instead of an elseif with isThree && isFive. I was quite stressed, but that's no excuse for missing a simple problem.

So the question is, how important is being able to produce working code on the spot relative to other factors, such as experience and personality? For instance, would the above code be a deal breaker?

  • 31
    I think the fact that you used the modulus operator is good enough
    – Ryathal
    Dec 6, 2012 at 20:43
  • 9
    you also don't print out the number when it's neither a multiple of 3 nor 5. The fact that you didn't mention that either in posting this question would also make very skeptical. Dec 6, 2012 at 20:43
  • 13
    How can anyone answer this on behalf of your interviewers?
    – pdr
    Dec 6, 2012 at 21:03
  • 5
    Tangential advice - do project euler problems 1-10 and you will have a handle on many of the standard types questions that will be asked of you as a "can you program - write this code"
    – user40980
    Dec 6, 2012 at 21:20
  • 20
    I don't think I'd hire someone who failed at writing FizzBuzz, but IMHO you failed at writing syntax perfectly on a whiteboard, which is something else. Dec 7, 2012 at 5:21

8 Answers 8


The point of FizzBuzz is to show that you actually know how to program, not that you've memorized all the finer syntax rules of the language you've been asked to program in (although that does matter, if they want to know how experienced you are in the language).

If you got this far in the stress of an interview environment, and can show that you understand the errors that you made, I'd say you passed.

  • Agreed, wasn't trying to imply it was me memorizing the answer. It's that I feel I am a quite capable programmer but feel like only having one programming problem and not doing well on it is a really bad reflection of my abilities. They also didn't say anything about the problem. I did not realize the error of my ways until I had gotten in my car and started to drive home. Then it was a OMG whyyy!! reaction. Dec 6, 2012 at 20:27
  • Did they give you the FizzBuzz question first? If they didn't end the interview right away, you passed. Interviewers consider other factors besides a simple coding test; good employers want people who know how to think critically and solve problems. Dec 6, 2012 at 20:29
  • They spent most of the time asking me about my resume, asking about various technologies I had used and how I used them. And then they asked me the programming problem. Then they asked me questions about myself. Then I asked a number of questions and I shook their hands and left. Dec 6, 2012 at 20:32
  • 4
    Good interviewers will terminate the interview when there is no longer any interest in hiring you, which should have happened right after FizzBuzz if you failed the test. It doesn't mean that they will still hire you, but it does mean that you didn't fail the interview out of hand. Dec 6, 2012 at 20:34
  • 4
    @RobertHarvey - not everyone will cut the interview off then and there. With my recent candidate who failed FizzBuzz, I continued the interview in an attempt to see if he could salvage things. In other words, I was willing to grant missing the exercise due to stress of the interview.
    – user53019
    Dec 6, 2012 at 21:08


Most of the people I have interviewed that failed the code exercise portion over minor syntax or slightly off logic ended up being the better hires.

Getting the core idea of the logic straight (which you did) and converting it to something decent and concise from a code point of view (which I think you mostly did) are far more important to me than getting it absolutely perfect.

I buy an IDE for it's syntax checking not hire a dev for it, and you would have realized the other mistakes within moments of your first debug.

You went from the initial requirement to a first attempt fairly directly and without doing anything terrible. That is more valuable in many environments then perfection in an absence of feedback. If the employer is that hung up on the details you missed it might be a sign of the environment to come anyway.

If the task was the print numbers variant, missing the detail would look a little bad, but it would not have enough weight to change my decision if I liked you for the position otherwise.

[Edit] As Alex pointed out there is the reaction and composure aspect as well. Personally I try to get that out of the way before getting to the practical exercises by trying to corner the interviewee on something a little outside their experience but some may choose to combine the two. Every once and a while I have run into someone who only has textbook knowledge and they sail right through the theoretical and background issues but seriously get hung up on where to start with the practical exercise. Some cannot even figure out where to begin.

These individuals are EXACTLY what I want weeded out with this exercise.

So unless you took 20 minutes in making the interviewer clarify the requirement I imagine your solution was more or less your first attempt with possibly a couple of corrections as you went. If you got what you put above in under 5 min you showed you can think enough for my standards.

  • 2
    Bill, I just want to say thanks alot for the detailed feedback. It's nice to get some other perspectives. It's just frustrating to make mistakes on something so simple and know that you're better than that. Dec 6, 2012 at 20:58
  • 1
    Just let me confirm what Bill just said. This kind of test is designed mainly to see how people react under pressure. You are NOT expected to be a perfect programmer when working under these conditions. You are just expected to... work. Really. You are just expected to try to stay calm and face the problem as well as you can. That is exactly what you did. Dec 6, 2012 at 21:29
  • It isn't only the not printing the numbers it's also the failure to recognize that at multitudes of 15 you don't print Fizz or Buzz but FizzBuzz. It doesn't show good breaking down of the problem. When to print "FizzBuzz" is imo the most important element of this puzzle.
    – Pieter B
    Dec 7, 2012 at 17:37
  • I don't use this particular example as lots of contract houses have their candidates memorize it, but it has been my experience that the people that make the "oh duh" mistakes in these exercises generally turn out to be better coworkers. His logic started from the right place, and there isn't a bunch of extra crap, that is good. He missed something you would have seen in the first compile. I would rather have they guy that gets it wrong 3 times in 15 minutes then is good than the guy that takes 30 min to begin.
    – Bill
    Dec 7, 2012 at 18:03
  • @Bill - What kind of answers to this problem do you see? I just dont understand how anyone who hasn't had one programming class can not know at least as much as I put. I wrote that in maybe a min to a min and a half and the only reason it took so long was because I was talking and writing on the whiteboard at the same time. Dec 8, 2012 at 22:08

The above code probably would be a deal breaker for me if I didn't have something else to go on. If they follow the Microsoft interview style, then the person who gave you this question will probably block you--and one is often all it takes.

What baffles me is that the interviewer didn't ask you about this code. A good interviewer has seen enough of their own code to know that people make mistakes--especially when in a hurry. Usually they say, "Now do you see anything wrong with this code?" "No? Well let's test it". You come up with some result sets and then run it through the function. Then you say, "Oh shit, that didn't work." "Ok, how would you fix it..." and so on. If you survive that dialog, it is actually quite impressive and demonstrates an ability to think critically, come up with test cases, and debug your own code.

Also note, they usually aren't looking for "working code". Who produces that the first try anyways? But logically correct with error handling and good test sets is a good goal.

In addition, this may surprise you, but you are competing with many people that can't even get started on fizzbuzz. We tend to assume that everyone else is traversing b+ trees in their sleep.... but in reality, they can't even figure out multiples of 3 and 5 and use a modulus operator. You may be delightfully surprised at how much better you did than the other candidates.

My advice, just brush it off. I interviewed at large software firms recently (Microsoft, Amazon etc...), and it was my first time to ever go through such a thorough interview process. I made a fool of myself at an onsite Microsoft interview largely because of nerves, but also, I just didn't know what to expect or what exactly they were looking for. I nailed a shortest path problem only to blow some really simple problems. I popped values off of the wrong end of a stack, forgot in an int atoi(char* value) implementation that int val = value[i] - '0'; would give me the integer value of the character, and several other silly mistakes. I was happy for the most part with the interview, but still understood why I didn't receive an offer. I had to realize that this was not so much a reflection on my abilities as it was an indicator that I just needed to keep trying it until I was able to master my nerves. Eventually I nailed some interviews with much harder questions and landed my dream job. It really is--for most people who actually know what they are doing--just a matter of figuring out what the interviewers want, being confident in yourself, and giving it to them. It takes a while.

  • I agree the code would be a deal breaker for me as well (I've been in some Lead Positions where I needed to review code). I expected them to ask me a number of programming problems and to do what I thought was the "traditional" approach of sort of walking me through the problem if need be. Like you mentioned "See anything wrong with this code" would have tipped me off immediately. I wasnt expecting FizzBuzz and thought this was an exercise in speed. And I def was nervous, didnt get much sleep the night before. Glad to hear you got your dream job. Ill keep interviewing to get mine too! Dec 7, 2012 at 23:32
  • @ja_programmer well fizzbuzz is an exercise in speed. You are supposed to complete it in less than 2 minutes. They are not testing your problem solving abilities, just your flat out ability to write simple code quickly. Also I have been asked "Do you see any problems with this code?" when the code was completely correct and they were just trying to gauge my confidence or piss me off--haven't decided yet. Dec 7, 2012 at 23:48
  • Good point, they could say that if it was correct. However, I do think in this case I needed a right smack upside the head which the "any problems with this code" would have gained. If I had gone through a simple test case like a normal person I would notice that my logic was incorrect. Also, as for your question, I'm going to go with a little bit of both ;) Dec 8, 2012 at 5:41
  • 2
    +1 for No? Well let's test it. I ask candidates to write fizz buzz in interviews. I also get them to write a unit test. Sometimes their fizz buzz fails, but their unit test detects this, leading them to fix it - this is fine. The guys that get rejected are the ones who write a failing solution and then write a test that fails to detect this. I ask them, are you happy with this test, if they are, thats when they fail.
    – Qwerky
    Dec 10, 2012 at 16:35

I would have to say no, but not for the reason you gave, but that you put the FizzBuzz section last. With the way your code works, it will never print FizzBuzz when you expect it to. As Lee commented, it will print it for every value not divisible by 3 or 5.

But the main point is that you learn from it. I like the fact that you're here asking about how you could have done better. Make sure you do some code puzzles and research common interview questions. Also, maybe try timing yourself or do something else that would increase pressure so that you can try to mimic the feeling you're going to get in an interview. And prep, prep, and do more prepping for the interview if you really want to knock it out of the park.

  • 3
    It will print FizzBuzz whenever i is not divisible by 3 or 5.
    – Lee
    Dec 6, 2012 at 20:31
  • 1
    Yeah, I realize that. I really don't know what I was thinking. Dec 6, 2012 at 20:35
  • @Lee sorry, you're right, I meant it wouldn't ever print when he wanted it to. Dec 6, 2012 at 21:04
  • 1
    @mattnz No, but I do expect someone claiming 3 years experience to be able to write a functioning if statement, and even if they get it wrong, be able to tell me, accurately, where they went wrong. (no offense to the OP, just trying to be as honest as possible) Dec 7, 2012 at 15:30
  • 6
    @mattnz: I'd be less worried about bugs and compilation than the fact that the logic of the program is completely wrong. I could live with the isThree = i % 3 mistake, but "else print FizzBuzz" part kills it for me. I'd probably give the interviewee a small nudge to see if they can catch and fix that problem, but if not it's a dealbreaker.
    – Misko
    Dec 7, 2012 at 16:04

No. The point of FizzBuzz is to see if you are able to work out basic conditional logic, that covers all the cases. Contrary to opinions of some people, FizzBuzz isn't about modulus operator, knowing ternary ops or boolean operands. It's a simple exercise in conditionals and you've failed it.

The problem is structured so that all the "elegant" looking code fails to cover at least one case.

Acceptable answers:

if div3 print fizz
if div5 print buzz
if !div3 && !div5 print x

if div3 {
    print fizz;
    if div5 {
        print buzz;
} else {
    if div5 {
        print buzz;
    } else {
        print x;
  • 2
    Your second example is way too confusing. Dec 13, 2012 at 19:33

I give people trivial programming problems to do at the whiteboard. Whether the resulting code is bug free is not the decision point at all. Instead I care about a number of behaviours exhibited during the writing of the code. It's interactive, and I'm learning a great deal about candidates while it's happening.

I go into more detail at Whiteboard "testing" during an interview: legitimate way to back up your (whiteboard) code?

Of course, your interviewer may be nothing like me. But it's entirely possible for you to have passed an interview with me while producing code that's a teeny tiny bit off, and entirely possible to have failed with the identical code.

  • 1
    thanks for the link. That was quite a good read. It's everything I heard about (a few years ago) in my interviewing prep-class. Wish I would have heard your advice before this past interview. I did not get asked any questions, but I also was not forthcoming and give out information. Well maybe a bit, but I think most of that was mumbled. I will take your advice to heart and use it in a (hopefully soon) future interview I have. Thank you!! Dec 11, 2012 at 21:28

If I were evaluating this, I would be looking for the following things:

  1. Does the candidate attempt to get a clear understanding of the requirements before moving on to implementation? Does the candidate seek to solve my problem or to use his pet tools in his programming toolbox? How does the candidate go about solving problems?
  2. Is the candidate fluent in at least one programming language?
  3. Does the candidate have a grasp of boolean logic?
  4. What does the candidate do to ensure the quality of his solutions?
  5. How does the candidate respond to feedback on his code?


It's hard to say on #1. Your question states that your problem did not include the "print number" part, and your solution does not in fact include that. I have no choice but to take your word for it, but if in fact it was the classic FizzBuzz problem that included printing the numbers that were not divisible by either, then it sounds like you jumped to a solution before fully understanding the requirements, which would be a mark off.

I'd give you partial credit for #2 and #3. You knew to use the modulus operator, and had the structure of a working solution, but missed parts of both.

It sounds like you didn't do #4, which would mark you down. In the future, I would recommend taking a step back from the whiteboard and looking over your solution before calling it done. I would also (without being prompted) step through a couple of unit tests for your solution, which would have quickly demonstrated where you messed up.

They didn't give you a chance on #5, which is unfortunate. But the point is I don't want someone who thinks that every line of code they have ever written is pure gold that couldn't possibly be improved, but rather someone willing to accept feedback on his solutions and engage in some conversation about his approach.


So, if I were evaluating on this alone, I would vote "No Hire." Things like this are sort of measuring a performance art rather than programming ability , but mastering it can still aid your career. So my, recommendations for future tech interviews would be:

  1. Before the interview, practice a couple of these type of exercises cold, using as few outside resources as possible. Not to memorize solutions, but to be sure you're comfortable with your preferred language

  2. Ask questions about the problem to validate your assumptions.

  3. Before announcing your solution complete, step back from the whiteboard and look it over, and walk through a couple simple unit test cases.

  • While I agree with this as a basic interview goal, this is not the point of fizzbuzz. Fizzbuzz is gauging one thing and one thing only. Can you write simple code quickly and correctly? Usually interviewers want this question done in less than 2 minutes. That isn't everything, I know, but that is what the question is designed for. Dec 7, 2012 at 23:50
  • 1
    The point of fizzBuzz is whatever the interviewer wants it to be. If I were to use fizzBuzz or a similar exercise, this is what I would be looking for.
    – JohnMcG
    Dec 10, 2012 at 20:21
  • 1
    Certainly any interview question is whatever the interviewer wants to use to evaluate the things they are interested in. My point is that FizzBuzz is a very poor question for evaluating anything other than, "Can he/she write correct code quickly?" It is not really technically challenging enough to gauge critical thinking skills. If someone seriously gets hung on this question, do you even want them on your team? It's like hiring an Engineer that can't do basic calculus. While everyone wants to make sure the Engineer knows his basic Calculus--it is really non-negotiable that he does. Dec 11, 2012 at 15:29

Asking someone to solve a problem without giving them the ability to get feedback on their solution is a questionable approach, because they aren't allowed to improve.

All this test tells us is that you didn't demonstrate very good "top-of-the-head" problem solving skills.

This could be one of the elements in the decision to hire you or not, but to me it should definitely not be the only one.

Would they have provided you with a unit testing or execution environment, the mistakes you made would have been less excusable.

  • 1
    There's a time and place to improve upon your abilities, but job interview is not it.
    – RokL
    Dec 7, 2012 at 16:22
  • Do you imply that a recruiter shouldn't care about the candidate's capacity to improve herself ? Dec 7, 2012 at 16:53
  • 1
    Improving oneself takes place on time scales longer than an hour. It's not important to the recruiter. Dec 7, 2012 at 17:04
  • I do think given how easy the problem was, I should not have made any mistakes despite me being under stress. That being said, I do think there is grounds for "improvement" in problems such as this, if the interviewer pushes the candidate a bit. Even saying something as simple as "do you think you could improve this at all?" will give the candidate a hint that something is not right or he/she could do better. I got no such comment. Dec 7, 2012 at 17:13
  • @whatsisname: I think it should be important to the recruiter, but not in the way you might think. If the candidate is turned down, the recruiter needs feedback to understand why so that (s)he can present better candidates to the company in the future, and instruct this candidate in how they can become a stronger candidate for the future. I think there is room for mutual benefit there.
    – alroc
    Dec 7, 2012 at 17:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.