editione1.0.8
Updated August 24, 2022You’re reading an excerpt of The Holloway Guide to Technical Recruiting and Hiring, a book by Osman (Ozzie) Osman and over 45 other contributors. It is the most authoritative resource on growing software engineering teams effectively, written by and for hiring managers, recruiters, interviewers, and candidates. Purchase the book to support the author and the ad-free Holloway reading experience. You get instant digital access, over 800 links and references, commentary and future updates, and a high-quality PDF download.
This section was written by Scott Woody.
One of the bigger sourcing opportunities for technology companies lies in the nontechnical staff they already have. We have seen successful companies convert non-engineers into engineers through thoughtful application of an internal conversion process.
Promotes nontraditional backgrounds. Engineering teams tend to be a monoculture of people from the same tech companies and top CS programs. Supporting people already familiar with your organization can be a great way to bring different backgrounds and ideas to your team.
Cultural risk is mitigated. Internal transfers are already employees, the cultural risk goes way down if you convert from internal employees.
Faster time to hire. Gauging interests, coordinating interviews, and getting references can be much faster when the candidates are “in the building.”
Internal mobility is a morale win. Internal mobility is one of the best ways to ensure that top talent feels like your company will always be their home.
Insights and motivation. Because they have experience outside of engineering, engineers who come through this channel have unique insights into product development. Additionally, because this process is so out of the norm, these engineers tend to push themselves to learn and grow at a faster clip than most new engineers.
Before the interview you want to put up some filters to ensure that the candidates who interview are likely to succeed in the process, and interested in a new role. Suggested filters include:
Excellent performance review. You want this program to be a reward to high achieving employees, so insist that they are already doing well in their current job.
Manager recommendation. In order to conduct an expedited interview process, you are leaning on signal from a manager in your organization who supports the transition. Keep in mind that this person likely can’t comment on their technical ability, but should be able to provide signal on behavioral and company-culture dimensions.
Prior engineering experience. This can be a class like Code Academy or Udacity and should include ample code samples to review. This gives you a minimal filter on their engineering ability, a sample of code to review, and direct evidence of the grit that they will need to convert to software engineering.
After filtering, you might do one of two things, or both.
Use trusted interviewers. Internal candidates frequently have less CS experience (for example, they might not be super familiar with Big O notation). You want interviewers who are capable of distinguishing potential and ability to produce code from ‘familiarity with CS classes.’ You are likely trading off raw CS knowledge for hustle, values alignment, and raw talent to learn. These candidates start off slower than most CS new grads, but climb the learning curve much faster.
Use their prior managers as the ultimate reference checks. Lean into the performance review signal from their managers to help guide your decision. As mentioned above, you are not getting a new grad CS student, you are getting a seasoned employee with enough engineering chops to do the job. This raw material is great for creating excellent engineers, but it requires work.
Ensure the candidates land in teams that can use their skills, and that can support them and help them grow. Choose a team that can leverage their prior backgrounds (for example, if they came from the sales department, place them on a team that works closely with sales). This will enable them to punch above their weight while they develop their engineering skills.
Whether you do an internship or normal interview, understand these engineers are going to start a little slower than most new grads you would hire. That is fine, because they will ultimately quickly accelerate their growth curve to match or exceed all but the best new hires. You know they are capable of being excellent employees, and you’re betting they can become excellent engineers. Because this is their first engineering job, they will likely need close mentorship and feedback continuously over the first six months. After that they will be indistinguishable from every other engineer in your organization.
Ensure equal access. You should advertise that you’re doing this program to all members of the company and approach it carefully. Engineering will be looking at these people and assessing whether they are at the right level of skill. Many people in non-engineering parts of the company will want to join. There will be a spotlight on this process, so ensure that qualifications and procedures are publicly known and equally accessible.
Maintain the same entry criteria. If the candidates that come out of this process are worse engineers than the ones you hire from outside the company, the program will not survive. You need to strive for independent evaluation of candidates. The best way is to find senior engineers who will do final assessment of the signal and place their stamp of approval on each internal applicant.
Guide your mentors closely. When running an internal pipeline internship, keep in mind that interns are already employees—they may have lots of pre-established relationships with the employees around them. This can lead to situations where an intern that is struggling isn’t honestly assessed by their mentor; the mentor may be afraid to give hard feedback or they may sandbag their expectations. As the manager, it is your job to precisely guide the mentor’s expectations and ensure they are not succumbing to social pressure to get this person though the process.
Limit the teams these employees can start on. These employees usually start from a slightly lower base of CS knowledge that they would have gotten in school or previous internships. This means they will start a little slower, but ultimately accelerate very quickly. The teams they land on need to understand this deeply, or risk making the new engineer feel excluded, or worse. Explain to the team that they need to be more forgiving in the beginning, and ensure the new engineer is working on projects appropriate to their level. At the same time, the team should hold high expectations for fast growth in this engineer’s abilities over the first six months, which can help them feel motivated and supported—everyone wants to know that their team believes in them. Rather than throwing these employees on a random team that’s not prepared for them, make sure they’ll be working with people who will help them fulfill their potential.