As a people leader, hiring is one of the hardest things I have done. I am constantly trying to balance making the interview fair for applicants vs ensuring we get the skills needed to be successful. That is why, when I have the opportunity to bring back talent we failed to retain in the past, I almost always choose that option.
Recently, because of the pandemic and other life issues, I have had several people ask to come back after moving on for various reasons. No one left because they didn’t enjoy the job, the team, the work, the culture, etc. It was all outside factors that have changed because of the pandemic. Most notably, our openness to hire more virtual candidates if it means we get better talent.
Is it worth retaining a rehire, vs looking for someone with the needed skills?
But something changes once you work with a person. You know you can get along. You know the work ethic. You understand there concerns and needs. Training a talented developer on other technology at that point seems trivial. Additionally, I find that I almost never get a developer that knows all technologies we use, and always requires some level of training. This is regardless of level or area. As a startup, we wear so many hats, there is always need for on-the-job learning. That means we have to ensure our hires can flex and demonstrate that skill during the interview process.
Typically when we hire, it takes weeks to months to find the right candidate. The level of the position changes this, but we have a tendency to not hire junior developers in my area due to the small team size, and big impact and responsibilities we have. So retraining a developer can take the same amount of time. But we didn’t have to go through the interview process. And arguable that developer is participating much earlier, even with the needed training.
It can not be understated how powerful it is to build a support network between engineers
Additionally, training and support from the team to level up another developer, is an amazing culture builder. It can not be understated how powerful it is to build a support network between engineers. It creates long term mentorship, great acknowledgment during peer reviews of code, and helps with egos.
Now there may be times this does not make sense. For example we always need to respect what the incoming engineer wants to do. For me, I specialize in front-end development and user facing applications. Working on network hardware, systems administration, monitoring, etc does not get me excited in the same way. And likewise, I don’t have the traditional background where I feel that I could jump into Swift or Kotlin development the way I can with front-end tools. And at this point in my career, I don’t need to blow up my comfort zone, as much as I need to extend and augment it.
The same is true for incoming talent. What are there goals? What do they want to do? Are they actually truly interested in the change? On the flip side, is the team ready to retrain another developer? Are they up for being a support network? Do they have the capacity to help unblock the returning hire?