(read more here) 

What is the first key to qualifying tech talent?


The first thing you want to do is understand the “Why.” A lot of new recruiters start off just looking at the “What.” If a hiring manager says ‘we need someone that knows Java,’ that really doesn’t tell me a lot as a tech recruiter.


As a recruiter I need to know the “why.” Is this person going to be doing embedded development? Mobile development? In which case, they may be looking for someone with Java ME. That might not be reflected on a resume, but it’s something that if I understand the technology and what they’re going to do with it, I then know what I should specifically be looking for.  


Alternatively, are they going to be using Java for enterprise level software systems? In which case they will need to know Java EE. Understanding the “Why” is almost important as understanding the “What.”


What else are you looking to understand about the candidate?


I also want to know what role this person going to be playing within organization. There are extremely talented developers that have experience writing massive code. Millions of lines of code. But all they want to do is come in and do their thing. They’re really not interested in growing and grooming and mentoring others. So, is the expectation for this person to be leader of the team or just another horse on the team? Conversely there are other engineers that really want to share. They really want to grow and groom the next generation of engineers.


What else would be helpful for the hiring manager to understand about a candidate to make a hiring decision?


When we look at skills, what is the role someone is going to play on a team? There are attributes and characteristics that someone might bring to the table that might be extremely valuable. Do they work or come from a company that has a unique methodology for example? Or are they using a tool that is hard to find or complex to learn that they could then bring in house to the organization?

If you look at Google for example. Google tasked engineers that if you were to look at the operations function as an engineer. How would you create that function? How would you create highly reliable, highly scalable sites from an operations perspective. And from that the term site reliability engineer has now been adopted and something that Google is driving. A lot of companies are starting to look at now how do we move beyond DevOps. How do we move into site reliability where we’re building ultra scalable sites like Google, Amazon and Twitter.