Coders At Work Interview


Coders At Work Interview

Peter Seibel wrote a great book called Coders at Work which contains interviews of various programmers throughout computer science history. Yury Lifshits has put up a site called Interview 2010 that lets you both define interviews and respond to them. Peter graciously agreed to put up a subset of his questions for the interviews that he did and I have my answers below. After that, you will find a form to enter your own answers to this set of questions.

Sam Pullara

Long-time computer programmer

Peter Seibel: How did you learn to program?

Sam Pullara: Back when I was around 10 I asked for a computer. My mother looked at the available choices and decided that the Atari 400 was just a game machine and the VIC-20 looked like I might actually learn something. She was right. I started out programming in BASIC and then later 6502 machine code on the 64 and 128. In high school I finally learned a ‘real’ computer programming language, C, by reading a 700 page volume book in a single night. One day I will take a computer class.

Peter Seibel: What is the thing that you worked on that you are most proud of?

Sam Pullara: The work that I did helping to create the WebLogic Server. Building a system that thousands of developers and in turn millions of users depended on was a great experience and very challenging. Ultimately, that work was acquired not by one company but eventually by two and is still one of the best enterprise software servers on the market in the very capable hands of Oracle.

Peter Seibel: What about books? Are there particular computer science or programming books that everyone should read?

Sam Pullara: I haven’t read a great deal of computer science books though I enjoy books about algorithms, languages and patterns rather than books about the details of programming an API or in a certain domain.

Peter Seibel: Do you still read code for fun, as opposed to reading it because you need to work with it?

Sam Pullara: I love exploring a new piece of code. Digging into something deeply and seeing the nuances and edge cases the developer discovered as they created the program is very interesting to me. I’ve had to hand my code off many times in my career and I am always pleased when someone takes the care to create code that is easily understood rather than clever.

Peter Seibel: What about organization, do you organize your code top down or bottom up? Do you refactor to keep the internal structure of the code coherent? Or do you have just very good sense at the beginning?

Sam Pullara: I try to write code that always works and refactor it into the final design. Java and its IDEs have trained me to write code backwards in many cases with the structure flowing out of an initially very procedural constructs. The invention of isomorphic transformations on code and semantic code completion have completely slaved me to languages that conform to the restrictions that make those very things possible.

Peter Seibel: How do you go about debugging?

Sam Pullara: I use a mixture of Zen, printlns and actual debuggers depending on the circumstances. For very esoteric edge conditions I prefer to figure out what must be true and work backwards from there. When code is only badly behaved rarely, printlns help you discover where you should look or think about. For complicated algorithms, I do enjoy the occasional debugging session where you interrogate every line to see if it is behaving as you expect.

Peter Seibel: How do you tackle understanding a piece of code that you didn’t write?

Sam Pullara: Figure out an interesting feature to add to it and add it. Nothing lets you really understand a piece of code like trying to change it. The tools of the trade are typically a refactoring IDE with all the modern bits of introspection that you can bring to bear. I’ve found that even obfuscated code is east to understand with modern tooling.

Peter Seibel: What about the length and intensity? I am sure you’ve done 80-, 100-, 120-hour weeks. Is that necessary? Under what circumstances it is really necessary and when it is just macho thing to do?

Sam Pullara: I have a pattern where I think and think and think, tinker, tinker, think and then finally in a like one huge breath blow the program out of my mind and into the computer. That final breath can take hours and hours straight but it is so much better than trying to force it before it is time.

Here is the form for your own answers to these questions:

Your full name or nickname


Couple of words about yourself


How did you learn to program?

What is the thing that you worked on that you are most proud of?

What about books? Are there particular computer science or programming books that everyone should read?

Do you still read code for fun, as opposed to reading it because you need to work with it?

What about organization, do you organize your code top down or bottom up? Do you refactor to keep the internal structure of the code coherent? Or do you have just very good sense at the beginning?

How do you go about debugging?

How do you tackle understanding a piece of code that you didn’t write?

What about the length and intensity? I am sure you’ve done 80-, 100-, 120-hour weeks. Is that necessary? Under what circumstances it is really necessary and when it is just macho thing to do?