What's the real difference between a junior developer, an intern and an apprentice?
Case Studies in Apprenticeship Vol. 7 — John Gile, Derek Nelson, and Brent Williams
Time to Read: 22 minutes
We’re back talking about software apprenticeships and the practices that make them successful. This time we’re talking to three leaders from Clique Studios, a design and engineering company in Chicago. They recently completed their first Modern Apprentice Program (MAP) and sat down to discuss what they learned.
Joe: Just to get started, I wanted to say thank you for taking the time to sit down and actually talk to me about the program you have.
Derek: Yeah, of course.
Joe: Could you tell me briefly what got you interested as a company in doing an apprenticeship program?
Derek: Sure. So when we were getting started on the initial site we had a link that said Clique University and it was actually just a blog. But, the idea was that we always wanted a pillar of our business to be about education and training and sharing our learnings, because I’m a believer (or at least a recent convert) to the idea that no designer or engineer is really self-taught.
Everybody is learning something through the community. So when I asked myself “how did I learn development?” Well, I was “self-taught”. What really happened was that I stole some code from some site that already exists by some engineer that was smarter than me. Took it apart, rebuilt it, whatever. That’s not self-taught, that’s
So we felt like an agency is a good place to do that, because if you’re working on, say, one software solution you’re building it and updating it all the time. It’s hard to get the varied amount of experiences you need to really be honing your craft. And having all these counter-arguments and other frameworks that might improve what you’re doing. So for us, we thought it was a good match. We just strictly believe in it, but we think an agency is a really good place to surround people with an environment to learn and get better.
So with us I think there’s two missions to our business. One’s what you see on our site; “Build something”. It’s making things. The second one is trying to get better at our jobs everyday. Brent has heard me say this ten times this week, but I want Clique to be the best at
Joe: Fantastic. And so Brent joined just prior to the initial apprenticeship round. Can you tell me a little bit about the structure of the program. How did you decide to lay it out?
Brent: Yeah, I joined the team kind of to do this thing. It was one of the first things. We wanted to try our hand at apprenticeship and really do a good job.
Joe: And you’re the Director of Education?
Brent: Yeah. That’s the title…
Derek: I’m trying to get him to refer to himself as the Dean.
Brent: *laughing* We’ll see if it sticks internally.
But the idea there really was to make it something that could be differentiated and at the same time really high quality. What we came up with was starting with what François, our head of engineering, and John, our CTO saying “Okay look, these are the skills we need for somebody to be highly successful.” And then planning backwards.
And I think that sounds intuitive. And it is. But it’s also for sure the way you would plan generally an educational experience, which is my background and mindset. And so that’s the way I tackled the problem. And then from there, we estimated how long we thought the average person would need to get to that bar, and landed on about twelve weeks. Starting out I always felt we had the advantage of leveraging a lot of shared apprentice program learnings throughout Chicago. So much has been learned and shared from your work on medium, to Dave Hoover’s book, the Apprentice meetup and friends like Blake and Jill at Enova etc.
So there was a mixture of explicit sessions, where you’re going to sit down with an engineer for two hours and really show you how something works, to projects, where you’re going to be on your own working through some stuff. To day long challenges to assess your learning. It became a mixture of things, but the idea that ran underneath it all was a progression from very very supportive one-on-one mentorship towards more and more independence.
Which is ultimately what you’re going to have to exercise to be effective as an engineer at the company. All of our engineers here mentor and pair with them, but eventually they get to a place where they’re a little more independent.
“Having an engineer that was in charge of mentoring all the apprentices through that project was more efficient and effective.”
Joe: So within that program, you said that everybody mentors. Does each apprentice have a set mentor, or is it something you’ve distributed across the team?
Brent: We started with doing one to one mentoring, and that remained a theme. But what became clear was that as we were giving projects to push people forward, having an engineer that was in charge of mentoring all the apprentices through that project was more efficient and effective.
And it’s hard when Bridget — John’s mentee — comes to him and says “this is what I’m working on”, if he hasn’t been involved in that project at all.
John: So we had an assigned mentor for every mentee throughout, but towards the end when we had larger projects, we tried to have a project lead essentially. So I would — as an example — if I were project lead, I wrote the project as it should be implemented, and so on. And then because I’m the one who wrote it, and because I have my own expectations, and because I’m the one who’s going to evaluate it have my own standards on how this project should be done, most questions go to me for that project.
But, that said. If it was just “I need help”, then you’d typically go more to your actual mentor.
Joe: Makes sense. So you mentioned evaluation, which I think is interesting. You guys wrote a blog post about the things you learned. And one of the things you mentioned was expectation setting. How do you set those demonstrable goals for apprentices, and how does that work when you have them reporting to a project where the owner’s criteria might be different.
Brent: That’s something that we realized partway through. That part of the challenge of doing it the first time is — because you don’t know how they’re going to respond to things — it can be hard in advance to say “this is the goal point”. Because they’re on a racetrack that is allowed to move. So it’s hard to figure out where the finish line is.
So what happened for us, is that in week six or seven, John, Ted, Derek and I were chatting. And we realized that we have a lot of qualitative thoughts about them. Y’know, “person A is doing this, person B is good at this.” But not a lot of quantitative “they can’t do this, they can do that.” And so, from that conversation the thing that we came up with to start trying these ideas of mini-challenges. And the way that we viewed that was we tried to segment out three of the biggest areas we need folks to be competent in. And for us, that ended up being really Full Stack PSD to Coded one page site, and a kind of Mini-Blog, and then François gave them a pretty basic Backend Task all in PHP.
And they each get to do each challenge, and they each get to be assessed by a different engineer. And so by the end of those three days, we have an unbiased (at least as unbiased as we can make it) datapoint from each engineer on each apprentice in three different skill areas.
John: I think how we started was that we started in the very beginning with more learning and less evaluation. We wanted to throw people in the deep end without heavy evaluation, and just push them in the right direction. And I think as you get further, you’ve got to start evaluating.
What we were having trouble with — well, I wouldn’t say trouble. When you get to bigger projects, they tend to cover everything, or more of everything.
Joe: They cut across concerns.
John: Yeah. And so the issue then can be that it sometimes becomes hard to evaluate what the actual holdup was in a project. Especially when you’re working with Wordpress as an example. It’s a framework where everything is so intertwined — frontend, backend, PHP, and so on — it’s not a clear set of backend classes and frontend code.
And so it gets hard to figure out where everyone’s strengths are. So what Brent was saying is, we did [the evaluations] and those are great to evaluate where you are as a whole. As in, as a junior level developer, will you be able to do these projects. But what we wanted to do is really isolate where people were strong and weak, so we can target those things for that person moving forward.
And that’s where we broke it up, and started to evaluate on specifically frontend tasks, specifically backend tasks, and then kind of hybrid full-stack tasks. That helped us to evaluate who was strongest in what area, and then what they needed to get better at individually.
Joe: Makes sense. Another thing that you mentioned in the blog post was learning to support people in their mentor roles. I think it’s interesting, because I think we forget that sometimes. That it’s not the same skill as doing engineering. Could you talk a little bit about what kind of support they needed, and what they responded well to?
Derek: Yeah, it’s important to lay foundations and principles for how to support somebody, right? Because engineers haven’t typically done that. For instance, I went to journalism school — a really great journalism school at University of Missouri. And almost everybody that taught me was somebody from the field. Some great award winning journalist.
Half of them were awesome professors because they were smart and had all these great experiences. Half of them weren’t because they weren’t teachers. They weren’t people that could actually convey their knowledge. So, with us it was really the reason and the impetus for bringing Brent in as a really early hire in a thirty person company. Because we realized that doing isn’t always the same as teaching. And education is a really valuable resource, and if you want to double down on it, you can’t just do it by talking. You need to make some smart targeted investments in that area.
So, I have a simple answer to that, which is that’s why Brent is here. That’s why we have a Director of Education, whose life has been devoted to education, so that we can support how to actually convey all this smart stuff that we’re doing and how we bring people up to speed.
Brent: The only thing I would add there would be that the thing we’ve learned was the difference between teaching and mentoring. I think a lot of our engineers, certainly John and François, were pretty well prepared to mentor because they’ve had to already. A lot of our engineers here have been here for a while, and worked together. You see them sitting there asking questions back and forth all day.
But teaching a group of three or more at a time is a different thing. Learning to structure a session. What we can do with a group of folks, versus what we can’t. I think those are the things that over time we’ve had to get better with.
Derek: And we’re still learning that.
John: Yeah, I mean when for several years I was the only engineer here. A long time ago, but I was the only engineer. Every engineer that’s come through here since then, I’ve probably had some role teaching them. Sometimes a lot, sometimes a little, but something. And mentoring.
So, I knew how to mentor and teach in those informal environments easily. But it’s a totally different thing to do a lesson with a group of people, and being able to move forward. And making it easy to consume whenever you can’t go hands on with every person in the group. I think that’s where Brent became super valuable for the mentors specifically. Teaching us how to do that and adjusting how we work. Just tweaking what we thought would be right, and getting it all finely tuned.
Joe: It seems like the experience of teaching makes it possible to take somebody who’s going to be even more junior. But it makes sense that when it’s
John: Exactly, that’s the thing.
Joe: You had three in your original class?
John: Yeah, three.
Brent: But it gets even bigger sometimes. We had a session teaching git to engineers…
John: Yeah, sorry, there’s three apprentices, but oftentimes our classes would have all our engineers in there.
Joe: Oh cool. So, using that opportunity to bring other people up.
John: Yeah, we’d bring other people in, because there are other things where everyone has their own specialty or experience. And so a lot of those classes were valuable for full-timers as well.
Derek: And as you’re talking through the value of programs like this, I think that’s a huge one that we somewhat expected but got even more value out of it than expected. Which is that it causes some self-analysis about best practices. And causes you to get your own stuff together because you’re going to be teaching it. You can’t teach proper usage for internal git if everyone works differently.
Joe: *laughing* If you don’t
Derek: Yeah. So there’s a quality assurance aspect of this. That I think is super important and I think is one of the best values we got out of it. Causing us to do some introspection about the best way to do things.
Joe: Are there other lessons that you learned in the process of running this first class? Things you think you might adjust a little bit in the future when you run another class like this?
Brent: We went through a pretty good process at the end, with the engineers and Ted and Derek, and the apprentices. I’ll tell you one thing; it’ll be great to have someone who was an apprentice already.
In terms of the way we think about it slightly differently in the future. I think we have significantly more clarity on exactly what we need from a candidate coming in and coming out. So I think that’s a huge change for us. And I think the shift to be more event-focused. Those would be two of the biggest changes from my end. I’m sure I’m forgetting one or two of the things we talked about…
John: Yeah, just focus in general. A piece of what we were trying to figure out was that a lot of these junior people come from bootcamp and so on. And we’re trying to figure out those gaps in things they didn’t pick up in their programs.
And we figured out that they’re good at one thing, whatever they were taught. But if you tell them “alright, I need you to go build a site from start to finish and launch it”, they have no idea. Most, typically, they can code the website, but they certainly can’t
Derek: I think one of the biggest learnings for me is that a graduate from a bootcamp is very different from somebody who’s been tweaking stuff on their own on the side, or somebody who just graduated from a computer science degree but hasn’t built anything.
Derek: *laughing* But they’re all very different, and so a typical junior engineer who comes in here before this is somebody who’s done a lot of HTML and CSS, has sort of learned frontend, has built a site for themselves, and is now looking to learn more of the backend. Bootcamp is very interesting because it’s the exact opposite.
They can do some really refined and impressive things with APIs, with custom backend frameworks, with ruby or whatever it is. But they need to be brought up to speed on a lot of the stuff that I did when I was learning. You have to make sure that it’s tailored to somebody’s background, because people aren’t one thing, right? People have
John: I always under the assumption that you learned HTML first, and then you learned CSS, and
Joe: I know a lot of bootcamps start on just
Derek: Isn’t that funny?
Joe: Yeah. I think it makes sense in the context of… “this is an if/else statement, this is a loop”.
John: Kind of universal programming stuff. Very little markup. And most people you’d think they’d learn markup first. That’s just how they did it. In junior high I took markup class.
Joe: I think we may have started in a different era of the internet….
Derek: *laughing* And that’s fine. I think the big gap right now is that there are a lot of people who are interested in the frontend. And there’s a big gap between that aspect and the engineering people. And bootcamps are filling that gap and getting more people to be interested in that part, I think that’s a great thing. It’s just
Joe: So, last question. What does the future of the program look like?
Brent: I think the thoughts about Clique U come from some of the things we did well in the apprenticeship. And have gone well in Clique U in general. And some of the things we learned we didn’t do well and maybe needed to change. And literally some product-market fit kind of stuff. And when I look at the future and when I talk to you and François about what we need, and the business needs. It seems like two things are clear.
One, having a little bit less structured
Joe: You’re not sure where you’re starting…
Brett: Exactly! So that’s a thing for us. And the other thing is that we see out in the ecosystem is that there are a lot of people that need. There’s
There’s definitely a step in-between, which is exploring the external ecosystem more. Because in a perfect world, we’d find a way to marry the external ecosystem with apprenticeship, which is great both for them in terms of job preparation, but is also better for us in terms of prepation for them.
Derek: The last thing I would add is that where we are now for at least the next month or two or three, is responding to some thoughts that we had during the apprenticeship program. We had three people in a room learning a frontend framework, or learning git, or learning how to deploy something to a server. And every time I saw that room, I go “there are hundreds or thousands of people in Chicago who could benefit from this. Why are we doing it in this small room?” Right?
And as a company, we’re all very very big believers that the smartest people in a generation should be making stuff. They should be inventors, they should be engineers. They shouldn’t be people who sit in meetings all day. They should be
So to us, we were saying “How can we expand all those learnings, and expand that impact, and try to convince as many smart people that this is the industry for you because you can be creating things.” Because that’s the core driver behind all this.
John: Yeah, that sounds good.
Joe: *laughing* “Ditto”. Awesome, well thanks so much for taking the time to talk.