In the 1990’s, I had access to the early internet (before the web) and made use of a public forum (Usenet) where I could ask and respond to questions about programming the Macintosh computer. I’ve mentioned before how this caught the attention of engineering at Apple (Tom Dowdy, in any event). Perhaps too, the game I had written for the Macintosh, Glider, had afforded me some name recognition.
Glider was a computer game I wrote originally as shareware. I wrote it while I was in college and trying to teach myself how to program the Macintosh. A few years later I reached out to a software publisher in California and they agreed to publish my game commercially (for publication I rewrote Glider in color and added a lot of other niceties to take it to the next level so to speak). The games editor for MacWorld magazine chose Glider as the best Macintosh arcade game of 1991, so it was perhaps unsurprising that a few of the engineers on the graphics programming team at Apple knew about the game.
When I had started to make money from royalties on Glider I bought the least expensive laser printer from Apple and proceeded to print the entire source code for my game. There was a print shop in Lawrence, Kansas that had some means of binding thick print jobs like mine — hardbound and everything. So for a little bit more of my royalty money I had the printed sources for Glider bound up. The thing looked like a volume from a big black encylopedia set.
I printed the source code duplex (both sides of the paper) which at that time, with that low-end laser printer, meant I had to print all the odd pages, then flip the printed pages over and run them through the printer a second time to print the even pages on the backs. A paper jam or any other screwup would result in having to reprint all or part of source code. The end result though looked much more professional and reduced the thickness of the printed code by half, of course. Nonetheless, the result was about two inches thick — nearly a ream of paper. It even suprised me how much code I had written.
I should point out, the reason I printed out the sources to Glider were two-fold. One, it was a sort of ultimate backup during a time when floppy disks and even hard drives were untrustworthy. I would have hated to do it, but in a week or two I probably could re-type all the code in by hand using this book. But the other reason I printed it out was as some sort of token or perhaps as a testament to this thing I had just accomplished. The end product of months and months of programming is, in the end, a stream of bytes that exists invisibly on some sort of magnetic media (in those days). Like a novelist having written a book, printing the code out provided the coding effort more of a sense of gravity (literally, ha ha).
Additionally, since programming can go on and on (a program is never truly done), printing the thing also gave a kind of finality to the project.
As I flew out to Cupertino, California for the job interview, I thought to grab my Glider book and bring it along as well — like, “Here’s an example of my programming.”
I found out though that bringing in a bound book of your source code to the interview is rather unusual. When I sat down in a small conference room across from two Apple engineers and put my Glider book between us, there were smiles and looks of surprise from the interviewers. That it turned out to be a conversation starter was a happy accident. From my vantage point in the present, having worked at Apple for over twenty-five years, having interviewed a couple dozen candidates myself, I see now how rather eccentric of a thing that was.
And, perhaps in no small part to this bit of ice-breaking, I felt relaxed to talk very casually to my interlocutors.
I should pause here and point out that an interview at Apple was an all-day affair. Pairs of engineers would meet with and interview me for perhaps an hour. The first pair of engineers might grill me on some esoteric topic like code design, afterwards the next pair of engineers would sit down and maybe cover programming language specific questions.
And so it was, with each round of interviews, I heard more than once from the engineering pair interviewing me how hard an interviewer “Andy” was and how I was going to enjoy (ha ha) my coming interview with him.
Andy (and this is not his real name) would be one of the last interviews, just him, no partner, and I understood this was to be the real no-nonsense interview.
Up to that point in the day I had found the interviews to be pretty relaxed and my confidence that at least the team liked me was pretty good. I don’t recall having stumbled much during the Q&A, but no doubt I showed some level of “juniorness”, but perhaps they would allow for that. This upcoming interview with Andy though was causing me some anxiousness.
When Andy sits down across from me it is clear from his natural scowl that he was all business. I’m sure my Glider book was still there on the table but I don’t think he showed any interest.
To break the ice, I offered, “So, I am a little nervous about this interview with you.”
“And why is that?” he replied, deadpan.
“Oh, I guess I heard from some of the other engineers that you can be a tough interviewer.”
“Why would they say that?” Again with quick question right back. I began to suspect that he was trying to give me enough rope to hang myself. And to be sure, I was squirming a little.
“I don’t know,” I said, “maybe you are going to ask me a question about Information Theory — entropy, something like that — and I don’t have a Computer Science degree, so…”
“So tell me about Information Theory, entropy.”
Now I bet Andy thought he had cornered me, but I am going to confess that I had been the one laying the trap. I actually had read a little about entropy with regard to programming (Information Theory) in Scientific American magazine or somewhere and it had fascinated me. So while establishing my ignorance of lofty topics like Information Theory, I had planted the one thing I could at least talk in layman’s terms about.
And so I did.
As I said though, I came about it from a layman’s point of view and I never pretended to know any more than that with Andy. But as it turned out, Andy was happy to talk about the topic and the rest of the interview began to feel more like I was attending a lecture on Information Theory and Andy was the lecturer.
In the end I have no idea how all of my efforts that day played out. The engineers that interviewed me would meet at the close of the day, or sometime during the next day, and would each give a thumbs up or thumbs down. Democratically, if I got more up than down votes I was in. It goes without I saying I passed the test as I was offered the position some weeks later.
But I’ll never know if my sparring with Andy won him over or if instead I had enough thumbs up from the other engineers that were charmed with my Glider book. In the end I think Apple got an engineer for the next twenty-five years that, though not the cleverest engineer, was one that worked quickly to prototype new ideas and took on some of the gruntwork that not every engineer wanted to work on.
Maybe I can recall some of those times and blog about them in the future.