Building a dev-focused learner management system with Django with Sheena O'Connell

Speaker 1: Hello, everybody. Um Cool. So I'm here to tell you a little bit of a tale from the trenches about how the organization that I work with didn't fall over because of COVID lockdown. We nearly did. But uh Django really helped us survive. So, before I get into the details, let me introduce myself. My name is Sheena, and you might agree that that is a remarkable likeness I'm the current CTO of Amozi. What I do day to day, what not what my focus is, is building people. So basically what we do as an organization is we take noobs and we turn them into professionals and we have a whole big system around how we do that very well. Um part of that system includes some software.

Speaker 1: So I built a whole lot of tools. Some of that you're gonna hear about today. And I also build management and people systems. So you have the tools and you have the people and they have to play nicely together, otherwise it all goes to hell. So that is a very big and important part of my role. And I have some emojis, so I'm into all sorts of nice things in the outside. So if anybody wants to go hiking Yeah. Um so I'm here to tell you a story, and that story starts off in an apartment block in Jeppystown, Johannesburg, South Africa. It starts off looking like that So basically what we're looking at there is a indoor parking lot that we rented out and we converted it into open plan office space and filled it up with people who are hungry to learn and we taught them cool skills.

Speaker 1: I actually sat at that desk over there behind those folks in the Before Times. So that place is called Umuzi. And Umusi means home, sort of. It's one of those words without a direct translation to English, but um that's the that's the working translation that we use We are a non-profit training provider and what we do is we find high potential un and underemployed youth in primarily in South Africa Um, the way we do that is we cast a very, very wide net and we um have all sorts of people do aptitude tests of different kinds and we take the cream of the crop and we invite them to selection boot camps where we like We have quite a rigorous uh selection process and we let people prove that they're worth investing in and then we invest in them.

Speaker 1: So we actually pay folks to learn. Um it's not a lot of money, it's enough to stay fed And it's enough to have a home with doors that lock while they're learning. We train them in high-value digital skills. So we have a whole lot of different things that we train people in. I'm mostly involved in techie things, so web development and data engineering and like mobile development and things like that. We also do things like copywriting and design and strategy, so quite a broad array of the things that are needed by industry, specifically South African industry. We offer nationally certified I mean a nationally recognized certification, which is really nice and all, but you can't eat your certification. Um so we also focus a lot on making sure that people get jobs and keep those jobs.

Speaker 1: So we have an like a little recruitment agency within our organization that's just about plugging people into into jobs. Because getting a job is a junior coder that came out of some weird breed camp in South Africa. It's like it's hard, so we help people out with that. We are great believers in holistic education. So we want to have the biggest impact that we can on every life that we touch. So it's not just about the technical stuff. We can't just like teach a person Python and be like, go be awesome. It doesn't really work. we put a lot of focus on teamwork in our education system. So the reason for that is because most of the people that come through our system they get into jobs and they get onto a team and they need to mesh with whoever they're there with and So we get people to collaborate a lot during the learning program.

Speaker 1: Um, but we also do things that are, I don't know, important for coders and teamwork. Like good code review. That's just good teamwork, you know? So there's all sorts of things like that which we put a lot of emphasis on. and seems to work. We put a lot of emphasis on professionalism as well. So a lot of the folks that we serve come from um pretty poor backgrounds. They don't necessarily have anybody who's like a legit professional in their in their circles. um like a lot of blue collar kind of work um and a lot of like yeah just a lot of challenges around um cultural differences sometimes so like um Sometimes if you want somebody to show up on time you have to like really explain like this is why. So there's a lot of um a lot of work on professionalism We have wellness support as well.

Speaker 1: So the backgrounds that people come from tend to be really hard. And the problems that they deal with, they're not first-world problems. They're like So we have um a team of coaches and counselors that are there to help people through all of the stuff that they're dealing with. On top of that, we have financial literacy. So if we want to have the most bang for our buck, if we want to like really set somebody up to change their life, we want to make sure that they don't make any bad decisions when they get their first paycheck. Like a lot of these folks, they'll end up being the highest paid member of their family like immediately, as soon as they get their first job. And their family are like, hey, we need money for things, or um so there's there's stuff around that which is challenging to deal with And some people just make bad decisions and buy fancy stuff and end up in debt.

Speaker 1: And then it's just like, what what did we spend all this time with you for? Now you are poor. So um so that's like a great way to just amplify the effect of our training Yeah. So like that was all swell and great. Um do you guys still say swell in America? Is swell a thing? Okay, sort of. Okay, I'm gonna teach you a South African word. We we say KIF, so everything was KIF. Um and then and then it wasn't KIF anymore. because COVID arrived and that was very, very stressful. That's another picture of me, a remarkable likeness. So we needed to change whoa what just happened. That was weird. Huh, who knew could do that?

Speaker 1: We needed to change everything and we needed to lock down very quickly. So we had about two weeks in which to get everybody home So typically what we'd do is we'd find these learners all around South Africa and we'd bust them into Jeffystown and we'd put them up with cheap accommodation there and stuff like that. And now we needed to get them home. So we had 250 learners on site and a bunch of staff members as well. We couldn't just send people home and say like go be productive and learn stuff. They didn't have computers, they didn't have internet access. So we ended up with about 250 SIM cards in our MD's name, which was hilarious as well. So logistically it was very, very challenging. Um our funding dried up as well. So th our funding model at the time um looked like this.

Speaker 1: We we basically Um large corporates in South Africa would um get some like BEE points by spending money on training. Um then spend their money with us and we they'd say like cool we want to buy like 30 learnerships and then they'd pay us some money and then we'd start the program and a year later we'd be able to deliver like 30 well-trained juniors to the corporate um and then they'd hire whoever they felt like from that group. Um so we had um So we had all these people that were already like paid for, um, but we had no more money coming in. So that was pretty tough. Um On top of that, a lot of our junior team were leaving. So we like one of the things that we do in order to function is we find systems where we can make use of junior talent ourselves So we had a large pool of interns who were on like working for us at the time

Speaker 1: and they were doing a lot of the on-the-ground legwork, like you know, going and helping people understand for loops and things like that. And that was really great. Like those dudes were fantastic to work with. And they were leaving. So our team size was getting cut in half on top of all of this. So it was very stressful. So we needed to stay alive. The first thing was we didn't want to let our learners down. So for a lot of these folks, like this is their only chance. You know, if they don't have this chance, like what are they going to do? So we couldn't let them down. And we couldn't let our funding partners down either. Like they prepaid us and we probably could have been like, oh COVID, we're sorry, we failed completely. Alternative education is a very um challenging uh industry to be in.

Speaker 1: The reason for that is that even though we are nationally certified and recognized like that the national level certification isn't like it it's not that solid. Like you can't just like get this this certi uh certificate and be useful. And so, yeah, it's a very risky thing for an organization to like buy 30 learnerships and be like, okay, cool, we'll figure out in a year if that was useful or not. So it's um just like you never let your potters down. That's just the rule. Um and on top of that we just have to stay alive somehow. We couldn't go broke So we all took pay cuts. Um most people volunteered for pay cuts very early on, which was quite a special thing. Yeah. And so in order to get everything right, we needed to build. The first thing we did was,

Speaker 1: like really, this was a hack, but it helped a lot. What we did was we needed to make sure that people were at least like trying to work wherever they were So we made a bunch of Google forms and the learners had to fill those out at different points in the day. So in the morning they'd say, today I want to work on this. I expect these kinds of challenges. In the middle of the day they'd say, so far so good, I've been working on this, but I don't know if I'm gonna finish that. And at the end of the day they could give us a little report back as well. And we'd expect them to fill out these forms at different points in time. And then we could graph that stuff. And you could see like different dots representing different form submissions and the size of the dot is like how much the person had to say and then we could see like who has actually been filling out the form and we can zoom in and see what people people are

Speaker 1: telling us about their days Which was really nice. Um completely insufficient, but really nice for a while. Um so for example, if somebody wasn't filling out the forms at all, if somebody's row was just blank, we'd be able to say um at least troubleshoot somewhat. Like maybe they didn't get home safe. Maybe their internet access wasn't okay. Maybe they were having family issues, you know, so we could at least like solve some of the problems. So this was a smoke detector. Um but it wouldn't prevent any fires. So that was totally insufficient. Um we don't really care about people being like having their butts in specific chairs at specific times of day so that they can get get the work done. Like like who cares really about that? What we needed though was an accountability mechanism.

Speaker 1: We needed to promote asynchronous interactions. And I think like in remote work, that's just a necessary thing by default. But it was slightly more necessary for us just because our internet infrastructure in South Africa wasn't really where it needed to be um in the situation we were in. It wasn't really designed to handle like everybody working from home. So yeah, we needed things to be asynchronous Self-paced learning also became very, very important. So if you think about just a normal classroom situation, you'll generally have like a teacher, a class, and the teacher will keep things at a specific pace. And there will be some learners who want to go faster, maybe they're bored. You'll have some learners who are like trailing behind and they're struggling to keep up and they're wondering why they're even there or if they're in the right place.

Speaker 1: And then you'll have like a group of people in the middle who who are doing fine. So you have like a normal distribution. Now if you introduce the chaos of like a pandemic and everybody going home, that distribution flattens out. And so if we tried to keep everybody moving in lockstep, it would be bad for like most people So self-based learning became a necessary thing. But self-paced learning is hard. I mean if you look at courses like Coursera and all of that, typically what happens is like most people drop out. I think Coursera has like a 7% completion rate or something like that. So that made all of those um accountability mechanisms really, really important. We needed all sorts of different kinds of smoke detection to spot different kinds of fires. So we're like, okay, do we need an LMS?

Speaker 1: LMSs exist. So yeah, there's loads of them out there. Some of them are open source even. So we're like, cool, maybe there's just some tool that we can get off the shelf that'll do what we needed But we had specific needs. So the first thing was that we wanted to be able to integrate with our existing GitHub Git repo where we kept our syllabus. So our syllabus is a static site, a Hugo-based static site. So Hugo is a static site generator. We've got a bunch of markdown files and um with a bit of front matter on those markdown files and we render those into a website and then the learners can interact with that. So we're like, cool, we want to be able to use that. Most LMSs, in fact all LMSs that I've seen, have a different way of thinking about syllabuses.

Speaker 1: They've got these rich text forms or WYSIWIGs where you can like write out your content and make it fancy, and that's nice and all. But um get is better, um, in my opinion. Um it's like one of the really cool things about our syllabus is that um our learners can make it better. When they see a resource that they like, they just make a pull request and then it's better forever. Right now there's some like random person in India who's making our Java syllabus better because they want to. And I'm just like, thanks, whoever you are. So we wanted to keep that. We also needed to reduce our dependency on staff quite a lot. So we needed something that would optimize peer-to-peer learning as much as possible, optimize collaborative learning. LMSs aren't typically developed in that direction.

Speaker 1: Like sometimes they'll have peer-to-peer assessments, but it's not like that's the core of what they do. The other thing we wanted to do was simulate real work as much as possible. So I said earlier we take noobs and we turn them into professionals. The best way to make a professional is to treat the person like a professional have it professional expectations and put them in an environment where it's like cool this is what real work is going to feel like. Um and that's also not something that um LMSs tend to do. Most LMSs are like really clever textbooks um with you know, bells and whistles and interactions and whatnot. And they're they're really cool and fit for whatever purpose they are fit for, um, but they weren't quite fit for what we wanted. Um We also wanted to integrate with GitHub. But and like there isn't a LMS that just like does that off the bat as far as I've seen.

Speaker 1: Some of them have plugins at work, but like even with that, it's like That's one requirement out of many that it was hitting. So yeah, so we're like, all right, maybe we should build something. And so we did. We bought this thing called tilde. So tilde also means home, sort of. It's very witty. So it's that's our learner management system. And it's kind of funny looking in this in this view, but um I'll go into some details. So well oops Oh. So the main thing we needed to think about was staying lean when we were making this thing because we had like no resources, no time. We still had to support our two hundred and fifty learners. remotely while building this thing and our staff was going away and it was it was intense.

Speaker 1: So we had to stay super super super lean and that implied certain things about how we architectured everything and what features we chose to build So we focused on our users and we focused on adding value to our users as quickly as possible. So the first and the most important user is the learner. So what they interact with day to day is something that looks a lot like a Kanban board, and that should be familiar to everybody here. So when a learner starts off in our program, they have a backlog and it's full of stuff. And their job is to take everything from the backlog and move it into the complete column. Pretty straightforward. In order to do that, they move through the various stages. They they start a card, then they eventually get to a point where they're like, sweet, I think I've done it.

Speaker 1: And they ask for a review. Then once somebody asks for a review, they can get some feedback. People can request changes and it can bounce back to review feedback. Then they can ask for another review and it can bounce back and forth as much as it needs to until the person has actually like mastered the thing We really believe in mastery of concepts. Eventually they get to a point where they are actually done and the car goes to the complete column. So nothing too fancy there, but there's some really really cool things happening under the hood. So the first thing to know is that we have different cards that behave in different ways So the coolest card is the repo card. And the repo card is something that yeah, it's basically like the card starts off in the back in the

Speaker 1: backlog. And then when the learner chooses to start the card, we do a bunch of stuff on the back end. We create a repo for them on GitHub. We protect the main branch. And we add the learner and their reviewers as collaborators on that repo. So now the the the learner can't just like push to the main branch willy-nilly. Um they yeah, it's just not allowed because that's not that's not how professionals work and their peers need to review their work because that's uh that's how we do things. And that's pretty cool. The learner has to make pull requests and that's fantastic. So that's the first like really cool thing that we did. The next thing to know about is how the review and review feedback columns really work. So here you'll notice that there are cards of different colors. So

Speaker 1: we're currently looking at Boitomelo's board. So the blue cards are things that Boitomelo needs to do herself, and the yellow cards are things that Boitomelo needs to review. So basically if somebody is working on a project, um then we'll assign reviewers to that project according to who's already finished that thing. So Boy Temeno has already like smashed the password checker project and so she gets to review other people's password checker projects. So that's quite nice. And that'll like reinforce her learning. It's it's repetition of concepts, which is pretty handy. But it gets pretty interesting in other ways. So if something is in the review column and it actually, next slide. So Okay, actually, previous slide, sorry. So if something's in the review column, then um

Speaker 1: pretty much anybody can bounce it back into the review feedback column. So anybody can say this is not quite where it needs to be, I'd like to request some changes, or you missed this specific lesson. Let's nail that Eventually it'll get to a point where all of the learners who are associated with the card as reviewers think it's positive. They're like, sweet, this thing is competent, let's let's call it complete. But a learner can't just move a card from review to to complete because They don't know yet what competent looks like. So they'll all say like, cool, thumbs up. And that's great Eventually there'll be a staff member or a trusted reviewer who can jump in and look at stuff in the review column that has a lot of thumbs ups on it and they can say, yes, this is in fact complete. Or no, I am going to request feedback and give feedback to all of you guys who thought that this was complete.

Speaker 1: So that's pretty handy. So there's all sorts of like interesting things that we can get out of that. So the first one is if many learners re approve a card and a trusted reviewer says no, it's not good enough, then we know that there's a knowledge gap and that knowledge gap needs to be plugged. If a learner has one card that's extra bouncy that goes like from review to feedback to review to feedback a lot, then it means that they need help. And we can we can organize an interaction with them around that and we can say cool like this person struggling, this person's struggling, this person struggling, you three together and a staff member. Sweet. Let's just like have a focused session just for you. Um and that works really well. If a sp a specific project always tends to be extra bouncy. So let's say like like a whole bunch of people are doing the same project and that project for all of them is extra bouncy.

Speaker 1: then it means that there's something wrong with the project specification. It means like maybe it's confusing or maybe there's some prerequisite information that's missing or a resource that's missing. So then we get to troubleshoot our syllabus in this way. Then if there's a specific reviewer that always causes extra bouncy code um cards, then it means that they're not necessarily doing the best job of reviewing the code. It means like either they're saying things that are confusing or they're not leaving complete reviews And so we can have some kind of intervention at least to say like, okay, what's actually going on here? Do you know that good code review is something you're going to need to do in your work life? So that's pretty cool. And then if one specific learner tends to just be bouncier than all of the other learners, then like sometimes it's a language barrier thing, sometimes it's something else.

Speaker 1: But we can allocate support early. Um we can say, cool, this person typically needs help. Let's just like give them a helper forever. And that's pretty cool. The next person that we need to look after is the on-the-ground staff member. So we've got several different flavours of people on the ground helping out. We've got junior scrum masters that do junior scrum master things with the Kanban boards and we have junior techies as well who run around and do a lot of the work. So we wanted to make sure that um Whatever we do, we set them up for success by giving them in like the information they need in order to take the next appropriate action, must be in their face all the time. So I'm not going to go through that in detail, but there's a whole lot of cool things there

Speaker 1: Next one, uh administrative users, you all recognize that. Um so basically we'll have some somebody who's more of a paper pusher type person in our organization and they get to do things like register for people for different courses and that kind of thing. And lastly we have data requests and scripting. So we got like some script kids in our organization. Occasionally they'll need to do some stuff or ask some questions of the data that aren't that's not like Like the answers aren't available on the front end, so they can pull data from the REST framework and figure out what they need to figure out. So those are our main users sorted out. Under the hood, things get slightly interesting. So mostly I tried to make sure that the architecture would be boring

Speaker 1: so that we could have people helping out on it easily. But we did out of necessity like Because we were so resource constrained and because we had some weird needs in terms of our syllabus, we did end up doing some things that were kind of interesting. The first thing we did is uh this is actually probably the most like weird thing we did. Um, syllabus is code. So our syllabus, as I mentioned earlier, is a static site built in Hugo So we've got a whole bunch of like markdown stuff at the bottom there, and then we've got front matter. And the front matter is just a YAML data structure. and we have control over what we want to put in that data structure. And so Hugo didn't need a lot of stuff. We were like, cool, let's add a whole lot. Let's add our prerequisites.

Speaker 1: So before you do this project, you need to do these other projects And let's add flavors. So this project can be done in JavaScript or TypeScript, and you can use any of the front-end frameworks, or you could use Redux. So you have like a piece of content and extra configuration around it. And then that can be interpreted as a kind of knowledge graph where you have a bunch of nodes and each node is a piece of content in a specific flavor. And from that you can say Cool, I want to create a syllabus made up of these pieces of content. I want the the learner to do this one first, then this one, then this one, then this one And then we can traverse the graph and say, sweet, we've got a um we can see exactly what they need to do in what order. And from that we can generate a backlog.

Speaker 1: So um the learner like if a learner jumps onto the syllabus um then they can basically start with any of the cards that aren't grayed out. They can say like cool one, I should start with one maybe, but C looks really interesting. I'm going to start there. So we can give them that amount of freedom and just see what they do with it. So long as something is complete, then you can work on its pu it's uh post -requisite. Yeah. The overall architecture looks like this. So I've already spoken about a bunch of it. Hugo. Hugo's nice. We're probably going to change it out for something else in the near future. But it serves its purpose very, very well. Django you all know about. We're using Dramatic for long running requests because that is necessary from time to time

Speaker 1: Django Arrest framework is fantastic. It makes my heart go boom. And then on the front end, we're not doing anything too weird. We've got React, Redux, Sagas, and Material UI So yeah, pretty pretty good stuff. Um this is all very, very successful. Like our learners are doing fine. In fact, like we're doing a better job than we used to do. Um we keep track of how many of our people get jobs and manage to keep their jobs after they are finished with our program. Like that's our main main thing. And pretty much like very close to everybody who has finished our course managed to hold down their first job. um since lockdown, which is ridiculous. Um yeah. We've run multiple cohorts of learners end to end.

Speaker 1: Like I've got learners who've gone through the system that I've never met in person. I've just like tested them and that's that's awesome. We even have people taking part in our selection boot camps on their cell phones. So in the past, whenever we had a selection boot camp, we would bus people into JP's town and we'd put them up with in accommodation for like a week or two. And they would have to like come into the studios and just like work a bunch and it was a very like it was a very heavy process. And now we can say, cool, we'll just spin up a spin up a board for you guys and do it however you do it and give them enough time that they can do it on their cell phone if that's all they have. So that's quite cool. And because we are now completely remote, we have learners as far afield as Kenya and Nigeria, which

Speaker 1: is also fantastic. Yeah, and that's it. This slide deck is um available if you use our QR code and there are links to things. That's it. Yeah. Any questions? Uh

Speaker 2: yeah, I was just curious uh how long it takes to run through the full program on average.

Speaker 1: Um so our program is very modular because of that nodey thing. Um but the main courses that we offer take um nine months to a year, depending on the pace that the learner moves at.

Speaker 2: Uh yeah, and kept all of that. And like how many like total cards would that be?

Speaker 3: Anyone else that question?

Speaker 4: Thanks. I'm curious and apologies, I missed the very beginning of a talk, so you might have addressed this already, but um I'm curious to know what the design process was like uh and how consensus was achieved given limited resources on what would work. well for students and kind of how you sort of manage that decision making in that kind of an organization which I know can be difficult.

Speaker 1: Yeah so that was um Probably not that well executed. I think we made good decisions, but I don't think we made them in a very structured way at all. Mostly I paced a lot like this and thought really hard. Eventually when um yeah, so so I didn't have a lot of technical support um at the time. Mostly people just needed to support the learners and I ended up um coming up with this And like when I came up with it, I'm like, oh it's obvious, of course, we need a Kanban board. But um yeah, come coming up with it was not that straightforward. Um I was initially thinking about it as like how can we represent a knowledge graph to our learners in a way that makes sense. And I was like, oh of course, like that's how we work already as developers.

Speaker 1: Yeah. But not not a very structured process. Um there's another question. I don't know if I can I can talk louder, maybe. Um I was just curious how I'm sorry. Okay.

Speaker 5: Alrighty. Okay. Um how how did the uh potential students find out about the program initially from like zero uh awareness to To hey, I should try and do this.

Speaker 1: So we have a lot of different mechanisms. I'm not like too involved in in advertising stuff, but there's a lot of advertising that happens. Um there are There's like a whole lot of Facebook stuff and Google stuff. There's also a lot of sort of aggregators of of opportunities that exist. little I don't know places where people will post different kinds of like tech junior opportunities and we'll plug into those. There's a lot of word of mouth as well. And Yeah, like like word gets around, we are becoming m more well known within South Africa. So that's that's it. Yeah.

Speaker 4: I have another question. But if somebody else has a question, I'll see me. Okay. I was also kind of curious, like in like how you were able to make the value proposition of choosing to build this in-house. Like I know it made sense obviously your talk to us about like these other platforms aren't sufficient, but I know sometimes that's a very difficult thing to g convince, especially to non-technical stakeholders about like actually this thing off the shelf might be cheaper, but is it actually cheaper? And like did it turn out to be cost effective? Like in terms of money or time or however you calculate that.

Speaker 1: Yeah, it's I think convincing people would have been hard. Um but they were all very, very busy. And so um like we were like cool, everybody's got something that they're working really, really hard on. This is my problem, I'm gonna try to solve it. And um once I came up with a solution I was like, sweet, I'm gonna build this thing. There isn't something that works. So we're just like, okay, just do what you believe in. I think if we ended up um like arguing about what the best solution was, it we probably would have just ended up tripping each other up. Um yeah, so I think trust was very, very important at that point in time. Yeah.

Speaker 6: This is awesome, by the way.

Speaker 1: Thanks.

Speaker 6: Can you talk a little bit about the initial candidate pool selection process?

Speaker 1: Okay, cool. So initially we so we send out all these adverts and do all the things and then people apply on our website. And then when they apply they have to do some aptitude tests and give us some basic information about themselves. So we do unfortunately have an age cutoff because that's just how the funding works in South Africa. And we do require that people have finished high school maths. Like they need to have just passed high school maths. Oh, cool. And so long as they pass high school maths, then they can actually do the certificate that we offer, which is great. But then We also um we do some aptitude tests with them online and those are very low-touch um sort of IQ-ish tests and some personality stuff as well

Speaker 1: Um we mostly focus on um like comprehension is really important because you guys know we need to read so many document so much docs. So comprehension is important. Strangely enough, if people um have a natural grasp of certain basics to statistics, then they tend to do better with us. And there's a bunch of different things that we that we look for there. So if somebody shows um through these tests that they have aptitude, then it really means it Either they have aptitude or someone they know has the aptitude. So a lot of people cheat on these things, unfortunately. Yeah, it's it's annoying. So then we'll take people who um Yeah, we'll take people who seem to score really well and we'll invite those guys to a boot camp. So back in the day we'd invite them to prep on premises, but now um

Speaker 1: We have a shorter bootcamp syllabus that we run on Tilde that lasts up to three weeks. And we just say, cool, start with the first card, like read the content for the first card, it'll explain like how the system works and Take you through the whole process. So the tilde kind of tutorial is built as a tilde syllabus as well. So that sticks that box. During the boot camp, we ask them to do all sorts of things. Some of it is writing as well, like just like tell us about yourself and and things like that. Um and goal setting and things like that. But then we also give people some cartas to do, some um programming cartas, so like draw a triangle and draw a square and and that sort of thing.

Speaker 1: one thing that we make heavy use of is other people's content as well. So we don't ever want to be the people who have to make all the content ourselves. There are lots of people out there who make really great content. So we'll rely on things like uh free code camp and like data camp and solo learn and things like that. So we'll um so our syllabus will be like cool resources that we found interlaced with um the things that we think are missing as well as extra exercises and projects for folks to do. So so yeah, we give them a bunch of cartas to do and a bunch of like learning to do during their boot camp. during the boot camp as well, like they need to learn Git. Like if they can't learn Git by themselves, then they don't they don't get in. Which which is a kind of a high bar

Speaker 1: um I think for a lot of people. Yeah, so then once they're through that boot camp, we we give them like a problem-solving test as well. So we use this platform called Codabytes, which is really nice for testing people cheaply in bulk And then if they get through all of that, it still might mean that they cheated , unfortunately. So and if we let in the wrong person, it's a huge investment. 'Cause like once somebody is in our program, we're just like, we're not giving up on you, you know. Um so even after all of that stuff, we have a final assessment, which is a staff member interviewing them about code. Um and uh they'll t it'll generally be like the staff member will have some examples of code and they'll say, cool, here's a piece of code. Um if I run it, what will get printed onto the console?

Speaker 1: Um and we have a bunch of questions that um Yeah, they cover different concepts that people should have mastered if they if they finish their their cartas themselves. Um and then Yeah, um that's scored in different ways. And even in like in every step of our application process, we do try to add value to the learner. So if we like if a staff member is interacting with a learner, an applicant, and they're like Cool, you don't actually understand this concept. They'll try and explain it to them and see if they can explain it to them and then they'll like at the end if somebody cheated but they seem to have high potential anyway, then we'll be like Okay, we don't want to just like throw you away because you did the stupid thing. Stop doing stupid things. We're gonna put you into like a bridging course and see if um you can last through that

Speaker 1: And then if you sort yourself out, then we can give you another chance. So yeah, that's that's the whole recruitment process, basically. Oh there's two more there, but oh I think he had his hand up first. Oh, yeah. Okay, cool, cool. Sorry.

Speaker 7: So I didn't quite understand. First of all, awesome, awesome. I I would love to see this replicated. in more places. Has anybody approached you? Because like everything's open source. Is it as easy as just

Speaker 1: um so it's not like super easy to run apparently. N nobody's really approached me to to get involved in it. But I think something that I'd like to do is turn it into a bigger project. So um supporting people in Kenya and Nigeria is nice, but I mean Oh why not India? Um so yeah, like definitely wanna build it out and make it better. It's still to me it still feels like an MVP as opposed to something that's maybe even like a proof of concept as opposed to something that can easily be rolled out. There's still a lot of like scripts that need to be run at random times and um so it's not like a complete thing yet um but we'll get there. Yeah There was one more question. I don't know if there's time.

Speaker 3: One and then we will have time.

Speaker 2: Yeah, mine's actually kind of a segue from his. I was wondering, so uh if you guys have, you know, are onboarding junior engineers just to your organization rather than like through the program, like are there any like big takeaways you have from that on about effective ways to onboard like you know not completely green people?

Speaker 1: So That's tricky. We actually only hire juniors from our own programs. Yeah, because it's the ultimate job interview. It's like we've seen how you are for a whole year and we've also seen you demonstrate like that teacher's heart that we need. So Yeah, I think onboarding juniors is really, really tough. Um so yeah, there's all sorts of traps that juniors fall into where they think they understand something and they don't understand it and then the organization that they work for doesn't know how to look for that understanding properly. So I think a lot of juniors are set up for failure in their first role. Just like not because anybody's doing anything wrong. It's just that's how how it is. Yeah, so one thing we try and think of when training folks is like, okay, we want to make sure that people last out the first three months of their their next job, because if they last the first first three months, then it tends to last longer.

Speaker 1: Um so we think about like what pitfalls are they likely to fall into on those first three months? How are they going to annoy their co-workers? Okay. Uh like I would love to spend more time figuring out how to make juniors more hireable, like how to de-risk that junior hire, because I think that'll change a lot of things. Yeah. Do you resume, but right now it's really, really labor intensive to teach like the first time ever engineers how to be like professional engineers? Yeah, so we actually like run grad programs as well for um large dev houses in South Africa where they're like Um even if somebody comes out of a university, they'll say, sweet, let's send them to a muzi and they can get polished up before they come to us

Speaker 1: and that works really well. Yeah. Sweet.

Speaker 3: Just a minute. All right. Well, thank you so much, Sheena. This was awesome. Great talk.