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.

Yes

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.

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 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.

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;
    }
}

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.

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.

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.