I don't think I had many testing job interviews. Less than 10. I am with my 4th employer. But how many is many?
On my first software testing job interview my future employer did not ask me standard questions related to testing like:
- What software development methodology did you use?
- What's the difference between validation and verification?
- Could you tell us about your experience with automatic testing?
- Are you an ISTQB certified tester?
I had a non-tech-related background and the answer to those questions would probably be: "I have no clue, sorry".
The fun began, when I was looking for my next employer.
How would you test a clock? A pen? A paper cup? A soda machine?
When it comes to soda machine, you probably have a rough idea on how to test it. You would possibly like to check at least if:
- the alphanumeric keyboard/buttons work as intended
- it accepts the currency it was intended for
- if it accepts real money
- it accept cards?
- it doesn't give the soda cans for free
- it returns the correct amount of cans for the value of money inserted
- it returns the right cans of soda
- it returns the correct amount of change (if needed)
But for the other inquires I asked miscellaneous sets of questions in return:
- What kind of clock? Digital, mechanical, online or maybe sundial?
- What kind of pen? Ballpoint, gel, rollerball or ink pen? Or maybe a quill?
- What kind of cup? For hot / cold beverages? How many milliliters will it fit?
Those replies were not necessarily wrong. The first question however should be: "What does the client want to do with that clock / pen / cup?"
Maybe the client intended that the paper cup is not to be drink from, but to be shot at from a rifle in an amusement park?
Maybe the pen was ordered by NASA to be used in space for writing purposes?
Maybe the clock will be a colossal monument of astrological clock, celebrating Richard of Wallingford?
Those "weird" questions' main purpose is to show the recruiter the way you think. But the client's and / or the end user's context is an important factor and it will reflect on the end goal - the quality outcome. Having a solid grasp of the actual product requirements makes the use cases, the entry and exit criteria, and every other testing activity much easier and relevant to the case. As such, the questions that seem strange to ask the candidate on an interview at first, serve their purpose.