How the best managers find hidden tech talent

For all the talk of “rock star” programmers adept at the latest and greatest languages and development philosophies, experienced tech recruiters say they look for more than particular skill sets when they hire. And what many of them most definitely don’t want are some of the qualities associated with “rock stars” who, for all their talent can also be narcissistic divas. That can be destructive both to themselves and others, including software development teams.

Several tech execs and team leaders say that they, of course, want to hire people with sharp tech skills, and pedigrees from top schools like MIT, Berkeley, Harvey Mudd, Harvard, and Stanford. But they also look at more intangible qualities, including the candidate’s mind set, sense of curiosity, and willingness to work on a team.

It’s not what recruits know but what they can learn

In aggregate, their comments could be summed up as: “Hey, we can teach the skills we need provided we hire bright people who want to learn.”

Many companies still focus on people who are experts in a given programming language. Java, JavaScript, Python, and Perl are perennial favorites, according to the Redmonk Programming Language ranking.  But as the rankings also show, newer languages (such as Go or Kotlin), can come on fast and strong. So, fielding an adaptable, quick-study team of developers is helpful.

Technical skills are table stakes in this game, a minimum requirement, says Ryan Grisso, group vice president of engineering for Oracle’s NetSuite Global Business Unit. More important than specific language expertise, he adds, are skills in broader object-oriented design skills and in software architecture.

Mariesa Dale, an experienced product design manager who has worked at Pivotal and elsewhere, says she looks for candidates who come with empathy and open minds. And she acknowledges that sometimes sparks pushback.

It is, she says, not uncommon to hear: “Hey why are we talking about feelings? I thought we were building software.”

To which her standard response is: “Well, yes. But we’re not just building software here. What we’re really doing is solving problems for people. It all comes back to that.”

Understanding people and how they use software is critical to the success of an app, says Jonn Nolitt, vice president of recruiting for Oracle. “I can have the greatest app that does everything but at the end of the day if it’s hard to use, then people won’t use it.”

Dale, the design manager, also likes to recruit people who have what she calls “strong opinions, lightly held.” That means candidates who have their own views and can communicate the justifications for those views clearly. But equally important is their ability to listen to other opinions and realize that their own take may not always be best in a given situation.

Expand your recruiting range

Every company hits up the aforementioned schools for tech talent. That fierce competition for those top pedigrees makes it smart to look beyond the usual fonts of tech genius for talent. Community colleges and vocational technical schools can be fruitful hunting grounds.

For example, Matt Sheppard, engineering manager at Oracle’s Dyn Global Business Unit in Manchester, NH, says a developer he hired out of a New York City boot camp with no formal degree is one of his most productive developers.

Since colleges are moving beyond the traditional “computer science” nomenclature, if the candidate comes from an unfamiliar school, Sheppard asks about classes and projects the prospect has completed.  Getting candidates to talk is very valuable because the interviewer gets a sense of what they have actually done and how they think.

Any candidate who has a strong background in non-computer engineering and math is worth a look, even without a B.S. in computer science. Again, the key point is that new hires with good foundational knowledge can pick up new task-specific skills.

It is more important for a candidate to think outside the box in solving problems than to sport a fancy degree, several execs said.

 “The job of a software engineer is not to memorize academic knowledge but to be a creative problem solver,” said Sylvain Kalache, a former LinkedIn senior site reliability engineer who went on to co-found the Holberton School in San Francisco, to train software developers of the future.

He also warns against legacy thinking that equates helping out another person with cheating. Collaboration should be championed, not punished, he said.

Steer clear of jerks

Many successful teams in and outside of tech adhere to an unwritten but strict “no a**hole” rule.  It’s hard to overstate how important this is.  People who are empathetic and listen well are less likely to act inappropriately, mistreat others, or be territorial about work than folks who act like entitled jerks.

 “Teams that trust each other work better,” says Sheppard. He red flags people who ridicule others or point out mistakes in a derogatory way.

Make recruiting a team sport

While managers usually have the final word on hiring, good ones will include other stakeholders, including would-be colleagues, into the interview process.

A manager might focus more on character and background, while a developer can drill down into specific tech skills and ask candidates how they would solve a particular problem.

Mobify, a Vancouver, BC-based mobile e-commerce technologies specialist, uses a structured interview process with a set question list to get candidates to illustrate their problem-solving skills.

It also uses a combination of one-on-one and group interviews depending on how senior the position is, says CEO and co-founder Igor Faletski.

A candidate who makes it through the first rounds is then brought in to work with a team at the company on an actual problem. Nothing shows how well a person will fit in than actually working with them.

As competition for talent heats up, top recruiters are adapting their recruiting criteria. Paradoxically, they may end up finding gems that traditional searches would have overlooked – often to the detriment of the teams they’re trying to build.