An idea - that can ruin your credibility and sometimes your career!

Recently, I opposed giving written tests for interviewing testers for hiring few testers for my team. I screened resumes, I shortlisted people from non-computer science backgrounds, I opted for people with tech support experience, I did many things the unconventional way. I experimented a bit with the hiring process as I have “some” power to suggest changes to the existing process or so I thought.

When it came to selecting candidates for 4 vacant positions out of 35+ candidates, the easiest means of evaluation was a written test. When I suggested that we give a sample program to test with a mission, evaluation took centre stage. “It is hard to evaluate subjective tests”, “it’s easy to give multiple choice questions”, “we don’t have so many people to evaluate the test papers”, “In testing, since there is no one standard answer, we might not be evaluating the test papers uniformly hence resulting in unfair evaluation” and many more. Atleast, I was given a chance to suggest a program. A rather small win, but a big one for me.

Once I finalized on a program (with due credits to the program author) and came up with a list of bugs, I sent it to hiring team for review. They had enough time to build their own impressions about the program. When we met, it was a completely different scenario. I was so delighted to know that many of them had found some bugs in the program already. Awesome. Isn’t it? May be, not so awesome. Some of them had memorized the bug list I sent rather than executing the program. Ah! The same way that our educational systems have trained us to learn – by rote.

Mistake 1: Give them a problem and give them a solution. Why will anyone think about solving the problem? There was this big fight over how dirty the program was and how it did not help find any logical bugs. All it had was UI and usability bugs which we anyway live with, sometimes for the entire lifetime of the products. This was the collective opinion from the group.

Mistake 2: I was offended when people made fun of the program without testing it on their own. The general consensus on the program was that it is too easy to test and hence should not be considered for testing testers’ skills. How easy it that? Easy compared to what? No answers, just reactionless faces!

Mistake 3: When a young orphaned QA team (without a QA Manager) handles the hiring process and a couple of Dev. Architects and managers take over the process of leading such a process, it’s harmful because it becomes an exercise of rating testers versus programmers. Though our Dev. Friends were kind enough to help us with the effort, it was hard to convince them that the chosen program need not look complex and can appear to be easy, yet help us rate testers based on their skills.

What next? Here is a testing questionnaire that could be given for testers (as if testers didn’t know how to scout for such documents on the internet). I had the shock of my life when I saw some questions which was similar to asking someone “If given a chance, which eye would you poke? Left or right?” I am dead against (am I rude? Of course Yes!) such questionnaires and after a little struggle within the team, we came up with an idea to provide a problem statement/test scenario which candidates could solve on a sheet of paper. The next two days went in discussing whose problem statement to solve. Finally, one was chosen. The plan was to provide a problem statement and a mission for the candidates to test. All set for the big day.

Mistake 4: I did not mind the fact that something that I suggested did not work. I was angry and offended that it was made fun of across teams to an extent that the program was called a dirty little program. How mean? I failed to negotiate. I failed to show value of the program.

Biggest Mistake: Many testers who want to bring changes within the organization are nipped in the bud. It’s not necessary that everything be accepted, but one shouldn’t make fun of the effort some people take to come up with an idea. Such people who get frustrated over a period of time either become reputed system dummies or leave the system to become their own bosses (Independent Consultants). Trust me - you wouldn’t mind if a consultant you hired by paying a fat paycheck told you to use the same dirty little program to hire testers. You would have said ‘Wow’!

Whenever an employee comes with an idea, ask “How can the idea help us perform better? Why did the idea come from this person alone? Why not someone else? What is the value that a new idea can bring in? Can we make changes to make it better? Can we brainstorm instead of identify dents in the effort? Should an idea be encouraged only if it came from reputed employees in the organization? Can’t a freshman suggest something reasonable? Don’t new employees come with a fresh pair of eyes?” (A big sigh). Just question marks.

Have you observed how sugarcane juice is extracted? Once done, have you seen the leftover sugarcane? This whole thing about sticking to traditional hiring processes is like taking juiceless sugarcane and extracting juice from it by adding water to it for the next few decades. Are you game for following such a process?

Next time you suggest an idea, Beware! Be well prepared.
Regards,
Parimala Shankaraiah

Auditioning for a Tester’s Role – Part II

Part I witnessed some really interesting comments. If you think Part II will be a pocket book on ”How to Interview Testers”, then you may want to stop reading this post right now.

I interviewed one person on telephone recently where I asked him to test a marker he claimed to have in his hand. He was shocked, “What? Test a marker?” He intended to say “Do you mean I’ll be testing markers in your organization?”

What is the solution? By the way, what is the problem? Interviewers, Interviewees, Who else? It’s the system we have lived with for years without questioning. Ok, the system has worked for many decades. So what? Why not change the system? Why not try?

Why not audition testers?

Have you ever attended a music concert? Have you witnessed an Arangetram? Musicians/Artists/Actors – these people don’t interview for jobs. They perform - in real time. They AUDITION.

Volunteer to test in an interview. Ask for a testing mission. Ask for stakeholder requirements. Ask questions. Get your doubts cleared. Explain your test strategy. Execute your tests. Summarize your test results. Is this so hard? It is if you have tested one module for 3+ years and did not think of anything else at your day job. Think out of the box about what’s inside the box. Keep looking out to learn and explore. Challenge yourself before someone else does it to you. Challenge others to challenge you as often as possible. Write about your experiences. Learn from your mistakes. GROW with time.

If we claim to be passionate to test, why do we shy away from testing in real time during interviews. Why do we express shock when we are given a mission to test? Why do we say “I have never leaked a bug till date” when asked “What will you do if a bug gets leaked into the production code?” What are we scared of? Not getting a job? Not getting good pay? Good designation? How much good enough is the good that you are willing to have?

Never say Never,
Perform in real time,
Audition!

Regards,
Parimala Shankaraiah