The Rockstar Ninja Coder And You
I have been doing tech recruiting for start-ups over the last 10 years and oh boy, did I fuck up a lot. On the plus side of things, I did also learn a lot about human behaviour, hiring bias and common misconceptions about what constitutes a “good” team member.
I have seen the biggest douche bags called the “top performers” and the actual performers “constant underachievers”. Actually that’s a pretty common topic I have seen across many organisations. Human perception is pretty freakin’ bad. We overvalue merits that are tangible and undervalue merits that are kind of fuzzy. Take the “rockstar developer” for instance (sometimes also called a ninja). People refer to a “rockstar developer” as to somebody that is exceptionally skilled and that literally carries the whole company on his back. Unfortunately that’s not all: A “rockstar” is a rockstar for a reason and only rarely communicates with mere mortals. Most senior team members I have ever talked to or read have a strong aversion towards those rockstars (with statements like “bratty prima donna” being quite common).
But this doesn’t mean that the terminology is used any less in recruiting unfortunately.
A classical set up I probably have seen dozens of time is that one of those rockstars delivers this super useful new backend feature that will be used on the web frontend everybody has been waiting for.
Problem is that he didn’t really care about communicating this. QA is missing. Normally not an issue since developers work in a squad where QA is a part of the team (you’re doing this, right?) but that rockstar never actually fit in anywhere so you kind of let him work on his own. Supervision by the product team was spotty at best since nobody really got along with our rockstar and so on and so on.
Fast forward 6 months: The feature is still not live, everybody involved is highly frustrated and the first team members are starting to click on the latest “Looking for a new challenge?” linkedin contact requests.
Now there are obviously a lot of things that went wrong (and not just with that single developer) but in most cases the overall perception will be that the rockstar developer delivered. While the other teams failed to so.
So how can you make sure this doesn’t happen to you?
Apart from the organisational problems the obvious solution to this is not hiring those kind of guys. The problem is that common recruiting wisdom says to look for developers that are technically capable first and then look for their so called “soft skills”, which is a very fuzzy term roughly translating to “the candidate should not be an obvious asshole”.
I think the way most companies evaluate candidates for tech jobs (probably for all jobs) is upside down.
Conventional recruiting wisdom is outdated and broken
It’s easy to fall prey to conventional recruiting wisdom because it offers you the quickest reward possible: It will get you a lot of candidates fast because common recruiting wisdom relies on a couple of core metrics that you can easily train on your HR intern in an hour or two.
The problem with all of those metrics is that they actually don’t mean anything.
Take “Proficient in language / technology / eco system X” - a vanity metric. You can do anything for 10 years or more and still suck at it if you have not embraced constant self-improvement and life-long learning.
Show me code. Show me your open source contributions. If you don’t have any, fine by me. A blog where you have written about your latest learnings works as well. Or an active conference life you tweet about. Or you attended a user group and maybe even did a presentation. Literally anything that shows that you actually care about what you do would suffice.
Somebody saying he has 10 years of experience in X with no traces to be found anywhere on the web except in his CV is probably not the guy you want. Good news is, you can train your HR team how to get a first impression about a candidate’s technical skills without being technical themselves. Bad news is, this costs more time so it is not as rewarding as quickly ticking off a checkbox that says “can code in Ruby”.
“Cultural fit” is something else that seems to be extremely important to most companies because they know that creative knowledge workers need to get along in order to really function well. At the same time, this is also the most fuzzy metric and sometimes it seems almost intentionally so.
I have rarely seen a company that actually had a thorough list of soft skills they were looking for in a candidate even though they would claim it was one of their top priorities.
So what should you actually look for in a candidate?
Empathy is king
There was a fascinating article in the New York Times recently that was called “What Google Learned From Its Quest to Build the Perfect Team”. Google had been trying to find out what kind of behavioural patterns all their successful teams shared. To their surprise, all the obvious metrics failed. Common wisdom like “Put the best guys in a room and let them figure it out” did not work out sometimes and they couldn’t really figure out why. Then, after years, they realised that all successful teams shared 2 traits:
As the researchers studied the groups, however, they noticed two behaviours that all the good teams generally shared. First, on the good teams, members spoke in roughly the same proportion, a phenomenon the researchers referred to as ‘‘equality in distribution of conversational turn-taking.’’ On some teams, everyone spoke during each task; on others, leadership shifted among teammates from assignment to assignment. But in each case, by the end of the day, everyone had spoken roughly the same amount. ‘‘As long as everyone got a chance to talk, the team did well,’’ Woolley said. ‘‘But if only one person or a small group spoke all the time, the collective intelligence declined.’’
Second, the good teams all had high ‘‘average social sensitivity’’ — a fancy way of saying they were skilled at intuiting how others felt based on their tone of voice, their expressions and other nonverbal cues. One of the easiest ways to gauge social sensitivity is to show someone photos of people’s eyes and ask him or her to describe what the people are thinking or feeling — an exam known as the Reading the Mind in the Eyes test. People on the more successful teams in Woolley’s experiment scored above average on the Reading the Mind in the Eyes test. They seemed to know when someone was feeling upset or left out. People on the ineffective teams, in contrast, scored below average. They seemed, as a group, to have less sensitivity toward their colleagues.
I had never thought about it this (apparently nobody had) but in hindsight, this seems to make sense, doesn’t it?
If you’re now thinking “damn, I’m not the most emphatic person on this planet for sure” like I did after reading this, don’t worry - like almost all other skills you can learn empathy as well.
Chad Fowler wrote an excellent article on the subject with a lot of good advice on how to develop your empathy skills. You also might want to check out “Six Habits of Highly Empathic People”.
Communication
Communication skills is probably one of the fuzziest attributes in all soft skills. There’s a surprisingly thin line between a succinct mail sent out to all stakeholders and huge fyi mails by default as part of a “cover your ass” mentality.
What makes for good communication?
- Being succinct but still assuming that your receiver has little knowledge about the topic. Yes, that means you should always start with a short introduction and not jump right into the middle even when you think that all stakeholders already know what it is about. Because there’s a high chance they don’t when you just assume context.
- Knowing whom to include
- Maybe even more important: Knowing whom to exclude because the topic is not relevant. I think Jeff Bezo’s 2 pizza rule does not only apply to meetings, it applies to communication in general (with the rare exception for topics that really are of interest to a broader audience)
- A lot of other attributes like bias free communication or being able give and receive feedback
Bottom line here is, all of those attributes should be part of your hiring evaluation as well.
Motivation
There was an interesting thread about being highly productive on hackernews a while ago.
One of the top comments caught my eye:
I’m a 10x developer most of the time. It’s all about motivation. When I’m producing 10 times as much as my peers, I’m working on something I want to work on. I can go all day without visiting facebook, reddit or hacker news, because I simply would rather be working than be reading those sites. Any time I see these kinds of articles that tell you to have “discipline” to not read those kinds of sites, I think they have it all wrong. You’re only addressing the symptom. When I’m forced to work on something I don’t think maters, I’m not a 10x developer. I’m really obsessed with code quality, so any task that involves refactoring, I am 10x or even 50x. If the task is to track down a complex bug in a PHP system, and I’m under strict orders to not refactor anything (which is common), then I will be a 0.01x developer. With my personal projects, I’m always 10x or more.
The key part here is
When I’m producing 10 times as much as my peers, I’m working on something I want to work on.
Great, so let’s just hire motivated people only and the problem is solved!
That sounds like an empty phrase and it is one indeed because probably nobody would disagree with it. But I’ve almost never seen any company that actually really made this a relevant attribute in their hiring process.
The biggest problem here is that getting highly motivated candidates implies a high degree of transparency and openness from the organisation itself. You can’t expect a developer candidate to be highly motivated when you’re closed up about your tech stack, now can you? You can’t expect a product guy to be motivated about your product if everything is hidden behind registration walls and key account managers that vet you before anything else.
We can’t all be like buffer and their transparency policy, granted. It is worth trying though, if it’s for your candidates only.
Problem solving attitude
There is a certain type of people that is especially prevalent in big corporations. The kind of people that you approach for help with one problem and after you come back from them you realise that they didn’t help you at all, but instead tried everything in their power to push back. Sometimes they even managed to give you more problems.
People who lack a problem solving attitude will always try to find reasons not to do things instead of looking for ways to do things. The reasons for doing so can be complex but in most cases I have seen (including my own!) it boils down to being insecure in your own abilities (so a lack of self-esteem) and being afraid to leave your own comfort zone.
Good thing is you can develop such an attitude. There are probably gazillions of articles about this topic out there. I personally believe that developing a growth mindset is the most important aspect, but maybe that’s just me (and if you haven’t read it, now would be a great time to check out Carol Dweck’s awesome book)).
Proactivity
A lack of proactivity goes a long way. Simple cases like “Yeah, our monitoring showed some weird numbers the hours before the downtime but we were hoping it would eventually go away and after a while it seemed like it had fixed itself” are the most obvious. More complex cases involve just doing enough so that you can’t be simply called lazy and staying strictly inside your comfort zone. Those cases are harder to spot but at the same times those are the ones that do the real damage since they will waste the time of other team members as well.
Proactivity is also listed as the number 1 habit of highly effective people.
Experience
There’s a quote from Thomas John Watson Sr., first CEO at IBM and inspiration for name of Watson (computer):
Recently, I was asked if I was going to fire an employee who made a mistake that cost the company $600,000. No, I replied, I just spent $600,000 training him. Why would I want somebody to hire his experience?
You can learn everything for sure but there just things you need to have experienced yourself. You need to have shut down the production database accidentally to really understand that you need to be careful what console window you’re typing in what. You need to have written that bad bug that killed your booking funnel to understand that QA needs to be an integral part of your workflow.
As a future employer it’s obviously best if you have made those mistakes already ;) Making “What was the biggest fuckup you caused in your professional life?” one of your standard questions in the initial interviews with a candidate can help you to get a better feeling for the candidate’s experience. If he goes blank he’s either extremely diligent or (more likely) not as experienced as he pretends.
Structured and analytical approach
Do a lot of your projects look like this?
We’re humans and humans will go for the quickest reward possible. And what’s the quickest reward in software development? Programming. Doing something. Getting shit done. Problem is that often you don’t know what “Getting shit done” actually means. Usually you need to talk to a lot of people, understand problems in depth, research possible solutions, read up on things, prepare an action plan of how to do things and why. Which is something that is not particularly rewarding and in worst case so painful, that people shy away from it.
Someone with a structured and analytical approach will do all of the above and more before even writing one single line of code.
Technical knowledge
Alright, so here it is: Technical knowledge is the least important attribute I’m looking for in a developer.
Why?
Because over the years I found out that it’s way harder to develop skills like empathy than it is to develop technical skills. Somebody who is diligent and analytical, has the energy and the drive, communicates well with the team and knows how to deal with people in general will pick up tech skills fast. Very fast.
Focus more on potential than on history or talent
Quite often we are obsessed with looking at what a candidate can do right now. Sometimes we call it skills, sometimes it’s called talent.
I think we should be more focused on potential (“what could the candidate be capable of”) instead of the history (“what has the candidate been doing”). Given you are motivated, you can become good at anything in a reasonable amount of time (mind that I said “good”, not “excellent” - that would be another story).
Recap
What we covered today:
- Conventional hiring wisdom is flawed at best because it overvalues tangible features and neglects intangible ones
- The fuzzy term “soft skills” is frequently undefined and as such often way underrated
- Tech skills are overrated
- Care more about the potential of a candidate than about the status quo
The next questions we should now look into are probably:
- How do we find people that fit the profile above without scanning thousands of people?
- If the attributes above are not tangible, how do you actually select people based on them?
- How do we get them into our recruiting funnel?
Those questions will be the topic of the next articles.