Building an apprenticeship or internship program, Part II: Hiring & onboarding

This is part II of a series on program design for apprenticeships and internships. In part I, we set some basic groundwork to give your program the best chance to succeed. Now, let’s chat about how hiring and onboarding for these programs fit into the picture.

Hiring is hard enough already

There does exist a rare type of person who finds interviewing fun. I know one! Most of us do not share their enthusiasm, but somehow the tech industry overwhelmingly shrugs, says “hiring is broken,” (here & here) and rather than change the game* focuses career advice on learning it. Some gatekeepers even prefer the game remain as-is to avoid “lowering the bar.” I’d argue the bar is already pretty low and that we’d be raising it with some of these improvements. Here I’ll (barely) scratch the surface and mostly talk about software hiring, but plenty of other roles in tech could use attention, too…

A note on privilege and equal opportunities

Unfortunately this play-the-game paradigm favors candidates with the resources (time, money, network) to master interviewing skills separately from those required for the role. Even without mastering interviewing, more privileged candidates can benefit from the biases (conscious or not) of their interviewers toward certain academic backgrounds, previous experience, languages, or personalities.

So when hiring interns or apprentices (or full-time entry-level), remember candidates early in their careers have less exposure to “the game” unless they have the opportunity to attend top universities with access to mock interviews, how-to books, recruiters from major companies in Silicon Valley or Seattle, and other resources. For a more equitable approach, your process should assume less about their familiarity with interviewing in general and more about their existing problem-solving and collaboration skills, growth mindset, and potential to learn and contribute.

How you source your candidates and, ultimately, conduct your interviews impacts your entire pipeline: everything from who applies to who accepts an offer. Companies often fear false positives because they are expensive. But instead of focusing on improving their process, they accept a much higher rate of false negatives (note: also expensive) by rejecting qualified candidates for at best, arbitrary or at worst, implicitly biased reasons. News flash: a candidate failing your interview doesn’t always mean they are unqualified for the role you’re trying to fill. Improving your process won’t eliminate false negatives or positives, but challenging the effectiveness of each stage of your company’s process can reduce both and cultivate a better-balanced pipeline.

Understand your team first

Before you can evaluate a candidate’s fitness to join your team, you need to clearly articulate which skills, knowledge and abilities make for effective individual contributors on it. Reflect on the gaps in your team’s skillset and seek candidates who might fill and complement those gaps rather than match the rest of your team.

I talk about this in more depth in a previous article on mentorship and onboarding, but the gist is to work backwards to learn your expectations from self-reflections such as “What, exactly, did our individual contributors know when they interviewed, what did they learn on the job, and at what pace?” If hiring new grads, interns or apprentices is new to your team, ask around for advice on evaluating candidates without prior work experience (or visit some of the resources at the end of this article).

Consider your interview process & evaluation criteria

Candidates are more likely to perform better and give employers solid data if you can recreate a somewhat realistic work experience in the interview — how do code review, pair programming, or technical decision-making fit into your team’s workday? Would making them part of your interview give you and your candidate a better idea of what it’d be like to work together?

There’s no single answer but I firmly believe, for example, arbitrary algorithm problems on a whiteboard from college CS courses are largely meaningless for most (not all!) entry-level software roles.

Once you consider what your interviews look like, think through how you want to evaluate your candidates. Would an intern or apprentice without relevant work experience be able to provide a meaningful code review if they’ve never done one before? Or might the process of teaching them a core part of the role show you how quickly they learn new skills, collaborate and give/receive feedback?

If you’ve never hired entry-level candidates, what they bring to your organization is probably unlike what nearly any other candidate has before — raw talent and potential, unfettered by years of bad habits, ready to be shaped into the engineer you need. Figure out the best way to judge that and incorporate it into your evaluation criteria.

Interviews are as much for the candidate to evaluate your company as they are for you to evaluate them — what impression do you want to give, regardless of your final decision? A rejected candidate is far more likely to speak highly of your company to a friend or classmate if they learned something or had a positive experience in your interview.

Train your interviewers

This is great for all hiring, but especially for candidates new to the industry. Don’t assume your top performers will make good interviewers without providing training. Bad interviews seem as common as plane colds and nearly every time someone describes theirs, I think “sounds like that interviewer wasn’t trained.” I once had an interviewer who talked nonstop for 20 minutes and asked two generic questions before we ran out of time. Rejected days later, I felt both relieved and confused — on what basis was I deemed unqualified?

Besides giving a bad candidate experience (which can lead to reputation issues that affect your pipeline), untrained interviewers can expose your company to legal issues, consciously or not. Did they ask about someone’s plans to start a family, or where someone’s from? Well-intentioned “getting to know you” questions can be a slippery slope to protected class hiring discrimination.

Many resources talk more in depth about interview training than I have time for here, but I’ll say the best in-depth ones are customized to your organization’s needs. Here’s a basic guide from Greenhouse to get started.

Experiment with your process… but not too much

No interviewing process is perfect, but making it better can be a hard sell. Experiments can be tricky (as I warn in part I), but as those in product development already know, is also a powerful way to gain insights into what’s working or not about your hiring process.

Story time! A few years ago at my former employer, Yelp, our technical recruiting team conducted a study of the initial screening stage for university candidates seeking entry-level software roles: We continued resume screening while offering all applicants from the same universities a short (originally 5 mins, but later extended to 15) coding challenge hosted by a third party. We interviewed everyone who passed either method and tracked their progress. Our hypothesis was the coding challenge would eliminate the need for resume screening, reducing bias and saving many hours at the first stage. This proved mostly correct: after tracking candidates through the entire hiring process from both entry points, resume screening was dramatically less likely to predict which candidates made it to the offer stage, with many more false negatives AND false positives.

But coding challenges aren’t perfect, either: most rejected candidates I spoke to had difficulty not with the questions, but using the platform, spotty WiFi connections, reading the instructions, or the time limit (especially non-native English speakers and people with disabilities). Back then, budget and interviewer capacity didn’t permit us to give challenges to every applicant, so getting the code challenge at all preferred certain candidates over others. Plagiarism became an issue. We saved many engineering hours on resume screening, but added recruiting hours fielding questions and investigating flags. While better than resumes, coding challenges favored candidates good at “quizzes,” who knew one of the platform’s (then) four supported programming languages, were resourceful about looking up questions on Glassdoor, or simply attended the right event to receive a test invite.

What made this experiment useful was keeping it simple (“are code challenges more effective than resume screening at predicting candidate success in our process?”), time-bound (one quarter) and minimizing changes during the experiment so our recruiters and interviewers had less extra work. Your process will probably will never be perfect. It needs to evolve/scale as your company grows and as your needs change.

Your candidates may be quite different than who you’ve hired before (reminder: that’s a good thing!), with little or no directly-relevant industry experience. Don’t assume they know how things work — or that they don’t. Experiment with your evaluating criteria, even if your process remains the same.

Onboarding — the roux to your team’s secret sauce

Even if you excel at recruiting talent from different backgrounds in the door, it won’t matter if you can’t support them after they show up. A “sink or swim” attitude doesn’t work when it comes to interns and apprentices (or anyone, really). If you want to benefit from interns or apprentices rather than see them as a burden, your company needs to invest in stellar onboarding to maximize their potential.

Assign & train your mentors — and give them space to be mentors

Even if you call it “new hire buddy” or distribute the responsibilities among several teammates, this role is crucial to an internship or apprenticeship program’s success. Mentors introduce their new hire to colleagues, the job, the workplace, and coach or guide them toward self-sufficiency along a mutually-agreed-upon plan. Mentors should be available during core work hours from the new hire’s first day to at least the first month — i.e. not on PTO for their first two weeks.

Make clear to everyone on your team: what’s expected of mentors and managers and who is a point person to resolve any issues (such as an Intern Program Manager, or if earlier in the program lifecycle, the sponsoring champion). Talk about the mission, program goals, and how mentors are a vital part of executing the program vision. If you decide to create a full mentorship program, here is a decent place to start. Other thoughts on mentorship as part of new hire onboarding are here and here.

Work with managers, product managers, etc, to ensure mentors have enough time carved from their other work to devote to whatever you’ve decided is the best mentor-mentee relationship style for your company. Mentorship is a valuable skillset to develop and has a huge impact on both mentor and mentee — set them up for success!

Write a detailed onboarding plan

Onboarding is so much more important than anyone gives it credit for. It’s a company and new hire’s chance to establish a rewarding partnership. This is even more critical for new hires with minimal industry experience. The team-specific onboarding I describe here should integrate seamlessly with any HR-required company orientation to the business, company values, and setting up employee benefits. This helps introduce HR as a proactive and useful partner, rather than something engineering reaches for in reactive circumstances.

For each role, write a clear plan for the length of your program with weekly goals that cover everything, including but not limited to:

• setting up the new hire’s computer, including dev environment and any credentials or SSH keys they need to access a team’s repo or other docs;
• where to find physical things like bathrooms and conference rooms;
• how to find digital things like team and company documentation;
• meeting everyone on the team — then other key folks the team works with;
• learning/proficiency objectives & expectations for certain tools or technologies;
• measurable contribution goals, such as progressively more complicated projects (if software engineering, start with a small ticket to fix something trivial like a typo, to verify their environment is set up properly and to get acquainted with the code lifecycle at your company).

Have managers and mentors review the onboarding plan with their new hire on the first day to level-set and ensure objectives seem reasonable. Make adjustments as necessary. Managers should continue checking in weekly for the first month or so, especially as new hires gain more context after the first day. Mentors should check in at least daily, if not sit near their mentee, probably for at least the first few weeks.

Let apprentices and interns know how they’re doing — often

Impostor syndrome is especially common among new hires. They often don’t know which questions are bothersome, or if they’re asking the right person at the right time, or where everybody just went or if they’re doing the right thing. And it’s understandable — apprentices and interns (most new hires, really) are processing and constantly interpreting a ton of information in a compressed amount of time, both related to the role and all the observed behavior from their colleagues. Three ways companies can help create a welcoming environment and minimize impostor syndrome:

• Normalize questions. Definitely set guidelines around asking questions without being disruptive, but no one should be nervous about or afraid to get help or clarification. You may be surprised at how innovative a new hire’s questions can be and what assumptions they can help your team challenge.
• Show you care about the little things. Communicate clearly so no one feels forgotten or left out. It starts with dotting the i’s before a new hire’s arrival (send a welcome email with the address and a Day 1 schedule, set up their desk, prepare their email address, etc), and continues with things like meeting invitations/locations, defining internal or industry acronyms, or other details that outsiders might not know. Explain inside jokes or references to company legends. Does the phrase “death by a thousand paper cuts” sound familiar? That’s what we’re hoping to avoid here. These details may seem unimportant but each instance compounds over time and new hires are hyper-vigilant when trying to pick things up quickly.
• The onboarding plan should be clear, with direct objectives that demonstrate to a mentor and manager that by meeting them (or exceeding in some areas while catching up in others), this person is performing as expected.

But managers (and sometimes mentors, depending on the company or mentor’s seniority) also need to be clear about what “performing as expected” means. Have both an open line of communication with regular informal checkins, and formal checkpoints where you assess their performance.

Does meeting or exceeding performance targets qualify them for a permanent or returning position? If so, let them know when the hiring team expects to make those decisions and on what criteria. If there are questions about their fitness for a permanent role but they meet your documented performance targets, you need to edit those targets to account for the questions you have. Have that conversation early and often so there are no surprises.

What to expect from their performance

Once you have an onboarding plan with detailed performance targets, it’s pretty easy to see whether they’re doing as you expected. You may discover that interns and apprentices excel or fall behind in different proficiency areas than others. That’s reasonable, but you’ll have to decide on the acceptable divergences from your rubric and be consistent about how you consider those adjustments. There is no typical profile, but very generally, here are some common traits I’ve seen and corroborated with engineering managers who’ve worked with both interns and apprentices:

• Interns without prior work experience are more likely to be sharp as a tack with academic concepts like systems design or algorithms, but less likely to have strong professional acumen or know current best practices for the tools in your stack. True story: an intern showed up at odd hours, regularly missing meetings but still submitting good work and improving his collaborative skills. Then one day he didn’t show up at all — their worried manager had me look up their address and call the police. Thankfully he was fine; he just didn’t know he should tell anyone he was taking a sick day.
• Apprentices with work experience in another field are far less likely to struggle with professionalism, but may be culture-shocked if your office has lots of snacks and other perks (tech is way ahead of other industries in this aspect). They are more likely to be highly proficient at the specific parts of your tech stack they learned in, say, a bootcamp or self-taught program, but be less familiar with the big-picture concepts that tech leads use to decide why certain tools are the best for certain projects.
• Both interns and apprentices are likely to lack experience with code deployment at scale and contributing to large projects. Both may have a favorite code editor and basic familiarity with git, but if they have public projects, they’re more likely to be solo or small-group projects at small scale. Writing excellent documentation on your team/company’s processes around testing and deployment for junior engineers will be a huge help to mentors, other engineers & operations teams, and newbies alike.

For now, the tech industry takes so few chances on junior engineers that they are often really eager to accept your offer and to learn. That is a huge recruiting opportunity compared to the hard sell to attract and retain more senior candidates. Use good hiring practices, mentorship and onboarding to leverage that energy into new ideas, productive work for your teams and engagement/retention opportunities for your senior engineers. You may be surprised to find industry new hires onboard even faster with your improved documentation and clear expectations — and that over time, your company culture will become more inclusive.

I won’t say the (many) other opinions on this topic are more wrong or right for your organization than mine. Check out these, too, and let me know what you think!

• Microsoft on the future of skills-based hiring.
• Eventbrite’s blog post on supporting junior engineers.
• Megan Tiu’s talk at We RISE Tech Atlanta on “The Practical Guide to Building an Apprenticeship.” This is basically part I and part II in video form, but I promise I found this in between writing the two parts!
• Felienne Herman’s talk at MIT CSAIL on direct instruction in programming education. While about teaching, there’s a lot that onboarding can learn from pedagogical methods for new skills or job requirements.
• An open-source list of companies not doing whiteboard interviews.
• apprenticeship.at, basically job board for apprenticeships.
• Thoughtbot’s approach to apprenticeship (from 2015).

*A growing group of products are disrupting the game (such as anonymous coding interviews, anonymizing resumes, coding challenges, etc) but I’d argue many really just help companies reduce or change their biases and improve candidate performance on existing metrics rather than changing the system itself. The game is better off with them playing, but is far from perfect.

About me: I used to be a technical recruiter and intern program manager at Yelp. Over the years, I noticed a sizable gap between how tech companies describe and execute employee experiences, from hiring processes through their last day. This gap means candidates and employees often succeed despite (not because of) the employer’s efforts — and this is a big problem if we hope to make real change in equal opportunity hiring.

I mediate between these worlds to narrow those gaps — by helping software engineering candidates find their best roles and prepare more effectively, and helping employers optimize their interview processes and employee engagement.

I’m based in San Francisco and a sucker for public transit, tasty cheese, fun facts and juicy novels. I’m on Twitter @keeterooni and LinkedIn.