Why Can't Programmers.. Program?

I was incredulous when I read this observation from Reginald Braithwaite:

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Notice from @riking:

Please put all solutions to FizzBuzz –here– instead of in this topic. Alternately, don’t do it at all - we’ve clearly had enough proof that it’s possible.

(Existing comments from before Discourse containing only solutions were moved there.)

*The original post by @Toepopper follows. *

Very very common, alas. I once interviewed a candidate for a VBA job (yes, you can stop booing for the peanut gallery) whom I asked to swap two variable contents without using a temp variable. It’s the standard a=a+b, b=a-b, a=a-b problem. His answer? Well, I can’t do it in VBA, but if you let me use Excel I can put the values in two cells and swap the cells’ contents using a third cell.

We hired the guy who said, well, “if they’re integers, then I’d do it by a=a|b, b=a^b, a=a^b. But I don’t know how to do it if they’re strings.”

I’ve been making a decent living from programming for over ten years, and if I may say so, I write some damn good code.

However, I have never once used - or had call to use - recursion to solve a problem, since I learned about it at university. Does this make me a bad programmer? Or is it simply that people program in different ways for different problem spheres?

I simply can’t believe that the other 199 people tested who can’t write a simple for…loop have no career as some kind of programmer ahead of them.
Does that mean that every one of those people who do program but don’t use (say) recursion is a bad programmer?

Or is it that you can’t rely on any one testing method (like writing simple programs) to prove either way that the person can program effectivley or not?

The most obvious way to decide - for me - is to run through these tests, emply the person you like the best and then look at the code they’ve produced after a week. Then you’ll know if they can do what you need.

The bottom line is, you can always learn to pass interview tests of any kind - that doesn’t mean you can program or not.


I think the use of recursion probably depends on the particular field that you code in.

As a web developer I also have very little cause to use it. The only time I use it is when I need to search through the file system.

Isn’t the code for that …

int main() { ExitPaperBag(); return 0; }

I’m not sure … copied it from somewhere :stuck_out_tongue:

There’s a cynical voice in my head that says “because no-one has ever asked them to”.

Where I work we spend a long time looking before we hire someone, because it’s so hard to find them. We use a walk-through test that has a sequence of “questions” leading to a simple app and are willing to argue the toss (I was hired despite arguing that the test had significant flaws: “why would I do that? That’s stupid because…” when they wanted me to code a solution that led to the next question).

I fear that any take-home or pre-interview component would lead to plagarism or “helped” solutions, so we make candidates perform in front of us.

That’s got our ratio up to 3/4 good hires.

shenpen - Unfortunately that wouldn’t be a valid solution (in VBScript) because WScript.echo adds a CRLF. In another language it might work though.

Sorry, but if someone were to ask me how to swap two variables w/o a temp variable I’d ask them to give me a good reason why.

Not being able to answer that particular question certainly doesn’t preclude someone from being a good programmer. That’d be like asking a C# programmer how to do modulo 16 using only a logical and. Why the hell would they need to know that, and how does that help you determine that they understand the ASP.Net framework, etc.?

1 Like

shenpen: As you point out, your solution doesn’t handle line breaks. It also doesn’t print out the original number!

shenpen, for shame. Read the spec again.

I don’t think I’ve ever interviewed a programmer quite that bad, but I did have a conversation with a contractor I was replacing once: I’d introduced a class into the monster spreadsheet he’d been maintaining and he looked at it and remarked “I wish I knew how to do that”. He was picking up about GBP400 a day (call it about $650 at that time) for this.

As I’m about to start looking for a programmer I shall be able to implement my long-cherished plan of asking candidates to submit a page or so of what they consider to be “good code”. I don’t mind if they wrote it or not, I want to see if we agree on the look of “goodness”. If we get that far, I can find out if we agree on why it’s good.

This is nasty but it’s technically a one-liner:

1.upto(100) { |n| puts n % 3 == 0 ? n % 5 == 0 ? “fizzbuzz” : “buzz” : n % 5 == 0 ? “fizz” : n }

WOW! (and not the vista kind).

I can’t believe there are people out there applying for jobs in software that cannot write a fizzbuzz program.

It’s true that knowing how to do modulo 16 using AND doesn’t relate to understanding ASP.Net.

On the other hand, do you want an ASP.Net technician, or someone who understands the theory behind it? Can you really call the candidate who only knows ASP.Net, but nothing about a basic logic a programmer (or a computer scientist, or a software engineer, or a coder), or is he just some guy who knows ASP.Net?

James: it’s amusing to me that any reference to a programming problem-- in this case, FizzBuzz-- immediately prompts developers to feverishly begin posting solutions.

  1. The whole point of the article is about WHY we have to ask people to write FizzBuzz. The mechanical part of writing and solving FizzBuzz is irrelevant.

  2. Any programmer who cares enough to read programming blogs is already far beyond such a simple problem. It’s the ones we can’t rerach-- the programmers who don’t read anything-- that we have to give the FizzBuzz test to.

But it’s OK, I mean no offense. It’s just funny. I know how software developers’ minds work. :slight_smile:

My point is that what you’re asking for isn’t “domain knowledge” strictly speaking. Using an XOR to swap two variables w/o a temp variable is only really useful when memory is expensive (embedded programming, et al). If you’re not interviewing for an embedded programmer why are you worried about it?

Same with the modulo trick. The first time I ever encountered that I was writing a Perlin Noise Generator based off of someone else’s work. Outside of routines that need to be highly optimized there’s no reason for it.

Are you trying to hire an ASP.Net programmer or an embedded systems programmer? Granted, the XOR trick is pretty well known, but not knowing it off the top of your head says nothing about your abilities as a programmer (whereas the fizzbuzz example does).

No one can know everything. I would expect that type of attitude from a non-IT person, but not someone who is interviewing programmers.

Ha ha! I see what you’re saying Jeff.

I hope I didn’t come across as feverish though. I sincerely thought that a solution may be of interest to someone who couldn’t write one themselves.

Perhaps you have readers who aspire to be programmers but are still learning?

Perhaps a future Google search for “FizzBuzz” will bring back this page? (And the Googler might be after the solution).

Interestingly, the use of a technical test in interviews can actually work both ways. In my recent hunt for a new job I automatically turned down any vacancy where I was not given a technical test. My reasoning behind that is that I know I can program, but do I want to work with other programmers who haven’t been tested?

The harder the test I was given, the more excited I was about the vacancy.

If anyone out there is looking for a new job I urge you to bear that in mind.

Instead of using recursion, it’s often faster to use a Stack.

There’s always ‘Survivor for Developers’ for those who don’t make the cut.


I once heard of a development group where every three months a vote was taken and the bottom ten percent of the group were replaced by newcomers. It sounded a bit like Survivor - Development.

A common immediate reaction is to assume that it would become a popularity contest but that wasn’t the case. The group had very specific KPI’s to achieve and those that helped achieve those goals were well respected in the group, regardless of “popularity”. Really anti-social folk tended to get removed though. (In our company, one of the tests we use during the hiring phase is lovingly called the “no axe murderers” test. I think we have Chris Hewitt to thank for that awesome terminology.)

When working as a manager, I always felt that Australian laws made it very difficult to remove the dead-wood out of teams. Clearly, having a tribal council and an eviction for certain development groups wouldn’t work, but on this Australia Day public holiday, ask yourself this: If your team had a vote yesterday, would you still have a job on Monday? If not, do something about that now.

At the end of each week, you vote the worst dev off the island.

It’s just performance anxiety.
Most people are terrified/stressed out during interviews.
Not “Can you X?” -
“Can you X whilst terrified?”


AndyToo wrote:
“However, I have never once used - or had call to use - recursion to solve a problem, since I learned about it at university. Does this make me a bad programmer? Or is it simply that people program in different ways for different problem spheres?”

i think you missed the point: if ou were explicitly tasked to write a algorithm using recursion, would you be able to do it ? would you be able to recognise the use of recursion while reading someone else code ? and most important, the one i struggled teaching to newly hired guys and which most people dont learn at school: do you understand the principles behind recursion ?

every good programmer knows there are plenty of ways to avoid recursion, but being able to avoid it implies that you know what recursion is.

and that is the point of such a question during an interview.

Damnd thing took me three minutes to write in php. I am getting slower with old age :wink:

if ($x/3 == floor($x/3) … and so on.