Actual QA Job Interviews, Vol. 1

My first QA job interview was at Macromedia, in late 1995. But first, a little background.

I had spent the previous year working in the Tech Support department, mainly answering phone calls from users of Macromedia Director 4.0.4 for Macintosh and Windows. Director was and is a very complex rapid application development tool geared toward interactive multimedia, with an object-oriented scripting language modeled after Smalltalk. In the main, our customers were using Director to build interactive CD-ROM titles, although a few people were beginning to create Shockwave pieces specifically for the WWW.

The trouble with Director is that it necessarily has to expose a lot of complexity. For one thing, there is no way to shield the user from crossplatform asymmetries in video and sound functionality. Mac OS 9 was better equipped for multimedia than Windows 3.11, plain and simple. So it was common for multimedia developers working on big projects to run into trouble sooner or later, and the truly desperate among them reached out to Tech Support.

The practical upshot was that over the course of a year answering people's questions about Macromedia Director, I learned how to use the app and knew a lot of its weak areas. And I knew what a lot of customers were actually trying to do with the tool. So I applied for the Director QA team, even though I knew almost nothing about Quality Assurance or the practice of testing.

I had a series of three consecutive interviews, each conducted in one-on-one fashion by an current Director QA tester.

The first interviewer probed my general computer skills. He asked me a lot of questions about where certain settings were stored in Mac OS, and which .INI files you would tweak in Windows to fix such-and-such. I remember he threw me a curve ball, when he casually mentioned three .INI files: WIN.INI, SYSTEM.INI, and DRIVER.INI. At his mention of the last one I remember scrunching my eyebrows in confusion, at which point he laughed and said "That's the correct response," because Windows 3.11 didn't have a DRIVER.INI. So I passed the general computer knowledge test, and he recommended I be hired.

The second interviewer tried to get a sense of my people skills, to see if I would be a good fit for team's interpersonal dynamic. She asked me very general questions about Quality Assurance, which I filibustered. The question was something like "What's the job of a QA tester?" I think I gave a 100-word answer. Then she said, in a very nice way, "You didn't mention finding bugs." My reaction was to insist that it fell under something that I did mention, which was "determining the current state of the product" or something like that. Despite my evident defensiveness, she recommended I be hired anyway.

The last interviewer assessed my testing mindset. He drew a simple calculator app on the whiteboard, and asked me to explain how I would go about testing it. I rattled off everything I could think of, most of it based around verifying that the arithmetic operations were not obviously broken and the boundary conditions at numeric overflows. Also I knew to include some basic stuff that every application has to support properly, like cut-copy-clear-paste. Then he drew a simple text editor app on the whiteboard. After spending a lot of time talking about how to make sure that the app doesn't crash opening huge textfiles, I drew a total blank. Later I would learn to consider character encoding sets, internationalization testing, and compatibility issues with spellcheckers and scripting languages. But I was a blank slate, with no real testing experience, so I whiffed that one. In spite of that, he also recommended I be hired.

So I joined the Director 5 project, which was already in progress.