Programmer aptitude?

The 1960s were characterized by a perpetual “crisis” in the supply of computer programmers.  The computer industry was expanding rapidly; the significance of software was becoming ever more apparent; and good programmers were hard to find. The central assumption  at the time was that programming ability was an innate rather than a learned ability, something to be identified rather than instilled. Good programming was believed to be dependent on uniquely qualified individuals, and that what defined these uniquely individuals was some indescribable, impalpable quality — a “twinkle in the eye,” an “indefinable enthusiasm,” or what one interviewer described as “the programming bug that meant … we’re going to take a chance on him despite his background.”

In order to identify the members of the special breed of people who might make for a good programmer, many firms turned to aptitude testing.  Many of these tests emphasized logical or mathematical puzzles: “Creativity is a major attribute of technically oriented people,” suggested one advocated of such testing. “Look for those who like intellectual challenge rather than interpersonal relations or managerial decision-making. Look for the chess player, the solver of mathematical puzzles.”

The most popular of these aptitude tests was the IBM Programmer Aptitude Test (PAT).  By 1962 an estimated eighty percent of all businesses used some form of aptitude test when hiring programmers, and half of these used the IBM PAT.

Although the use of such tests was popular (see Chapter 3, Chess-players, Music-lovers, and Mathematicians), the were also widely criticized.  The focus on mathematical trivia, logic puzzles, and word games, for example, did not allow for any more nuanced or meaningful or context-specific problem solving. By the late 1960s, the widespread use of such tests had become something of a joke, as this Datamation editorial cartoon illustrates.


So why did these puzzle tests continue to be used (including to this day)?  In part, despite their flaws, they were the best (only?) tool available for processing large pools of programmer candidates.  In the absence of some shared understanding of what made a good programmer good, they were at least some quantifiable measure of … something.

2 thoughts on “Programmer aptitude?”

  1. Well this is the problem even today, there is still no adequate measure for identifying good (or potential) programmer from the bad ones.
    There are a lot of rumours, discussions and unproven hypotheses… but the truth is no one has been able to create a bulletproof test for programming aptitude.
    However I believe you hit a key point with “processing large pools of programmer candidates”. My opinion is that there is no perfect way to recruit developers, that would never yield false positive or false negative results.
    Nevertheless it doesn’t mean that we should give up on testing the candidates, on-contrary by doing this we can filter out the candidates. But for this I wouldn’t use puzzle tests, instead I would go with something like the coding tests from TestDome.

  2. In about 1968, I was a programmer in the US Army, rated on Army testing in the top 5% of programmers. A new colonel took command and mandated the IBM PAT. I failed. All the other senior programmers (except the ones who had been drafted from IBM) failed. Most of those IBM draftees worked for me, and they were adequate. The PAT went away, and the colonel was quietly reassigned to a Signal Corps unit.

    In 1974, after graduating college, I applied for a job at Northrop. They also required the PAT. I failed again, but passed with 100% their internal test based on symbolic logic, coding and math. They hired me. I spent 40 years coding and designing systems, teaching at undergrad and grad levels, and was a Dean of Computer Science.

    Forget the tests. Give me an hour with a student, and I can tell you if they can program or not.

    Most can’t. It truly is a combination of talent and training.

    In full disclosure, since I have retired, I have not kept current. I lost a great job once because I told Ed Yourdon that C had set the industry back 10 years. It was and is a macro assembler (as are all its successors). Even IBM thought those were bad ideas. I was a Wirth follower at the time. I still think that Modula-2 was a good language. Ada was a disaster designed by a DoD committee.

    So, to all of you C, C++, and variant programmers out there, I welcome you back to the 1960s. We professionals tried like hell to get out, but managers and junior programmers who didn’t know anything else jumped on the C wagon because they learned it in college.

    Challenge for you: take 1000 line of C written 10 years ago by somebody who has left your department and write a description of what it actually DOES.

    I submit, based on experience, that it is not possible.

Leave a Reply

Your email address will not be published. Required fields are marked *