You Can't Teach Height - Measuring Programmer Competence via FizzBuzz
Sponsored By
The comments are abuzz over at Jeff's blog as he's aggreblogged the current discussion on the FizzBuzz problem. It started when Imran said that he has found so few programmers who can code that he, as Raganwald put it, "set the bar ridiculously low."
A FizzBuzz-style question is:
Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.
And for the sake of your immortal soul and your webutation, don't post the solution in the comments. You'll only die a little inside if you do.
Speaking of comments, there's some pretty choice comments on the various blogs that are worth looking at:
It's just performance anxiety.
Most people are terrified/stressed out during interviews.
Not "Can you X?" -
"Can you X whilst terrified?"
This is, to a point, reasonably valid, but I think that if you're hiring someone to sing, it's reasonable to have them sing at the interview. If you're being paid to write code for the better part of your week, and you're offended by being asked to write code at the interview, I say you're hypersensitive. If the interviewer pulls out a laptop and says, "let's write some code" at an interview, as the interviewee, I'd be happy to see that they mean business. I mean, we ARE writing code to solve business problems, right? Seems like not having someone write any code until you've worked somewhere two or three weeks, gone through orientation and company training, could be a dangerous gamble.
Here's another:
However, I have never *once* used - or had call to use - recursion to solve a problem, since I learned about it at university.
Statements like this are kind of dodgy as well. I don't know this individual, but based solely on this one sentence I would surmise they are either, rather young (i.e. recently out of school, maybe the last 5 years) or they've been writing the same general kind of code in their career. Saying that I have never used X since school either means you haven't been out of school long, or that X is a totally useless thing.
What's really important isn't whether a person has used recursion since school, but:
- Could they use recursion if they had to?
- Would they recognize the opportunity to use it when it arose?
This can of course be make generic:
- Could they use [insert well-known computer science dogma here] if they had to?
- Would they recognize the opportunity to use it when it arose?
A few years back I kind of got some flack for posting on "What Great .NET Developers Ought to Know." I just wrote that post on a plane, brainstorming the general kinds of things I thought that someone who worked for me should be able to answer. It wasn't an exercise in trivia, I was literally writing it up to prepare to hire someone.
Some - very fervent - folks thought it was a manifesto, dictating that one had to know these things to be successful. Certainly this isn't the case.
But what can we ask folks who are being hired to code? What do you think they'll say if we ask:
- Say, can you code?
- Bug free, izzit?
- Lots of Unit Tests?
- You love Continuous Integration? Cool.
- Work well with others? Easy going? Charming.
- Drugs on the side? No. Good. Come to work on time?
- You're not evil are you? One of Satan's minions? Good...
- Got a degree of some kind? Yes, good.
- Or: No? Being doing this a while though? Got good references?
- Here solve this simply programming problem. Don't worry, it's not obscure or a trick. I just want to see how you think.
Surely these are all reasonable questions...I could go on. Here's the deal, when I hire someone, I'm looking for them to be tall. A boss told me once that he just wanted his programmers to be tall, because when you're putting together a basketball team, you have to remember that you can't teach height.
We're looking for folks who are excited about computers, who are lifelong learners, who are easy to get along with but willing to fight for what they know to be right. We want folks who will raise the quality of their own code with experience, and also raise the teams level of quality through a process of ongoing improvement and introspection. Seems reasonable to me.
One other thing that's amazing to me about this blogversation (look at me coining B.S. Web 2.0 words left and right!) is that some of the programmers who read these blogs feel the need to actually solve the FizzBuzz problem.
They've completely - no, I need a work with more oomph - utterly? missed the point.
The FizzBuzz exercise is an interesting one, but it certainly should only be considered as a single arrow in one's interviewing quiver. But, Imran ends his post with this, and I shall as well: "This sort of question won’t identify great programmers, but it will identify the weak ones."
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
Quote from my chat with Jeff: "Statement: Hello, programmers! Most programmers suck! That's like going to Guitar Center and yelling out that most guitarists suck."
I've come to this conclusion before. No one applying for a programming job should be offended by having to actually write code, and talk about how and why they did what they did. Can't solve the problem? Great, assume this is your current task and you're sitting at your desk. What would you do? Okay, you'd do a web search? Cool, what search query would you use?
I've come to this conclusion before. No one applying for a programming job should be offended by having to actually write code, and talk about how and why they did what they did. Can't solve the problem? Great, assume this is your current task and you're sitting at your desk. What would you do? Okay, you'd do a web search? Cool, what search query would you use?
"...some of the programmers who read these blogs feel the need to actually solve the FizzBuzz problem. They've completely - no, I need a work with more oomph - utterly? missed the point."
Missed the point?? Developers are problem-solvers - OF COURSE we're going to try to code a solution! :)
Missed the point?? Developers are problem-solvers - OF COURSE we're going to try to code a solution! :)
Having developers prove that they can program something trivial is an OK, but not great, interview procedure.
Smarter yet would be remembering that when it gets down to it, developers do very little "new" programming and are instead maintenance programmers the bulk of the time. Even when we write new code, do you spend the majority of your time writing new code or analyzing where you're at and refactoring it as you proceed? You stop from time to time to think about how maintainable the code you're writing is, right?
The better follow-up question then becomes pretty obvious - OK, you can write at least trivial code. Here's a pretty simple class that I wrote (and have stripped the comments out of). Walk me through my code and explain to me what it's doing. Prove to me that you can read and understand code that other people have written as well as writing it yourself.
Smarter yet would be remembering that when it gets down to it, developers do very little "new" programming and are instead maintenance programmers the bulk of the time. Even when we write new code, do you spend the majority of your time writing new code or analyzing where you're at and refactoring it as you proceed? You stop from time to time to think about how maintainable the code you're writing is, right?
The better follow-up question then becomes pretty obvious - OK, you can write at least trivial code. Here's a pretty simple class that I wrote (and have stripped the comments out of). Walk me through my code and explain to me what it's doing. Prove to me that you can read and understand code that other people have written as well as writing it yourself.
grats on being the 408th reference to blogversation. :) http://search.live.com/results.aspx?q=blogversation+&src=IE-SearchBox
Now I know why I always look at this blog first. Good stuff, for even my braindamaged abilities. (once every year I want to color every other line in a web application. I just look at the last one I did for the syntax. Once every 5 years I need to use recursion. It's there for me to find, but I know when I have to use it).
:)
:)
Interesting as ever. I am interviewing someone by phone tomorrow, and I'm definitely asking some coding questions. That's because I want to hire a programmer.
Oh, and I love your 'webutation' neologism. That's gold.
Oh, and I love your 'webutation' neologism. That's gold.
What I think is classic is how many developers not only rush to solve the problem, but get it wrong! I wrote about that.
If I were to ask this question, I would really be impressed with the developer who instead of rushing to write the code, asked me for some clarifications of the requirements.
"Does the output need to be available on the web, or is a console app sufficient?"
"Any performance requirements for generating the output?"
"Any preferred platform? Who's going to maintain this app?"
If I were to ask this question, I would really be impressed with the developer who instead of rushing to write the code, asked me for some clarifications of the requirements.
"Does the output need to be available on the web, or is a console app sufficient?"
"Any performance requirements for generating the output?"
"Any preferred platform? Who's going to maintain this app?"
Dave,
The issue is here is look for the people who are completely _blank_ about it.
If you struggle to solve this problem, I don't want you on my team.
And frankly, my team _does_ write new code, all the time. Any time that I create a new aspx file, any time that I create a new class.
If I wanted a maintainer programmer, I would have interview for a COBOL job.
The issue is here is look for the people who are completely _blank_ about it.
If you struggle to solve this problem, I don't want you on my team.
And frankly, my team _does_ write new code, all the time. Any time that I create a new aspx file, any time that I create a new class.
If I wanted a maintainer programmer, I would have interview for a COBOL job.
Its a mad dash to solve the wrong problem, and even then solve it incorrectly. Phillip your brilliant. I still have no clue why there is this need to post a solution.
Lame solution:
(in VFP a ? is a print to console statement)
? "1"
? "2"
? "Fizz"
? "4"
? "Buzz"
? "Fizz"
? "Buzz"
? "8"
? "Fizz"
? "10"
? "11"
BOb
(What's really lame is those that don't know this is tounge-in-cheek.)
(in VFP a ? is a print to console statement)
? "1"
? "2"
? "Fizz"
? "4"
? "Buzz"
? "Fizz"
? "Buzz"
? "8"
? "Fizz"
? "10"
? "11"
BOb
(What's really lame is those that don't know this is tounge-in-cheek.)
People always talk about performing unit tests because the earlier you catch an error, the cheaper and easier it is to correct. In my mind then, interview questions become the ultimate set of unit tests. Of course Scott will find someone who has coded nInterviewUnit and add it to the tools list, while Phil Haack and Jon Galloway will immediately tout the benefits of mbInterviewUnit as being superior to nInterviewUnit. Jeff Atwood will subsequently publish a detailed statistical analysis of exactly how many interview unit tests you can run each hour using each framework, thereby increasing your interview throughput (you can overclock the interviewers with little caffeine, but you have to be carefult not to overdo it).
Walking through code and saying what it does I think is a great interview method for part of the interview if you are hiring them to do maintenance work. But I think questions like the FizzBuzz question is good, because it can test their analysis and how they think of problems. I still think the greatest question in an interview is "If you have a bowling ball in a boat and you want to measure how deep the Marianas Trench using any method how would you?"
@Joe... Actually I'm starting a new open source project, SubInterviewUnit.
Ouch, Joe! Actually, this whole thing went according to the usual script:
1) Jeff strategically quoted some interesting articles, wrapping it up in a way that told a good story.
2) The story got dugg and got 40 billion views, but because silly Jeff has issues with ads he didn't make a single penny.
3) Scott wrote up a nice thoughtful piece which made a practical application based on the comment thread and got a decent number of comments.
4) Phil wrote up a nice thoughtful piece which made a practical application based on the comment thread and got a decent number of comments.
5) Jon spent his time writing a stupid solution in MSIL which ended up as the obscure 241st comment, right before Jeff hid the comment thread to trim the bandwidth.
1) Jeff strategically quoted some interesting articles, wrapping it up in a way that told a good story.
2) The story got dugg and got 40 billion views, but because silly Jeff has issues with ads he didn't make a single penny.
3) Scott wrote up a nice thoughtful piece which made a practical application based on the comment thread and got a decent number of comments.
4) Phil wrote up a nice thoughtful piece which made a practical application based on the comment thread and got a decent number of comments.
5) Jon spent his time writing a stupid solution in MSIL which ended up as the obscure 241st comment, right before Jeff hid the comment thread to trim the bandwidth.
6) Jon is currently working on a solution in assembly and then binary.
See Scott, your boss wasn't thinking outside the box. You can't TEACH tall, but you can STRETCH tall.
http://orthoinfo.aaos.org/fact/thr_report.cfm?Thread_ID=310&topcategory=About+Orthopaedics
Think of all the good material he wasted when he didn't see the potential.
http://orthoinfo.aaos.org/fact/thr_report.cfm?Thread_ID=310&topcategory=About+Orthopaedics
Think of all the good material he wasted when he didn't see the potential.
these are always fun questions because they can show how someone approaches a problem. I view that as much more important than what the actual pseudo-code looks like. That and can they write (communicate well). I've seen a handful of programmers who punch out this *amazing* code, technically, but it is hard to maintain, there are usually minimal if any comments, and the developer sort of missed the point with the code because they didn't take the time to understand the larger problem they were trying to solve. Very little of what developers work on these days is done in a vacuum, and no matter how good they are, if they can't work in a team, then they aren't worth having around. [/end_manifesto] You can tell I feel pretty strongly about this ;)
"If I wanted a maintainer programmer, I would have interview for a COBOL job."
And you'd have lots to do. The other COBOL programmers are off writing the billion lines of 'new' COBOL each year.
http://www.linuxinsider.com/story/53842.html
However, slightly more on topic: I'd *much* rather have a thinker on my team than a language guru. While I think it's totally fair to ask someone to code up a quick algorithm I think it's much more indicative of their long term usefulness to see if they can understand the concepts in somebody elses code, apply some reasoning to things they don't know and have the ability to learn new things and communicate with the team. We change technologies constantly. If you can't adapt you WILL become the mantainance programmer. Or worse. That kind of person doesn't benefit my team as much as the one who can grasp new ideas and apply them.
Which I guess is what most people here are saying..
Oddly enough I was just discussing this topic at lunchtime (before I saw this post). My boss commented that were he to be asked if he 'knew php' his answer would likely be 'nope. But let me download it and give me an hour'.
The conversation started as a discussion about Knuths 'the art of computer programming' an how it should be required reading..
And you'd have lots to do. The other COBOL programmers are off writing the billion lines of 'new' COBOL each year.
http://www.linuxinsider.com/story/53842.html
However, slightly more on topic: I'd *much* rather have a thinker on my team than a language guru. While I think it's totally fair to ask someone to code up a quick algorithm I think it's much more indicative of their long term usefulness to see if they can understand the concepts in somebody elses code, apply some reasoning to things they don't know and have the ability to learn new things and communicate with the team. We change technologies constantly. If you can't adapt you WILL become the mantainance programmer. Or worse. That kind of person doesn't benefit my team as much as the one who can grasp new ideas and apply them.
Which I guess is what most people here are saying..
Oddly enough I was just discussing this topic at lunchtime (before I saw this post). My boss commented that were he to be asked if he 'knew php' his answer would likely be 'nope. But let me download it and give me an hour'.
The conversation started as a discussion about Knuths 'the art of computer programming' an how it should be required reading..
Scott, I thought about not responding, but had to clarify my comment on Jeff's blog, which I beleive has been misunderstood by many people (or maybe my point wasn't made clearly enough).
My comment; your response:
"However, I have never *once* used - or had call to use - recursion to solve a problem, since I learned about it at university."
"Statements like this are kind of dodgy as well. I don't know this individual, but based solely on this one sentence I would surmise they are either, rather young (i.e. recently out of school, maybe the last 5 years) or they've been writing the same general kind of code in their career."
I wrote the comment you're commenting on. It's plain true, I'm afraid. As I said in the original comment, I've not used recursion in the 10+ years I've been programming for a living.
Can I use recursion where necessary? Sure.
Can I recognise where recursion should be used? Sure.
I've seen one instance where recursion was needed, about two years ago, but it wasn't my job to write that code. I've not written a binary sort since Uni either - jeez what kind of crappy programmer am I??
Again, as I said in the comment - I have not had call to use recursion. And whilst I do write business software which solves business problems which could be thought of as broadly similar in nature, I've not been writing the same code for 10 years. I make it a personal ambition to learn and improve my code on a continual basis, which is one of the reasons I read blogs like yours. And I think I'm better than the majority of my peers in my code quality, at any company I've worked at (not to be too immodest).
To address another point you made:
"Saying that I have never used X since school either means you haven't been out of school long, or that X is a totally useless thing."
I don't agree. It's just that I don't solve the same sort of problems you do (very obviously). I write good code, and good apps to solve business problems. Just not problems that require recursion. That's certinaly not to say that I don't like it, wouldn't use it, or couldn't use it if the need arose.
The fact is that a) recursion, or any other programming construct is not useful in every single problem domain, and b) to say that if someone doesn't use recursion they don't know what they're doing or must be inexperienced is flaty untrue. (I don't level this at you, but mainly to the commenters on the related posts, for example on Jeff's blog.)
As I said in my original comment - simple tests like FizzBuzz prove only one thing: you can write solutions to simple tests like FizzBuzz. Big whoop. I agree that this test might (might) wheedle out the really crap applicants from your pile, but I would prefer to judge a developer's work-a-day code any time.
My comment; your response:
"However, I have never *once* used - or had call to use - recursion to solve a problem, since I learned about it at university."
"Statements like this are kind of dodgy as well. I don't know this individual, but based solely on this one sentence I would surmise they are either, rather young (i.e. recently out of school, maybe the last 5 years) or they've been writing the same general kind of code in their career."
I wrote the comment you're commenting on. It's plain true, I'm afraid. As I said in the original comment, I've not used recursion in the 10+ years I've been programming for a living.
Can I use recursion where necessary? Sure.
Can I recognise where recursion should be used? Sure.
I've seen one instance where recursion was needed, about two years ago, but it wasn't my job to write that code. I've not written a binary sort since Uni either - jeez what kind of crappy programmer am I??
Again, as I said in the comment - I have not had call to use recursion. And whilst I do write business software which solves business problems which could be thought of as broadly similar in nature, I've not been writing the same code for 10 years. I make it a personal ambition to learn and improve my code on a continual basis, which is one of the reasons I read blogs like yours. And I think I'm better than the majority of my peers in my code quality, at any company I've worked at (not to be too immodest).
To address another point you made:
"Saying that I have never used X since school either means you haven't been out of school long, or that X is a totally useless thing."
I don't agree. It's just that I don't solve the same sort of problems you do (very obviously). I write good code, and good apps to solve business problems. Just not problems that require recursion. That's certinaly not to say that I don't like it, wouldn't use it, or couldn't use it if the need arose.
The fact is that a) recursion, or any other programming construct is not useful in every single problem domain, and b) to say that if someone doesn't use recursion they don't know what they're doing or must be inexperienced is flaty untrue. (I don't level this at you, but mainly to the commenters on the related posts, for example on Jeff's blog.)
As I said in my original comment - simple tests like FizzBuzz prove only one thing: you can write solutions to simple tests like FizzBuzz. Big whoop. I agree that this test might (might) wheedle out the really crap applicants from your pile, but I would prefer to judge a developer's work-a-day code any time.
Good points and thanks for your comment, AndyToo.
Let me ask you thing, referring to the last paragraph in your comment here -
What should one do if the interviewee CAN'T write a solution to a simple test like FizzBuzz? Is the interview over?
Let me ask you thing, referring to the last paragraph in your comment here -
What should one do if the interviewee CAN'T write a solution to a simple test like FizzBuzz? Is the interview over?
My response to that last question - too often, the interview _is_ over at that point, but it's a mistake. It's a great opportunity to see how a developer proceeds when they don't know exactly what to do next, which is a very common spot for real life programmers to be in. Okay, you're stuck - why are you stuck, what do you do now that you're stuck?
Now, if they're stuck on FizzBuzz, I'd be worried, but I'd still want to know why and what's next from their point of view.
Now, if they're stuck on FizzBuzz, I'd be worried, but I'd still want to know why and what's next from their point of view.
AndyToo... It sounds as if you are missing the point of the FizzBuzz test. I don't care who can pass it, I care who can't pass it because I don't want them on my team. I wouldn't fail someone for a syntax error, heck, I wouldn't even care so much if they could at least write the answer in pseudo code. The point of the exercise is to see if they even have a very basic understanding of programming. Without that, there really isn't much more to discuss. In my book, if you can't grasp the usage of a basic loops and conditionals then you are not really a programmer.
I understand - nobody wants to be a "maintenance programmer", but when you get down to it, everyone's a maintenance programmer. I've yet to write a class that was bug free out of the gates or didn't need to be modified at some point in its lifetime (refactoring, bugs, changing requirements, yadda yadda) and hey look, suddenly I've fallen from blazing glorious new paths to lowly maintenance programming.
I'm not saying do away with having them write code (because I agree that you want to know that they have a clue what they're doing), I'm looking to avoid hiring write-only programmers. In my team, I've got folks who we can give tasks to do and they spend time walking through code until they hit fundamental roadblocks, at which point they'll ask questions that show me that they've done their homework before they get to me... and then there are the folks that ask me questions that Google or the bookshelf could have answered without wasting my time.
Once you know they can write their own code, what exactly is the harm in having them prove that they can read and understand your code as well?
I'm not saying do away with having them write code (because I agree that you want to know that they have a clue what they're doing), I'm looking to avoid hiring write-only programmers. In my team, I've got folks who we can give tasks to do and they spend time walking through code until they hit fundamental roadblocks, at which point they'll ask questions that show me that they've done their homework before they get to me... and then there are the folks that ask me questions that Google or the bookshelf could have answered without wasting my time.
Once you know they can write their own code, what exactly is the harm in having them prove that they can read and understand your code as well?
I think you missed the point on on people being stressed in interviews. I suffer from this myself and it isn't that I'm somehow "offended" or otherwise put out by being asked to write a code sample, on the contrary I am more then happy to do so, however, when in an interview situation (already stressful enough) to be asked to write code while someone sits over your shoulder and knowingly judges and your possible future at that company, can make even the least self conscious person edgy. When your in that situation, some people, such as myself, find that their mind goes blank, hands sweat, and thinking turns to molasses. Yet when they get on the job they can handle their responsibilities admirably. Some people are just naturally more nervous then others in interviews. It doesn't mean they are bad programmers, only perhaps that they are bad at interviews.
AndyToo: I cannot imagine a programmer working 10+ year without having call to use recursion. But maybe you are right; what problem domain do you work in? And can you give an example of where recursion would be valuable in a business programming setting (I've found many, one specifically in TSQL for a very common problem on the web. But I don't want to give it away...)
When I interviewed at MS in Redmond back in 98', I got stuck with a really tough problem - didn't have a clue on coding it "properly". I asked a lot of questions like Haacked suggested earlier. I didn't get that job but I figure it made an impression. What I did get was, "You're not what we had in mind for that job, but do you mind heading to Irving, TX for an interview with Enterprise Support division for SQL, etc?" I got an offer from that second interview - probably helped that I schooled a senior engineer on something I learned from the last interview he didn't know existed in DHCP discover packets..
Being able to think fast on your feet, learn from earlier mistakes, ask reasonable questions and focus on the problem space make up for a lack of distinct knowledge any day.
BTW - The company I actually went with instead of MS had me interviewing programmers on DAY 2 from the local University...
Go Figure!
Mark
Being able to think fast on your feet, learn from earlier mistakes, ask reasonable questions and focus on the problem space make up for a lack of distinct knowledge any day.
BTW - The company I actually went with instead of MS had me interviewing programmers on DAY 2 from the local University...
Go Figure!
Mark
I'm sure that everyone posting these solutions typed them directly into the message box in under 3 minutes without bothering to check it first with a compiler, right?
Apparently the point of all of this is not that the people they are interviewing can't program, it's that they can't program on a piece of paper under interview conditions without IntelliSense or access to a 5 second Google search to double check just the syntax of the modulus operator because they haven't had the need to use in the last three months.
And this would seem a valid argument... if we all programmed on sheets of paper in environments without IntelliSense and no internet access but obviously this hasn't been the case in a decade. If a company does its programming using "vi" or "edlin" in the middle of the Pacific Ocean with not Net access, then hey... maybe such interview techniques are valid. If not, then... eh... not so much.
Programmers have to keep a lot of stuff crammed in their brains. It's not like the old days when you just had to remember
a single language syntax. Now we've got a bazillion APIs and patterns and protocols to keep crammed in our heads so some brain-page-swapping is bound to take place and maybe the poor guy being interviewed just doesn't remember something trivial like how to format a float to 5 decimal places today because it isn't something he's had to do in the last year.
Give the poor slob a chance to look the thing up for goodness sake like he would if he was actually working for you rather than send him to a whiteboard to fumble around.
Why not just give the interviewee a problem, give him a computer, and give him five minutes and then see what you get. That seems much more reasonable... and respectful.
Apparently the point of all of this is not that the people they are interviewing can't program, it's that they can't program on a piece of paper under interview conditions without IntelliSense or access to a 5 second Google search to double check just the syntax of the modulus operator because they haven't had the need to use in the last three months.
And this would seem a valid argument... if we all programmed on sheets of paper in environments without IntelliSense and no internet access but obviously this hasn't been the case in a decade. If a company does its programming using "vi" or "edlin" in the middle of the Pacific Ocean with not Net access, then hey... maybe such interview techniques are valid. If not, then... eh... not so much.
Programmers have to keep a lot of stuff crammed in their brains. It's not like the old days when you just had to remember
a single language syntax. Now we've got a bazillion APIs and patterns and protocols to keep crammed in our heads so some brain-page-swapping is bound to take place and maybe the poor guy being interviewed just doesn't remember something trivial like how to format a float to 5 decimal places today because it isn't something he's had to do in the last year.
Give the poor slob a chance to look the thing up for goodness sake like he would if he was actually working for you rather than send him to a whiteboard to fumble around.
Why not just give the interviewee a problem, give him a computer, and give him five minutes and then see what you get. That seems much more reasonable... and respectful.
Scott: What should one do if the interviewee CAN'T write a solution to a simple test like FizzBuzz? Is the interview over?
Is the interview over? The career is over. Seriously. If I were interviewing a programmer who couldn't pass the FizzBuzz test, I'd switch into "career counselor" mode and suggest that they really ought to think about going back to school and choosing another profession. If they claimed to have a degree from an accredited program, I might give the program a piece of my mind, too, as there is some kind of fraud going on somewhere.
An you imagine going to a doctor who couldn't find a femur?
Is the interview over? The career is over. Seriously. If I were interviewing a programmer who couldn't pass the FizzBuzz test, I'd switch into "career counselor" mode and suggest that they really ought to think about going back to school and choosing another profession. If they claimed to have a degree from an accredited program, I might give the program a piece of my mind, too, as there is some kind of fraud going on somewhere.
An you imagine going to a doctor who couldn't find a femur?
# Hey, I'm a programmer
# -- so of course I'm going to solve the toy problem!
for i in range(1, 101):
fizz = ''
buzz = ''
if i % 3 == 0:
fizz = 'Fizz'
if i % 5 == 0:
buzz = 'Buzz'
if fizz == '' and buzz == '':
print i
else:
print '%s%s' % (fizz, buzz)
# -- so of course I'm going to solve the toy problem!
for i in range(1, 101):
fizz = ''
buzz = ''
if i % 3 == 0:
fizz = 'Fizz'
if i % 5 == 0:
buzz = 'Buzz'
if fizz == '' and buzz == '':
print i
else:
print '%s%s' % (fizz, buzz)
The problem here isn't that people are unable to solve the problem, because everyone who has replied has been able to (even the sarcastic comments make me think that they know how). The problem here is that people don't know how to do it in assembly. MOV on friends!
Recursion is great, but in normal languages, it's not really necessary, you can solve any problem without recursion. The problem a lot of developers have with recursion is that it is a bit more complex at first to grasp why it works, what backtracking is etc. Once you get it, it's easier to write code with recursion than without it. THough if you never reach that point, it's thus a mechanism which the developer always will try to avoid, even if s/he has to write pages and pages of extra code. So there's no real situation where you 'have to' use recursion, it just saves a lot of typing in most cases. :)
I find formulating code to test if someone is capable of doing what you want him/her to do rather unimportant. What matters is how this person thinks, can this person solve the problem behind the question? If yes, then you can make the step to see if that person can translate that solution to an executable format, but that's just a thing you can test once.
Programming isn't about typing in statements, it's about formulating the algorithms formed by the statements. A great programmer can formulate algorithms and solutions to problems without thinking in a specific programming language, because that's just implementation of the solution, i.o.w. the boring part which takes up a small part of the actual process to come to a working program.
That's also the humour in the posts with solutions to this tiny fizzbuzz question: it's completely irrelevant what code you provide, what matters is the solution in abstract form cooked up by YOU and the steps you came to that algorithm and solution.
I find formulating code to test if someone is capable of doing what you want him/her to do rather unimportant. What matters is how this person thinks, can this person solve the problem behind the question? If yes, then you can make the step to see if that person can translate that solution to an executable format, but that's just a thing you can test once.
Programming isn't about typing in statements, it's about formulating the algorithms formed by the statements. A great programmer can formulate algorithms and solutions to problems without thinking in a specific programming language, because that's just implementation of the solution, i.o.w. the boring part which takes up a small part of the actual process to come to a working program.
That's also the humour in the posts with solutions to this tiny fizzbuzz question: it's completely irrelevant what code you provide, what matters is the solution in abstract form cooked up by YOU and the steps you came to that algorithm and solution.
At my company, we require a candidate (who passes the phone tech and a full face-to-face interview) to do an exercise on the computer, which is based on the type of development we do here every single day. Maybe we should have them do the exercise before the face-to-face in order to weed them out faster, but it does help to get them more at ease before they dive into code.
Yet, we still have people here who think it's a bit harsh to make someone take a "test" to get the job. When I report that someone did poorly, I get the usual responses about "under stress", and "hard to write code at an interview", etc. But that's the kind of pressure we have to work under every day! If a candidate can't handle the pressure at the interview, do they really expect that if we skip the test, that we won't still be keeping them under the microscope when the actual job starts and we find out what they can really do?
We give the candidate about 45 minutes, and we really aren't strict about the time. Of course, we give them access to the Internet, and fully expect them to be looking things up when they're stuck. We even step into the room every 15 minutes or so to make sure they're not stuck for too long, and if they are, we help walk them through their thinking process. All of this helps us see 1) how they work under pressure, 2) what they do when they get stuck, 3) how they can communicate any issues -- and IF they even try to communicate any issues, 4) and how well they can work alone and with others.
I think the exercise is rather trivial, and I don't code day to day anymore. But in the years that we've given this exercise, only one person has ever completed it successfully (and they also completed a couple of bonus exercises). I am often very shocked. I'm usually appalled at the mediocrity in the field (but probably shouldn't be too surprised, since the barriers to entry are very low these days). But I continue to be amazed at how well some people come off during the interview stages, but can't get far at all with the exercise. It's often very disheartening when this happens, and it happens often, but we're better off finding out before making the hire.
Concerning "new development" vs. "maintenance"..."new development" is EXTREMELY rare these days. I've been in the field for over 22 years, and the VAST majority of development I've seen and done have been bug fixes and enhancements to existing systems. The exercise we give requires the candidate to take an existing ASP.NET app (we give them a choice of using C# or VB.NET), and to 1) fix the bugs to make it work as described in the spec and the sample finished version, and 2) to make enhancements to add new, and change the old functionality. 3) We also give them a simple IIS problem that most ASP.NET developers should be able to tackle. This gives us what I think is the most balanced approach for OUR specific business. There is no one right exercise. It must be customized to your company's needs and typical types of projects.
The other thing that blows my mind is how often we check the browser history after they're done and find how little some people even bother using the Internet as a resource, IF AT ALL -- and almost every candidate has gotten stuck on the problem. Unreal!
Yet, we still have people here who think it's a bit harsh to make someone take a "test" to get the job. When I report that someone did poorly, I get the usual responses about "under stress", and "hard to write code at an interview", etc. But that's the kind of pressure we have to work under every day! If a candidate can't handle the pressure at the interview, do they really expect that if we skip the test, that we won't still be keeping them under the microscope when the actual job starts and we find out what they can really do?
We give the candidate about 45 minutes, and we really aren't strict about the time. Of course, we give them access to the Internet, and fully expect them to be looking things up when they're stuck. We even step into the room every 15 minutes or so to make sure they're not stuck for too long, and if they are, we help walk them through their thinking process. All of this helps us see 1) how they work under pressure, 2) what they do when they get stuck, 3) how they can communicate any issues -- and IF they even try to communicate any issues, 4) and how well they can work alone and with others.
I think the exercise is rather trivial, and I don't code day to day anymore. But in the years that we've given this exercise, only one person has ever completed it successfully (and they also completed a couple of bonus exercises). I am often very shocked. I'm usually appalled at the mediocrity in the field (but probably shouldn't be too surprised, since the barriers to entry are very low these days). But I continue to be amazed at how well some people come off during the interview stages, but can't get far at all with the exercise. It's often very disheartening when this happens, and it happens often, but we're better off finding out before making the hire.
Concerning "new development" vs. "maintenance"..."new development" is EXTREMELY rare these days. I've been in the field for over 22 years, and the VAST majority of development I've seen and done have been bug fixes and enhancements to existing systems. The exercise we give requires the candidate to take an existing ASP.NET app (we give them a choice of using C# or VB.NET), and to 1) fix the bugs to make it work as described in the spec and the sample finished version, and 2) to make enhancements to add new, and change the old functionality. 3) We also give them a simple IIS problem that most ASP.NET developers should be able to tackle. This gives us what I think is the most balanced approach for OUR specific business. There is no one right exercise. It must be customized to your company's needs and typical types of projects.
The other thing that blows my mind is how often we check the browser history after they're done and find how little some people even bother using the Internet as a resource, IF AT ALL -- and almost every candidate has gotten stuck on the problem. Unreal!
To AndyToo: a good example for recursion in business software is filling a treecontrol recursively. You can do it in two ways: with recursion or without recursion, and the one with recursion is pretty simple and small. The thing is, in business apps, this is a common scenario, still I don't think a lot of business app writers use recursion for this trivial problem. That's ok, their code will also work, though with recursion it will be simpler to read, HOWEVER I have to admit, it's then thus only simpler for a person who really understands recursion. It's similar with the C# yield keyword. I've never ever had the need to use it and find the keyword awkward for readability. I therefore won't use it if I'm not forced to use it. People who understand the yield keyword 100% and love it, will use it whenever they can, and will find code with yield easy to read, though people who never used yield won't.
You can't teach people to be tall, it's true. On the other hand, you can make the population taller on average but you have to start several generations ago. Importantly, when filling the roster of your basektball team don't confuse people who wear stilts for those who are tall just because their heads are the same hight off the ground.
Similarly, when hiring into a programming team don't confuse people who happen to have "IT professional" jobs with programmers just because they both have something to do with building systems. Blunt an instrument as fizzbuzz is, it will atelas lets you distinguish those two groups.
Similarly, when hiring into a programming team don't confuse people who happen to have "IT professional" jobs with programmers just because they both have something to do with building systems. Blunt an instrument as fizzbuzz is, it will atelas lets you distinguish those two groups.
To Mark Freedman: If interview style pressure is the type of pressure you work under every day then please, drop your company name here so that I can be sure to avoid it like the plague. The workplace does not need to be a pressure cooker of stress and anxiety day and and day out and any company that makes it so, is a workplace to avoid with extreme prejudice!
on your testing excercise. While I can agree that some level is testing is necessary to guage how a prospect thinks, relying on it as the sole barometer of the quality of that prospect is absurd. What's even more amazing is that after all the good interview candidates you've had with only 1 who accomplished the test, it hasn't occured to you that maybe, just maybe the problem lies in your testing and how it's being done and not in the candidates themselves. That is what I find most "Unreal" about your tale, and not to be too rude or anything...frankly a little arrogant.
on your testing excercise. While I can agree that some level is testing is necessary to guage how a prospect thinks, relying on it as the sole barometer of the quality of that prospect is absurd. What's even more amazing is that after all the good interview candidates you've had with only 1 who accomplished the test, it hasn't occured to you that maybe, just maybe the problem lies in your testing and how it's being done and not in the candidates themselves. That is what I find most "Unreal" about your tale, and not to be too rude or anything...frankly a little arrogant.
Hi, Mark. I can see how you can consider my post a little arrogant. I can see how someone can feel that it's a lot arrogant. I didn't mean for it to come off like that, but I get what you're saying.
It's definitely true that our company isn't for everyone. It's been one of the fastest growing young companies in the country over the past several years, therefore, much of that pressure is due to the rapid growth of the business. Many of the employees there consider it a challenge. It always challenges me, and it's the best job I ever had. I've been there for seven years, and I'm always learning. I'm not saying that it's a pressure cooker -- but yes, there is often pressure, and we MUST be able to gauge how people would handle pressure.
I know very few, if any, developers that don't have some type of pressure in their job. "A complete lack of stress is called death" is a quote I heard somewhere.
I, myself, doubt that I would finish the test. We have hired several people who didn't finish it (I didn't say that a lack of completion is a failure -- those people were obviously on the right track, and we could tell that they knew how to approach the problem). But the real point is that some people are so far off -- not even looking in the right places -- that it appears that they just rehearsed the buzzwords and snowed us during the interview. Maybe I'm just frustrated by the group of people that we've interviewed. Maybe we've just had bad luck. Maybe all of the best people are staying put.
We do not rely on the test as the sole barometer; not at all. I didn't mean to imply that. My point is that some people come off so well on the face-to-face, but put them in front of a computer, and they look clueless; like they've never even seen Visual Studio. I admit that we are very strict about who we offer a job to. But those are the current requirements we have as a fast growing dot com. We need our team members to be self-starters who are ready to dive in from day one with limited technical guidance. In our company, we usually have just enough time to front-load business training and a system overview. It's worked quite well with the people we've hired in the past, and they were certainly up to the task.
It's definitely true that our company isn't for everyone. It's been one of the fastest growing young companies in the country over the past several years, therefore, much of that pressure is due to the rapid growth of the business. Many of the employees there consider it a challenge. It always challenges me, and it's the best job I ever had. I've been there for seven years, and I'm always learning. I'm not saying that it's a pressure cooker -- but yes, there is often pressure, and we MUST be able to gauge how people would handle pressure.
I know very few, if any, developers that don't have some type of pressure in their job. "A complete lack of stress is called death" is a quote I heard somewhere.
I, myself, doubt that I would finish the test. We have hired several people who didn't finish it (I didn't say that a lack of completion is a failure -- those people were obviously on the right track, and we could tell that they knew how to approach the problem). But the real point is that some people are so far off -- not even looking in the right places -- that it appears that they just rehearsed the buzzwords and snowed us during the interview. Maybe I'm just frustrated by the group of people that we've interviewed. Maybe we've just had bad luck. Maybe all of the best people are staying put.
We do not rely on the test as the sole barometer; not at all. I didn't mean to imply that. My point is that some people come off so well on the face-to-face, but put them in front of a computer, and they look clueless; like they've never even seen Visual Studio. I admit that we are very strict about who we offer a job to. But those are the current requirements we have as a fast growing dot com. We need our team members to be self-starters who are ready to dive in from day one with limited technical guidance. In our company, we usually have just enough time to front-load business training and a system overview. It's worked quite well with the people we've hired in the past, and they were certainly up to the task.
One more point, Mark -- I think you were the one who wrote the post where you said "It doesn't mean they are bad programmers, only perhaps that they are bad at interviews." I agree with that. We always take that into account. That's why we observe them closely every 15 minutes when we try to walk them through the pieces they get stuck at. No, we don't look over their shoulder. As I mentioned in my initial post, we leave the room for at least 15 minutes at a time, and we let them know that we'll come back to help them along if they're stuck. We also leave our phone numbers in case they need to call us before those intervals.
The candidates that we don't consider are those candidates who obviously don't even know what to look at next, even with a lot of prodding, hinting, and discussion about how they may approach the problem. We find the exercise a great tool, because we get to observe them trying to solve the problem, and how they make use of other resources such as other developers (us) and the Internet. The only thing we don't give them is a "life line" like in those game shows ;) It becomes extremely and painfully obvious when we find someone who is great at interviewing, but extremely lacking in implementation.
So, as a play on your wording, I'll make this point: "It doesn't mean they are good programmers, only perhaps that they are good at interviews."
The candidates that we don't consider are those candidates who obviously don't even know what to look at next, even with a lot of prodding, hinting, and discussion about how they may approach the problem. We find the exercise a great tool, because we get to observe them trying to solve the problem, and how they make use of other resources such as other developers (us) and the Internet. The only thing we don't give them is a "life line" like in those game shows ;) It becomes extremely and painfully obvious when we find someone who is great at interviewing, but extremely lacking in implementation.
So, as a play on your wording, I'll make this point: "It doesn't mean they are good programmers, only perhaps that they are good at interviews."
-> apeman said
>Bob Archer: And ? also works in Commodore 64 BASIC. Sweet...
Dude! So I provided a cross platform solution without even trying. Damn, I'm good!
>Bob Archer: And ? also works in Commodore 64 BASIC. Sweet...
Dude! So I provided a cross platform solution without even trying. Damn, I'm good!
Qwas said "Why not just give the interviewee a problem, give him a computer, and give him five minutes and then see what you get. That seems much more reasonable... and respectful."
Totally agreed and that's how we hire our programmers at our shop - except it is an hour long problem, not 5 minutes.
And in some ways, we are not too interested in the actual solution (cause it can't be solved in an hour, on purpose), but the thought process on how the candidate arrived at the solution. If we hear that the person started Google'ing for hints/answers within the first 30 seconds we left the room, s/he is already looking good in our eyes, because it has (mostly) all been done before and you can find the answer(s)on the internet (blogs, MSDN, etc.), even when you have been asked to code a web part in MOSS 2007, which is relatively new technology.
In my view FizzBuzz is a useless and futile exercise. Our pro services company builds MOSS 2007 and Commerce Server 2007 solutions using .NET FCL and C#. Showing me that you can or cannot write FizzBuzz proves nothing to me in the context of why we would hire you to write MOSS/CS .NET solutions.
What really amazes me are the comments to this and Jeff's blog and the nerves it struck. I thought as an industry, we were well beyond this sort of nonsense...
Totally agreed and that's how we hire our programmers at our shop - except it is an hour long problem, not 5 minutes.
And in some ways, we are not too interested in the actual solution (cause it can't be solved in an hour, on purpose), but the thought process on how the candidate arrived at the solution. If we hear that the person started Google'ing for hints/answers within the first 30 seconds we left the room, s/he is already looking good in our eyes, because it has (mostly) all been done before and you can find the answer(s)on the internet (blogs, MSDN, etc.), even when you have been asked to code a web part in MOSS 2007, which is relatively new technology.
In my view FizzBuzz is a useless and futile exercise. Our pro services company builds MOSS 2007 and Commerce Server 2007 solutions using .NET FCL and C#. Showing me that you can or cannot write FizzBuzz proves nothing to me in the context of why we would hire you to write MOSS/CS .NET solutions.
What really amazes me are the comments to this and Jeff's blog and the nerves it struck. I thought as an industry, we were well beyond this sort of nonsense...
Never in over 10 years have I been asked to write code in an interview. That would seem like a waste of time in my opinion... I mean, would I really be there in the first place if they were concerned about whether I could code up some FizzBuzz? I'm not above it, but it would actually be a red flag for me. I'd secretly wonder if they were micro-managing control freaks.
As others have said, the low level coding details are something that can easily be looked up - it's knowing "what are the right things to look up" that's important. It's the high level concepts that are often lacking.
A couple of questions I was asked last year while interviewing for an architect position were "what are some design considerations that go into making an application scalable?" and "describe the projects you've worked on that would qualify you to work on our system?". Those are open-ended enough to get the discussion going, and then more detailed questions followed to determine if I was just blowing smoke or really understood what made a component loosely coupled.
Also, especially in Portland, it's hard to not leave a people trail if you've worked for a few years (hiring manager asks developer "have you heard of this guy?"... developer says "yeah, he worked with so and so on project xyz"... manager calls so and so, and gets a green or red light)... so your interview is often just to make sure you're a nice guy who the other developers like, and who can communicate with non-techie people.
As others have said, the low level coding details are something that can easily be looked up - it's knowing "what are the right things to look up" that's important. It's the high level concepts that are often lacking.
A couple of questions I was asked last year while interviewing for an architect position were "what are some design considerations that go into making an application scalable?" and "describe the projects you've worked on that would qualify you to work on our system?". Those are open-ended enough to get the discussion going, and then more detailed questions followed to determine if I was just blowing smoke or really understood what made a component loosely coupled.
Also, especially in Portland, it's hard to not leave a people trail if you've worked for a few years (hiring manager asks developer "have you heard of this guy?"... developer says "yeah, he worked with so and so on project xyz"... manager calls so and so, and gets a green or red light)... so your interview is often just to make sure you're a nice guy who the other developers like, and who can communicate with non-techie people.
Comments are closed.
Ahh, old proverb say "Beware artisan who claims 20 year of experience, but really has one year of experience 20 times."
Grace and Peace.