Being Hired as a Programmer

I'm currently reading Eric Sink's new book The Business of Software.  I promise a full review when I'm done, but the section I just read brought back some memories.

Eric has a chapter on how to hire a programmer, where he gives advice to the operators of a small software company on how to hire the best developers.  I've never hired a developer myself (not for a regular job - I've hired developers for outsourced projects), but his advice looks good to me.  It reminds me of when I was looking for a programmer job, exactly ten years ago.

In fact, exactly ten years ago today, on April 1, 1996, I started a new job as a programmer at a small ISV.  The company was located in Springfield, which is why I moved here from Bloomington in 1996.  The company was a value added reseller (VAR) for a big accounting and inventory control software package.  The company sold the software and made custom modifications to it for their customers (which is where we programmers came in).   My job was mosting writing additional code to enhance areas of the software, plus a lot of fixing of other programmer's bugs (both from our own enhancements and in the original code).  This was 1996 and the first version of the product was written somewhere around 1980 (I believe), and it grew from there.  Probably hundreds of programmers had had their fingers in the code over the years.  As I said, I spent most of my time fixing bugs.

Before I started the job on April 1st, I spent the whole 3 months from January to March of 1996 interviewing for a programmer job.  From 1988 to 1995, I had been primarily a college math instructor, teaching mathematics courses such as calculus, algebra, finite mathematics and so on at various colleges and universities, including the University of Illinois, Illinois State University, and just about every college in Bloomington-Normal, Illinois (which, actually, has a lot of colleges).  Both Anne and I were what we called "academic migrant workers": picking up a course at this college, a course at that college, driving between them from class to class.  Teaching was fun, but the pay was awful.  On the side, I also did programming for my father's very small corn research company.

This was what I was doing when I wrote the first versions of Pretty Good Solitaire.  In the summer, I didn't teach any classes, so all I did then was corn research work.  It was during the summer of 1995 that I wrote the first version.  In the fall it started to make a little money.  The primary reason I started the game was to learn more about programming in Visual Basic.  At that time, Visual Basic programming jobs were hot and my idea was to get good at VB and look for a VB programming job.

While I did a few interviews during the fall of 1995, I didn't really start until I quit teaching at the end of 1995 and went full time job hunting.  Which brings us back to Eric Sink's tips for how to hire a programmer (he has an online version here: Hazards of Hiring).

I interviewed at probably about a dozen different companies.  Basically, nobody does (or did 10 years ago) hiring according to Eric's advice.  In most of the interviews, I was interviewed by a Human Resources person.  These interviews were pretty much over before they started.  An interview with an HR person tests you on how well you can schmooze up to an HR person, which I am not good at.  Instead of testing you on how good of a programmer you are, it tests you on how good you can talk.  Most good programming does not involve talking, so this is a lousy way to find a good programmer. 

I interviewed in small towns and big ones in an area from Indianapolis to St. Louis, looking for a company looking for a VB programmer.  There were only a couple of times that I was interviewed by a programmer. But nobody really tried to find out how good of a programmer I was, which was very frustrating.  Here I was interviewing for jobs writing code and the inteview process never had anything whatsoever to do with writing code.  Finally, this company in Springfield was the first to actually test me, with a test that was mostly math and some coding.  With my degree in Math & Computer Science plus my two years of math grad school, not to mention 8 years of teaching math and writing and giving math tests, I was going to blow away any math test given to me, so finally I was able to do well.

So I went with this company in Springfield because they actually tested me on how good I was, plus it was a company where the top person was a programmer himself, which as Eric mentions in his book is a good thing for a software development company (think: Microsoft).   The programming wasn't in VB, but it was in a version of Basic that wasn't too different, so I didn't have much trouble technically.

As things turned out, I only stayed at the job for a couple of years, essentially for years 2 and 3 of Pretty Good Solitaire.  What was a small part time income in the hundreds of dollars a month when I started the job quickly turned into thousands a few months later and by the time I left the job I was making 5 times my salary from shareware.

Eric says he looks for a degree from a good computer science department for good developers.  While a college degree is important, my experience was that my CS degree from the University of Illinois was worthless.  I learned nothing in any computer science course in college.  When I got to college, I had already been programming for years on my own computer.  The CS courses taught me nothing additional I needed to know.  In fact, most of it was worthless stuff about "np-complete" and other things that will absolutely never come up when you are writing an accounting application (or a computer game).  There was not a single course that taught you how you actually code.  Maybe they have such courses now, but they didn't in the early 80s.  My major was "math and computer science", which was a mixture of math courses and computer science courses.  I quickly arranged my schedule to take as few CS courses as required and then took many more math courses than required, which worked out well.  I enjoyed my math courses and hated the CS courses. 

In fact, after learning to program in high school, I learned nothing more about developing until I read the book Code Complete by Steve McConnell in the early 90s.  I learned more about how to actually program from one chapter of that book than in all of my college CS courses combined.  Reading that book (probably in 1993 or 1994) was what made writing Pretty Good Solitaire possible for me.

Comments

[Andrey Butov]

I work on Wall Street for an international investment bank and have interviews dozens of candidates. Before that, I've interviewed candidates for Software Development positions at small Wall Street firms as well.

Not once did I pay attention to the resume if the candidate in question was what I was looking for. If the candidate is a 'super star', for lack of a better term, I don't care if he attended a reputable school - in fact, the best developers I've worked with had no degrees of note, and came into the field from other fields (mostly Physics).

I, myself, have a Master's from Columbia in Computer Science, and no one who has ever hired me has paid much attention to my degree. There are many developers better than I, and many with advanced degrees from reputable schools who are not.

[Factory]

"But nobody really tried to find out how good of a programmer I was, which was very frustrating."

Hmm odd, when I was getting a job a few years ago (in Australia) at least half of the places had some form of test for compotency in programming. At my current work they have a test basically to weed out most of the applicants, apparantly there are some really easy questions that most ppl don't get right.