Great Expectations: Power-Charging Apprenticeship Programs
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 69 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/37766 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Ruby Conference 201751 / 69
2
5
8
11
13
19
20
21
32
33
34
35
37
40
43
44
52
54
55
56
57
58
62
64
65
67
00:00
Computer programPower (physics)Turing testCASE <Informatik>Computer programmingPower (physics)Front and back endsTuring testXMLUMLComputer animation
00:43
Turing testCodeTwitterBitTwitterMereologyQuicksortPoint (geometry)Computer programmingSoftware developerFile formatProcess (computing)Level (video gaming)Perspective (visual)Different (Kate Ryan album)AngleRight angleSelf-organizationOrder (biology)Goodness of fitExpected valueStructural loadCodeGame theoryType theoryMultiplication signData structureMeeting/InterviewComputer animation
05:14
VacuumMultiplication signComputer programmingGroup actionPosition operatorPoint (geometry)Right angleFreewareTerm (mathematics)WordComputer animation
06:38
Point (geometry)Set (mathematics)Strategy gameOnline helpMultiplication signPhase transitionComputer programmingPlanningSelectivity (electronic)Computer animation
07:26
Phase transitionPlanningPhysical systemArithmetic progressionTrailMedical imagingSelectivity (electronic)Bus (computing)PlanningStrategy gameMultiplication signRight angleBitProjective planeComputer programmingClient (computing)SoftwareGame theoryQuicksortComputer animation
08:57
Strategy gameGroup actionSpectrum (functional analysis)CodeComputer programmingDifferent (Kate Ryan album)QuicksortLevel (video gaming)PlanningRange (statistics)Strategy gameAxiom of choiceBitHypermediaOnline helpAngleSlide ruleWeb pageComputer animation
11:35
PlanningFood energyArithmetic meanMultiplication signData managementWhiteboardWeb pageMereologyPhase transitionCASE <Informatik>Computer animation
12:32
Latent heatBuildingCASE <Informatik>QuicksortPosition operatorAddress spaceDependent and independent variablesScheduling (computing)CASE <Informatik>BuildingPoint (geometry)Level (video gaming)Key (cryptography)Inheritance (object-oriented programming)Band matrixDifferent (Kate Ryan album)Data managementWeb pageComputer programmingPlanningPerspective (visual)Wave packetBootingLatent heatStrategy gameMultiplication signExpected valueGame theoryBit rateSet (mathematics)Dressing (medical)Computer animation
15:51
PlanningView (database)Level (video gaming)Arithmetic progressionInformationEntire functionMultiplication signPlanningCASE <Informatik>Game theoryData structureAffine spacePixelData conversionRight angleElectronic mailing listRing (mathematics)Bit rateInformationComputer programmingLevel (video gaming)Message passingWater vaporSet (mathematics)Point (geometry)SpacetimeQuicksortResultantWordProjective planeWeb pageMixed realityParallel portComputer animation
20:02
QuicksortOnline helpLevel (video gaming)Arithmetic progressionDifferent (Kate Ryan album)NumberData structureSoftwareMultiplicationMultitier architectureServer (computing)Expert systemPhysical systemBitChemical equationMultiplication signNumbering schemeComputer animation
21:36
Formal languageSemantics (computer science)ImplementationCodeFeedbackFunction (mathematics)Message passingSet (mathematics)VolumeTuring testQuicksortFormal languageElectronic program guideWeb pageGame theoryBitWordArithmetic progressionSet (mathematics)Revision controlControl flowGame controllerLevel (video gaming)Student's t-testSheaf (mathematics)View (database)MathematicsFeedbackCodeFunctional (mathematics)Physical systemWhiteboardPlanningSemantics (computer science)Reading (process)Computer animation
24:56
Multiplication signTrailPerspective (visual)Row (database)Set (mathematics)BitIntegrated development environmentMereologyProcess (computing)Right angleSpeech synthesisBlogFitness functionPosition operatorType theoryEuler anglesComputer animation
26:09
Computer virusLocal GroupEuler anglesLimit (category theory)CodeStandard deviationComputer programmingPhase transitionRevision controlCodeRow (database)Multiplication signOnline helpPlanningElectronic mailing listBitTrailSet (mathematics)Pattern languageType theoryQuicksortIntegrated development environmentEuler anglesGroup actionTuring testFocus (optics)Sheaf (mathematics)Dynamical systemRight angleLogic gateVector potentialSelf-organizationData structureLine (geometry)Process (computing)Point (geometry)MereologyPosition operatorArithmetic progressionClient (computing)Formal languageCausalityAngleTerm (mathematics)ConsistencySolid geometryFloppy diskGradientWater vaporArmWeightNP-hardNatural numberCircleComputer animation
35:39
Physical systemTelecommunicationDirection (geometry)PlanningWhiteboardBitTrailLattice (order)InformationRule of inferenceStaff (military)QuicksortDirection (geometry)TelecommunicationMobile appPhysical systemDifferent (Kate Ryan album)CodeLink (knot theory)Bookmark (World Wide Web)Arithmetic meanLatent heatUniform resource locatorWeb pageGoogolMilitary baseRight angleGoodness of fitComputer animation
38:14
Broadcast programmingTelecommunicationArithmetic progressionExpected valueQuicksortData structureTrajectoryTrailLevel (video gaming)Scheduling (computing)Electronic mailing listGodRule of inferenceProcess (computing)Computer animation
39:41
Performance appraisalFunction (mathematics)CodeFeedbackImplementationArithmetic progressionBitTrajectoryPerformance appraisalComputer programmingComputer animation
40:21
Projective planeCodeQuicksortLengthVideo gamePressureClient (computing)Wave packetPoint (geometry)NP-hardBitSoftwareControl flowUniversal product codeSpacetimeSocial classMereologyComputer animation
43:11
Online helpFitness functionCASE <Informatik>Term (mathematics)Computer programmingPosition operatorPoint (geometry)Film editingLoop (music)Bit rateVideo gameClient (computing)Letterpress printingBest, worst and average caseFault-tolerant systemComputer animation
45:41
ResultantSource codeQuicksortPlanningOpen sourceFigurate numberComputer animationLecture/Conference
46:50
QuicksortLevel (video gaming)Computer programmingGroup actionPosition operatorProjective planeDivisorMusical ensembleDistortion (mathematics)Lecture/Conference
47:48
Expected valueChemical equationTask (computing)Product (business)QuicksortProcess (computing)SpacetimeWordRight angleBitSubsetPoint (geometry)MereologyProjective planeNormal (geometry)Multiplication signUniversal product codeLattice (order)Server (computing)HypermediaCrash (computing)1 (number)Reading (process)Video gameDecision theoryStudent's t-testLecture/Conference
51:35
Coma BerenicesXML
Transcript: English(auto-generated)
00:12
So it is 2.40, so I'm gonna go ahead and get started. I'm gonna be talking about power-charging apprenticeship programs today.
00:23
And you are probably wondering, who is this lady? Hi, I'm Louisa. I work at the Turing School of Software and Design. I am the founding instructor and I'm currently the director of the front-end engineering program.
00:41
And that means that I work with, I don't know if you're familiar with Turing, but this is Jeff Casimir, here's our founder. He's not here today, so I can pick on him a little bit. So back to me now. So since I'm on the front-end team, I like design and I like code, and I also like teaching. And that means that I basically, I spend my days
01:02
hurting humans, talking about typography, JavaScript, and if you will excuse my, like pardon my French, CSS. And I am extremely bad at Twitter, but this is my Twitter handle, and it's like, it's really embarrassing how bad I am at Twitter, so just don't judge me.
01:23
So, I'm a friend in person. I am at a Ruby conference, so that's weird, why am I here? Firstly, extremely good at Ruby, as you can tell by this. And mostly, jokes, I'm good at it.
01:40
Okay, woo, all right, anyway, so. What I'm actually here to talk to you about is apprenticeships, and so for the last couple years, I'm also used to like walking around when I talk, so if I keep like walking away from the mic, please forgive me and I'll come back to it. So, for the last couple years, my whole job has been
02:01
to figure out the best and most repeatable techniques to get people ramped up into junior dev level skill levels to do that really quickly and to do that really consistently and obviously, like I'm working at a school, so I'm in a more education-based place,
02:22
but that's essentially what an apprenticeship is, right? It's in a little bit more like business-minded format rather than an education-based format. So, I do this a lot, this is my job, and I just wanted to talk to you about it. And part of why I wanna do that is because my background is in design.
02:40
I was a designer for a very long time, I've been in the creative industries for many years before I switched over to writing code, and it was really interesting to me coming from the creative industry where apprenticeships and internships are just kind of like part of the game, and it's like expected that you will have had some sort of an apprenticeship
03:00
or some sort of an internship at some point before you have like your first like real job. And often, again, because it's a creative industry, those jobs are, those internships or those apprenticeships are often unpaid because of reasons like experience
03:21
and you're passionate about it, which is a load of crap. But it was really interesting coming into software development because it was a very different kind of like mindset around them. They were a little bit less common. I think people took them a lot more seriously, and I feel like part of the reason that they did that is because there's this expectation
03:42
that you should be like compensated fairly for your work in this industry, which is quite a fantastic thing, right? That's great. But it means that people take it a little bit more seriously and that people are more concerned about making sure that it's actually fair and that people are being treated right. But at the same time, that means that I feel like
04:00
there are potentially fewer opportunities to get your foot in the door in an apprenticeship-type situation at a company unless it's a really big organization that has a lot of wiggle room and funding for it. But the thing is that apprenticeships are really valuable to teams. I think that they are really great experiences
04:21
for both the person who is the actual apprentice and then also the team that they're working with. And really, the biggest thing is just to structure them correctly and just be mindful of how you're putting them together in order for them to really be successful and really be a good experience for everyone. So, yes, setting up a successful apprenticeship
04:41
is not impossible and it is not scary. And they really are worth it. And part of that is just because it is so energizing to have somebody who's new to the industry as a part of your team. They are incredibly motivated, they are really excited, and they are also just really fun to work with. They see things from new perspectives and different angles and it's just really exciting
05:02
and fun to be a part of it when you're on a team with someone like that. So, yes, all of you could absolutely build in a successful apprenticeship program and your team will be significantly stronger for it. So, if you are still thinking that an apprenticeship program seems like it's just kind of a high-risk time and money vacuum
05:23
and you're kind of wondering if that investment is really gonna pay off, yes, it will. In my experience, the benefits to the team and just like the general company ecosystem are actually really big. An apprenticeship can be, or just bringing on an apprentice is a really great way to re-energize a team.
05:42
Even if you just have like, if you are able to have a team of just senior people, bringing on somebody who's brand new is a really energizing and fun thing to do. And they can bring a lot of just joy and fun to the group that you may not expect. And remember, it also isn't something that's forever for either party, right? Like an apprenticeship is a termed thing
06:01
that somebody's gonna grow out of. They're gonna grow into a more experienced role, they're gonna be a junior, they're gonna become a mid-level person at some point, they're gonna move into a senior position at some point down the road. So, like, they're super motivated, they know that there's a light at the end of the tunnel, they know that they're gonna be progressing quickly, so they're gonna be working really hard and they're gonna get better really fast.
06:21
And so investing in them at that point in their careers is really beneficial to you and them and it really will pay off quickly. So, again, in conclusion, you absolutely can have an apprenticeship program and they will make your team better and you will have a lot of really new, weird jokes, which is always great, right? More jokes. So, the plan, you should have one.
06:43
Perfect, great. So again, like, before you get started, the very first thing you should do is just make sure that your whole team, so like top down, understands, like, what the point of an apprentice is. And it is an educational learning relationship, right? So, like, you're bringing on someone
07:01
who is there to learn from you and someone who you've committed to teaching for a set amount of time. And keeping that in mind, that this is something that you have agreed to do, that you're, like, agreeing to teach someone and they're agreeing to learn from you, we're gonna talk about some strategies that will help teams plan and prepare
07:20
for a successful apprenticeship program. And there are three phases of planning that I'm gonna be talking about today. So, first, like, what to do before you start an apprenticeship. So, like, systems and processes to have in place, things to do before you actually get rolling with it. How to hire for an apprenticeship, so how to actually find the right candidate
07:40
and then hire the right person. And then just what to do during the apprenticeship. Like, how do you keep somebody on track? How do you make sure that they're making progress and how do you keep the wheels on the bus? I guess is how you could say that. So, with those in mind, those are the things we're gonna be talking about and we're gonna just dive right in to what to do before you start an apprenticeship.
08:04
So, like most things that are worth doing, this does take a little bit of work to put a program like this together and that's okay. It's kind of like, it's not really that different than, like, when you start a new, like, if you bring out a new client project, or you just start a new software project,
08:20
it's just planning, right? So in these phases, this is just sort of like strategy and planning and making sure everybody's on board. And like a new client project or a new software project, it's in your best interest to put about five to 10% of your time in upfront to make sure that you're in a good place to have things that you can, like goals and a game plan to execute on
08:41
throughout the duration of your program. So, the work you put in should start, before you even start thinking about interviewing candidates and it's really gonna pay you back tenfold once you actually bring someone onto your team. So, with that in mind, let's dig into it. So, something to consider before you get started again
09:01
is just put your, the whys before the hows, right? So this is really trying to understand the reasons and motivations that are driving you to start a program like this. There's not necessarily, like, a wrong motivation or a right motivation, but there are different motivators and it's very important to just make sure
09:21
that you're paying attention to that. Cause if you are sort of angling, if you're taking it at an angle that isn't really, truly targeting the motivations and the reasons that you're doing this, you could potentially not have as successful an experience as you would otherwise. So, whys behind bringing on an apprentice can, there can be a big range of reasons,
09:41
like lots of different reasons why you might do this. And they might range from, like, educational, you might feel like you really wanna just bring someone into the industry and help them get a toehold and just get a good, solid start. Or they might be financial, like maybe you're at a really small company and you need more hands on deck, and the reality is that you don't have the budget to bring on a mid-level or senior person.
10:02
And an apprentice is sort of like, okay, I'm gonna get this person started, but I also, it's gonna help me because I can actually, like, afford to pay them. And again, those are both valid reasons, there's not necessarily that there isn't, like, a right way or a wrong way to do this, it's just, be honest about it.
10:22
And be clear with yourself, your team, and the person you're bringing on, so that everybody's really on the same page about, like, what's going on and why they're coming onto the team. So, and because those two, sort of like, two spectrums of motivations are very different,
10:41
they're going to impact how you actually approach a program like this. So, if you tell yourself that you are going to help, like, a newbie get a toehold in the industry, that's gonna really sort of direct your choices and how you structure things very differently than if what you need is somebody who is gonna be able to actually hit the ground running
11:02
a little bit faster and really start contributing to code because you just need more hands on deck. So, just make sure that you're clear on that and then your planning and your execution will be more aligned. And again, just being honest with yourself about that will lead to more successes. So, making sure that you are planning carefully,
11:23
hiring strategically, and then having an actionable curriculum strategy, which sounds scarier than it actually is, are going to make sure that you have set yourself up for success with your team. So, before, again, like, before you bring on,
11:42
before you start hiring anybody or anything like that, but this is all still part of the planning phase of things, you wanna make sure that you have buy in from the whole team. So, this is basically top down buy in. Like, you wanna pitch this and sell it to your whole team. So, what that kind of means is that, you know, you end up making sure that, like, management
12:01
needs to understand, like, the reasoning behind this, why it offers value, and then your team should also be on board and, like, understanding that this is something that they're excited about and invested in. So, everybody needs to be on the same page about how time and energy is gonna be allocated for something like this. And then, because people have an easier time
12:21
saying yes when they can clearly see, like, the path to success, here are some ways that you can be strategic and communicate your plan to the whole team to get go ahead from everybody. So, you wanna make your case and you wanna be specific about it, so you wanna understand, you wanna have a defendable business reason
12:41
and, like, team building reasons for why adding this position is gonna be beneficial. And you wanna be, like, very explicit and direct around what roles everyone is gonna be responsible for when you get someone on the team. And again, like, the stronger you can make a case for this now, the more your team will understand,
13:01
like, where you're headed and where your head's at and this, like, the plan. And they will be able to support you better. And again, this comes from management down. So you wanna go top down, everyone should be bought in, everybody should be on the same page. Because then you ultimately, what you wanna do is be, you wanna have it be as supportive as you can for this new person that you're bringing on.
13:20
And again, like, the whole point of this is to just make it easy for the team to say yes to this. So you need to be prepared to explain why this program is valuable to the team and then to be clear about who is responsible for what. So just make sure that you have, like, a strategy and a plan around, like, how things are happening and when they're gonna happen and all that. And some things you can dig into are
13:40
to build a strong case for this. Know who the primary point person is gonna be. So you wanna make sure that you have someone who's gonna be, like, an owner of this apprenticeship and they're going to be the primary mentor. You want to be clear about how key team members will have bandwidth in their schedules. So if it's possible to sort of, like,
14:02
address scheduling issues and make sure that people aren't gonna feel totally overloaded. So just sort of, like, being able to adjust schedules in such a way or just address scheduling issues in such a way to make sure that people actually have the bandwidth to support this person. And then just being clear that teaching actually makes your team a lot stronger.
14:21
So if you have a team of very senior people, there are a lot of opportunities for teaching a brand new beginner that will make them better. Having to explain something at a really granular, like, specific level to somebody who doesn't understand the bigger picture is really difficult, and it's actually surprising
14:40
how many senior people struggle with that. So bringing somebody on who's super junior and doesn't have a lot of exposure to these things is actually really great, even if you have a primarily senior level team. It also brings on a lot of different perspectives and skill sets, especially, I mean, even if you're hiring from, like, a traditional CS program, but if you're hiring
15:00
from, like, an accelerated training program or a boot camp, you're gonna get all of this, like, life history and career experience that is really interesting and kind of exciting. So it's gonna re-energize your team, and it's gonna bring on a lot of interesting perspectives and approaches to the work, which is great.
15:21
And then you should also just be very clear about how your apprentice's time will be spent and how they're gonna be progressively ramping up so they are able to take on more and more billable work. Like, there's an expectation that initially you're gonna be, you know, not have as much billable time, and then as you taper off towards the end of your apprenticeship, that you should be pretty much mostly billable, right?
15:42
So be clear about that, and then just have a game plan for how they're going to get up to that skill level so they are more billable. So then we have backwards planning. So this is something around, so this is probably something that's gonna be happening
16:00
around the same time as your team buy-in conversations, and this is something that's going to help you do that. So backwards planning is essentially helping you make a case for why this is doable and achievable, and it also helps you just set up a game plan for how you're gonna structure things. So when I'm talking about backwards planning, what I'm essentially talking about
16:20
is just curriculum planning. So it's basically like, so first of all, curriculum's not a scary word, you can do this. It's basically just saying that you are going to start out figuring out where the person needs to end up, and then working your way backwards. So at the end of the program, they should have this set of skills, and I know that,
16:42
and then how do I actually break that down from day one to make them successful to hit that point that I need them to be at? So around curriculum planning, things that you can do to organize this is, so you start, again, you start with the list of skills and competencies
17:00
that you want them to have mastery of at the very end of the program. So you're gonna go ahead and make sure that you have been very clear and explicit about that. So we're basically starting at the biggest picture view, and then we're working our way into more granular level. So again, we start out with end of the program,
17:20
where do they need to be? Then we work our way in from there, so we say 10,000 foot view, how do I get them there? So this is when you start thinking about, like if I need them to know this whole big set of stuff, how do I actually break that down into bite-sizeable pieces so I'm not just like throwing them in the deep end and expecting them to know how to swim if I haven't put little water wings on them at all?
17:43
So that's this next step. Then finally we kind of go down into a week-by-week breakdown of goals. So this is when we really start getting granular, we really start breaking this bigger end goal down into these little pieces. And again, this isn't all that different from like project planning, right? So it's essentially like you are taking this big problem
18:03
and you're breaking it into little pieces that don't seem so intimidating. But again, this is about education, so we're dealing with how do we take this larger problem and then we break it down into little pieces. So this is gonna be something where like you figure out from week one, what do I need them to know? And then I'm gonna build on that,
18:21
you're just gonna build your way upwards towards the end of the program. You also need to understand what success looks like at all of these various stages of the apprenticeship and then also additionally, so you need to understand what success looks like and then in parallel with that, you need to understand what kind of a plan do you have
18:41
if they start falling behind? And it's likely that they'll have several different things that they need to be working on at the same time or that they'll be ramping up on and not everybody learns the same skills at the same pace. So it could be that there are certain things that they are really excelling at and then certain things that they are sort of struggling with. So just being prepared for that and then having some sort of a game plan so you can kind of hop in
19:01
and start helping them out if they get stuck. And then another thing is just to be sure that you have clear ways that someone can understand what skills they need to know and then how they can improve on those.
19:26
And again, to get a whole team buy-in, it's important that you have set up this information in a way that is accessible to the whole team. So everybody's able to be on the same page and just be clearly communicating at the same time
19:41
to both the apprenticeship and each other about where they are at. And this is also really helpful because the apprentice can then sort of self-assess along the way and it's not just totally on you to have to handhold them and tell them where they're at. Yeah, so again, it just allows the team to be aligned and you're not getting mixed messages from everyone.
20:04
All right, so again, to understand how to track progress for once your apprentice gets started, this is something that is a little bit tricky, right? Because it can feel a little bit ambiguous and you've got a lot of different things that you need to kind of pay attention to
20:21
because if you, software is not a simple thing, so you need to have, there's gonna be multiple things that they're ramping up on at the same time. And so you need some sort of a rubric that you can balance against and check against so people understand where they're at and they have actionable steps that they can take to get better at certain specific skills.
20:41
And so things that I've seen great success with are when we have a tiered scoring system, essentially. So these can be either rankings from red to green, so red would be something that someone is struggling with and green is something that they're just, they're crews and they don't need a lot of help with that. You could have like sort of a number system, so one to four or even just something
21:02
like from novice to expert, right? So you can just have just some sort of ranking that somebody understands the tiers and like the structure that they can keep working their way up from. It should be kept somewhat simple. You don't wanna get so complex that it's overly tricky to understand or to use.
21:21
So I'd say probably between three and five sort of skill levels per skill that they're mastering. So different levels that they can work their way up from. And it should really have clear and explicit steps that explain how to move forward from one level to the next. Something else to consider is just semantics, right? So how you phrase things really matters,
21:41
especially when someone's in a situation where they're learning something new that they're a little bit uncomfortable with. And it can actually have a really big impact on people if you use poorly chosen words and you can really negatively impact someone's progress and their growth. So you don't have to treat them like a delicate flower.
22:01
You don't have to be like overly warm and fuzzy about everything. But it is important to just use language that builds them up rather than tears them down. So as an example of that, here's an example of some positive language that we use at Turing. So this is a very high level breakdown
22:21
of just the language that we use for students in the first few weeks of Turing. So you see we have a breakdown from novice, advanced beginner, proficient to exceptional. So we have four levels of skills. And then within there, so novice is defined as, and again, this is very high level. This isn't broken down into like granular sections
22:40
of like skills. This is just sort of like big picture, 10,000 foot view of like how they're doing. So it says can function but needs a lot of oversight. For novice, advanced beginner can function with very little oversight. Proficient is can confidently implement code without the need for rigid feedback. And then exceptional is understands and execute advanced concepts.
23:00
So there's a pretty clear progression of skills and understanding there. And it allows them to like, they can go and read this and they don't need us to necessarily sit next to them and like guide them. And that's really useful because it means that there's much more, they're able to take control of their own learning and you don't have to like handhold them quite so much. Then we have another slightly more in-depth example.
23:25
So this is an example for just get how they understand version control. And again, we have the four-tier breakdown from novice to exceptional. With novice essentially just saying they can use commits.
23:42
They can articulate what a commit is, so that's good. Hooray! And then they also, but they're kind of taking like big commits and then shove them all up to master, which is, you know, a little bit of a dangerous game. And then we take it up to exceptional, which is that they understand, or that they know how to reset to previous commits,
24:01
rebase large sets of small commits, and then if applicable, use other advanced get maneuvers. So we have a pretty drastic change in their understanding of this specific skillset, which is really useful. And so again, like you would just sort of break down each sort of step of the skills that you'd want them to understand in this way so they can go in and self-assess.
24:21
And this should be something that is available and accessible to your whole team, so everyone who's working with the apprentice, everyone who needs to like support them and guide them, so everyone's on the same page and being consistent with the messaging that they're giving them. So everyone's just communicating consistently to them. And they can also self-assess. So those are things that you should handle
24:41
before you get a human on board, right? So that's gonna be something that's going to allow you to be in a good place to just start working with them once you get somebody on board, and you're gonna have like all your systems in place, your team's on board, you have like a game plan, you know where you need them to be, and then you need to actually find the right human.
25:00
So it's not really all that different than hiring, like for another dev position. The biggest thing is that you're looking for somebody, you're investing in someone as a prospect rather than someone with a proven track record. So it takes a little bit of,
25:20
I guess potentially a little bit more finesse than just hiring someone who you know, like you've seen their work at other companies, you've seen them speaking at conferences, you've seen them around, you've seen their blog posts, like you know what they've been doing and you know they're really good. This is someone who's kind of an unknown and gets a little bit of a risk. But there are definitely things you can look for
25:41
that will be really helpful in guiding you to find the right person and the right fit, and that's actually a big part of what I do at Turing, right? So a big part of my job is to really just quickly and accurately gauge who has the right personality or just attitude and perspective to be successful in this type of environment where it's a little bit less,
26:01
it's a little bit less supported, and it's someone that they can, something that they can sort of learn on their own and they can be successful there. So things that I look for, so I tried not to use GIFs but I should have put a GIF in here, anyway. So something that, I'm sure that most companies
26:22
have some sort of structure around how to evaluate people for the role that they're looking to fill and it's super useful to do that for apprentices as well. And you also have to just consider what are your goals for this person? Where do you want them to land and what do you actually need them to do? Are you looking for somebody who's gonna be just a hotshot right out of the gate
26:42
that has leadership potential and who's gonna make your company and probably your program just look amazing because they're just really good but potentially you're gonna get poached away for something a little bit more fancy pretty quickly, like you never know, or do you want somebody who's gonna be really solid, who's gonna just get into your code base and just learn it really, really deeply
27:02
and really effectively and be happy to hang out for a couple years. Understand where you want this person to go and what they're gonna do for your program and then hire appropriately. So not all personalities are gonna fill the same role in the same way. So things to look for are just thinking about how they're gonna fit in the group.
27:21
So there's this interesting idea when you're thinking about group dynamics and you'll see this a lot in just companies and organizations and it's this 10-80-10 rule, which means that essentially when you have a group of people they'll be broken out into three groups. So you'll have the top 10%, these are the leaders. These are the people who are,
27:40
they're going to excel no matter where you put them. They're really motivated. They're gonna push really hard and they really just are driven to lead. These are the people who you tend to gravitate to. You're like, oh, I'm gonna hire that person but they're also the people who maybe that's not actually what you want. They're the people who are gonna be the movers and shakers and they might mix things up and change things a little bit.
28:01
The middle 80%, these are the people who are more than happy to do the work that is asked of them. They're not gonna rock the boat. They're gonna be really consistent. They're solid, they're really stable and they're gonna execute really well and they're consistent. This is like obviously 80%. This is the majority of people that you end up working with. And then there's the bottom 10%,
28:22
which are, they're kind of like the dumpster fires that are cleverly disguised as humans. So we're gonna just assume that you can tell when those people are in front of you and you're not gonna hire them. So we're gonna focus on the top 10% and that middle 80%. And again, the group that you want your apprentice to come from really just depends on what your long-term goals are
28:42
for that person and for that role. And so you just have to make sure that you're hiring from the right group. So things to consider. When you are looking for your apprentice, that attitude really counts for a lot. So I've worked with around 150 people that have taken from like zero to getting jobs.
29:02
And I focus on the first section of their time at Turing. So I'm like mama bearing them when they're in their first like, what is happening to me phases of school. And so the patterns, I've gotten very good at like noticing patterns and behaviors that indicate someone is gonna be successful in this environment
29:22
and then which patterns indicate that somebody might not be. And people who really excel in these types of situations and these sort of like semi-self-directed learning environments have a shared set of qualities. So things that they tend to do, they're very engaged. So these are people who, they're very curious,
29:42
they wanna go investigate. If they see something they don't understand, they don't wait for you to kind of give them a nudge to go check it out. They're just in it. They start checking it out. They start digging around and start poking around and investigating things on their own. And they also generally, because they're really curious and they're really engaged, they find ways to make it fun for themselves.
30:00
And fun makes you learn things better. It makes you learn faster. If you're able to make things interesting for yourself, it means that learning is gonna come easier to you. They're also loyal. These are people who like if things get hard or kind of go off course because this is a business and you never know, like maybe you're gonna lose a client, maybe something weird's gonna happen. They're not gonna bail.
30:21
They're not gonna freak out. They're gonna stay the course. They're vocal and they're honest. So these are people who, they're not gonna be confrontational and they're not gonna be irrational, but if something is wrong or if they don't like something, they're gonna speak up and they're gonna talk to you about it. You have high standards. They have high standards. These people are often top performers.
30:41
They're used to excelling at things. They understand what success looks like and they understand how much work it takes to get to that point. So they understand effort and they understand what it takes to get there. And then they're dedicated. So again, if you give them something, they're gonna do it to the best of their ability and if they get stuck, they're gonna ask you for help.
31:04
Great. Obviously, like again, when things get hard, they're not gonna bail on you. They're gonna keep cranking. They're not gonna give up even if things get uncomfortable because they know that things will get better and that they'll grow. And then they're just good-natured. Programming is hard. Learning to program is hard. You wanna be working with someone
31:21
who's gonna make it a fun experience for you and for them. And then again, it's one thing to have that list of what to look for, but then it's another thing to actually be able to identify that in a candidate.
31:41
How do you actually know that they're really like that? It's very easy for some. I mean, some people are really good at just jazz-handsing their way through interviews and then they show up on day one and you're like, oh, you are not who I thought you were. So how do you avoid that, right? So that's a little bit of a tricky thing. So it's important to start to think about
32:01
how do you separate the people who are really great from the people who are just really good at interviewing. So things to look at. Their track record. What have they been up to? Have they actually shown that they are able to tough out hard things? When things get hard, do they bail or do they tough it out? Have they been floating, as Wayne from Wayne's World says,
32:20
he has many name tags and hairnets. So you don't want someone who's like that. You want somebody who's shown that they can hang in there, tough it out, grow in a role and be there through the hard times and the good times. Again, you wanna show that they're able to tough it out through difficult times. So this could be shown in a previous career,
32:41
whatever that is. I don't care if they were an attorney or if they were working as a line cook. There are difficult things in every job and there's potential to demonstrate that they're gritty and tough and can handle things in any position they've had before. Or in school, right? So if they were able to deal with a difficult program or just get through school in a way that is successful, there are many ways that they could show this to you.
33:02
And essentially what you're just looking for is that they're able to make steady and consistent forward progress when they set their minds to doing something. And then another thing to think about is just how do they really pay attention to how they're answering questions? Again, like the jazz handsers, they're gonna be trying to target
33:21
what they think you wanna hear and they're gonna tell you that. But really, if you pay attention to them and if they're thinking about how they take your question and they apply it to their own experiences, that's important. So be mindful if you think that they're just telling you what you wanna hear or if they're actually taking your question and answering it truthfully.
33:41
And to help you see if this is what they're doing, you can set up a situation where you're asking leading questions where you might say like, what would you do in an example situation? If a client calls you and they're really upset about something, what do you do? How do you handle it? They might answer, they might tell you what they might do hypothetically,
34:01
and then you say, you listen to it, you hear them out and you say, cool, great, that's awesome. Can you give me an example of when you did that in a real situation? Tell me when you actually did that. And someone who actually has done that will tell you about it, or that's how they would answer the question initially, and someone who never has and is just sort of like playing to your question, might not have that answer for you.
34:23
It's also useful, so something that I've seen, especially with apprenticeships, is that oftentimes the actual code challenge gets passed over because people just assume that this person's gonna learn on the job, I don't really need to do a code challenge with them, that's not something that's super important. But it actually is, right? And it's less about,
34:40
should I hire this person or not? Because you understand that they don't know everything, and they may be pretty soft in certain areas, but it's more around, just so on day one when they come in, you know where they're coming from and you know where their skills are. So this is just to kind of help you understand what your starting point is. So, yeah, it gives you an idea of like,
35:02
do they understand the language, what's their handle on syntax, do they understand what normal workflow looks like, do they understand version control or like how to pair with people, just basic stuff around, just experience with the industry. And then, again, keep your end goals in mind. So have a plan, like just keep your eye on the prize
35:21
of like where do you want this person to end up at the end of your program, do you want them to be a part of your team for a long time or do you want them to come through the program, be really successful, and then like spread their wings and go somewhere else, like who knows, just be mindful of that and then hire appropriately and gauge appropriately. All right, so you have done all your planning
35:43
before you started an apprenticeship, you have hired the right person, you have a plan, your whole team is on board, so now what do you do? Great, how do you get it all together? So, when you are hiring someone who's never worked in the industry before,
36:00
onboarding is a little bit different than someone who understands the routine and knows what to do with everything. So, it's a great idea to just get some things in place to have one central location where all of this information is available, again, to the apprentice and the rest of your team so everyone's on the same page about things.
36:21
A very sort of simple, low effort way to do this is to just have, like you can make a document, you can just like open, you can do something in Google Docs, have some sort of a calendar or something where you have all the relevant and important links in one place so your apprentice can just bookmark one thing and then they have access to everything so they don't have to chase it all around.
36:41
And things that they might need could include what repos they need access to and then who's gonna be taking care of that for them, who's gonna actually give them access to all these things. Any specific system setup that they need to have before you get started, so they have access to all, again, so they have access to this, they know where to go, they know where to look for it.
37:04
Any communication channels that they should have access to before you get started, that means like, if it's Slack, HipChat, whatever, make sure that they're in the main channels that your team communicates with so they're able to hit the ground running and they're not sort of out in the cold and feeling a little bit ignored.
37:22
Any important calendars, calendars are great. That's always important, again, so you can track timelines. This is also a place where you can put all of those details around like goals for where they need to be every week. That's also great. And then just directions for how to contribute to a code base, like how does your team follow specific rules? You can't assume that this person has done this before,
37:41
so it's important to make sure that it might seem a little bit silly or a little bit obvious, but this is someone who hasn't worked in this industry before, so silly and obvious is okay. It's not silly, it's good. So, just any sort of directives around how to contribute to code bases and giving them enough information that they can kind of dive right in
38:01
and start taking a crack at contributing. And then also, just if there are meetings like stand-ups, team meetings, staff meetings, whatever, make sure that they understand when that is so they're able to go to that when they need to. It's also important to have a syllabus and a schedule.
38:20
So again, calendars and then some sort of a structure for your curriculum. Again, this is all about communication and your calendar's gonna map out expectations and timelines that are going to allow your apprentice to have a clear upwards trajectory of skills and progression that you expect them to be hitting.
38:42
And this is something that is going to just allow them so they can keep track every week as they're working. So, for your syllabus, again, it's your learning goals for every week, and it gives the apprentice a place to see where they're headed and what they need to be focusing on. That could include like a list of useful resources, so if there are tutorials, documentation, things like that
39:03
that would help them hit those goals for that week, that's a great place to put it. Assignments, so we'll talk about what that might look like in a minute, but you could potentially have like assignments that they could be working on, so outside of just like teamwork or like billable work, they could have things that they're actually working on
39:20
to like just keep improving. And then checks for understanding, so ways that they can actually confirm that they're learning what they need to be learning. And this just takes some of the mystery out of the learning process, because again, it's very explicit and it's very clear and it's giving them a clear path forward with a clear like upward trajectory of steps and that they should be taking.
39:42
Okay, so again, during when we are evaluating progress, this kind of comes back to that idea of that rubric that we talked about a little bit, from like novice to exceptional or one to four, those kinds of ideas. It's important to understand that you have a way to track that they actually are making the progress that you need them to be making.
40:01
So if we consider our evaluation rubric again, this gives us clear actionable documentation of like what understanding and progress looks like and it allows you to keep, it allows them to keep up a steady upward trajectory of progress as they keep working through the program.
40:22
And then again, like for the actual sort of like assignments or things that they can be working on as they're growing and learning, this idea of a breakable toy is really useful. So this is essentially like a little project that's owned by the apprentice. It's a code base that's just fully owned by the apprentice and it has a lifespan
40:41
that's the length of the apprenticeship. And this is an interesting idea because it allows you to, it's non-billable code, it's owned by the apprentice, and it allows them to have a thing they can break without worry that they're gonna like break an actual production code base. And it's also something that you can strategically
41:00
just match learning goals with like features that you're having to build out on this breakable toy. It gives them space to kind of get goofy and weird and have fun with it. So it allows them to have the freedom to sort of play with their code. It allows them to like kind of pick a topic or something around about the project that they're really excited about and want to like play with.
41:20
And that can be something that like trickles upwards into the rest of the team. Having fun and just building things because it's a fun project is really great. Another thing about this that is really fun, like you can just get weird with it and have fun. So one of the ways that, again, learning happens the most when you're in a place
41:41
of just goofing around and having fun with things. So this is a great place to like fight through the hard problems because it's a project that's like a little bit of, it's near to their heart and they just really care about it. So something silly where they don't have the pressure of the actual client work is important. Something to keep in mind.
42:00
An apprenticeship should be a safe place to fail. Failing is part of learning. It's like when you're learning to ride a bike and you first take the training wheels off and you realize that you have to think really hard about riding the bike and staying on the bike and then you're gonna fall off the bike a lot with that point. The more you're thinking about it, the more you're gonna fall off of it and that's okay.
42:20
And then gradually you realize that you have to think about the bike less and then eventually you realize that you're not thinking about the bike at all and you're just getting on the bike and riding away. And that's okay. If they fall off the bike, if they break things, that's okay.
42:40
It's the same deal with software as riding a bicycle. You have to just encourage them to keep getting back on the bike and you have to let them break things. Don't make a huge deal out of it but let them know that they did it and then make them fix it. Don't fix it for them. Don't follow them around. They're not delicate flowers. They can fix it themselves.
43:01
But be supportive and then help them when they need it. And again, as you move forward, they should be able to do that with less and less and less hand holding. And then what do you do if the worst happens? Let's say you get started. The team was really into it. You found someone you thought was gonna be a really great fit
43:20
and then things start going sideways. Maybe you realize that this person you thought was gonna be a great fit maybe isn't meshing well with your team. Maybe they're not learning at the rate that you needed them to. There could be many things that are happening
43:41
that mean that this isn't gonna work out. Just be honest and upfront about it. Things that I've seen happen sometimes is that apprenticeship programs can get dragged out well beyond their useful lifespan. And that doesn't do the team any favors. It doesn't do the apprentice any favors. They probably know that they're struggling at that point
44:02
and keeping them around in that way isn't really doing them any, it's not kind. So it's better to just call a spade a spade. If it's not working out, it doesn't mean that they can't do this. It probably just means that this isn't the right fit for them. Or maybe they're okay, but you ran out of money.
44:21
That could happen too. Maybe you lost a big account, maybe you lost a client, maybe just the business, just something happened to the business and you lost users or something. That's okay, that happens, but never put someone, especially an apprentice, don't put someone in a position where you can't pay them and you want them to work for experience. So if you get to a point where there is not money for them,
44:41
again, cut them loose. Let them know what's happening, keep them in the loop and then cut them loose. And the thing is that bad things happen, it's okay. Just be fair and be honest about it and really do your best to set them up for success and try to help them land on their feet.
45:02
So the way that an apprenticeship ends, whether it's the happy path where you now have a new junior dev on your team who's just crushing it and just kicking ass and doing everything perfectly, or you have someone who just didn't work out for whatever reason, the way that that ends says a lot about your team.
45:21
And if worst case scenario happens and it's not working out, the way that you handle that and if you're able to end on good terms with this person and support them and really still try to help them land on their feet, speaks very highly about you and your team. So again, just make sure that you are being respectful and kind for everything.
45:41
And then I just have, thanks to people who have helped me. And then, yeah, some resources for self-mentorship. Okay, so the question is, how would you adapt this advice for self-mentorship? There are actually several,
46:01
there are some great apprenticeships that have sort of like open source curriculum that they set up. There are also some schools that have like their curriculum that's online. Sparkbox has a really great, they have a really, like if you go on GitHub and just like Google Sparkbox, you can find them.
46:21
They have a very like clear, direct, just like curriculum path for their apprenticeships that has lots of like tutorials, lots of like documentation, lots of things like that around there. And then there's also various schools and things. So a lot of it's the same thing. Like you figure out, it's like that backwards planning is super valuable. So if you think about where you want to land
46:41
and just start like working, like figuring out like from where you want to be and then taking small steps forward. Does that answer your question? Yeah, okay. So the question is, what is sort of like, thoughts on taking an apprentice cohort rather than having them working together rather than having individual apprentices
47:01
sort of like divide and conquer solo on side projects and things. I think that there's a lot of value in having like your battle buddies, right? So it's the same thing like in school. Like you have a group of people, you have a cohort that they're there to support you. They're there to bounce questions off of. They're people who are at a similar level to you. So maybe you don't feel quite as self-conscious
47:21
if you get stuck on something that you think might be a little bit silly. I think that there's a lot of value in that. I think there's also value in kind of just, if you're like, if you're in a program that only has one apprentice, kind of being like the only person there, like the lone wolf, there's also value in that and having to just sort of get in there and just force yourself to talk to the senior people who might be intimidating.
47:40
But I think they're absolutely, if you are in a position where you can have a cohort of people who can like support each other, I think there's a lot of value in that. Sure, yeah, sure. Okay, so sort of question is like, how do you sort of keep your bias, your sort of like internal biases from impacting the way you're hiring decisions, even if like some of the things that you're sort of hiring for
48:01
tend to maybe be a little bit more generally considered like masculine, is that okay? So I think something to consider with that is, and part of that is just like the interview process and setting this person up to feel like comfortable in that and you'll find that it's interesting because like we see this also when we're interviewing students as well.
48:21
You'll have people who come from these not like non-white guy backgrounds and they'll come into the interview and they'll sort of start out with the normal, like maybe I'm a little bit more quiet, a little more reserved, and then you start talking to them and you ask them the right questions and you realize that like they're crushing it and they're amazing and that they're super smart
48:42
and they're really good and they have opinions and they're able to do these things and I think a lot of it is just setting up the interview process in a way that allows people to have room and space to tell their stories really effectively and to be safe. So some of that is just forcing yourself to make sure that your interview process is structured in a way that you're not intimidating people, you're not making people uncomfortable.
49:01
It's also about outreach as well, right? So making sure that you are like getting word of your apprenticeship out there so people who are maybe from these different, more diverse backgrounds know about it and they're able to talk, to speak to it, or to see it and apply for it. Does that answer your question? Yeah, so I think absolutely the expectation
49:22
should be set that in the beginning of the, oh sorry, so the question was just like the balance of like billable work versus non-billable work during the course of the apprenticeship. Is that trick, okay. So, sure, yeah. So if we're talking about, so billable work, so first just what I mean when I say billable work, like when you're on the job,
49:41
when you're going to like your timesheet and you're putting in what I did today, billable work would be the things that are actually, the tasks that you've done that are allowing the company to make money. So that could be like actually pushing production code, like doing things like that. Things like meetings or like internal meetings
50:01
or like reading documentation or doing tutorials or something like that, that's non-billable. But like actually like writing production code and like pushing that up and getting that live, that's all part of like your billable hours. And as an apprentice, part of this role and part of this job is that you are learning.
50:21
So it should be that in the beginning, your hours are skewed more heavily on the non-billable side. So you're working on like your breakable toy project. You're working on something that isn't necessarily contributing to the inflow of cash to the company, but you are still growing and you're still learning really well.
50:41
And so, but the idea is that in the beginning, you're going to be learning, you're going to be ramping up and figuring all this stuff out. And then during the course of the apprenticeship, you should be, that ratio of billable to non-billable should flip. And you're going to be having almost, basically by the end of it, you should be at sort of like normal billable hours for a junior dev.
51:00
So whatever that breaks down to for that company, so I'm not sure like what percentage that might be per company, but like there are certain sort of like acceptable, acceptable amounts of hours that should be billable. So you would want to, by the end of it, the idea would be that you'd be at that point and then you'd have less time dedicated to like learning and that sort of thing.
51:21
And then in the beginning, you'd be much more heavily skewed towards learning. Does that answer your question? Cool. Any other questions? All right. Thank you so much. Thank you.