I noticed most of the sample code submitted does not correctly handle the case of the number 53. FizzBuzz usually requires you to check not only whether a given number is divisible by 3 or 5, but also whether it contains a 3 or 5.
In my opinion, a good programmer tries to first make sure they have properly defined the problem, try to devise a proper solution, perhaps considering several options and then picking the best one, do some testing, THEN implement it.
I suppose if they are a junior programmer or fresh out of college they might not deserve to get fired for acting like this. However, this would assume that someone who knows what they are doing has to double check all their work anyways, which usually means that they are pretty much useless anyhow.
I don’t think you can place the blame fully on programmers, I personally think the main problem lies with the system that programs are often trapped into. Most programmers will come out of university having just completed a very enthralling 3 or 4 years of high level computer science studies, they have just finished an amazing final year project and they are ready to take on the world and become the next Zuckerberg. But what always happens? They end up getting hired in some graduate scheme and promised an amazing learning experience and a chance to work on the greatest projects, yet most often they end up get thrown into horrible projects and given miniscule pathetic roles that they cannot ever possibly grow in. They struggle with that for 3-5 years, and by the time they’re ready to go and finally take on that great role they always wanted they get thrown back by the fact that because they ended up spending the last 3-5 years doing crappy jobs, they forgot the basics of programming, they have become corporate software engineers.
Indeed, these corporate software engineers will be good doing focused and well outlined jobs that are often part of a bigger and well constructed application, but what they cannot do is start something on their own, building from scratch, and this is their pitful, they’re relying too much on what’s there and not looking outside of their crappy JIRA user story to see the bigger picture!
“Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.”
Do you have no memory of what it was like to interview for jobs and take coding tests?
We are programmers, not novelists. I have never met a programmer who could code worth a shit on paper with a pencil. Even ignoring that the vast majority of people are really bad at interviews and are operating at 10% during one, coders do not have good handwriting. And all the muscle memory and situational memory is completely gone when you hand us a pencil and a blank piece of paper. Add to that that this is all during an interview, and as programmers we have no idea how do handwriting, and obviously most fail.
@jonathonwisnosk If one needs a keyboard to conceive of the concepts one needs to write FizzBuzz, that one is a code monkey, not a programmer. A lot of code monkeys still get jobs, but you don’t want your Senior Programmer to struggle with FizzBuzz. Look at @Ivan_Teoh’s python example. That is easy to read and easy to write, with pencil and paper. If a candidate can’t do that much at 10%, but another one comes along who can, guess who gets the job? And it’s not a matter of “good” handwriting, it’s a matter of just writing it down.
Once again, if your ability to type out FizzBuzz is all in how your fingers remember which keys to press to make the computer actually do something, rather than in your mind’s ability to conceptualize the problem and dig into your basic language knowledge to rapidly prototype a solution, then you are not a programmer, you are a code monkey.
the problem I think is that the one that does gets it is far more likely be to capable of that feat by just being better at unrelated skills like communication, interviews, handwriting.
I agree that FizzBuzz is ridiculously easy to conceptualise, but in the circumstances anything can become impossible and error prone. And even if they have the concept down pat they could still descend into internal hysterics when trying to remember how to start a self running class, or if “Print” in some language automatically adds a newline or not.
And all of this while at an interview, being told to use a pen and paper, and without internet access. Which I would consider far more like the scenario of being charged by a large ferocious grisly bear, than the scenario of programming in an office setting.
I am not saying I have a better way of doing the interview, I am just saying that it is not so much that 99% of coders are too stupid to understand FizzBuzz, it is that 99% of coders are shy introverts who will quite possibly fail any interview you give them.
I’m not so sure that communication, interviews, and handwriting are that big of a factor here. I don’t think handwriting is a factor at all. In terms of communication, you were given a set of instructions that could not be more clearer. Maybe interview skills will cause you to step back and gather yourself before writing down the solution, but like you said, FizzBuzz is so ridiculously easy to conceptualise, that prospective programmers should just be able to do it.
There really shouldn’t be much thinking to this problem anyway. A prospective programmer really only needs to remember loops and the modulus operator, the very basics. If that programmer needs internet access for something so trivial, there is no hope. Programming isn’t just putting code to editor. It’s knowing that you will eventually mess up to the point where you will put yourself in tight circumstances, but instead of finding the problem at hand impossible or error prone, you find a solution. If the prospective programmer crumbles on pressure, then the programmer is simply a coder, not a programmer. Coders obviously still find jobs, but they definitely should not be calling themselves Senior Programmers.
As @Inheadkay mentioned, “they will be good doing focused and well outlined jobs that are often part of a bigger and well constructed application, but what they cannot do is start something on their own”. They can certainly google a solution to an existing problem, but asked to do something completely unexpected, they will give you the deer in the headlights look.
The fact is that there are a lot of programmers out there who can’t program. Maybe not 99%, but a large enough chunk to be noticed. What should be discussed is what can be done about it. Instead of saying they are too stupid to understand, maybe we should say they don’t have enough experience with actual programming, and put new programmers through internships where they will learn the skills they need to be successful in the industry.
There’s a lot of cruft in any field where there is money to be made. Simply everyone wants a piece. Go check out Wall Street. The impostors far outnumber the competent and connected. Not very interesting.
What I do find interesting is how narrowly focused are the brain teasers that interviewers often ask. Recursion? Why is something so rare (and so often overzealously misused) being regarded with such reverence? I like the questions where they ask how do you do this without using recursion? Or they simply don’t tell you that a non-recursive solution is more efficient and see if you can figure it out.
Also, I find the pissing contests in this thread extremely amusing.
I’m a programmer in russia, i have strong mathematic and computer scines degree.
I write system in PHP language for avla and whatever ticket sales. My system produces much money for company.
My problem is - not enough english language skills to migrate. (i think so and went to courses)
1st problem i leave in Russia and have only less than 2000 dollars salary per month.
So, maybe bosses just looks for good programmers in wrong places? I think i’m good and i need work visa (that’s all) to make money for your buiseness (for better salary of course).
At current position and in current country i feel discomfort. And i just read this post about coders who can’t code, and this stupid peple leave in better place with double salary that mine.
What’s wrong with world…
Sorry about my english, i write it all by myself without checking with translator.
You’re absolute right. Let’s put the petty hubris aside. I think we ought to be a little skeptical here, not just of the claims being made, but likewise of the kinds of questions asked during interviews and the ways they’re asked.
First of all, phone interviews or interviews involving coding in a span of a few minutes is generally a terrible idea. While for really simple programs this isn’t much of a problem (the kind where you just have to find a word count in a string or something), for problems where you need a little focus, lots of programmers can’t perform while there’s someone peering over their shoulders or on the other end of the line with them, observing them like a show dog. It’s an artificial situation and it stupidly selects out people who often can put the phone down and produce a solution very quickly right after the phone interview. You’re not applying to be a spy or some guy who needs to write code with a gun pointed at your head.
Personally, I am in favor of having a phone interview just to have a discussion with the interviewee, ask about some work they’ve done in the past, that sort of thing. As far as the technical interview, coding assignments are a better option. Make it a larger assignment than one given over the phone. You want to see how they program in the wild in a realistic setting. Some of the worst code I’ve ever seen was written by people who are great interviewers (many of these are at a certain company we all know that shall not be named). We’re really failing here and part of it point to a lack of common sense and empathy on the part of hiring staff.
Secondly, the questions asked during many interviews aren’t even close to the kinds of problems you really solve as a programmer. Most of it is API plumbing and actually quite boring, relying more on familiarity with particular technologies more than “clever” ways of doing things. As Andy says, recursion seems to be a favorite among interviewers. I personally like those problems, but I have never come across a recursive solution in the wild and so people have no practice with such problems (and you really need practice). There are a lot of reasons: they’re usually unnecessary, they can be very inefficient in many languages such as those lacking TCO or ones where there are limits on the call stack, and in a world where OO dominates, an essentially functional solution can’t or shouldn’t even be used. Certain languages actually discourage recursive solutions an make use of idioms that are anything but.
Last, I’ve not only never come across a question as simple as the ones given above, but I’ve never heard of anyone not being able to loop over something. I just don’t believe it. I really think someone is making things up to get attention.
The problem it solves is filtering out the people who literally do not know how to program, they just applied for the job because it sounded nice. Or they have delusions of non-zero competency. (Not to say they can never learn, but still.)
Going one level deeper, where are all these people coming from? The answer is obvious in retrospect - they “stay around”. They keep applying for more jobs, not understanding that the problem is themselves too slow to shrink the size of the group.
I cannot believe the assertion made in this post. If a CS graduate cannot code a simple for loop during an interview, some thing else is at work here. He is clearly under enormous stress, the stress of the interview. May be this is his first interview? Make your candidates feel at home before letting them code anything. Coding should never be the first round.
Do you make your programmers write programs in front of you, to make sure they don’t plagiarize or get “help?” No? Why not?
Sounds like maybe your test isn’t a realistic test of what you’re looking for, but rather just another irritating hoop for the trained monkey to jump through. If you want to test a programmer’s ability to write a program, have them write a program, using tools and an environment they’re comfortable in. Because otherwise, what are you really testing?
Getting a degree (bachelors, masters, or PhD) in Computer Science or related fields has little to do with programming. Sure, the odds are that someone in pursuit of a degree in these fields will have to do some programming at some point, but most of the time is spent on non-programming activities. In fact, I can say that when I was getting my degree that most of my classes had nothing to do with programming. Programmers are generally the least experienced people in the IT department of any company I’ve worked for, which I attribute to the fact that most people HATE programming and so they get out of it as soon as possible. It’s HARD! It’s PAINSTAKING! It has DELIVERABLES! And those deliverables actually have to WORK! So programming is viewed as something to get away from rather than something to “do”. (And yes, at age 57 I still write software for a living. Too stupid to take the easy way out, I guess…).
RE: swapping two variables without a temp variable. I dunno, I’ve been programming for thirty years and this might trip me up. The temp variable is definitely the most efficient and correct way to do this, and I don’t think there’s any real world case where addition and subtraction or XORing will be a win. Like the guy you hired, I would also think about different types of variables. However, if you didn’t specify that a and b were integers, I’d assume you were looking for a generic solution, something like this:
template void swap ( T& a, T& b )
{
T c(a); a=b; b=c;
}
So IMO, this isn’t a great question to ask during an interview. It’s contrived and doesn’t relate to actual engineering problems. JMO
I strongly disagree with this. I come from database world and back when I was looking for job I was asked these stupid questions. Like do recursion in sql. Lol haha. My answer was “When you do recursion in sql you are doing something wrong”.
Swapping two variables. Even in this discussion I see people writing some ridiculous code full of errors. Only right answer is to swap variable names. Or also why on Earth would you ever do such horrible and pointless thing?
Or when I was asked by someone to write pivot table in MDX. Run awayyyyy.
Biggest problem is that most of these people know how to code atleast in their own way. But they have no idea what problem they are solving.
