What's the best piece of advice a tech leader can give when identifying software testing resources for their team?

For me its an individual who is able to communicate effectively, who is curious, and who is an effective problem solver- hits a wall, then works smarter not harder to climb, go around or through it!

Also agree with some other points made around a person having some basic coding skills and experience!

Consider ease of use. A key criteria you want to keep in mind is that technology should at it's core make things easier/simpler. If you select a piece of technology and someone on your team that manages it quits the next day, how quickly will the rest of the team pick it up or will it stop in it's tracks? Thats the question you want to ask yourself as you evaluate all new software. Nothing worse than getting tech that is difficult to manage and having critical team dependencies that you can't easily replicate. 

For me, it's two things: Having a process driven approach, and having strong communication skills.  Being process driven ensures that any bugs or clarifying tasks have the needed descriptions and data for the rest of the team to follow, and allows us to determine whether the testing scenarios match the business processes that are being validated.  Strong communication skills are key because we want to ensure that testing findings or suggestions are clear and understood.  Some testers are not always able to articulate their findings or process, which results in additional work for the rest of the team.  

Courage is high on the list for me.  

My best QA people over the years by far are the ones who will speak up, ask clarifying questions, point out when people in the room aren't paying attention to the details, and who hold their peers accountable to quality standards. 

We do both manual and QA automation at our company, but our QA people operate more as "consultants" than people who do the majority of the QA lift. We changed our process in Q4 of last year are seeing fantastic results from the change.

The way our QA process works now, QA, devs, and product folks confer on a ticket and agree that the change they're going to make is testable, and that a basic direction on testing the change is well understood. Developers largely test their own work, manual and automated, and are expected to keep notes on what they test and how. QA reviews those notes, suggests improvements or other tests as the work is closer to completion. 

We found that in our old, more traditional QA process the learning feedback loop was broken for engineers. This was especially true during periods of rapid development and for minor bugs. It was easy to say "yep, that's a bug" without digging in and figuring out how you wrote that bug and how to guard against it in the future.  

With the new process, we are seeing only slightly slowed development pace, but the bug-rate in newly released code is down by 2/3rds. 

When we hire testers, we must look for  -

1. Ability to understand the requirements (do they have taste in the mouth?).
2. Attention to details.

If they know test automation, it's a big ++.

We would send UI of amazon.com or Gmail etc, UI of well-understood services and ask the candidates to come up with possible test scenarios and cases. It is quite revealing to see how superficial most of the candidates are, and also it is pleasantly surprising to see how detailed some of them are. BTW, though it appears quite cumbersome, but it is not. One can quickly figure out who is bad and good.