Categories
Career Testing

How to hire an entry-level tester

By Jim Grey (about)

Where I live and work, it’s difficult to find experienced developers and testers. Demand outpaces supply. So one strategy I’ve been using to grow my testing team is to hire people who have never tested.

Obviously, that means they need to be taught how to test. It so happens I like doing that! But this means I have to be able to identify non-traditional candidates who are apt to be good students.

I look to my company’s customer-service team for candidates, as those people know the software and understand the customer. But that’s not enough; I need to know whether they can be taught to test.

Faces

Fortunately, I’ve figured out four key traits someone needs to be able to learn to test and to enjoy it. The new tester must have a knack for troubleshooting, which means they are curious and persistent, can create mental models of the system they’re examining, and can develop and investigate theories of why things are broken.

Be curious:  A tester needs to notice when something is wrong and feel compelled to investigate. “Wait, what? Why did the software do that? I’d better dig in and find out.”

Be persistent:  But sometimes the investigations take a while. A tester needs to keep feeling compelled, even when the investigation stretches on. (Bonus points if they recognize when they’ve reached a point of diminishing returns, and choose a different avenue of exploration.) 

Create mental models:  Building a mental model of a system, even if it’s incomplete or partially inaccurate, helps a tester orient themselves to a problem and generate ideas on how to work through it.

Develop a theory of error:  Thinking about how the current problem is creating or exposing a flaw in the system informs the steps taken to prove or disprove the theory — and isolate bugs.

A person who’s not curious won’t troubleshoot. A person who’s not persistent won’t keep going when the troubleshooting gets rough. Troubleshooting doesn’t get very far if you can’t see how the thing you’re troubleshooting is a system and imagine reasons why it’s not working.

So when I interview testers, I ask this question, which gets at all of these things:

Think of a time you had a problem with software or electronic equipment when you tried to solve the problem. It might have been trouble with your home network, some difficulty upgrading your PC or your phone to a new OS, a misbehaving printer, or anything that went wrong with technology you use. Tell me how you assessed the problem and tried to figure out what was wrong, and what steps you took to try to fix the problem.

I ask candidates to tell me two or three stories in answer to this question. Many people can come up with one story, but someone who enjoys, or at least doesn’t mind, getting to the bottom of technology problems will have more than one story.

I’m discouraged when I hear these things in answers:

  • Trying nothing beyond obvious troubleshooting steps, such as rebooting
  • Giving up after a couple steps: “I tried a couple things and then just called support”
  • Trying things randomly in hopes one of them works
  • Fear of trying things because they might break things worse

I’m excited when I hear these things in answers:

  • Developing a theory of how the system works, including applying knowledge from other systems — “I wonder if this thing I’m trying to figure out is like that other thing I know very well”
  • Some logical, systematic method for exploring the problem, generally starting from the simplest, most probable causes and moving stepwise through successively less likely and more complicated possible causes
  • Research, usually via Internet search but also by asking someone who might know
  • Evidence that they learned something about how the system worked, and felt some satisfaction in that

It’s fine if the candidate didn’t successfully resolve the problem. What I’m listening for is whether they systematically eliminate possibilities and move toward finding root cause.

Good answers can be mundane. One candidate told me about sitting down one night to watch Netflix, but his movie kept failing to stream. He was used to experiencing a little of that on Friday and Saturday night; he knew Netflix drew a lot of Internet traffic on those nights. But because it was a weeknight he wondered whether the problem might be within his home. He knew that rebooting the Roku usually solved connectivity problems, but it didn’t work this time. So he went over to his AT&T Uverse modem to check out its blinking lights. “I don’t know much about those lights,” he said, “but I do know that if most of them aren’t blinking, especially the INTERNET light, there’s a problem.” Sure enough, the INTERNET light was out. So he tried rebooting the modem, but the INTERNET light wouldn’t come back on. He found his modem’s manual, but it didn’t cover the situation. He tried a couple Google searches for this condition, but found no useful information. Out of ideas, he called AT&T, which reported intermittent outages in his area.

The candidate’s answer showed that he created a mental model of how Netflix and the Internet work and tried the most likely causes first. I especially liked that he confidently used his incomplete technical knowledge to narrow down the problem. And I didn’t mind it a bit that he ended up calling for help — he’d first done all he reasonably could.

The rest of my interview questions look to gauge technical experience and fit for the company and the team. It’s pretty standard stuff. But without good answers to the troubleshooting question, the candidate goes no further.

So look for these four traits. They give you trainable team members.

Thanks to Rick Grey for his valuable feedback that helped shape this post.

Categories
Career Managing People Teambuilding

I believe in “A teams” over “A players”

By Jim Grey (about)

I’ve heard it again and again at work. “We need to hire a real A player for this job, a total rock star.”

crayolaqa
A test team I once belonged to, dressed as crayons for Halloween. I’m the gray crayon, natch. Our colorful dunce caps do not mean we weren’t A players!

This statement usually comes at a time some critical task or function isn’t being done well (or at all) and it’s causing projects to fail. “If we can just bring in a super-skilled specialist,” the thinking goes, “it would solve all of our problems!”

Sometimes this gets stretched into a one-size-fits-all approach to hiring. “Let’s hire only A players,” someone proclaims, “and then get out of their way and let them perform.”

No doubt about it: A players are extremely talented and deeply experienced. They are heavily self-motivated and especially hardworking. They are creative problem solvers who focus on getting the job done.

But don’t assume that putting A players on the job is like sprinkling magic fairy dust that makes problems go away. That’s setting them up to fail – and setting your company up to fail, too. Companies are much better served building high-performing teams.

A players are no substitute for leadership. The most important step in that leadership is to help your people form solid teams. I’ve been in software-company leadership roles for more than 15 years now. I’ve delivered many, many successful software projects with teams made mostly of B players. But those successes came after company leadership:

  • Created a shared, common vision that everybody rallied around and focused on
  • Built a process framework within which team members worked, which set standards for workflow, quality, and completion
  • Praised and rewarded team members for jobs well done
  • Hired for fit within the company culture, as well as for skill

A players are hard to find. A reason why I often hire B players is because most people aren’t A players. I’d say less than one in ten people I’ve ever worked with are that good. I make software in Indianapolis, which we sometimes call the Silicon Cornfield. Many of the truly outstanding geeks move to California, North Carolina, or Texas, where the opportunities are greater. But even in those places, there are only so many A players to go around. Sooner or later you have to hire B players too. Those B players will work best under strong leadership and in highly functioning teams.

A players often have the biggest egos. A little swagger is part of the A-player territory. If you don’t lead well and help them gel into a team, conflicting egos will put your projects at risk.

A long time ago I followed rec.music, a once-popular Internet forum about music. In a recurring discussion thread, members wrote about which musicians they’d put in the best supergroup ever. The debate raged – Eric Clapton on guitar, and Neil Peart on the drums, and Paul McCartney on bass, … no no, Phil Collins on drums and Jeff Beck on guitar! …no! It must be John Paul Jones on bass!

It was fun to fantasize about such things. But do you really think a band with some of the biggest egos in music would gel? I’m reminded of We Are the World, the 1985 charity song recorded by a supergroup of pretty much every popular musician of the time. The famous story goes that someone taped a sign that read, “Check Your Egos At the Door” on the recording-studio entrance – but that didn’t stop arguments over many of the recording’s details, with at least one musician walking out and not returning.

Don’t let that be your team.

Still, A players can be mighty useful. There are times when it’s right to hire A players. Here are the times when I’ve settled for no less than an A player:

  • Lead roles – I needed someone to figure out some thorny problems, and to set the pace and point the way for the team.
  • Lone wolves – I needed someone for a highly specialized job where I was unlikely to need more people in that role for a long time, especially a role where I lacked the skills to do it myself and therefore would have a hard time managing its details.

Really, I’ve never not hired an A player just because he or she was an A player. Who wouldn’t want their skill and determination on the team? I’ve only passed on A players when they would be a poor cultural fit in my company and in my team.