A lot of the people that hate on programming interviews haven't had to interview candidates. Don't get me wrong, interviews are still annoying and sorta broken but your perspective really changes when you're the one filtering candidates.
I hate them and I have had to make the call to hire/not hire - what is that supposed to say?
The side of hiring I find interesting is more on the behavioral side - many employers don't find enough ways to screen candidates on those grounds, and it is interesting the ways you find candidates filtering themselves out there if you ask the right questions.
Yes, my interviewing generally scaled up in difficulty as the interview progressed. I don't like the idea of putting so much stress on nice people, but it's shocking how many people interview for system's level programming jobs with clearly made up resumes.
One young person showed up with a resume listing about 10 programming languages. I simply went through the 10 and asked her how to write a comment for each language. We didn't have to go far before she admitted that she really only knew Pascal very well.
To be fair, there were a lot of people that would have made good employees be didn't happen to quite fit the job we were trying to fill at the moment. The matching process often involved a significant degree of luck and I sure that I missed out on many people I should have hired.
"No programming test these days is valid without full access to Google."
This is the opposite to conventional wisdom which says that programming tests must be done in an isolated environment without access to the web "please deposit your mobile phone at the testing room door".
No programming is done in isolation so the only way to effectively and realistically test someone is to see what results they get in a real world environment, which means full web access.
Don't get me wrong - I am very much against the idea that "I don't need to understand fundamentals cause I can Google everything" - only the misguided think that. What I do think is that recruiting needs to be about measuring real world results - that means full access to Google and StackOverflow.
THE most critical skill that is almost NEVER meaured - and in fact is generally avoided measuring - is the programmers skills in Googling to solve unfamiliar problems. The best programmers ride Google and StackOverflow like racehorse jockeys ride the ponies.
The whole point is that if you are properly testing candidates then it is an open test and there's no point in theoretical tests like fizzbuzz when it is open book. The correct solution to fizzbuzz in an open book test is to search Google for "optimal fizzbuzz solution in language X".
It forces the employer to create a test that is more real world and thus is a closer reflection of the actual work being done at that company.
Unless of course your company is doing alot of real world fizzbuzz.
That would defeat the point of fizzbuzz in the first place. It's to see if they can translate rules into code, to see if they understand the very basics of programming. If they google "optimal fizzbuzz solution in language X" then you're seeing if they can copy and paste code.
There is plenty of room for more open tests, but fizzbuzz doesn't require it.
The same way all other industries do it, by asking the candidates questions and judging their capability based on how they answer said questions. How do hospitals hire doctors? How do law firms hire lawyers? How do insurance companies hire insurance salesmen?
> How do hospitals hire doctors? How do law firms hire lawyers?
Both of those examples have rigorous training requirements before it's even legal to call yourself one and even then they still have some level of fraud.
Anyone can call themselves a programmer and the only real world requirement is being able to program.
Can you provide a more effective first filter that can solve the same problem (discarding the 50%+ candidates that have zero programming ability and shouldn't have applied in the first place) quicker than fizzbuzz?
There are many, many approaches that will also filter them out, but the point of fizzbuzz is to do it immediately without wasting a lot of time of your engineers on candidates that can and should be discarded within five minutes.
I suspect that you are thinking of FizzBuzz differently than it was originally intended.
FizzBuzz is not designed as a test of real-world programming skills; rather, it is a deliberately easy test to ensure that a candidate can solve an elementary programming problem from scratch.
The idea being, that somebody that can not solve a trivial problem is in no shape to tackle a harder problem.
Many companies overthink this. They add TDD, or try and test if a candidate can implement Dijkstra's Shortest-Path Algorithm, or any number of other complications.
But that all misses the point of what FizzBuzz does.
FizzBuzz is a first-stage filter, and exists only to screen out copy-pasta programmers that, while their resumes might look good on paper, can't actually code.
There are a lot of those programmers out there, even today.
FizzBuzz should take a candidate no more than five minutes in a language they are familiar with. It really should be that level of simple.
After FizzBuzz is when you can dive into the real-world problems, because the candidate has demonstrated that they can write code.
Now, admittedly, I have moved past FizzBuzz, and now prefer doing a simple pairing exercise over-the-phone, but FizzBuzz is still a useful tool in the interviewing toolbox for companies that don't use pair programming.
If you do use FizzBuzz, I do recommend changing it up. Don't just copy Atwood's FizzBuzz problem. Change the numbers, mix the conditionals around, that sort of thing. But keep it just as simple.
> FizzBuzz is a first-stage filter, and exists only to screen out copy-pasta programmers that, while their resumes might look good on paper, can't actually code.
I said recently in another thread that the lead tech at my company was complaining during one round of interviews for a senior position, that some of the candidates couldn't even conceptually 'get' FizzBuzz, let alone code it.
> FizzBuzz should take a candidate no more than five minutes in a language they are familiar with
I'll go a step further and say that if you're the kind of person that takes FizzBuzz as a personal insult, then you should be able to write it out in 60 seconds max, and move on with the interview. FizzBuzz is not for 'you', it's for the people who claim to be as good as 'you', so take it easy and move on.
Complaining about FizzBuzz is like complaining about having a police check done, even though you don't have a criminal record. The check isn't for 'you', the innocent person.
> I'll go a step further and say that if you're the kind of person that takes FizzBuzz as a personal insult, then you should be able to write it out in 60 seconds max, and move on with the interview.
I see your step, and raise you. :)
Asking a developer to spend five minutes to write a trivial problem is not an insult. Somebody that takes this as such is probably not going to be the type of person I, or my team, will want to work with, and we can end the interview process there.
I can totally understand balking at a one-day "homework problem" given out as part of the interview.
Not because this is an insult, but because it gives nothing to the candidate. An on-site or remote "test drive" where they spend a day working with the team is fine in my book, because that experience is valuable to the candidate in answering the question of "will I be happy and productive here?"
A company that demands a full- or half-day of time in exchange for nothing, not even information, probably does not value its employees much.
My personal policy is that the interview process can consume no more than one day of a candidate's time in total, plus an hour for a phone screen, and that at the end of the interview, both parties can make an informed decision as to whether or not they want to continue.
But five minutes to complete a trivial programming test? Writing this post took about that amount of time.
Personally, I think FizzBuzz is stupid as hell, but I understand its role as an initial filter.
My real frustration with FizzBuzz rises from getting this "test" at the in-person interview. Multiple times. Do it in a live coding session as part of the phone screening, and make those results available to all interviewers. Reserve the limited time that is available for in-person interviews for real questions, not filters.
Or think of a better filter question than FizzBuzz. One great example for someone who claims to be a Python programmer - fix this:
def foo(x, bar=[]):
bar.append(x)
return bar
That lets me know that you as the interviewer also know more than FizzBuzz.
Run `foo('a')` a few times in a row - you'll start seeing that "bar" keep state unexpectedly. It's a fairly classic Python gotcha - the mutable object is retained across calls when the default is used.
Okay, minus another couple points to me for not testing each case more than once, and yes, if you're going to present syntactically valid code and ask people to "fix" it you should probably state what it's supposed to do, but aside from all that... the hell?
Okay, having Googled the logic behind this behaviour, I still think it's stupid. My next question is - is being aware of little language gotchas like this really so important? It really bugs me that about all I'm good for in the employment market is making computers do stuff, but I'll never pass an "esoteric language behaviour test" in anything - my tastes are too diverse and I've never gone "all-in" on anything. But I don't think it gets in the way too much - you keep your changes modular and test frequently, and if it doesn't work right you figure out why. Which corners of the language you tend to bump into depends very much on your coding style (for instance I try hard not to mutate things which is possibly why I've not hit this before), so even with a brand new language you should be able to get going pretty quickly.
> is being aware of little language gotchas like this really so important
Somewhat ironically, our conversation here highlights why it is important. If you initially tested these three lines of code to your satisfaction and didn't find the bug, how could you assume that your unit tests would catch the bug?
> Surely I'm not useless?
I would hardly think you're useless, but it does show a lack of experience with the Python language. On the other hand, your most recent response also shows a capacity for looking up and identifying the language WTF and how to fix it, skills which are important in lieu of experience.
> Somewhat ironically, our conversation here highlights why it is important. If you initially tested these three lines of code to your satisfaction and didn't find the bug, how could you assume that your unit tests would catch the bug?
If you can't define the behavior for such a simple function how are they supposed to know if it's working or not? Several posts later you still haven't. Is foo meant to append to the array? Is it meant to initialize a new one? Is it meant to create one if it's null?
Eh, I'll give falcolas a pass on that, since the intended behaviour is clearly what any normal person looking at that would think it does - if you wanted to make some sort of closure, I'd hope you'd do it more explicitly (though my opinion of good style and what's supposedly "Pythonic" are often at odds - the whole "[].append()" idiom seems perverse to me). It's not necessarily unreasonable to present technically valid code and say "find the bug" - in C for example you might see "if(x=3)" and conclude, on the basis of what's idiomatic, that it's probably an error.
It is a Python gotcha, and nice if you recognise it, but this definitely does NOT give you any indication of whether or not this person is a good programmer.
What can be said is that if someone recognises this isssue then likely they are a good Python programmer. But the converse is not true that all good Python programmers would recognise this, and therefore this is a test that potentially eliminates a bunch of good programmers. That's a bad test.
This test allows the interviewer to feel smug about how much smarter they are than the interviewee. LOTS of interview tests are set up that way. "Oh, you don't know some very specific thing about your primary programming language? Then (jeering) you're not very good are you!! I know that and you don't!". That's not skills evaluation, it's ego wrapped in the guise of skills evaluation.
This is "trick oriented recruiting" and not far removed to me from asking how many ping pong balls would fit in a 747.
I was with you until the "The best programmers..." line. They are the best programmers for whatever reasons were important in whatever it was that they were doing.
When I have asked interviewees to do anything on a whiteboard I've generally said 'pseudo-code is fine or whatever language your comfortable in or even diagram it'. What I'm looking for is an awareness of high-level concepts and ideas. People may not google for something if they don't know to google for it.
If you can't write FizzBuzz in the language of your choice without access to Google, I don't want to hire you. Period. In fact, I will campaign actively against you being hired.
Note that I said Fizzbuzz, not an actual in-depth programming question.
FizzBuzz (and similar) questions tell me nothing whatsoever about your programming ability, but they can tell me everything about your lack of it.
I completely agree with you - being unable to write FizzBuzz is a red flag. However, finishing FizzBuzz under interview conditions does not really prove very much at all about a candidate's likely success on the job.
In the limited time I want to spend interviewing, an hour on FizzBuzz is a massive waste of everyone's time.
EDIT: for the commenters - I agree an hour is too much. Whacking out FizzBuzz in 15 minutes could have its place :)
When I experienced FizzBuzz as a candidate I was coding onto a projected screen, and the test involved writing unit tests and doing a final refactoring step into something "reusable". It took the best part of an hour. The instructions themselves required a good 5-10 minutes of reading/parsing to understand exactly what was expected of you.
Yes. I definitely should have clarified that I mean "if you can't write FizzBuzz in the first few minutes of the interview..." not as the only question in an hour-long interview. I've used a FizzBuzz-like question as the first question of a phone screen, for example, to determine if more in-depth questions are a waste of everyone's time.
I agree entirely that it doesn't prove anything about a candidate's likely success as a hire, but it is a reasonably strong signal about their likely failure.
The author using FizzBuzz as a comical-but-recognizable launching point for demonstrating introducing the basics of programming language implementation and RPLY, and the HN comments being nothing but people yelling about FizzBuzz, is a pretty amazing summary of the state Hacker News comments. It also makes me think next time I have a technical article, I should prepend some controversial statement to it just to generate buzz :V
In all seriousness: this is a really cool article, thanks for sharing! I'm not very familiar with RPython or RPLY and it was really cool to see a "real-world" example of it. I actually just read through something similar in JavaScript (https://github.com/thejameskyle/the-super-tiny-compiler). I really should give language implementation a shot one of these days (closest I've come is writing a JSON lexer & parser); always like to read about it!
There was a project linked to HN in ~December or November of last year about building your own Lisp, which would probably be a terrific jump off point into that, if you're looking for a place to get started.
There doesn't need to be a separate test for 3 and 5, his example already handles it properly -- it's two separate if statements, not an if/elsif, so it'll just meet both conditions and print "fizz" then "buzz" to create "fizzbuzz". What's forgotten is printing the number alone if it's divisible by neither.
Fizzbuzz is one of those problems where there's really no clever hidden golfy solution better than the plain old first-reaction naive approach: an iteration with if/elsif/elsif/else.
> Fizzbuzz is one of those problems where there's really no clever hidden golfy solution better than the plain old first-reaction naive approach: an iteration with if/elsif/elsif/else.
> Fizzbuzz is one of those problems where there's really no clever hidden golfy solution better than the plain old first-reaction naive approach: an iteration with if/elsif/elsif/else.
There is if you exploit that monoid homomorphisms exist from any monoidal type to both the Optional and Function types.
My favourite solution is this:
let (m ~> str) x = str <$ guard (x `mod` m == 0)
in map (fromMaybe . show <*> 3 ~> "fizz" <> 5 ~> "buzz") [1..100]
This is extensible because you can stick as many rules as you want in there, or even factor them out and make it a function
I usually give his answer (but in Python), and every now and then the interviewer will make your same mistake (if if, not if else if) Delightfully awkward, the worst was the guy who didn't believe me and popped up a shell to test it. What's the appropriate social response when someone trips over their own weed-out question?
If I were asked I might just go verbally, well; for i from 0 to 100, if i mod print fizz, else if etc. Followed by test it, check loop conditions, edge cases, representative number of ifs and prints for each type; put a header on the code with a description and we're done.
For me it's not about getting it 100% correct, its about showing that you can do basic programming and know how computers work, followed by the simple breaking down of a concept into a program.
The rest I consider details. Even if you implemented it 100%, its so simple that it doesn't nearly guarantee that you will do the same for a large program. And if you don't get it 100% correct, as long as you roughly indicate some fields where you're going to test for issues I'd be more than happy about it. Thereafter the human factor/generics, for example did it take you 30 minutes to think this up or was it pretty much rapid-fire? How learned of a response is programming to you?
But as to your question; people don't really like being showed up, but that works well for filtering for you as well. If he hated it then it might very well not be a place/person you want to work with.
I did when others corrected me. I would have docked you for producing something that's not particularly readable. Fizzbuzz isn't about providing a clever one liner.
well, there are variations of the problem. some people ask candidates to print the number, some ask to print empty string, etc. I'm just used to the latter.
Saying one is a C++ expert is a pretty extraordinary claim and should require extraordinary evidence :)
I'm regularly intimidated by positions looking for capital s Senior C++ developers, because no matter how deep my knowledge goes, memory model, templates substitution rules and all, I realize there's dragons lurking behind every corner. Now, C is a language that fits in my head, C++ … not so much, but maybe that's because it is not part of my daily routine.
I'd suggest you look for _productive C++ developers_ that know their limitations. I think you might even get better candidates that way.
I can't help but notice that it doesn't help when the order of the strings need to change. Consider the following problem: For multiples
* of 105 print 'buzzfizzfuzz'
* of 35 print 'buzzfuzz'
* of 21 print 'fuzzfizz'
* of 15 print 'fizzbuzz'
* of 7 print 'fuzz'
* of 5 print 'buzz'
* of 3 print 'fizz'
82 comments
[ 3.4 ms ] story [ 151 ms ] threadJeff Atwood on the other hand thinks it's a great way to filter out "developers" who can't program their way out of a wet paper bag:
https://blog.codinghorror.com/why-cant-programmers-program/
The side of hiring I find interesting is more on the behavioral side - many employers don't find enough ways to screen candidates on those grounds, and it is interesting the ways you find candidates filtering themselves out there if you ask the right questions.
One young person showed up with a resume listing about 10 programming languages. I simply went through the 10 and asked her how to write a comment for each language. We didn't have to go far before she admitted that she really only knew Pascal very well.
To be fair, there were a lot of people that would have made good employees be didn't happen to quite fit the job we were trying to fill at the moment. The matching process often involved a significant degree of luck and I sure that I missed out on many people I should have hired.
https://gist.github.com/houmei/4649209
welp
"No programming test these days is valid without full access to Google."
This is the opposite to conventional wisdom which says that programming tests must be done in an isolated environment without access to the web "please deposit your mobile phone at the testing room door".
No programming is done in isolation so the only way to effectively and realistically test someone is to see what results they get in a real world environment, which means full web access.
Don't get me wrong - I am very much against the idea that "I don't need to understand fundamentals cause I can Google everything" - only the misguided think that. What I do think is that recruiting needs to be about measuring real world results - that means full access to Google and StackOverflow.
THE most critical skill that is almost NEVER meaured - and in fact is generally avoided measuring - is the programmers skills in Googling to solve unfamiliar problems. The best programmers ride Google and StackOverflow like racehorse jockeys ride the ponies.
It forces the employer to create a test that is more real world and thus is a closer reflection of the actual work being done at that company.
Unless of course your company is doing alot of real world fizzbuzz.
There is plenty of room for more open tests, but fizzbuzz doesn't require it.
That's precisely my point.
If your selection process includes fizzbuzz then your selection process is ineffective.
Both of those examples have rigorous training requirements before it's even legal to call yourself one and even then they still have some level of fraud.
Anyone can call themselves a programmer and the only real world requirement is being able to program.
There are many, many approaches that will also filter them out, but the point of fizzbuzz is to do it immediately without wasting a lot of time of your engineers on candidates that can and should be discarded within five minutes.
Thats the job though. Most jobs include a lot of googling + copy/paste.
FizzBuzz is not designed as a test of real-world programming skills; rather, it is a deliberately easy test to ensure that a candidate can solve an elementary programming problem from scratch.
The idea being, that somebody that can not solve a trivial problem is in no shape to tackle a harder problem.
Many companies overthink this. They add TDD, or try and test if a candidate can implement Dijkstra's Shortest-Path Algorithm, or any number of other complications.
But that all misses the point of what FizzBuzz does.
FizzBuzz is a first-stage filter, and exists only to screen out copy-pasta programmers that, while their resumes might look good on paper, can't actually code.
There are a lot of those programmers out there, even today.
FizzBuzz should take a candidate no more than five minutes in a language they are familiar with. It really should be that level of simple.
After FizzBuzz is when you can dive into the real-world problems, because the candidate has demonstrated that they can write code.
Now, admittedly, I have moved past FizzBuzz, and now prefer doing a simple pairing exercise over-the-phone, but FizzBuzz is still a useful tool in the interviewing toolbox for companies that don't use pair programming.
If you do use FizzBuzz, I do recommend changing it up. Don't just copy Atwood's FizzBuzz problem. Change the numbers, mix the conditionals around, that sort of thing. But keep it just as simple.
I said recently in another thread that the lead tech at my company was complaining during one round of interviews for a senior position, that some of the candidates couldn't even conceptually 'get' FizzBuzz, let alone code it.
> FizzBuzz should take a candidate no more than five minutes in a language they are familiar with
I'll go a step further and say that if you're the kind of person that takes FizzBuzz as a personal insult, then you should be able to write it out in 60 seconds max, and move on with the interview. FizzBuzz is not for 'you', it's for the people who claim to be as good as 'you', so take it easy and move on.
Complaining about FizzBuzz is like complaining about having a police check done, even though you don't have a criminal record. The check isn't for 'you', the innocent person.
I see your step, and raise you. :)
Asking a developer to spend five minutes to write a trivial problem is not an insult. Somebody that takes this as such is probably not going to be the type of person I, or my team, will want to work with, and we can end the interview process there.
I can totally understand balking at a one-day "homework problem" given out as part of the interview.
Not because this is an insult, but because it gives nothing to the candidate. An on-site or remote "test drive" where they spend a day working with the team is fine in my book, because that experience is valuable to the candidate in answering the question of "will I be happy and productive here?"
A company that demands a full- or half-day of time in exchange for nothing, not even information, probably does not value its employees much.
My personal policy is that the interview process can consume no more than one day of a candidate's time in total, plus an hour for a phone screen, and that at the end of the interview, both parties can make an informed decision as to whether or not they want to continue.
But five minutes to complete a trivial programming test? Writing this post took about that amount of time.
My real frustration with FizzBuzz rises from getting this "test" at the in-person interview. Multiple times. Do it in a live coding session as part of the phone screening, and make those results available to all interviewers. Reserve the limited time that is available for in-person interviews for real questions, not filters.
Or think of a better filter question than FizzBuzz. One great example for someone who claims to be a Python programmer - fix this:
That lets me know that you as the interviewer also know more than FizzBuzz.Okay, minus another couple points to me for not testing each case more than once, and yes, if you're going to present syntactically valid code and ask people to "fix" it you should probably state what it's supposed to do, but aside from all that... the hell?
Okay, having Googled the logic behind this behaviour, I still think it's stupid. My next question is - is being aware of little language gotchas like this really so important? It really bugs me that about all I'm good for in the employment market is making computers do stuff, but I'll never pass an "esoteric language behaviour test" in anything - my tastes are too diverse and I've never gone "all-in" on anything. But I don't think it gets in the way too much - you keep your changes modular and test frequently, and if it doesn't work right you figure out why. Which corners of the language you tend to bump into depends very much on your coding style (for instance I try hard not to mutate things which is possibly why I've not hit this before), so even with a brand new language you should be able to get going pretty quickly.
Surely I'm not useless?
Yeah. Python. A fun little wart.
> is being aware of little language gotchas like this really so important
Somewhat ironically, our conversation here highlights why it is important. If you initially tested these three lines of code to your satisfaction and didn't find the bug, how could you assume that your unit tests would catch the bug?
> Surely I'm not useless?
I would hardly think you're useless, but it does show a lack of experience with the Python language. On the other hand, your most recent response also shows a capacity for looking up and identifying the language WTF and how to fix it, skills which are important in lieu of experience.
If you can't define the behavior for such a simple function how are they supposed to know if it's working or not? Several posts later you still haven't. Is foo meant to append to the array? Is it meant to initialize a new one? Is it meant to create one if it's null?
The function is called foo, any normal person would say "wtf is that supposed to do?".
It is a Python gotcha, and nice if you recognise it, but this definitely does NOT give you any indication of whether or not this person is a good programmer.
What can be said is that if someone recognises this isssue then likely they are a good Python programmer. But the converse is not true that all good Python programmers would recognise this, and therefore this is a test that potentially eliminates a bunch of good programmers. That's a bad test.
This test allows the interviewer to feel smug about how much smarter they are than the interviewee. LOTS of interview tests are set up that way. "Oh, you don't know some very specific thing about your primary programming language? Then (jeering) you're not very good are you!! I know that and you don't!". That's not skills evaluation, it's ego wrapped in the guise of skills evaluation.
This is "trick oriented recruiting" and not far removed to me from asking how many ping pong balls would fit in a 747.
When I have asked interviewees to do anything on a whiteboard I've generally said 'pseudo-code is fine or whatever language your comfortable in or even diagram it'. What I'm looking for is an awareness of high-level concepts and ideas. People may not google for something if they don't know to google for it.
Note that I said Fizzbuzz, not an actual in-depth programming question.
FizzBuzz (and similar) questions tell me nothing whatsoever about your programming ability, but they can tell me everything about your lack of it.
In the limited time I want to spend interviewing, an hour on FizzBuzz is a massive waste of everyone's time.
How could it possibly take an hour to write fizzbuzz for anyone of reasonable ability?
If it takes a candidate an hour, something is wrong.
When I experienced FizzBuzz as a candidate I was coding onto a projected screen, and the test involved writing unit tests and doing a final refactoring step into something "reusable". It took the best part of an hour. The instructions themselves required a good 5-10 minutes of reading/parsing to understand exactly what was expected of you.
I agree entirely that it doesn't prove anything about a candidate's likely success as a hire, but it is a reasonably strong signal about their likely failure.
In all seriousness: this is a really cool article, thanks for sharing! I'm not very familiar with RPython or RPLY and it was really cool to see a "real-world" example of it. I actually just read through something similar in JavaScript (https://github.com/thejameskyle/the-super-tiny-compiler). I really should give language implementation a shot one of these days (closest I've come is writing a JSON lexer & parser); always like to read about it!
https://en.wikibooks.org/wiki/Write_Yourself_a_Scheme_in_48_...
https://news.ycombinator.com/item?id=10474717
Nah, those articles tend to fizz out
(1..100).each{|n| p "#{'fizz' if n%3==0}#{'buzz' if n%5==0}"}
Fizzbuzz is one of those problems where there's really no clever hidden golfy solution better than the plain old first-reaction naive approach: an iteration with if/elsif/elsif/else.
There are. With a funky calculation.
For example, taken from Rosetta C version:
You might say the calculations are hidden if/else, but well...Edit: Would be nice if the original author of that code snippet threw in some parentheses for a little clarity with the operator precedence.
There is if you exploit that monoid homomorphisms exist from any monoidal type to both the Optional and Function types.
My favourite solution is this:
This is extensible because you can stick as many rules as you want in there, or even factor them out and make it a functionFor me it's not about getting it 100% correct, its about showing that you can do basic programming and know how computers work, followed by the simple breaking down of a concept into a program.
The rest I consider details. Even if you implemented it 100%, its so simple that it doesn't nearly guarantee that you will do the same for a large program. And if you don't get it 100% correct, as long as you roughly indicate some fields where you're going to test for issues I'd be more than happy about it. Thereafter the human factor/generics, for example did it take you 30 minutes to think this up or was it pretty much rapid-fire? How learned of a response is programming to you?
But as to your question; people don't really like being showed up, but that works well for filtering for you as well. If he hated it then it might very well not be a place/person you want to work with.
> The goal is to sufficiently intimidate junior developers so they will know to steer clear of your organization.
We use fizzbuzz on senior devs claiming to be C++ experts and they stumble on it regularly.
I'm regularly intimidated by positions looking for capital s Senior C++ developers, because no matter how deep my knowledge goes, memory model, templates substitution rules and all, I realize there's dragons lurking behind every corner. Now, C is a language that fits in my head, C++ … not so much, but maybe that's because it is not part of my daily routine.
I'd suggest you look for _productive C++ developers_ that know their limitations. I think you might even get better candidates that way.
It sounds like they are. The "expert" is a self described one.
They were just way too good at playing the game and it took us way too long to get rid of the person - fired, not just dumped.
This outcome can be evidence of either condition:
1. There are a lot of expert developers who are actually not experts
2. The test is giving false negatives
Which do you think it is?
* of 105 print 'buzzfizzfuzz' * of 35 print 'buzzfuzz' * of 21 print 'fuzzfizz' * of 15 print 'fizzbuzz' * of 7 print 'fuzz' * of 5 print 'buzz' * of 3 print 'fizz'