 apprenticeship. My name is, as he said, Megan Tew. You can find me all over the internet at Megan Tew Twitter, GitHub, most places. And I have the pleasure of sharing this talk with y'all today because last year I got to do something really cool. So I didn't really think I'd ever be able to do. I was able to create a program for entry-level developers and bring new people into this industry. And it's something I'm really proud of. And I think that apprenticeships are a severely underrated part of our professional systems. I think they deserve a bit more attention for a few reasons. For one, they fulfill a very real need. So with coding boot camps and it generally being more accessible to learn to code, there are a ton of junior developers out there. But so rarely do we see open junior positions. There are a ton of fantastic eager folks that are just waiting for the opportunity to be seen. And further, when we do see these junior positions, they're asking for things like three years of experience. There has to be some kind of role in middle there. And apprenticeships fill that hole. They also help unify and engage your teams because when your team can rally around the common goal of teaching a new developer that's excited and ready to go, they'll unify. They'll be excited, too. They also help us create more diverse and inclusive organizations. So historically, the tech population tends to look all a bit the same, especially here in the US. We have a bit of a white male problem. But more and more, we're seeing juniors that are coming out of code schools or that are self-taught, that are members of groups underrepresented in tech. Apprenticeships provide these folks the jumpstart into long-lasting careers as engineers that they truly need. So what exactly is an apprenticeship? So it's an entry-level program designed for brand-new software engineers to sustainably grow their knowledge, establish a solid foundation for their craft, and learn more from their experienced peers. And for our program that we built, it ended up being a four-month-long program where the end goal was that the apprentices are then hired at the end as full software engineers. And a question I get a lot when I talk about apprenticeships is how they differ from internships. So internships tend to be focused on one specific project. Maybe you're hiring an intern to write your API docs. Or they tend to have a bit of a negative connotation in that way. You're like, okay, we'll just make the intern do that. Like, they'll do that work, whatever. They also tend to be a bit shorter term. So especially when we consider college interns, you may hire them on for the college semester, and then they'll be gone after that. Apprenticeships on the other hand focus more on sustainable growth. So instead of just doing one project, they get exposure to lots of different learning opportunities. They also imply that the apprentices will be honing their craft, because this kind of program is an investment in them as developers. They also tend to be a bit longer term. So our program was four months long, but so many of programs tend to be even longer than a year. So keeping in mind that you want an apprenticeship over an internship, it's time to lay the groundwork. So this is all the pitching, planning, and preparation that go into before you're actually able to put anything in motion. So what do you need? Three things, actually. You need a plan. You need cash, because if you expect someone to dedicate their energy and time to learning and growing, you can't have them worry about putting food on the table. And you also need buy-in. And ideally, you can get buy-in from everyone in your engineering organization, but often that's not feasible, especially as you scale. But hopefully, at least the one person you do have buy-in from is your boss. Or perhaps if you're at a large organization, your boss is boss. And this can range in difficulty. But for for-profit companies, they're likely going to need to justify the time and monetary costs of your program. And you can do this with material costs. So apprentice programs eliminate onboarding costs. Typically, with more experienced engineers, you spend time training them up, getting them to know your system, your domain. But with apprentices, during that period where they're just there learning to program, learning to code, and getting going, that whole time they're actually learning your stack as well. They're learning what you do and your domain. And so when you hire them on later as experienced engineers, you don't have that additional time. They also help eliminate recruiting costs. So in an environment where we're spending tens of thousands of dollars to someone else source candidates for us, instead with apprenticeships, there's such a high demand for this kind of program, this kind of entry-level position that candidates will flock to you. That's definitely the experience we had. Also helps in hiring senior developers too, if that's your thing, which for a lot of people is. When I, as a senior engineer, look at companies with apprenticeships, I see that sends a message, right? It says, hey, we're a company that values growth and values learning. Come learn and grow with us. Come help your other coworkers do that too. And of course, there are the immaterial benefits that you can pitch. Lots of things we've already talked about, like increasing diversity of background and skill, improving team connectivity, and even increasing developer productivity. Because if you have a senior and a junior pairing on a project, yes, your junior will be learning a lot, but so will the senior. They'll be learning probably just as much, if not more, as the junior. So once you've convinced your boss and you're ready to start, there are a few different things you decide. How long the program will be, how many apprentices you'll hire, and who's going to do what. Because these kinds of defined roles are really crucial in making sure that everything gets done and that the apprentices have designated people for various different types of questions. We decided on a four month long program. We knew we wanted to hire two apprentices because it's like a manageable number for a smaller team and they could be even paired together. And that for the roles, we'd have one program coordinator, mentor combo, a manager, and multiple people to help with the hiring process, reviewing applications, and things like that. You also didn't decide what the apprentices should know when they get to you, what you want them to learn while they're with you, and how they'll learn it. And these things will vary by organization. For us, we knew we wanted them to have built some web apps before, wanted them to know basic programming things like control flow. We knew we wanted them to learn refactoring and testing and best practices, but even more importantly, confidence in themselves as developers and in their skills. We knew pair programming would be great for them because it's a great way to share knowledge, as well as working with many different teams so they could gain exposure to multiple levels of the stack, parts of the product, things like that. What's most important here, though, is that you really need a game plan. So leading up to this program, I did a ton of research in order to create a very thorough plan. And never once did I think that it wasn't necessary. I kept referring back to that research consistently all throughout the program. And this is what my master plan looked like for the program, covered things like our goals, what kind of folks we wanted to hire, what stuff they would be working on while they were with us, as well as how we were going to help them learn it. And all this planning was crucial going into the implementation phase. So actually doing the thing. We break this down into three phases. Hiring, onboarding, and growing. So let's hire some apprentices. Our goal here is to establish an unbiased, even playing field for our candidates. And this goes back to one of our overall goals of increasing diversity. It's so crucial in making sure that everyone has an equal chance at a place in this program. You've got to remove as much bias as possible. So our hiring process has three phases as well. The application phase, a code challenge, and a final interview. It's really cool to note we had end-to-end anonymization throughout this entire process leading up to the final interviews. So when a candidate submitted an application, they were assigned a hashed candidate ID. And that was the only way that we were identifying them all the way up until talking to them in person. So first is the application phase. We had an application that looked like this, though I don't expect you to read that in the back. We asked them a few different questions about themselves and what kind of work they like to do. We asked them like, what does your background bring to the table? And in our application, we specifically stated that we were looking for folks that did not have any previous professional programming experience. And despite that fact, the candidates consistently tried to make up for that fact that they didn't have that technical experience. The problem of a lack of junior positions is so bad that we've conditioned people at the beginning of their careers to keep apologizing over and over again for still being in the learning process. In the application, we also asked them to tell us about our problem, that challenged them when they were learning to code, but they ultimately conquered and how. This is a really fantastic question for us because it really helped with the decision-making process. So the worst answers, we were able to sort of weed out the candidates, maybe that didn't put a lot of effort in their answers like, oh, we, you know, I pushed through and tried, shrug. But the best answer is we really got to see their thought processes and how they step through problems, how, you know, what kind of debugging tool they use, maybe what kind of documentation they read, where they go for things. It was really interesting. And then to review the applications, we created a rubric to standardize that review as much as possible and remove, again, as much bias as possible. It looks a little like this. And we asked our reviewers to rate each application on three things, eagerness and excitement, curiosity, and drive. And we did this on a numerical scale of one to six, so there were like no easy outs by picking that middle number, like we so often tend to do, you have to pick a, pick a stance. And this numerical data helped us really make actual data-driven conclusions in this hiring process. So if we had a candidate that consistently received lower scores from every reviewer, maybe they weren't best cut out for this program, but if they consistently received higher scores from our reviewers, like, hey, we might not even need to look at this application again, they're probably a good fit. Let's keep moving. And that moves us into the code challenge. So when you're crafting a code challenge, first you need to decide what you want to learn about your candidates when they're performing this task, figure out what kind of format you want and then do the thing. We knew we wanted them to, again, going back to what we wanted them to know, we wanted to test for control flow, see if they're comfortable writing Ruby. We also, in figuring out the format we want, we chose a TDD style task where we gave them a file full of failing tests that they then wrote code to make pass. And in writing the code challenge, it's actually a lot easier said than done if you've never done this. It's very hard to reverse engineer for what we thought the candidates would be able to do, but then still leave a little bit of wiggle room for them to go above and beyond. The way we've ministered the code challenge, each candidate had their own GitHub repository where they could push to the master branch when they were finished. It looked a bit like this. It was for a program called Greater. And Greater helps teachers score multiple choice tests and gain insights into how their students are doing based on average scores and things like that. And the read me was pretty extensive because we knew that based on the coding schools in Atlanta, many of the candidates might not have touched on any automated testing before. And so we wanted to make sure that they knew exactly how to run a file of our spec tests, that they know what it looks like when they're failing so that they got to the right point. And then finally, what it looks like when they're passing so that they knew they finished. We also gave them an empty class, Greater, where they wrote their code. And then a file of full of our spec tests. And we found it really important that to ground all of the tests in reality as much as possible. So if we're testing for things like passing in a nil answer, well, someone just reading this might not know exactly what that would mean. Like, yes, nil is a thing in Ruby, but what does that mean in concept text of a student taking a test? Well, maybe they forgot to put an answer, nil is a representation of nothing in Ruby. And so we got there that way. And so we found it really important that the code comments were the only contacts that the candidates had. So when they were, when they're sitting there going through the challenge, that only, all they have is what you give them. And so we've got to give them as much possible so that they can focus on solving the problem instead of figuring out what the problem is. To anonymize the code challenge, we had a script that scrubbed each of their commits author info and then submitted a pull request to a separate submissions only repository just associated with their candidate ID. And this allowed us to really preserve that commit history without ever identifying the candidates. So if we, you know, if you were kind of person that squashes your commits all up into one, we could see that. Or if you commit each step along the way, step by step and preserve that, we could see that too. And then we can see their thought process and that was really cool. The PR format also allowed the reviewers to assess the submissions in a very familiar environment. So the company where we built this program used GitHub's built-in tools for code review. So reading these PRs felt really natural and we felt we got better results out of the reviewers. And in reviewing this, we used again a similar rubric to the application to standardize that review. We tested for things like that we knew we wanted to learn going in, right? The things we wrote the challenge with in mind. Can they use control flow? Are they comfortable writing a diplomatic review? We also asked the reviewers to provide feedback to the applicants. We knew that we really wanted this program to be an investment in the community's juniors, not just a way to bring people in. And so we felt it very important that even if they weren't selected to move on within the process, they were able to get some actionable feedback and still learn and grow even if they weren't selected. So that moves us into the final interview. What's really cool is that this was really the first time we have been able to put names and faces to the answers and submissions we've got. Our final interview is three phases. So a product and company intro, a technical conversation, and a behavioral chat. And the technical chat was a little bit different than it would normally be for our experienced developers. Because you can't just use the same terms or ask the same questions and automatically know that they're not new at what you're talking about. And so we were able to use the code challenge as a focal point of that discussion because it's code that we had both seen that they had written and we could really move forward there. And so that enabled me to ask questions like what challenge do while you're completing this exercise. And this showed us how they worked through different problems and then how that was then reflected in their submission. We also got to use the feedback collected during the code challenge review and gave it to them in the interview so that they could see, so we could see how they process feedback, what kind of questions they ask when they're trying to process and things like that. Now the behavioral conversation was a bit more like standard job interview type questions, but one apprentice specific thing we got to ask was what would you change about the school you attended? Be it a code school, a university or even your own self-taught program, this was able to give us an idea of what their needs are in learning and make sure that we as the people running it can meet their needs going in. So ways to improve the hiring process, I'd really recommend using an HR platform. The point we were at this company small enough that we just didn't have one of these yet. And so I essentially ended up rolling my own with a suite of Google Docs and Sheets and Forms and it was, it worked for sure, but all that time that I spent doing that probably would have been better spent putting that into the program. I'd also recommend not limiting your code challenge to one programming language if possible. So this company, all the server side application code was written in Ruby and as Rubyist myself, that's the only language I really felt comfortable testing other developers on. And we did receive like a lot of great applicants from PHP or JavaScript backgrounds, but once they got to the code challenge, they were a little bit too challenged, right? More challenge than we wanted them to be because they had to then adapt to Ruby. So I really feel like we lost out on some fantastic candidates because they couldn't get over that hurdle. I'd also recommend being very direct with your application questions. So ask specifically what you want to know. Your candidates are just trying to answer the question that you gave them, not deduce some hidden meaning of what you they thought you might have actually wanted. So just be direct. Ask exactly what you want to know. Once you've hired some fantastic apprentices, it's time to onboard them. So our goals here are to set the apprentices up for success and teach them the essential concepts that they need going forward, not only in the program, but throughout their careers. It was important for us to give them as much of the same onboarding experience as we would for the rest of our developers. So this included different things like info sessions on our applications, important parts of the code base, things like that. One apprentice specific thing we got to do was a scavenger hunt where we gave them a list of questions of things like tell us the name of the controller action that does this thing. And then they would have to use the context clues provided in the questions to work backwards and find the answer. And this was really fantastic because it was a very, it was a way for them to become more familiar with our large production code base, larger than they had ever seen before, but in a very chill, low risk way. In addition to that and the other info sessions, we also gave them some lessons on foundational concepts like object-oriented programming and debugging, things that we tend to expect are more experienced developers to know coming in, but couldn't expect the same of entry-level developers. So we wanted to give them the right, starting on the right foot there. Ways to improve onboarding, I would recommend giving your apprentices very early exposure to any processes that your team uses like sprint planning and point estimation. About halfway through the program, I had an apprentice come ask me what a sprint was. And as someone deeply ingrained in software culture, that wouldn't have occurred to me that you wouldn't have known. But of course, right? If you're just starting out in software, of course you don't know what a sprint is in relating to project management, right? So make sure you start that with them at the beginning instead of towards the middle. And finally, it's time to grow your apprentices. So there's a lot of info out there about engineering leadership and how to grow developers. So we'll try to keep this specific to apprentices. Our goals here are to anticipate their needs, provide an inclusive and friendly environment to grow and learn, and increase apprentice independence because independence is one of the better indicators of experience in a developer. So we brought this into two phases. First, an initial ramping up period where they were working on internal work, just small things, maybe a CSS tweak, fixing a bug. But these were able to build up their confidence in themselves and in their skills. The second phase were team rotations, doing some more customer facing work with our regular product teams. This is fantastic because it gave them exposure to all levels of the stack, different parts of our code base, and even different ways of running teams. And this ramping up really showed them that the larger projects that they did towards the end of the program were comprised of the smaller ones in the beginning and helps with story breakdown later on. We also made sure to set early expectations. So they came in knowing that their end goal was to get higher on as engineers afterwards. And so we gave them the sheet and we said, please try to meet all, if not most of these things during the course of your program so that we can meet that end goal. It includes things like personally verify that your change's work is intended and lean on the expertise of your coworkers to improve your own work. We also made sure to establish regular communication through one-on-ones with both me as their mentor and as their manager to keep just sort of a very focused look at their progress and making sure that they don't have blockers and things like that. Also made sure to include them in their team rotation decisions. So we realized that they would learn and grow best if they were able to work on things that they truly enjoyed. And one of our goals for this program was to help them figure out what they do enjoy. Do they prefer back-end work? Do they prefer front-work? Is there something in particular that really drives them? And allowing them to be involved in these kinds of decisions really helped them find their path. And most importantly, do not be afraid to let them fail. So there will absolutely come a time when you're pairing with one of your apprentices and they're like, hey, what if we tried this? And you'll think that would fail. Well, but you can't say that, right? You've got to shut your mouth, sit on your hands, whatever it is you need to do because in order for them to truly learn and grow, they need to see that error message. They need to see why that error message occurred and then how they fix it. They need to have that thought process and that hands-on experience in order to truly learn. Ways we'd improve the growth phase. So look for early warning signs and be proactive about intervening. In general, junior developers tend to be, have a bit of a harder time admitting that they're struggling, often because they just don't feel like they truly own their role yet. They don't feel like real developers, whatever that means. So make sure you're able to recognize the signs of this and support them as they need it. Also want to make sure that everyone is involved in the program is on the same page regarding their expectations. So we ran to a situation where the team leads that were working with the apprentices, weren't quite sure what the apprentices knew when they got to them or what they should be teaching them. And the apprentices knew that they should be learning but not what necessarily. And so this was an easy fix. We're next going forward. We'll provide a sheet that outlines all the things that we want them to learn over the course of the program and then keep it updated as they move through teams and things like that. It's an easy fix but one that's extremely important for making sure that everyone is on the same page and knows what they're supposed to be doing. And you can use all these lessons we've learned here as you mentor and grow other developers even running your own apprenticeship program. So to wrap up, we created a master plan for our program. We used a fair, anonymous hiring process to hire some fantastic apprentices. We set them up for success through onboarding and we grew them into fantastic software engineers. I'm happy to say that our results, we hired on both of the apprentices afterwards and they have been with the company since September and they are both very productive members of their teams and their teams would not want to be without them. So some lessons we've learned throughout this process. When hiring, make sure to listen to the early hunches. You have about each candidate. So we had one candidate that in their application sounded potentially overconfident in a way that might hinder collaboration. But the rest of the application was really good so we pushed them through the code challenge and their code was really good so we pushed them through the final interview and once we actually got to talk to them, realized that early hunch was true and we feel that egos don't really have a place in collaboration, they hinder it. And so make sure to listen to that early gut feeling because more often than not, it does turn out to be true, positive or negative. You also want to give yourself a lot of time for this process. So our program was greenlit in June last year and once we sat down to plan, realized that in order to finish before Christmas, we needed to shorten the program from four months to three. It's really important to give yourself this time. It does take a while, but it's very, very worth it in planning. And finally, always, always work with your goals in mind. It will be really tempting to do things and maybe an easier way or a way that someone specifically asks you to. But please remember that you're in this to make a real impact. I'm really happy to say that with this program, we were able to provide W2 jobs that paid a living wage and include full benefits, which is not typical for entry-level positions. But these kinds of jobs are the small change that can become something bigger. It's our opportunity to make big change on a small scale. We often say that we want to bring different kinds of people into this industry. We say we want to value education and growth in our organizations. We say we want to help junior developers and we want to give back, right? This is a concrete way to do all of those things. So go start in apprenticeship. Again, thanks. I'm at Megan2 on Twitter and the internet places. I want to thank all these people for helping me either through research or implementation phases of the program. I'll be around all day today, so please come find me. I could talk about apprenticeships all day. Thanks.