The Interview

I graduated from the University of Waterloo in 1992 with a BMath in computer science. During my last term at Waterloo, those who were graduating went through interviews for full-time jobs. I interviewed for several companies, but I was only really interested in two: Microsoft in Redmond, Washington and Corel in Ottawa. I did my sixth work term at Microsoft, and they flew me out there again for the grad interviews. Unfortunately, due to some administrative mix-up, they had set up interviews for me on the assumption that I was a co-op student looking for a four-month position, not a graduate looking for full-time work, so those interviews didn't amount to anything. I have no memory of flying or driving to Ottawa for the Corel interview, but I remember it taking place there, so I must have made my way there somehow.

I went through three interviews that day. The first was with the HR person (whose name, I believe, was Sandra Gibson – I have no idea why I remember that), telling me about compensation and benefits and such. The second was with the man who would be my boss if I got the job, Roger Bryanton, in which he told me about what their group did and the positions available. He asked me some technical questions as well as some more general ones like what I'd be interested in working on. Then came the third one, which is the only one I really remember. The interviewer was a man named Pat Beirne, who was Corel's chief engineer and the man who originally wrote much of their signature application, CorelDRAW. I didn't know it at the time, but the man was basically a living legend among Corel people. Roger brought me into Pat's office, introduced us and left. I knew this was going to be a technical interview, so I put on my virtual propeller hat and got ready for the questions. Pat stood up and walked over to the large whiteboard on the wall to my left. It's been over seventeen years since that interview, but I still clearly remember what he said next:

I'm here to find out if you know what you say you know.

I didn't lie on my resume. I didn't say I was an expert in anything. I didn't say I had extensive C experience when I really only had some C experience. I didn't say I was proficient in something I'd never used. But when the chief freakin' engineer of the company says something like that and you're twenty-two years old, even if you didn't lie, and regardless of your self-confidence level, you're gonna get nervous. And I was.

"Let's start with an algorithm," he said. I don't remember what it was for, but he asked me to write some C code that would solve some fairly simple problem. There was a loop and an array and some numbers, but that's all I remember. I wrote it up on the whiteboard in about 15-20 lines of code. "Great," he told me, and I finally breathed out. I'd done it – I'd proven that I knew what I said I knew! I'd gotten the job, right? Not quite yet – we weren't done. Not even close.

"Now make it faster."

"Ummmm... OK.... I guess there are a few things being done here that don't always need to be done, so you could add an if statement around them, and that would be a little faster."

"Good. Now instead of handling just ten values, make it handle any number of values."

"Oh... ummm... rather than using a static array here, you could dynamically allocate it."

"Excellent. Now make it use half as much memory."

"Uhhhhhh... you could.... ummmm....."

"Here's a hint: none of the numbers you're storing is bigger than 50,000."

"Oh, OK, you could use a short int rather than int and that would use half as much space."

"Very good. Now make it faster."

We went on like that for hours. Well, it felt like hours. "Make it faster." "Make the code smaller." "Make it handle negative numbers." "Make it faster again." By the time I was done, I'm sure I had three machine instructions that would handle an infinite number of values in a nanosecond using zero memory.

Of course even then I knew that he wasn't testing to see how small and fast I could make this particular algorithm. He was testing three things:

1. How well I knew the C language, and programming concepts in general
2. What kind of problem solving skills I had
3. How I perform under pressure

These are in no particular order; in fact #1 was by far the least important of the three. If I had #1 but was short on #2 or #3, well thanks for coming in and we'll be in touch. Someone with #2 and #3 but was short on #1 – well, you can learn C. Which would you rather have on your team: A great C programmer who can only solve easy problems or falls apart under pressure, or a great problem solver who works well under pressure but doesn't know C very well? The first one is useless – in fact he's worse than useless, he's a hindrance to the team. You take the second guy, send him on a five-day C course, and you're all set. It doesn't mean that he's definitely going to turn into an awesome programmer, but he's certainly got a better shot than the first guy.

"But how does the story end?"

I got the job, and worked for Roger on CorelSCSI Pro from June 1992 until August 1993, when I left Ottawa to start grad school at Western. One of the pieces of software I worked on at Corel was a CD-ROM driver for Novell NetWare, which did not support CD-ROMs at the time. When I started at Sybase in 1997, I was hired to replace someone who happened to be the NetWare guy. My boss saw NetWare on my resume, and I became the new NetWare guy. Twelve years later, I'm still the NetWare guy.

(Geek alert: technophobes stop reading now) I learned something about the C language that day as well – if you have a pointer to type X, then incrementing the pointer by one does not advance the pointer by one byte, it advances it by sizeof(X) bytes. During the interview, that bit of knowledge allowed me to make the code just a little smaller, but it's such a fundamental part of how pointers work in C that I can't begin to count the number of times I've made use of it since then. And I can honestly say that I learned it from Pat Beirne.