Pluralsight’s virtual hack.summit() event started yesterday, and I managed to follow most of the sessions. The last session was by Hampton Catlin (“Created Sass, Haml, m.wikipedia.org, and book author") on the topic of “How (not) to Hire”. The session is partially a reflection on the success of past hires, but also the sharing of alternative and (lots of) interesting ideas on how to hire people/developers.
One of ideas I thought was most relevant was that you WILL do bad hires, and that you should face the idea of letting people go as naturally as possible: “It’s your job as a manager”. I’ve had to do it in the past, and it’s not easy, but he’s right. “What are you afraid of when hiring someone? that he’ll bring down the company?” These questions frame the process in a “lighter way”: you don’t have to get it right at first, and should accept that you'll make mistakes. I guess most of us are so cautious when hiring because of the effort/time associated, but also because of the failure itself and being associated with it. I’ve both done bad hires in the past, and also seen the “stigma” associated with it in a colleague, so accepting that mistakes will inevitably happen should be in our minds to avoid this - no mistakes, no learning.
Another relevant insight from the session was the difference between Positive and Negative hiring. In Negative hiring, you try to find problems, reasons NOT to hire. In Positive hiring, you try to find out how awesome someone can be, what are his strong points, how he can make a difference. I bet most of us that hire follow the first approach (me included). He says that he used to follow the “Veto Rule”, whereby if anyone on the team wasn’t convinced the interviewee was awesome, they wouldn’t hire. This is exactly what I did for most of my career, on the footsteps of “Peopleware”’s recommendation to involve the team in the hiring process. An alternative approach, he mentions, is the “Believer Rule”, whereby if anyone on the team is really convinced someone would be awesome, he should be hired. The truth is probably somewhere in the middle, but this a great idea.
Catlin also advocates that you should hire mostly depending on someone's ability to work as a team/collaborate, and not only technical skills – “It’s easier to teach code than it is to teach empathy”. This is true, but I’d say there must also be a technical baseline.
Another idea, and this was to me the most interesting one, was the suggestion that candidates themselves should design their own hiring process, giving them a chance to show off and see their best side. What the candidate chooses is obviously a clue into what his strong and weak points are. I find this idea brilliant, and will keep this in mind for the future.
Another suggestion that he gives is that just discussing technology with candidates is a very effective way of assessing the person, and his/her passion, interest and skill in technology. Asking about some specific project, what they think of Azure vs AWS, or of C# vs Python, etc.
Finally, during the Q&A there was another interesting insight, or framing of the hiring process overall. Some companies (I think I’ve read about Google doing this) try to hire people that are better than the average of the company, constantly “raising the bar”. The insight is this: if you keep doing this, at some moment in time you yourself should NOT be employed at the company! :)
Anyway, lots of good ideas in the session, to keep in mind for the future.