About Interview structure for test automation lab developers

Question

Hi,

I am interviewing new applicants for a team that is doing test automation on our company product(s). The team is composed of junior software developers and a team leader. The product runs on windows and has both managed and unmanaged parts. The test automation is done on both client side (user mode and kernel mode) and server side (IIS, Windows Services, backend). We are doing mainly intergration tests and black box tests. I am trying to figure out how to organize my interview. My overall idea is to ask about a project they have done, then ask some technical questions (multithreading, GC, design patterns) and one programming question. Please note that there is another interview done before me with 2 programming questions. My programming question is rather simple (for example: reversing a singly-linked linked list). My coworkers think that my questions will not find good developers since my questions are rather simple and well known, but so far most of the applicants fail those questions. My questions are:

• Should I change the structure of my interview for this kind of job?
• What questions do you ask to figure our if the applicant is test oriented? (Maybe I should provide a buggy implementation of a problem and let them find the bugs and then ask them about what tests they would have done)

Regards,

Answer 1

I don't think I would make the interview so rigid - perhaps make a list of 10 or 20 questions, and choose from them depending on the applicants answers to the first few questions. Then a really good applicant would be able to show that he is really good by moving on to the tough questions after he has aced the first few ones.

For a tester, knowledge of design patterns might not be too relevant. Unless of course the tester position is intended to be the first career step in becoming a developer for your company.

You will need to test that a tester can work methodically over a problem, while checking all edge cases. I think your idea of giving them a testing problem to solve, is a good one. Perhaps provide them with an implementation which has a few obvious bugs, and a few well-hidden subtle ones.