Historical programmer evaluation materials

Question

I am interested in finding out what were considered important attributes of a developer in the early days of programming, i.e., 1950s, 1960s, or early 1970s. Post any examples/materials you have: interview questions, developer tests, expected experience, personality assessments, anything that was used to evaluate a programmer before Microsoft's time.

If you can, provide references such as the company that used the test and the location and date of use, as well as programming languages and hardware that would have been in use had the participant been hired on.

Answer 1

In the early days, you must be able to walk with a large amount of cards without tripping.

Not afraid of bugs was also a requirement ;-).

Answer 2

Well, in those days, programmer salaries peaked at about $35,000/yr (based on what my father was making in 1976).

Computers, on the other hand, were vastly more expensive than they are now, so it really wouldn't take a company long to spend about $35,000 in computer time.

Which means, that if an important program was running slowly, it could be cost effective to have a top programmer work full-time for a year to optimize it to shave a couple minutes off a daily run.

More specific skills:

• Punch cards meant that an typos were much more expensive (you couldn't backspace -- you had to tear up the card and start again), so typing was important.
• Errors generated a huge hex dump of the system. Understanding hex and being able to navigate a 40 page dump was useful.
• A regardless of the language you wrote the code in, the hex dump would be in assembly or machine code, so you'd have to know those also.

Answer 3

• Must read hex
• Must be accurate typist
• Able to navigate an Abend printout
• thorough desk checker- must be able to run and test the code in your head before you waste machine time
• Able to lift 35 lbs (the approx weight of 3 full card trays)
• must understand that if you leave "Ready Trace" statements in your code when you check it into production then the 71 boxes of paper that operations will be delivering to your desk are yours to dispose of and by tradition none of your co-workers will help you.
• must be able to work 2nd shift - the computer is only available for compiles and test runs after 6pm (you can of course submit your job in the daytime and wait till the next morning to see if you got a clean compile)
• Must not drink at work

Answer 4

Must be able to keep track of your cigarette (yeah, we smoked at our desks).

With all the print outs from last night, the cards, and the feed tracks (those tear off bits on either side of the paper to feed it through the line printer), you had a considerable fire hazard, and a badly placed cigarette could ruin your day.

Answer 5

Realise that in the early days the programming languages were much more limited than they are now. There were two type of language: assembler and 'high-level' languages (FORTRAN, BASIC, COBOL, etc).

• Code was written on programming sheets (structured graph paper) and then transferred to cards or tape for input. Either you typed (punched), or you sent it off to a pool and then you had to check everything tirelessly. NUMBER YOUR CARDS!!
• Documentation was scarce, flow charts for design, code comments.
• Compiler messages were not always understandable - oh that's today as well!
• Editing your code was best done from the console - if you were allowed.

What attributes:

• Not much different than today except we worked at something that was totally obscure to a lot of our friends and family. Magician.
• Logical thinking.
• Little loony.
• Math based.
• Ability to sift through scads of paper.
• Best use of punched cards: I kept a box next to the phone.
• Patient - you sent your code off and waited for a result to be delivered. Not much interactive work back then.

Old times. That'll do for now.

Answer 6

It would probably be worth reading Weinberg's "The Psychology of Computer Programmers". It was originally written in 1971, but you'd more likely find the Silver Anniversary Edition now. The additional material in it was a disappointment, but the original material is outstanding. In contrast, the anniversary edition of Brooks' "The Mythical Man Month" has valuable extra material - most notably the "No Silver Bullet" essay. Both books would also give you insights into programming of the late 60s and early 70s -- though much of what is discussed is still relevant.