The Surprising Number of Programmers Who Can’t Program

I've known some very talented developers who could never pass a standard software engineering interview but if you give them a week to create a project they'll have something to you that works.

I've also known some very talented interviewers who have never completed a project from start to finish.

I think we just need to all agree that interviewing is hard for Software Engineering and no one has a good solution for it yet. I am constantly on the lookout for someone who finds something that is both effective and doesn't waste a ton of time for both the interviewer and interviewee.

Once we'd actually started using it, though, we found it filtered between 20-30% of our applicant pool, even when we let them use literally any language they desired, presumably their strongest.

However, it usually only filtered fresh grads (CS students from top-10 schools). Those with previous work experience almost never had a problem.

I once worked with someone who refused to use loops. He would write everything out... Thousands of copy-pasted lines with incrementing values... He'd often insist that things only deal with certain numbers of inputs for this reason. E.g. he had a bulk data transfer tool that would only transfer 10 items. If you had less than ten, you had to make dummy files. If you had more than 10, you were supposed to use it multiple times. He was also considered "a key technical leader", and constantly lauded by management. He was in his late 20's and had a CS degree from a relatively well-known school. I'm a geologist, so I was constantly told I "just didn't know anything about programming" when I'd ask why. (I suspect he thought it was an optimization, but he never explained.)

This was at a company that's a household name (though not a tech company). I suppose the moral of the story is to be careful about assuming that experience implies a certain level of competence.

EDIT: Contrary to what some believe, there is no programmer who you simply hand requirements to and then they take those requirements to a dark room, produce programs that fulfill those requirements, and then reappear and hand you the programs, all in silence without looking you in the eye. Programmers need to be able to communicate about the code they're writing to collect requirements, explain problems, etc., and if social anxiety keeps them from doing that, social anxiety keeps them from doing their job.

No one screens for understanding complex business domains, breaking risky big scope tasks down into iterative low risk steps, leading meetings / conversations where you have to rethink complex tech requirements into non-technical speak.

So, when stating "can't do FizzBuzz in interview" I think there are two meanings: (1) Candidate attempts to do it, writes some code in language X with some (many) syntax errors and some logic errors and (2) Cannot do anything at all, i.e. candidate there's no response and the onscreen cursor does not move (usually this is a phone interview). My experience with candidates I've seen is that the ratio of (1) to (2) is about equal!

Depending on the number and the of errors, (1) could be worrisome but the issue that people generally bring up in discussions on FizzBuzz is the utter incredulity of (2).

I'm mechanically challenged and have never changed a tire, yet , if asked to do so, will make some movements that are roughly aligned with the goal, albeit may be laughable to more knowledgeable people. Ditto for cooking a simple dish, e.g. spaghetti. I think this residual knowledge is acquired by osmosis through being around people (or watching TV) doing the task.

So, the most unnerving aspect of (2) to me is that it shows that the candidate does not even has this residual knowledge about programming.

Those people who couldn't program their way out of a paper bag in the first interview probably went on to solve whatever issue it is they were having that day (nerves, not ever having heard of modulo etc) and subsequently get more practiced by at least the 3rd interview. All of a sudden they can magically program.

I just don't buy the premise that these people can't program, get rejected from every interview, give up and drop out of industry.

I'd say the vast majority of them get jobs. And you're hiring filter can't calibrate for how the previous interviews have set the current candidate up for your interview.

If you could be a fly on the wall for every interview the candidate you just hired had done, there would likely be some in which you would have assessed "this person isn't capable of doing the job".

The signal/noise ratio in hiring is abysmal.

She was trying to run a C program she'd created, but it wouldn't run. I asked if she'd compiled it. She asked what a compiler was.

How can a person could survive in an office where C was the main language, and be taking courses that assumed familiarity with C, and still not know what a compiler is?

Turned out she was very skilled at taking credit for other people's work.

This is so true. IME, less than 50% of applicants can even get close. Mostly due to not remembering or even knowing about the modulo operator or a suitable workaround.

  ------------------

  def alpha(n):
      if(n <= 1):
          return n
      else:
          return(alpha(n-1) + alpha(n-2))

  what is alpha(5)?
  -----------------

I think a huge crutch for a lot of people is the immediate feedback loop execution gives you. Rather than truly understand the api we’re using, I think there’s sometimes a tendency for programmers to just skim, try a function call, and see what the repl/executable or w/e does, and to roll with that. While this works for getting things done it doesn’t really improve your understanding. I think practicing programming without the feedback loops the computer provides, e.g. based on documentation and reasoning alone, is a great way to become better and more disciplined. You can do this with pseudocode, whiteboards, or even with actual languages, forcing yourself to write complete programs/features before turning to the repl instead of a piecemeal write then verify approach.

I work well under pressure. I generally have no issues with speaking in public or performing; I majored in music in college. My programming skills have lots of room for improvement, but that hasn’t stopped me from writing lots of useful, maintainable, performant code.

It sucked to fail at FizzBuzz. I’ve been working at my algorithms and syntax, but also trying to code in front of others as much as possible.

With quotes like:

> So, as someone who spends maybe 20% of their time hiring, it’s still a very effective screen. You wouldn’t believe how many people can’t do it. People at big companies, respected places. It’s surprising.

Shouldn’t people start questioning the validity of their method?

There's also nuance to the "fizzBuzz" thing that people always leave out when they say that developers can't do "a simple fizzBuzz". Things like => It needs to be done on a whiteboard w/o syntax errors, they give FizzBuzz a significant variation, a requirement is slipped in to have fizzBuzz print on the same line when 15s come up, tons of things that make "a simple fizzBuzz" not so simple to pass if people aren't paying attention.

Gun to their head, IDE in hand, and stack overflow at their beckon, the vast majority of those programmers wouldn't have a problem stringing together fizzBuzz... but thats not really the question being asked in an interview now is it?

It is incorrect to say that there are a surprising number of programmers who can't program something as simple as FizzBuzz. The vast, vast, vast majority of working programmers have no trouble with such ridiculously simple toy problems.

However, although the overall proportion of self-identified programmers who can't program FizzBuzz is very, very small, the proportion of job applicants who can't program FizzBuzz is surprisingly large.

The entirety of the "surprise" as originally described was that the percentage is so out-of-whack. But once you think about it, it is not so difficult to understand why this may be so.

Competent programmers spend most of their careers working, not interviewing. If they are looking for a job, they tend to only go to a few interviews. Whereas, incompetent programmers spend more time looking for jobs, and when they are looking, they tend to apply over and over and over again to job after job after job.

So every company that has an opening gets "spammed" with the same couple of hundred applications from the same people the are applying for job after job after job. And many of them can't program FizzBuzz.

Whereas, the few competent people looking for a job tend to get an interview or two through referrals, then get an offer, accept it, and they are back in the workforce. But the couple of hundred applicants who can't program FizzBuzz shoulder grimly on, applying for the next job opening they find.

The net result is that if you have a job opening, you might have to filter out 90 or 95% of the applicants as "no-hopers," but that does not mean that 90% or even 9% or even 0.9% of programmers cannot program FizzBuzz.

TL;DR: The sample of programmers applying for a job is not representative of the set of all programmers, not even close.

Is that a bad thing? Probably. Computers are, at their base, imperative. So it's important to have a grasp on that way of thinking. But does it mean these people who've held "programming" jobs are frauds who don't know how to program at all? Not necessarily, I don't think.

I've seen the tech tests we receive from potential candidates and they are for the most part appaling. Our technical test is incredibly simple as well and they can do it at home in their own time.

Imagine something as simple as write a console app where you have a class that represents an Account. Write a function to debit and credit an amount that value and have a property to return the balance and a property to show if the value is negative.

The amount of code we see that looks something like:

    public class Account
    {
        public decimal Balance { get; set; }
        public bool IsNegative { get; set; }
        public void Debit(decimal amount)
        {
           Balance = Balance - amount;
           if(Balance < 0)
             IsNegative = true;
        }

        public void Credit(decimal amount)
        {
           Balance = Balance + amount;
           if(Balance >= 0)
             IsNegative = false;
        }
    }

I've wanted something harder for a while as a filter and we changed the test to write a very basic WEB API. The tests you get back are equally hopeless.

When you finally get a test that looks somewhat acceptable and they get an interview, they invariably are awful in the interview if you ask them anything other than the most basic of questions.

We are still looking. Getting someone you can give a problem to and they can't be left alone for a reasonable period of time, with minimum of hand holding, and they will come back with a working, implemented solution is so hard.

If these programmers that can't program drop out of the industry, then great. Maybe we will eventually raise the bar for what it means to be a programmer that we will get some decent software.

My theory is that coding is kind of like carrying a tune in music - either you have it or you don't. It's not an intelligence issue or a matter of education. These were bright folks. There is a mysterious innate ability that you must have to begin with, and some just don't.

My theory is that I'm the last of a generation of developers who learned to program without the Internet. I started learning QBasic when I was 8 and progressed through C++, Perl and .NET. Back then you HAD to learn to break problems down and use logic to troubleshoot. You couldn't just Google the problem.

Google and StackOverflow are great resources but you have to understand how to approach and break down problems if you ever want to be a good developer.

Either you:

1. Use modulo 2

2. Bitwise AND with 1

3. Divide as x and check if floor(x) == x

4. Swap variables

And probably there are other ways as well. I have just disproven myself I think.

All that said, I think you better measure a programmer/developer by asking some questions. Knowing syntax is the last step. But knowing how to break a problem up and which approaches to take in solving it, especially if there are constraints stated, is far more interesting. It's basically like asking the programmer to describe the program they would write.

Let's say the problem is, "Find the first 1000 prime numbers." The solution is less than 10 lines of code in most languages, but there's plenty to talk about.

I(nterviewer): How would you approach this problem?

C(andidate): Can I use the "prime" Ruby gem?

I: Well, it's good that you know it exists, but let's assume you can't.

C: I first need to define a function that, given a number, will return if the number is a prime.

C: Then I need to loop 1000 times, checking each successive integer (starting from 1) with the is_prime?() function. If it's prime, I print it.

C: Then I increment to the next integer and return to the top of the loop.

I: How did you determine if the number was prime?

C: The simple approach is just to loop from 2 to n-1 (the number we are checking), testing to find out if the number is evenly divisible by the loop index. If it is evenly divisible, then it is not prime. Otherwise, it is prime.

I: Great. What if I asked for the first million primes? Is there anything you would do differently?

C: I would improve the is_prime? algorithm. Blah blah blah, go from 2 to n/2 (or is it square root of n?) Etc. And if that was still too slow, I would research efficient prime algorithms and implement one.

This will tell you if someone can program - even if they have never typed on a keyboard. Programming isn't about typing, it's about being able to define the steps needed to solve a problem.

https://en.wikipedia.org/wiki/Modular_arithmetic

I won't comment on whether it is a good or bad thing that one can consider oneself a computer programmer† without being cognizant of modular arithmetic.

†to the degree that one is applying to be paid for it.

I’ve been a programmer for years! Why can’t you just believe me!?

Is FizzBuzz done with the benefit of Google?

I ask this because, while the program is straightforward, different languages have different division functions, and you want to make sure you have the one with a remainder.

You also want to get the OR and AND operator right. (Is it "or", "|", "||"?)

Now, I've used all these many times, but in an interview, you may just forget for whatever reason. I don't think I would, but I imagine someone competent could.

Like DHH, for instance:

https://twitter.com/dhh/status/834146806594433025

Or curated here:

https://theoutline.com/post/1166/programmers-are-confessing-...

Anecdotally, i recently became semi_obsessed with operating systems and OS development.I tried to pick up C wanting to do some kernel development on NetBSD and thought it would be easy, given the familiar syntax, u just needed to learn pointer logic/ arithmetic. I was finally defeated after trying to write a program with multidimensional arrays and working with them decayed down to pointers. At the same time, though, I need a new job asap, so I've given up on the interesting stuff and am back to learning stuff for employability reasons only

I had to program for eng 101, engineering 280 mechatronics, and our senior design.

I'm not a programmer by degree, but I was often the only one in group projects that understood what needed to get done.

I don't know what I missed out on. I've wrote AI since college and created embedded systems.

Programming feels unlimited.

But what don't I know? Security? Faster algorithms? I don't know what I don't know.

1.upto(100) do |i|

  if i % 5 == 0 and i % 3 == 0

    puts "FizzBuzz"

  elsif i % 5 == 0

    puts "Buzz"

  elsif i % 3 == 0

    puts "Fizz"

  else

    puts i

  end