One thing that becomes apparent as you progress through a career in software engineering is that the hiring process for software engineers is pretty bad across the entire industry. Some companies are vastly better than others, but in general, most don’t even do much work to evaluate the overall effectiveness of their hiring process.
What I liked most about Thomas Ptacek’s post on what they’ve learned about recruiting at security consulting firm Matasano is that they have taken a deliberate and thoughtful approach to building a hiring process. You may disagree with some of the things that they do, but you have to respect their efforts to design a process that works for them.
He makes plenty of trenchant obseverations about the problems with hiring as it is traditionally approached. For example, his reminder that being good at interviews is a skill unto itself, separate and distinct from the skills associated with being a good software engineer is often forgotten when candidates are evaluated. The goal of the recruiting process is to hire people who will be good team members, but it’s very easy to wind up hiring people who are just good at getting hired instead. The ideal processes discovers the true capabilities of the candidates regardless of how proficient the candidate is at bringing them up on their own.
Another factor that, if left unaccounted for in the hiring process, vastly reduces the quality of the outcome is unconscious bias. Not only does it lead to poorer hiring in general, it has a devastating effect on diversity. He doesn’t mention diversity in the post, everything in section 7 of the post should mitigate against the effects of unconscious bias when evaluating candidates.
His approach to phone screens is really smart. Rather than using the phone screen to try to assess the technical abilities of the candidate, he suggests using it to talk to the candidate about the team, the company, and the job, and to give them a clear impression of what subsequent interviews will be like. Personally, I hate asking programming questions over the phone, and never ask them during phone screens. I can generally get what I need from the candidate to figure out whether to proceed without doing so.
Finally, I just want to applaud the approach of structuring the interview process to reduce its adversarial nature. Obviously, the goal of the interview process is to explore a candidate’s knowledge, skills, and demeanor, but the best way to do that effectively is to make them comfortable and enable them to present themselves at their best. All too often, interviewing can be about the ego of the interviewer rather than learning about the person being interviewed. I’m glad when anyone takes steps to stamp this out.
The pleasure of building big things
Accomplishing big things takes a long time, even in the modern world of software. I was reminded of that today when I read Mike Kruzeniski’s post Jony’s Patience. Here’s the crux of it:
In a world of accelerators and frameworks and cloud services, the reminders that you can build significant companies and products very quickly are all around us. It’s worth taking a step back to remember that the really big jobs take a long time. Soon we’re going to launch a big infrastructure project at work that has been about a year in the making. In December, I gave a talk on the years of foundational work that put us in a position to even start on this project. After we launch, we’ll have a number of new capabilities that will enable us to build some stuff that has been on the drawing board for years.
Quick wins are great, but there’s something uniquely satisfying about companies, teams, products, and infrastructure evolving together into new things that can only be created with years of effort.