Joel has his "The Guerrilla Guide to Interviewing (version 3.0)", but that's really for programmers.

How should you go about interviewing testers?

We ask programmers to program on a whiteboard; how you can you ask testers to test in an interview, in a way that tells you something useful about them?

  • 1
    Maybe the question you ask in the body would be a more specific title: "How can you ask testers to test in an interview?"?
    – testerab
    Commented May 4, 2011 at 1:05

16 Answers 16


You can ask people to test on a whiteboard too - draw up a sample dialog, or system, and ask them to discuss what ideas they'd have for testing. I really like Cem Kaner's approach to this. He goes into some detail about how he conducts test auditions - he tends to give two similar examples, with the first one as a practice run.

I've found it very revealing to see how different candidates react to being asked to come up with test ideas for a sample dialog. Some run out of ideas very quickly. Some people are very single-track minded, and all their test ideas are along the same lines. Some people ask hardly any questions, and others ask lots. Watching what kind of questions people come up with gives me an insight into what kind of mental model they're building, and what their blind spots are.

I've also tried giving people an actual app during an interview - I didn't find that much of an improvement on the whiteboard, personally, but it's possible that a better choice of app, or framing, would have helped there.

I'm not so much of a fan of "test this lightswitch" or "test this pen" questions - I prefer things that are close enough to real that they trigger genuine questions for people. I know some people have difficulty in getting inspired by things that don't seem like authentic problems, and I don't want to disadvantage potentially promising candidates.

  • I used to like the "test this <object>" question and got some good use out of it, but after awhile it became stale as people either heard about it or I just got tired of the same responses. I like the whiteboard and use that now when I can, give a diagram and start a discussion and that works out well.
    – MichaelF
    Commented May 4, 2012 at 16:58

We have several portions to our interviews:

  • Here's a simple, well-known system anyone should know, we like to use elevators. Here is a very basic spec. Talk about some tests you'd run.
  • We've written the spec so that anyone worth their salt should have a dozen questions about it.
  • We want to see the different types of tests they come up with, not just the specific issues.
  • See how curious they are about things. Good testers test everything all the time, including you and your interview process.

I like to say (metaphorically) that when you ask a good tester to pick a number between 1 and 10 they'll choose π.

  • 5
    I think this approach has its ups and downs. :-) Commented May 9, 2012 at 16:13
  • I like to ask them to test a vending machine. It covers several different systems--taking money, counting money, product selection, product dispensing, anti-theft, administrative functions like loading product and retrieving change, back end procedures like cycling coins through to be used as change for future transactions instead of putting them in a general bin, error conditions (Can't hold more change? Selected product empty? Didn't dispense?), and it's familiar enough that any tester should have interacted with one before. And what happens if I choose e or φ?
    – Roger Cook
    Commented Aug 13, 2018 at 16:27

I think it depends on what you want your testers do to. If working in a team environment and collaboration are key aspects of what your test team does, make them solve a testing problem with you. If you want them to write some automation or tools (or at least be able to if they're stuck), you may want to have them write some code (but have them write code to solve a testing problem - not some "interesting" algorithm).

In general though, I like to take some time before the interview to think, "What would the A+ tester on this team do?". I create a list of attributes, then brainstorm questions that will help me figure out if the candidate has those attributes.

And finally, where I work, career growth has a huge emphasis, so I probe a bit to make sure the tester I'm hiring has long-term potential (I like to ask, "How do you learn?", as this gives me an indication of how much they want to grow).


In addition to giving them an app to test, I've had good luck with showing testers a set of requirements and then letting them ask questions about the requirements and start to brainstorm tests from them. I try to make sure the list of requirements has some vague statements in them to see what kind of questions people will ask.


I agree with testerab that Cem Kaner, in his PDF, has outlined a good approach to hiring.

Paul Carvalho also has a good PDF called Hiring Software Testers in an Information Age that he published in 2007. Besides conducting the interview, you as the interviewer should look for common attributes, be able to skim through resumes, identify the school of testing they belong to, identify revelant work experience, etc.

I found Paul's PDF after reading his article Hobbies and Interests. The article has a lot of good information on hiring testers which Interviewees can look at to get an idea of what someone might look for. In the comments he lists a few examples of the types of problems / sample applications he gives to testers. Its worth a read.

Cem Kaner posted in Dr. Dobbs on Recruiting Software Testers back in 2000 that's worth a view as well.

I used to think quizzing testers on their vocabulary (i.e. what does verify mean?) was a good idea but I learned quickly it didn't matter. We all have different ideas on what things mean and the value they carry - as long as you can articulate your reasoning.

  • 1
    +1 for some great refs - have read the Paul Carvalho article and it's excellent, really useful for explaining to folks that you get testers, and you get testers, and that mate they know who's a tester may be great in their environment but is a terrible, terrible fit for yours.
    – testerab
    Commented Feb 19, 2012 at 15:10

I think that this is well covered by Steve McConnell in his book "After the Gold Rush", where he states that you should make jugglers juggle before you hire them, so make them test in the interview.

For example, pick a piece of commonly used software, like say copying a file to a folder in windows and ask them "You are the test lead on this, what would you want to test before you ship it." Good testers will be able to tell you hundreds of test cases, poor testers will struggle at 10-20 obvious ones.

  • 01 Verify that filename exists in the folder 02 Verify that the same filename exists in the folder (if no existence of that file before) 03 Verify that the md5 hash of the original file and the new one are the same 04 Verify that the file was copied fast enough 05 Verify that the actual content of the file are the same as the original file 06 Verify that if a similar file already exists in the folder, that a prompt will be rendered to ask for overwriting the file 07 Verify that if overwriting the file is cancelled that the destination file is not replaced Commented Jul 4, 2022 at 22:50
  • 08 Verify that if overwriting the file is accepted that the destination file is replaced and matches the original 09 Verify that timestamp of the file being modified is updated for the destination file 10 Verify that the original file after the copying process has remained intact 11 Verify that copying is allowed both by dragging the file on the folder and also by right clicking on the folder and selecting paste 12 Verify that if the destination file is set as system protected then it cannot be replaced during the copy procedure Commented Jul 4, 2022 at 22:51
  • 12 Verify that if the destination file is set as system protected then it cannot be replaced during the copy procedure 13 Verify that copying a file with characters which are non english but valid, will be allowed and the copy operation will be successful 14 Verify that after original copy, if deleting the file then the copy process can be repeated 15 Verify that copying a very large file that takes hours to complete that the process will be robust enough and will not fail 16 Verify that copying a very small file, the smallest of one byte or even of zero bytes is still allowed Commented Jul 4, 2022 at 22:51
  • 17 Verify that copying a symbolic link, then the destination file will be pointing to the same target as the original file 18 Verify that the occupied disk space as shown to the user after the disk space will be double the size of the original file 19 Verify that cancelling the copying process of the file will yield no new files in the folder 20 Verify that cancelling the copying process will keep the occupied disk size to the same as it was originally before the copy process Commented Jul 4, 2022 at 22:52
  • 21 Verify that attempting to copy the file to the same folder that it belongs it will not be allowed and will render a corresponding error message Commented Jul 4, 2022 at 22:52

I try to understand whether they actually like testing or whether they're using testing as a stepping stone into development. What you do with that information depends on the organization, although if they don't actually want to test, you may have problems with the quality of their work.


From my experience i feel what ever questions need to be asked should be practical ones rather than theoritical. I have come across few of my friends who have just mugged up on theoritical knowledge and have cleared interviews, in reality they have no practical knowledge(I am talking wrt to lateral hires). Based on project requirement and the knowledge required that a tester should have,a set of questions has to be prepared along with few basic standard questions. It is best to avoid questions on asking different types of testing i.e what is black box testing,white box testing,exploratory testing and so on.. People get in answering such questions.


Great Question

As per my experience, it's very difficult to get a right employee who has very good judgment, sharp focus, attention & great observation skills.

Earlier it was very difficult to filter right candidate but our team come with some solution for that We made some minor changes in our interview process as follows:-

Now before conducting F2F interview We give some Android/iOS application's & instruction sheet to the candidate and ask to perform any type of testing(functional, GUI, Usability, Security....etc ) & find any kind of the bug based on this instruction. We give around 1 hour time to the candidate to find bugs as much as He/she can find. If the candidate is able to find even a single bug then we go for next round F2F interview otherwise we don't proceed with the candidate.

This small change saves a lot of time of our working employee & it helps us to figure out these basic qualities of the candidate like.

  • Judgement Capability
  • Decision making capability (Bug or not)
  • Attention to details (Instruction sheet)
  • Efficiency of the candidate
  • Focus on random application (Layman approach)
  • Flexibility with the situation & work
  • Time management
  • Observation of the random application....& much more

Then in the F2F interview, we start to ask the question-related to AUT we ask about his experience about that hour and Other skill sets (In resume) And try to judge the above properties in a good candidate.

I can't say that it is a standard procedure but its help us a lot to filter out a very good candidate from crowed, for our work.


I can give an example of how not to take testers !

In the Indian IT industry, some of the companies recruit or assign Fresh Under grads to testing team, by 1) Names starting A <--> M - Development Team, N <--> S - Testing Team & rest will be in PMO etc & if the candidate did not cleared the Programming language test(cut off limit for developer positions) but still scored a decent mark, then will be assigned to test Team. There are many permutation & Combinations like the above.

Main problem for these companies is they have to recruit in thousands every year.

  • really ????? must be service based organizations like TCS and WIPRO
    – Aura
    Commented Jan 29, 2015 at 12:30

Take something you know well and just see how your interviewee would approach testing it from the highest level and describe their thought process before they begin.

You probably want to know more how they think rather than whether they do it the "right" way.

  • 1
    This is just the most static way of interviewers ... and i hate this approach .. instead of asking what the tester know .. u want to know ur knowledge back ... and that is just useless for understanding different perspectives
    – Aura
    Commented Jan 29, 2015 at 12:28
  1. The common sense of a tester. Check if s/he is sensitive to the product testing.
  2. The knowledge of test methodologies.
  3. Experience.
  4. Talk about the chanllenges that s/he met in the past
  5. Take a real system for example, or a pen, a cup, a selling vendor machine to ask s/he to think about the test cases.

For the job i have currently my boss asked me how i would QA a calculator program. The company was adding a multiplication functionality and wanted to know how i would go about testing it. The first thing i did was pull out a note pad and paper and started writing down boundary cases and COS requirements. This was definitely impressive for him because it showed that i was able to plan before just jumping in. Most interviewees he said would just spout off several cases that came to mind but with me i comprehensively dissected the problem in terms of boundaries and what needed to work in order for the development to pass(Acceptance testing).


Here is my "proprietary" interview question which usually gives me clear insight on what a person can and what mindset they have:

  • Assume you have a calculator to test
  • This calculator has some specific
    • It accepts only the digits "0" and "1" as input
    • It uses decimal numeration though
    • It displays a result using 0-9
    • It can display decimal fraction
    • However it does not accept input of decimal fraction
    • It can display negative numbers
    • However it does not accept input of negative number
    • It supports the only two operations: division and subtraction
    • It supports sequential input without the need of pressing "=" (e.g. 10/1/10 = 1)
    • It displays only 5 digits on a screen, however it accepts 6 digit input so that the most significant digit is not shown. It however takes part in calculation.

Basically, here it is:

enter image description here

Question: We are limited with only 5 tests to execute. What would be those five most important tests and why

  • 1) Verify that the input is following the limit of the screen <-- challenging the requirements as would be absurd to let digits beyond the screen limit 2) Verify that the order of the operations matter: 10 - 100 / 9 = -10 (and not -1.1111) 3) Verify that infinitely repeating decimals work: 10001 / 11 = 909.18 4) Verify that same operation multiple times works: 1 //////// 1 = 1 5) Verify that 1 / 0 = an error message and not something valid Commented Jul 4, 2022 at 15:18
  • Not sure if you would like my answers or not but even though I like your approach it is only a small indicator as it depends on past experiences. For example equally valid scenarios and out of the box and/or depending on context scenarios could be: 1) Long pressing number 1 should do what exactly ? 2) Throwing the calculator from a couple of meters should not break as it may be used from kids 3) Batteries should last at least one day or more 4) Using the calculator under low lighting should still have the screen be readable 5) Pressing two buttons simulataneously should do nothing etc. Commented Jul 4, 2022 at 15:26

Interviewing candidates for a software testing job isn't all about firing questions at a person and hoping for what you believe is the right answer. You want to explore who they are and see how well they may fill any role.

Be prepared yourself

You the interviewer could also fail at interviewing just as much as the person wanting the job so its important that you do your homework first.

Make sure you know what the job is and what level it's for and tailor any questions, demonstrations or presentations towards what skills you would expect.

Knowing a little more about each candidate in advance can also be a benefit, their CV may give you a formal idea of how well they present themselves on paper, but you can easily find out more from their website / online social media presence.

Have a conversation

You're going to want to learn as much about the person as possible and you will only have a short time period to do this.

Allow the candidate to talk around any questions, find out how passionate they are for things (do they actually enjoy their field of work) and what experience they have had.

Soft skills

You're also going to want to find out how good their soft skills are, are they right for the culture of the company, will they work well within the team, and how good they are at communicating ideas.

Put them on the spot

Asking random questions will show you if they can think quickly out the box, but how about also asking them to perform a certain task without being warned in advance. This can be anything from a technical skill they have mentioned on their CV to performing to testing on a whiteboard (as someone suggested in a previous comment)

Remember you are not aiming to catch them out, but see how adaptable they are when put on the spot.

Here's some further tips for interviewing software testers on SoftwareTester.Careers

  • Hi ! The "Put them on the spot" section should be done very carefully, because the interviewer and the candidate are still two strangers and they do not necessarily want to work with each other yet. Why not first have an interview to make sure you get to know the candidate and only after you see there is a good chemistry start "playing" and cooperating to solve a problem together ? And yes playing includes putting someone on the spot, playing is competitive but can be also fun Commented Jul 4, 2022 at 14:57

Great tester asks right questions

Instead of asking questions to candidates, how about what would they ask in a given situation?

A great tester ask right questions to right people in a right way in a given context.

Example : What question they think important to ask for testing an web based financial application? A desktop application? A medical application? An internal application? A public facing external application? A legacy application? A Video game? A mobile app? A native app? A hybrid app? A game console? A single page responsive app? A combination of any of the above?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.