 I'm Rebecca and this is the Junior Jump and we're going to talk about nurturing junior engineering talent. And we start by raising a couple of hands. How many of y'all wrote Ruby at your first job? Cool, quite a few people. As a developer? As a developer, yes, absolutely, at your first programming job. And how many of you have interviewed someone for what would become their first technical job? Cool, is anybody looking for their first programming job right now? Awesome, we do have like a couple of hands so y'all find those people. But this conversation is particularly relevant for us to have as Rubyists because over the past several years we've become the welcome gate to the programming community for a lot of people, including myself. And the Ruby community is really good at getting people excited about programming. We have Rails Girls and Tri-Ruby and all of these resources that have done what is really an unprecedented job of convincing people who never thought writing code could be for them, that they should give it a shot. And that's a lot of responsibility for us because not only are we training the engineers that we have to work with, but it's very likely that we're onboarding engineers who will probably train future engineers. And if you didn't raise your hand at the beginning of the talk, these are a few of the reasons your team might consider investing in engineers at the very beginning of their career. It can be really scary, but really rewarding. We get excited about the 20% of the work that's so boring, but the rest of your team doesn't really want to do it. This is true. And it's because we're smart, ambitious people who like to be able to do things on our own. And when you're getting into a large codebase for the first time, that's not necessarily a lot of things. And that's not necessarily the stuff that people with even three to five years experience find really fun. We're a little bit easier to find. This is true particularly for diverse engineers. Diverse engineers can be really difficult to hire laterally. If you're looking to diversify entrepreneurship, you might find the best way to do that is hiring a diverse person and growing them into the engineering leader that you need over several years. And teaching grows both teachers and learners. The best juniors ask smart questions and encourage the rest of your team to articulate implementation strategy, reconsider old opinions and try new things. However, a junior dev is not a chia pet. You have to help them grow. I want to talk specifically about preparing to bring a junior developer onto your team because I started thinking about this talk about a year ago when I was interviewing for my first tech job and everyone was asking me the same question which was what kind of resources do you need to succeed here? And that question is really scary. Don't ask it. What you're basically saying to the candidate is we think you're super cool and all, but the work we do here is really hard. How are you going to pull this off? Nobody can answer that. Not at their first job. You're the person who has experience coding in a production environment. You know what kind of resources are practical for your company. When you ask candidates this question, you're kind of asking them to have psychic abilities. They don't have access to that information. What they do have access to is the self-awareness of how they learn best. And that's totally a valid question to ask. Because when you're hiring at the junior level, you're not just hiring for coding ability. You're hiring for how enjoyable that person will be to teach. It's really hard when you're first starting out to know what resources are appropriate to ask for. These are some things that I came up with in my own experience while preparing for this talk. Books. Books can be great. Buying a junior developer a book is generally a lot cheaper than the amount of time in mentorship that you would pay to teach them something. Conferences. Send your junior developers here. Put them in a community that makes them feel really glad that they made this professional choice. Meetups are great as well. Meetups in the position where you have a really great space and a very senior team. Hosting meetups can surround your junior engineers with a little bit of a peer group that they might not be getting on the day-to-day. FaceTime, which can often be pairing if you have a pairing culture. I was lucky enough to have joined my team at a time when we were just barely small enough that I got to set aside 30 minutes for a single person on my team for them to just talk about whatever they thought it was important for me to know. You learn a lot about the values of your team members and conversations like that. You can always ask to pair and you can always make yourself available to pair. And explicit time to learn. I was a bartender before I was a programmer in Manhattan at a very, very busy bar. If you weren't physically selling a drink, you weren't doing your job, and you weren't making any money. It took me quite a while to figure out that learning was actually part of my job now. I got really into design patterns when I'd been working for two or three months and I sat down with my manager and I was like, is it okay if I take an hour a week to just read about the stuff that I really like? He actually laughed in my face and told me to take an hour a day instead. And the last thing is transcripts. I was really, really lucky to come onto a team that did transcriptions and they weren't there for me, they were there for someone else, but they're extraordinarily useful because when you don't have a lot of context, you can really only listen to your iOS engineer talk about functional Swift for so long before it starts going over your head a little bit. But you can learn so much by going back and looking at documents like that. Before you're hiring a junior engineer, you need to get your documentation game on point. Ask the guy who wrote it is not on point. You should generate a lot of paper when preparing for new engineers and then after they get a little bit of experience, they should generate that paper. This is important for not only all the very good reasons that having well documented code is important for everyone, but social reasons as well. When you're transitioning into a production environment, written documentation gives you something to do while you're waiting to be told what to do and it gives you hope that the answer is somewhere out there. Good documentation allows your junior developer to become more self-sufficient and less reliant on the mentorship of more senior members of your team. The second part of preparing for a new engineer might be the most technically difficult and that's planning an appropriate first project. Have you all ever heard of a round to it? As in when are you going to document that process? I'll get a round to it. It's really cheesy but my high school English teacher had one of these on her wall and I think it's helpful when it comes to thinking about how to assign work to new engineers. Assuming you have the resource to mentor your new engineer pretty closely for her first 30 days or so, her first project shouldn't necessarily be your easiest work. You're actually assigning work to a pair, a pair which hopefully includes one of your more senior engineers. That pair of engineers is a round to it. Give them the work that you've always been meaning to get around to implementing, but that isn't so mission critical that it has to be done on a really quick turnaround. What you're trying to do is balance exciting work that has to be done with supervision that makes you excited to show up every day and just boring stuff that fosters independence. Don't feel guilty about assigning boring stuff as long as it's not the only thing your junior is doing. Not only do you get to outsource the work that doesn't thrill you, but even if it is just objectively really dull, productivity and the ability to contribute independently is incredibly empowering. It's particularly useful if these kinds of tasks involve interacting with a broad section of your product because then they can serve to provide overview and context. When we're talking about projects, it's important to talk about admin tools and how your admin tools can be a great resource for finding work for new engineers. I've noticed just anecdotally from talking to people and reading industry blogs that teams that tend to roll their own and build a lot of things internally also tend to be really committed to growing talent. And I don't think those two things are entirely unrelated. Internal facing tools are a great place to look for appropriate projects for junior devs. While having a package environment set up and ready to go allows people to really hit the ground running, when you build a lot of internal tools, you're really creating a sandbox for both the mentoring of new engineers and for more established devs to experiment. I built that is easier to explain to your grandfather than a string extraction. It's important to give your juniors a story to tell when people ask what did you do today at your new job. Visible work is important and that brings us to mentorship which is probably the most difficult part of integrating a new person into an engineering team. The most valuable thing that a mentor can do is to lower the cost of asking questions. Most people who care about being good at something feel like they're failing at that thing almost all the time. Communicating with people who know more than you is really the only way to get rid of that feeling. Even if your organization is just you and the person you're hiring write it into your onboarding guide that every new engineer will be assigned a mentor to meet with once a week. Some people will take advantage of that resource more than others, but the ones who need it the most are the ones who would be least likely to ask for it. Making it explicit and default alleviates a lot of pressure for new engineers. When you're ready to make an offer to a new engineer your team needs to ask these three questions. What kind of resources can we give this person? How can we best help them? And how can they help us help them? And the answer to those second two questions should be made explicit in your team's documentation. How many people here did not have a mentor in their first engineering job? This is actually pretty good. We have a pretty scary number of people. But it's a pretty common situation. I was really lucky and my first job was at a pretty established company that could prioritize mentoring me. But some organizations might not be in that position when they decide to invest in junior talent. And that's okay too. If the only resource you can really offer a candidate is time to get up to speed. Our community is full of really independent, self-motivated learners that that might be great for. But make investment of that time explicit. Clarify those expectations. And also don't discount the value of peer and early stage mentorship. A really effective model that I've seen work in small startups is hiring two junior engineers who pair with each other all the time. It's hard to onboard a junior engineer. It's actually not that much harder to onboard two of them. Supplying your junior devs with peers can be just as meaningful as giving them role models. And as your junior devs get ready to take on more responsibility within your organization, one of the most concrete ways you can demonstrate their growth is by giving them an intern to mentor. But if you are in the other situation and you have an embarrassment of mentorship riches, you might want to look at you two. We can debate their musical merit all we want, but the structure of their public persona is pretty great metaphor for a mentorship team. You need a bono. This is the explicit mentor you've assigned to your new engineer. Much like bono is you choose explicit interface with the general public, this mentors your new engineers interface with all of the knowledge you need them to acquire. Mentoring your new dev is part of this person's job. And it's important that they consent to be evaluated on that. This person meets with your new dev regularly during their early days on the job. A big part of bono's job is being a person who can answer the question of how do I internet without passing too much judgment? One of the most difficult parts of being a new developer is that you haven't really developed the level of discernment to know which parts of your code base are specific to your company and like what you can actually just get out of Google. It's this mentor's job to help the junior dev cultivate that ability. The second person on the mentorship team is the edge. Still really important, not quite as public. You might not get all that face time with this person during the day-to-day. Your supervisor or maybe your mentor's mentor might fill this role. People who are really great at filling this role are available to the new developer as an alternate perspective and are happy to provide help in the event that you've driven your primary mentor just a little bit insane. And then the last person on your team is a Larry Mullen. No one knows who Larry Mullen is. I mean, I do because I googled pictures of him, but I'm not going to tell you which one of these guys is Larry Mullen. Being the Larry Mullen of a mentorship team is a thankless and incredibly important job. When you are Larry Mullen, you do not get mentioned in your junior developer speech at the Imaginary Engineering Academy Awards. A Larry Mullen is simply a colleague that doesn't roll her eyes when a junior dev asks questions. These roles don't have to be explicitly articulated. They don't even have to be the same person every day. Larry Mullen might have something in common with the junior dev, a project, a gender, a global fondness for rock climbing, but it's not a prerequisite. You are never too inexperienced to be Larry Mullen. Everyone in this room has the power to be Larry Mullen. So the people you need on your mentorship team is an explicit mentor you meet every day, an additional mentor that provides support to that mentor, and just a team of engineers that understands that developing talent is just as important as writing clean code. So just to recap really quick, planning, work with your new engineer to develop her onboarding plan. It is awesome to be ready to invest in helping someone launch a career in programming. Work with them to support that investment. Projects, look at assigning work to your new engineers as an opportunity. They're around to it. Give them projects with visible impact. Balance exciting supervised work with boring independent work. Lower the cost of asking questions and empower yourself to be everybody's Larry Mullen. Thanks all. You've been great. Great. Great talk. Questions? Hi there. You mentioned that transcripts were really helpful. Did you mean, it wasn't quite clear whether you meant just transcripts of conferences or whether internally in your team there were transcripts made of meetings? Yeah, I have a deaf colleague and so we have transcripts at all of our engineering meetings and product dev talks and some of our larger meetings and then when we're in small groups we tend to transcribe ourselves in Google Docs. So cool to watch that question being transcribed by Kimberly. More questions for Rebecca? Yeah, so this is actually advice for I guess HR people and whoever will be hiring the junior devs. Do you actually have any advice for the junior developers who've been hired and for example, have not been assigned a mentor? How to get them to or how to get the HR people to yeah. I feel like the junior devs I know who have been happiest in their positions and have like found a lot of mentorship available to them made contacts with their company through the engineering department it's hard because a lot of it is like very much about that personal connection I mean sometimes I do think that you have to seek that influence outside of your company if you're in a city like New York or Berlin where there are a lot of user groups and you can find that mentorship elsewhere also Slack can be great there's like a lot of communities kind of coming up there where like you might be able to get mentorship from people but you know are many many miles from you yeah that's a really difficult question Yeah, I was wondering if you could say something about how mentors can get feedback from junior developers or trainees or something because when you ask someone who is really inexperienced am I doing a good job at teaching you I don't think you get a very useful answer out of that and I'm usually wondering if I'm actually good at mentoring someone and I can't really tell Totally, because we're so grateful to be mentored so it's like anyone who has taken the time out of their day to invest in someone at the junior level like usually you're so excited about that that it's very difficult to be like well this could be better in this way and also when we're talking about people very early in their career they don't have a lot to compare that to this is something that we're kind of working on now at my company I'm mentoring a summer intern with a more senior developer and there's several of us and we've kind of had to talk about the different between ourselves the different ways in which we mentor and what our expectations are of each other and then you can present like that kind of template to your junior as things that might be realistic expectations for them that's kind of the best way that we've like having more conversations like these and like discussing different mentorship models I think is kind of the best way to deal with that well a lot of the stuff that we do as engineers like a lot of the paradigms that we use or technology that we use are ultimately solutions to problems that are very contextual so how to strike the right balance between I mean explaining the solution to a problem and on the other hand like letting people experience problems on their own and explaining the solution if you don't know the problem itself right it's actually very hard to me to strike this balance do you have any suggestions yeah so we're talking about striking a balance between being like perhaps a little bit too helpful because a lot of a lot of cultivating good engineering practice is coming up with the ability to answer those questions on your own I actually got a really good anecdote about this from my boyfriend last night who kind of helped teach me to code and many other people in that why would he sorry oh I walked around too much the slide on documentation and he said that when he's mentored junior engineers that he will and they're stuck on something that isn't well documented he will be like give me a minute then go and write the documentation and then tell them to look in the documentation and I thought that was pretty great thank you another round of applause for Rebecca