 Should we get started? It's like right on time for being late. Is that like a good thing? So before we start, I have a favor to ask all of you. I am a little bit nervous. And so if you could help me out by every time I take a drink of water, if you could applaud, that would be very useful for me. So let's just practice real quick, pretend I've been talking for a while and you've sort of forgotten about this weird favor I asked you. And then I'm like, OK, yeah, you're so good at that. That's going to happen so many more times. You might get sick of it by the end, but I won't. So OK, I think my slides work. So welcome to RailsConf. Welcome to Kansas City. My name is Lily Shaline. It is not phonetic. Here is how you say it. You can picture Sean Connery addressing Canadian pop legend Celine Dion. A little bit of that list again. Shaline, hopefully you'll remember that forever. So who here is from Kansas City? I am, yeah, it's not true. I don't know who's from Kansas City. I'm from Kansas City. I live in San Francisco now, but I'm super excited for RailsConf to have come to my hometown. So let's see. I'm a software engineer at Omata Health. We help people avoid getting type 2 diabetes via the internet. It's kind of fancy. So I would like to know more about you. Can you show me your hands if you have ever been an engineering intern? I have. All right, half the room. Have you ever worked with an engineering intern? More people. And who is hiring engineers in general right now? So most people, yeah, OK, that's not surprising in any way. OK, so I'm going to share with you some true stories of internships. Some of the details have been changed. Names have been left out. Some of the people are coworkers I've had at Omata. And some are like stories that I've heard from other people. So I'll tell you which ones are which. So you can be like, oh, yeah, they're wondering the identities of these folks. So the first one is not an Omata person. And this is the CS Hammer. It's a person who starts an internship and they were a recent CS grad and they just wanted to use CS for everything. Everything was a red-black tree. No one wanted to work with this person. It was really sad. They basically, this person went off by himself and just sort of like implemented this interface that they're going to like, we don't need this. And they don't understand why this person wants to do it. And they didn't really want to help him get back on the right track because they had enough work to do that it was like, we don't really have time to get this person to write the code that we actually want to use. So they just kind of ignored him. And then at the end of his internship, they were like, great, it's over. He's leaving. And then they just never did anything with his code. So that's a way to run an internship program. Um, yeah. So another one that I heard about, which was not a Nomada one, was the founder's spouse's cousin was interested in programming. And so they were like, oh, hey, let's start an internship program so this person can get a job here. And it was like, all right. So that's the thing you can do. They ended up deciding to pay all of their interns minimum wage, which is also interesting. So they didn't actually find a lot of good candidates beyond, I don't actually know if the relative was a good candidate or not. They ended up putting all of their interns on these little toy projects that did not matter at all. And it was just kind of this separate thing that nobody else learned from. And it didn't seem like a great idea. So that was kind of sad. Our third intern is a friend of mine, who is the cutting edge cat. Really wanted to use this really cool technology. Like really didn't care about building something useful at all. Ended up putting in, wanted to build a dashboard that showed the number of users logged into the site. So he put in a sidekick job that every minute would report out the number of currently logged in users. And it was just like a complete nightmare and really stupid. And I deleted his code a few months after the internship was over. But then we hired him because he was actually great despite his terrible, terrible solo project choice. So it can work out even when somebody does something really stupid. And then we have just the unabashed, a good one. We just have a really successful internship. This was also somebody at Omata. They were a recent boot camp grad. They were willing to ask a lot of questions, admit their ignorance. And they were just really a pleasure to work with. They worked with our product team to build sort of a lower priority feature, but one that was still user facing. And they copied some patterns in our code base that were just really not great. And we were like, oh yeah, don't just don't do what we did a year ago. Like we had really, really bad taste back then. And so that person was able to get some autonomy, but also support when they needed it. Yeah, and so all of these different internships are going to teach us lessons. Very good, very good. The first one, the CS Hammer. So one thing that you could take from that is don't hire CS grads, because they'll just try to make everything a red-black tree. The actual answer is not that CS is bad, but that giving someone feedback and guiding the intern and actually working with them to create the thing that you want rather than just ignoring them and saying, like, we don't really have time to make you do a good thing. That team also realized just how sort of siloed they were and how they didn't have a really collaborative culture already. Because they weren't able to sort of integrate the intern onto their team, they were like, you just go sit over here and hopefully you'll just do it right. And that's not an effective pattern for bringing on a junior developer. With the relative, you need to have a clear goal in mind that isn't just we want to employ someone's relative. You need to actually know what you want to get out of your interns, otherwise you're just going to spend resources and money having some people around who have the potential to make a big positive impact on your team, but then don't. Yeah, sad. My friend, Andy, he's great. He needed more guidance. We needed to sell him more on the fact that the goal of his internship was not to try out some sexy new technology, that his actually what he could get out of this internship is the collaboration with the rest of the team. And we sort of failed him by letting him like do work on this project that was ended up being pretty dumb. And then from the good one, we learned like a lot of stuff about like our code base that we have these bad patterns that even though we're supporting this person and I think we did a good job of helping them, they still were looking through and seeing things that we were like, oh no, no good, no good at all. So all of these things are audits. An internship program, running an internship program is letting you audit your process, your code. It's helping you see exactly what could be better about it. Okay, because really, sorry, don't move the thing. Okay, because a bad internship really isn't about, is it the intern's fault? Yes, they can contribute to it. Yes, there are like bad programmers and you might hire someone who isn't very effective. But ultimately, a bad internship is looking at it is about seeing what you've done wrong as a company to not support the intern and not to create a structure that could help them succeed. The structure of your internship matters. If you don't structure it well, it's probably gonna suck for you and the intern. And you'll probably mess it up initially. You're probably your first internship you ever run, probably won't be as great, but you'll iterate and get better at it if you're thinking critically. So a quick note on nomenclature. So I've said intern probably 65 times so far. And I'm gonna keep saying intern, but you might say something more like apprentice. I think the patterns that I'm talking about are often called apprenticeships at other companies. You might also just, these are good techniques for onboarding junior developers in general if you've hired them on to a full-time position. And they can come from a lot of different places. I think a lot of people think intern and they think a summer CS student, but they could be someone on a co-op program where they have a whole semester and then you could also have boot camp grads. So boot camp grads or internal transfers, people who were in support or design who want to get into development. So these people can come from a lot of different places in your company or from outside of your company. Okay, so that's enough about why internships are useful. I'm gonna talk a little bit about how we run them at Omata. I think we have a pretty good way of doing it, but can we just take a really quick break and just stand up for a second? We just do that. I mean really helpful. So stand with your feet about hip distance apart and roll forward and back on your feet a little bit. Ah, it's nice. Like lift your arms up and kind of stretch up and kind of stretch over to whichever side you feel like, but press the opposite foot down so that you're actually really getting a good side stretch. So, yeah, that's nice. Okay, thank you for your drink of water. Thank you. So how can you do this? The first thing you need to do is you need to make the business case. An internship program costs money, it costs time. And so you need to convince management that there's actually like a good outcome and it's not just charity work. One thing that this talk is like the slides are mostly just big words on slides. It's like not super useful to go back to. So I've done two blog post versions of this. So literally published right now. So I scheduled those. And so you can go to our tech blog and I'll have the link at the end. So you can use this stuff to try to convince your management team that the internship programs are actually really useful and that you should set one up and then how to do it. Because if you don't have buy-in for management, you shouldn't run an internship program. You just definitely don't do it if you can't pay them and take the time to really support the interns because you're not gonna get as much out of it if you're scrambling and they're not gonna have a good time if you don't have time to support them. And so yeah, having goals is really important. So for Omada, we want to make sure our onboarding game is always on point. We wanna make sure that we're really good at teaching and sort of knowledge transfer. I hate that phrase, knowledge transfer. Like it's really so corporate and weird but people seem to like it better than teaching because they think teaching is like where you're in front of a classroom and you're like, I don't wanna teach people programming and I'm like, you're doing it every day with your colleagues anyway. So, and then we also really appreciate like the different backgrounds that people who come in as interns have. And so they bring a lot of like fresh ideas and they ask a lot of questions about our process and that helps us. So how do we roll? How we roll? I really like this GIF. That's a hedgehog. The toilet paper roll on its face. Just in case you needed narration. All right, so the way an Omada internship works is we start with pairing for about a month or six weeks and then we have them go on a solo project for another month or six weeks and then finally back to the pairing again. It's a pretty straightforward process and they always have a mentor who is someone from their team. And so you might wonder what kinds of teams can support an intern. Don't have a team of all interns. I would try to avoid that. You hear about this like in San Francisco where like people will hire one boot camp grad and then three months later they'll hire another boot camp grad and another one and then you're like, oh no, this doesn't seem good for like the boot campers or the company so you know, avoid that. At Omada we usually have on a team one to two seniors, one to two mid level devs and one to two junior or interns. I joined a team of about three and a half engineers when I first started at Omada and it was super useful. So if you have three engineers you can probably support an intern. Thank you. Stickin' with it. So we do pair programming at Omada. Could you raise your hand relative to the amount of pair programming you do? So I do like 80% pair programming at my company. If you don't pair, put no hands up. Okay, so me like five, six, awesome. Okay, does everybody know what pair programming is mostly? Cool, you know what pair programming isn't? It isn't that thing where you go over to your coworkers computer and look over their shoulder and help them when they got stuck. Pair programming is when there is one computer, two keyboards, two mice, sometimes two monitors if you're fancy. So just try to like socialize that to your team. Like don't say like, oh yeah, we pair like when it gets stuck or when we need to make really big architectural decisions. It's like, no that's not pairing. So anyway, rant over. I like pair programming because it helps us have fewer silos. Communication and teaching skill is expected of people in pair programming environments. You're not just gonna be by yourself so you should be able to communicate to your pair what's going on. And onboarding is so much easier. Just pairing with someone and they get to ship production code on the first day and it's like the next story in the backlog which I really like. So you might think like, oh great, we don't pair but like pairing would be super useful for an intern, right? And I actually would not recommend starting pairing with an intern because pairing across skill levels is a completely different beast than pairing with someone approximately the same skill level as you. Pairing with someone who is around the same skill level is like, for me very fun. There's like a little flow and I like pairing with interns but it's a lot slower. So I would not recommend starting pairing with an intern but start pairing with your current colleagues. Do it, try it, it's really fun, I like it. Just need some more keyboards. If you are pairing with an intern you wanna make sure you let them type. It's really easy just to grab the keyboard or even if you're not pairing but you're just walking through a problem with them. It's really easy if you see a test that's failing that you don't expect to just grab the keyboard immediately and not work through the problem with them. Some of the people that I have a ton of respect for that I've paired with have grabbed the keyboard just immediately upon being confused because it's really hard to just stop and talk it through. So if you don't care, obviously you're not gonna have an intern pick up like the next important feature off of the backlog on their first day. So you're probably gonna start with something like a solo project and code review is gonna be really important. Hopefully you do have a code review practice. If you don't, you should like do that. So once you have an intern and they're working on stuff you are going to learn sad things unfortunately. So bummer, sad thing, number one, you already know your code is confusing. Bart is sad, aw. But yeah, you know that, you know because but you might have forgotten that like that model name that was named that thing because back in like 2011 there was a different thing and then we sort of changed what it did but we didn't change the name because like find and replace is like really hard. You might have to write a migration. Like I don't wanna do that. So you have to explain to someone sort of like how that works but you've basically gotten used to all of the weird things in your code base and you might have some like Stockholm syndrome with your code base. Like yeah, I do. And the bummer is pretty soon your intern is actually gonna get used to it too. So it's important to have regularly occurring interns and regularly bringing people on so they have those fresh eyes and are like why are you doing this? And encouraging interns to ask why even if they're not like it can be hard to question sort of an existing code base if you're more junior. But that is so much their value. So if any of you are current interns please start asking why every day about at least one thing if not five times a day. The second sad thing that you're gonna learn is that some people are just not good teachers. You're gonna like watch people and it's gonna kind of suck because it's like you're gonna be like hogging the keyboard all the time or like you're gonna read their comments on their pull requests and be like that was like so not the nicest way you could have said that. Like it could have been nicer because you wanna watch out for snark for judgment for people who aren't letting the intern like really do their best work and then coach those people because good news teaching is a skill that you could learn. People are not born teachers. Some people might be socialized to be more empathetic but all human beings can learn the skill of teaching. They just have to try. So one other thing about that is that sometimes as an intern at least for me I felt like it was important that I teach people how to teach me. So if I was working with someone who wasn't a very good teacher I'd be like oh if I could just like ask the perfect question maybe they could like explain this thing to me and then it just would not happen. And so reminding your interns that it's not their job to teach the teachers like they should really just they give feedback to you or their mentor or the managers because yeah it's not their job. Everybody out there is gonna be really wondering why there's like all this very polite applause every few minutes. Cool so the solo project is a huge part of running an internship program after I was pairing for about a month at Omata and then I had to write my first controller spec. I was like oh what are you doing? I had written so many specs with my pairs but I'd never had to write one by myself really. So then I got some code review and it was like you know these if statements like you should probably have tests for those paths or paths and maybe you should TDD those and I was like oh yeah that thing we've been doing really consistently but then I stopped doing as soon as I was by myself. Yeah so the solo project is super good for learning and sort of integrating some of the things. I've talked about this a little bit before but picking a project I think is pretty important for how much the intern gets out of their internship or at least their solo project. One of our most recent interns worked directly with the product team to add a thing as I mentioned earlier and it was just really awesome to see her like go and like pair with her ahead of time and then have her solo and learn a bunch of stuff and then come back to the team and like just know so much more and just have a lot more like confidence was really cool. Yeah so the next up is code review. So it's really important during the solo project obviously it's really important if you don't pair program. We're sort of of the pairing is inline code review school so we actually just all like if it has a pair we just push to master and say goodbye. Y'all might pair and then do code review that seems cool too. So in person code review is really great if you can if you're a co-located team. I don't know how you would run an internship program distributedly but if somebody can give a talk next year about that that would be cool because my team is co-located. So it feels straightforward compared to what I think distributed would be. And let's see so last year at RailsConf Derek Pryor gave a talk about code review and you should totes watch it because it's so wonderful and he talks a lot about how written communication is just inherently more emotionally ambiguous and that's I think especially important when you're working with an intern. Really all of your colleagues you should be like treating with a lot of care and respect but please do check out his talk about code review. Our mentorship is set up kind of from the beginning so it's usually a team lead but it can sometimes be someone else from the team it's a nice opportunity for someone who's sort of management curious to see what it feels like to be in that role. The mentorship is helpful if it's scheduled during the solo project so if you actually have like a five o'clock check-in every day with the intern it's really useful we learned that the hard way by like a couple weeks into the solo project being like hey how's that thing you're working on and you're just like oh my god like wow but you didn't say it out loud you just felt it in your heart because you wouldn't want to make them sad and make like reveal how horrified you were. So we've started doing like scheduled check-ins every day which is really useful for the intern to be able to know that that is their time and then obviously the team is interruptible throughout the day if they have a question if they're stuck on something we don't want someone to have to wait from like 9.30 in the morning all the way to 5 p.m. if they're stuck they can definitely talk to the rest of us. So if you're a consultancy that's kind of different we're a product company so like the cost of an intern just sort of gets rolled into the cost of existing. When you're actually looking at developer hours and paying that person money I don't have a slide for this but you have to pay interns don't ever do a free internship also the law is like wants you to pay them because if they benefit your company then like you kind of need to yeah pay them because that's how that works so sorry aside. Some companies I've heard of some consultancies will bill at a discounted rate from the intern from the very beginning sometimes they'll start billing later in the internship so they'll start doing kind of like internal toy projects and then sort of like ramp up once people are a little bit more confident. I think the how long it's gonna be before you can bill for an intern is gonna depend a lot on their skills coming into the internship. If you have someone who's super super fresh it might take a little bit longer. And then I've also heard of consultancies where an intern will work on a single client project for some period of time for like the duration of their internship and then get hired on by the client at the end of it. So everybody's happy, jobs at the end. It's so much less awkward because you don't have just like listened to me drink the water, I really like it. Okay so secret bonus thing about running an internship program is it's super rad for making your team more diverse. Hiring interns is not the only part of the strategy of making a diverse team because having a diverse team where like all of your seniors are white dudes and all of your juniors are not, like that really sucks, so don't do that. But it's like still kind of cool because it is a way that might be a little bit easier to diversify your team. So some statistics for you. So a rough percentage of people who are women, software engineers, we have about 16% of software engineers are women according to LinkedIn. They probably know like a couple of things, right? 18% of CS grads are women according to the National Science Foundation. And 38% of bootcamp grads are women. What, that's so many more. According to 432 surveyed in 2014. I have no idea whether that's like a good sample size or not. I don't know anything about statistics but it seems pretty cool that 38% of the people who took that survey were women. So if you wanna get more women on your team, having bootcamp grads do an internship or something and then join your team is a great way to do it. The stats on race are like way more depressing. I don't actually understand why the people, so the bootcamp survey, this was their like race box and I was like, what is other? Like, could you really not have more than four options? Like, I'm just really frustrating. I don't know what it is. But it's not nearly as sort of exciting or like the statistics are not as like, oh yeah, this is gonna be a slam dunk. So you, to find like people of color and other underrepresented groups, you're still gonna have to put in some more elbow grease. And so to do that, you really wanna make sure that you're posting outside of your usual networks. If you run an internship program and all you do is like email like current employees friends or if you don't put a posting up or if you like only put it up on your website and don't tell anybody, it's not, you're only gonna find the people who would already kind of clued into your company. And then you also, you can work with organizations like Railsbridge or Code2040 to help them know that you have an internship program and then awesome people will come your way. Half of our female developers came to Omada via internships via Railsbridge. So that's cool. And so yeah, when you are recruiting and interviewing interns, we tend to like just have a little bit of a less strenuous process. We start with a code challenge where they need to fix some broken tests. It's amazing how many people don't follow directions and they're just like, oh, I don't like this test. I'm just gonna change it. And it's like, no, that's like the whole point. Just make the test pass. They still do it. It's useful though, right? Cause then they just don't move on. And then they have a phone screen. They get past the code challenge, short one with a manager. And then if that goes well, we bring them in for a pairing interview. If you're hiring people based on not on their current technical skill, if you're hiring people cause they ask good questions and they have a lot of potential, you're not gonna wanna ask them like algorithms or like whiteboarding things. So just like stop doing that entirely but also stop doing that for everyone in addition to interns. If you could do that for me, that'd be great. So one of the cool things about our internship program is it really helps us also retain current developers. We use the same sort of structure for team rotations. So last fall, I did a three month rotation on to our ops team and it was so awesome. Like I spent, like I literally did like a month of pairing in with the team, a month of a solo project where I just like fought with Nagios and then a month back with the team. And when I got done, I was like, I knew a lot more about monitoring than I started. So I highly recommend doing this kind of thing within your teams cause engineers, like we wanna learn new stuff and we wanna expand our skill set. So give that a shot. So there are a few things that I would change about Omada's internship program. I'd be interested in potentially just hiring these people as junior engineers instead of giving them this like three or four month long like audition where it's like we might give you a job at the end if everything works out. It's nice cause it's like way less commitment and you get to like take chances on people if you're like, well it's fine. Like not giving someone a job is obviously easier than firing someone but it still feels kind of like me to me. I'd be interested in potentially calling our interns apprentices if we're planning on hiring them at the end cause it seems like maybe like the word that people use more. Maybe we should give them health insurance. My bosses are gonna be really excited that I'm just saying all these things. They're gonna love it. And then I would love to see us and I know we're planning on doing this but we haven't done it yet is posting our internship openings to the job boards at like historically black colleges and universities just so that we can sort of like we have a lot of women in tech sort of organizations that we work with but I'd really like to see us focus more on getting more people of color onto our team. So all of this what I'd like to leave you with is that audits are helpful. It's a little bit painful when an intern comes on and it's like it's really hard to explain this part of the code base or they ask like why do you point and then everyone's like oh I don't actually know what is pointing. It's a good pain. It's good to like recognize the things that are not great on your team and then improve them. And doing so will help you like hire and retain awesome people. It'll keep your team on your toes and you'll be better at making software. So that's it. One more drink of water.