Recruiters, please stop asking those dumb questions and learn what software testing really is!

I was on the job market last year, I am briefly this year, and it pisses me off when recruiters (either agents or interviewers at the institution listing the job) fire-up the same useless, depressing, time-wasting questions.

The way they ask questions reflects their knowledge about the actual work of a tester: very little, if not nada, niente, nothing at all!

(c) Raz Van Constantine

Please take a minute and read what Joel Spolski wrote about WHY hiring testers and WHO should be a tester.

If you can’t read the whole blog entry, here’s the quote I want to use today:

** ** **

For programmers, getting better at what you do requires quick feedback, positive and negative, on what you’ve just done. The faster you get the feedback, the faster you’ll learn. With long-cycle shrinkwrap software, it can take a year or more to hear feedback from customers.

That’s one of the reasons we have testers. A great tester gives programmers immediate feedback on what they did right and what they did wrong. Believe it or not, one of the most valuable features of a tester is providing positive reinforcement. There is no better way to improve a programmer’s morale, happiness, and subjective sense of well-being than a La Marzocco Linea espresso machine to have dedicated testers who get frequent releases from the developers, try them out, and give negative and positive feedback. Otherwise it’s depressing to be a programmer. Here I am, typing away, writing all this awesome code, and nobody cares. Boo hoo.

Who should be a tester? That’s tricky! Software testing is one of those careers that isn’t that well known, so a lot of people who would be great at testing and would probably enjoy it a lot never consider applying for jobs as testers.

Signs of a good tester:

  • Scientific
  • Loves a good puzzle, even the kind that takes days to solve
  • Likes to think about things methodically
  • Generally likes working with software and computers

You don’t have to be a programmer to be a tester. A lot of companies want testers to be programmers who write automated test suites. It seems more efficient that way. This reflects a misunderstanding of what testers are supposed to do, which is evaluate new code, find the good things, find the bad things, and give positive and negative reinforcement to the developers. Sure, automated test suites are a time saver, but testing software covers so much more than that. If you put too much emphasis on those scripts, you won’t notice misaligned text, hostile user interfaces, bad color choices, and inconsistency. Worse, you’ll have a culture of testers frantically working to get their own code working, which crowds out what you need them to do: evaluate someone else’s code.

A particularly terrible idea is to offer testing jobs to the programmers who apply for jobs at your company and aren’t good enough to be programmers. Testers don’t have to be programmers, but if you spend long enough acting like a tester is just an incompetent programmer, eventually you’re building a team of incompetent programmers, not a team of competent testers. Since testing can be taught on the job, but general intelligence can’t, you really need very smart people as testers, even if they don’t have relevant experience. Many of the best testers I’ve worked with didn’t even realize they wanted to be testers until someone offered them the job.

If you:

  • Love software and computers
  • Want to work on a software team, and
  • Don’t particularly like programming

you should consider being a tester.

Cool job posting for a tester: a test in itself - on Fog Creek's website

** ** **

I cannot agree more with Joel!

But here is what I am facing while looking for work in Toronto:

Position applied for: QA Analyst in a Canadian bank

Question: on a scale of 1-10, how good are you in writing UNIX language?

Really? I didn’t know you’re hiring a UNIX writer.

I made a nice resume for you, why don’t you learn how to read it?

If you look in there, you will see about a dozen back-end, UNIX-like apps. For each of them I had to learn 20-30 commands to get a handle of what they do and dig for the data in there. In 2 days or less I was proficient with each of those back-end monsters.

Questions to ask instead: did you work in a back-end environment before? How fast can you learn a new BE app?

** **

Position applied for: bilingual (English/French) tester

Question: on a scale of 1-10, how good are you in speaking and writing French?

I tested 4 major applications for major Canadians companies (pharma and banks) in French. My name is all over the place on the French bug-list. While doing this I spoke ZERO words in French, wrote ZERO words in Frech. ZEROOOOOOOOOO!!!

So why do you ask me about speaking and writing French?

Writing French is for editors.

Speaking French is for telephone customer service.

I speak poorly in French, but I know French grammar better than many of the native French-speakers that I met.

Questions to ask instead: how did you test the application in French?

** **

Position applied for: QA Lead for a Canadian retailer

Question: what is the difference between SQL commands LEFT JOIN and RIGHT JOIN?

I’ve been using a SQL tool for more than 5 years now, every day. Be it SQL Developer or TOAD, every day I turn on the computer at the office I open the seehquel tool.

But I am a tester -> testers don’t write queries! Damn it, even BAs don’t write queries, they write the business logic for that report!

That’s why we pay the licence for the damn tool, and that’s why we give testers and BAs read-only access to the tool, so they can use it without too much fuss about their SQL language skills.

We, testers and BAs, need the Database/Schema/Table/Primary Key  information and we’re ready to go.

If I need to see the data in the table, I click the DATA tab in SQL developer, I don’t write a query.

I go to the table, I filter/order  and  then I can validate my data.

I may use SELECT, TO_DATE, COUNT, DISTINCT, TO_DATE, TO_CHAR, but that’s about it.

I don’t have to do JOINS.

If I have to look in more than 2 tables, I will stick to SELECT and use column names.

THAT’S ALL THE SQL testers need to know.

So why do you give me a friggin SQL test at the interview for a tester position???

Why do you ask me what’s a stupid command doing in an interview for a QA???

Because you have no clue how testers use SQL tools.

I am passionate about QA, and I learned SQL to the level I can read the code and understand it.

But if I have to write a SQL query in more than 2 lines, my dev friend will write it for me and save both of us time.

Questions to ask instead: have you ever used a SQL query tool, such as TOAD? How did you use it?

And so on…

The interview is not a 1-way tool. It also helps the tester to decide if he wants to work for that person.

If you don’t know how testers work but you’re a QA Manager interviewing a tester, please, please stick to the deliverables listed in his resume and see how they match to the tasks in your job description.

And if you want to give him a test during the interview, ask him to write a test case: I’ve seen so many testers with lots of coding skills in their resume but unable to articulate a simple test case.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.