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