Not one of my better interviews, but I'll just post some highlights for the benefit of anyone who wants to know what a QA interview is like (specifically, for a Safari web browser testing position).

Asked to explain what I meant by some words I use to describe myself in the summary section of my résumé (the section right underneath the header containing my addresses and phone number). Tried to give convincing examples, but in general I feel funny talking about myself in that manner.

Asked about several projects I'd worked on. I had started to feel somewhat uneasy, so I didn't express myself as well as I do when I'm just talking to someone casually.

Asked to explain how I would handle approaching a developer with a bug I found but they couldn't reproduce. I wasn't really prepared for this question so I said I'd try meeting with the person with a sample of the bug in question and would involve the developer's manager if that didn't work.

Asked what types of testing I generally do. I think the interviewer was looking for specific terms, but none really came to mind, so I told him I didn't know the specific terms. He said it was ok to use general descriptions. Then I remembered some of my work with the eXtreme Programming (XP) at my last job, so I described the method of how we'd either get a bug report from a client or discover one in house, write up a story for it describing the problem and the desired functionality, submit it to the developers, verify that the bug was fixed, and close the story. Emphasis is on the member of the test group acting as a proxy for the client to make sure the bug fix meets the client's expectations.

Asked what a buffer overflow attack was. At first I didn't remember. I started to describe it a couple of times but stopped myself stating that I wasn't explaining it properly. Finally gave an explanation that was not the best possible one noting how the attacker can write past the end of allocated memory into locations where environment variables can be modified or a command can be executed.

Asked something about trust analysis. It sounded like the guy wanted information about covert channels, but I couldn't think of the name, so I tried to give an explanation of how some processes might not be able to communicate directly with one another but might be able to read something like the /tmp directory where they could pass information to each other via it. I used the word "signaling" instead, which is ok (according to Wikipedia) but not as good as it could have been.

I'll just note here that I didn't actually apply for this job. When the recruiter first contacted me and told me about the job, I told her that I didn't have that type of experience and that I was really looking for a network software development job, like the Bonjour project. She told me that she wasn't the recruiter for Bonjour. She also said that the guy who interviewed me had asked about me, so I figured I'd just give it a chance. However there seemed to be somewhat of a mixup because the interviewer seemed surprised to be getting someone whose primary focus was on development rather than testing. Of interest to some is that even with this knowledge, he put me through what he called "the QA interview process" (paraphrased) which suggests there is some kind of template for some candidates.

Anyway, to me this is more proof of when I answer questions incorrectly or poorly, it's a matter of not having done something in many years so I just can't describe it as accurately as someone who's been working on that type of project more recently. It's also an indication of a mismatch, in this particular case, but in my own defense I didn't apply for this position.

To relate this to dancing, Gita and I worked on more of the hustle routine last night. Some of the names she uses to identify the patterns are different than the names that were used when I first did the routine seven years ago. Also, the patterns don't all feel familar to me because they aren't ones I usually lead. In fact I was discussing this with another dancer friend of mine before my lesson. He had to take some time off from dance to take care of his mother. He's now starting to get back into it a bit and is finding it difficult to recall some things that came easily to him before he had to stop. Before his mother became ill he won several competitions and was considered one of the top dancers in the studio. So it is reasonable to expect that people will have trouble doing things they haven't done in at least a year, such as dancing or software engineering.

Comments

On trying to get the developer to see the bug is reproducible though he/she argues it is not reproducible you should1. If you can only talk to them, then walk them over the steps together and checking on what build/model of gadget/version of browser/ they are following the steps to reproduce the bug on2. If possible bring him/her over to your machine and reproduce it in front of them 3. Try to reproduce the bug on another machine besides yours

Do not say you will involve his manager that invites trouble

On the question about what types of testing. I think it meant was it black box testing or white box testing or automation. Black box testing you are just testing the functionalities of the system manually. (ie. Clicking on the print button to make sure it prints.) White Box testing is looking at the code while you are testing. Writing scripts to test out the system to see if it behaves correctly. Automation is writing scripts using a program brought or created in house to test the system automatically like running overnight or over the weekend without requiring users to click buttons/test manually.

I don't know what a buffer overflow attack is. I think your position is a senior qa position requiring code testing aka white box testing. It kind of requires some development work so it is somewhat in your ballpark though not exactly. Don't be so hard on yourself. You did your best that's all you can ask for.

Well, I was thinking of the situation where the client needed an answer and the only way to get it was to involve the developer's manager, because the developer didn't find the bug for some reason. (I did point this out, however.)

On the question about what types of testing. I think it meant was it black box testing or white box testing or automation.

I did all three types of testing at Nominum.

I think your position is a senior qa position requiring code testing aka white box testing.

I think the problem is that my experience in QA has been rather informal. My guess is they were looking for a more formally experienced QA person. Since that clearly isn't what I've done (and don't really aspire to), I don't feel badly about not getting the job.

I too had an interview today, and I'll try to post about it at some point.

I have definitely had the experience of getting quizzed on something I haven't done, or thought about for a long time. Mostly I think I do exactly what you described: I begin to talk my way through it, and usually come up with an answer I'm semi-satisfied with, but not using the terms I would use if I were more readily familiar with it.

Anyway, good on you for getting additional exposure to interview/phone screening. I have also had the experience of someone asking me about something on the resume and not being able to speak to it, but after a number of interviews this month it's happening less and less. I am getting much better at the "standard" questions like, why are you looking to change jobs, tell me about yourself and your background, what are you looking for, why did you write that you want to be *either* a manager *or* and individual contributor, etc.

Here are some types of testing that I usually think of when writing a test plan.Functional, or positive: does it do what it says it will do?Negative: Try to make it do something you know it can't, get intelligent error.Error, or destructive: Bad data, full disk, powering off in the middle of an operation, any other really bad shit.Performance: How fast can it do its thing? If processing time is 5x normal in the next build, we want to know.Limits: when pushed hard, will it run out of cpu, memory, bandwidth, or other resource? How will it react, does it fail gracefully?

I think there may be "black box" and "white box" (open box?) tests in all the above categories, but most of the above are predominantly black-box. If I know the internals of something and can exploit that to make the thing fail, that's white box, but it's probably more important when dealing with a server or security application than with a shrink-wrap, sell-to-user piece of software.