Tag: hiring

Categories
Diversity

Juneteenth: are we really woke this time?

By Jim Grey (about)

I published this on my personal blog yesterday, Juneteenth 2020. It has a message for the people I try to reach with this blog, as well.

My dad was the sole white member of the Dr. Martin Luther King, Jr., Senior Men’s Club in my hometown of South Bend, Indiana. Dad was interested in economic development in the city’s depressed west side, where he had lived as a teenager. He worked with a few west-side groups trying to move initiatives forward, and the Men’s Club was one of them.

Through this, I think, he became aware of the challenges black families faced in South Bend. Whenever I’d see him he’d eventually steer our conversations toward those challenges. He could talk for hours about them. As a dyed-in-the-wool Republican he always advanced conservative solutions. The men of the Men’s Club were Democrats to the core and vigorously disagreed with Dad, but they came to like him anyway.

This is how I first heard of Juneteenth. There were celebrations every year on South Bend’s west side, and my parents always went to them.

I work in technology, specifically in software development. This industry is overwhelmingly the domain of young white men from the middle and upper classes. Where I work now, we have the most diverse team of anyplace I’ve ever worked. That doesn’t mean it’s highly diverse — we just have some women and a few black people on the team. We also have several immigrants from India and China and a few old white guys like me. That’s enough to set us well apart.

The murder of George Floyd by police in Minneapolis was the one-time-too-many that finally captured this nation’s attention. People of all backgrounds are saying enough. It’s time to treat black people with the same dignity and respect that is afforded white people.

At work, leaders have been talking a lot about how to improve the diversity of our team. Because I follow a lot of Indiana tech companies on LinkedIn, I see through their updates that they are having the same kinds of conversations.

I see it as systemic that our industry is made mostly of young white men. Most jobs either require or favor a four-year engineering-related degree. In my experience, that’s overwhelmingly the domain of young white men of some means.

Technology companies should eliminate the degree requirement. Then they should invest in training and apprenticeships. Yes, let’s apply the old trade model to technology. At least in software development, there are coding academies that teach the basics. Companies can band together to create scholarships to those academies, and heavily recruit people to those scholarships who are not young white men. They can then bring graduates on board and show them the ropes on the job.

Personally, when I have an opening on my team I scour LinkedIn for people who aren’t young white men and I recruit them. Plenty of young white men find my opening on their own. I’m still selecting from the pool of people who are already in the industry, blocking people who want to get in but don’t yet have the bona fides. But it has led to my last two offers going to a black software engineer and a woman engineering manager.

Out of the blue, my company this week announced that they are giving us this afternoon off to celebrate Juneteenth. My brother works for another local tech company that has one-upped us: they’ve made Juneteenth a paid company holiday, starting this year.

I’m cynical. Are we just signaling virtue? Will we actually carry our discussions about diversity through to action?

None of the social welfare and justice initiatives Dad was involved in drove lasting change. It was an uphill climb, and it required persistence and cooperation beyond what my father could arrange. The same persistence and cooperation is required to drive diverse hiring in the tech industry. It’s also needed across the United States for the good of our whole nation.

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.