Hiring and Mentoring Coding Bootcamp Grads, With John Harden

John Harden is the Principal Software Engineer at Kerauno, a workflow and communication software company that just raised a $25M Series A. When he’s not leading a high-growth development team, he’s mentoring for two coding academies, Eleven Fifty and Kenzie Academy.

Hiring coding bootcamp alumni is a controversial subject in development circles, but bootcamps aren’t going anywhere. In fact, according to Career Karma, in 2019, 33,959 students attended one of the 105 coding bootcamps studied in this market analysis, representing a 4.38% growth since 2018. In 2020, we expect the bootcamp sector to grow to an estimated 35,446 students.

In this episode, we talk about:

1. Finding mentorship early in your career
2. The importance of “tech jams” when scoping a project
3. Hiring and mentoring coding bootcamp alumni

Listen to the full episode here

John Harden, thanks so much for joining us today on Scaling Software Teams.

Hey Wes, thanks for having me over here.

‍

So, John, what brought you into engineering leadership?

My story’s a little bit of a long one, but this June I celebrate my 10 years over at the Kerauno company. So engineering leadership has been something that I’ve earned internally at the organization – I went a little bit of different path. I know that the shelf life a lot of times when you look at engineers and the code and in the day-to-day process, it sometimes feels closer to a few years. But where I’ve been able to afford the luxury at Kerauno is I’ve got some great leaders over here that have really invested in me early.

And what I really like to do, and how I like to help this organization, aligns with where they’re trying to take the company. And so it’s just been kind of a fortunate alignment. I’ve had the opportunity to really push myself as far as I want at this organization. They took the training wheels off pretty early for me, and I can’t thank them [enough] for that. So really it was just a good alignment with the leadership – we have great communication internally, and what I want is what they want. So it’s just been kind of a really lucky path for me.

 

‍

Can you tell us a little bit more about those investments they made into you? I think that’s something we all aspire to – investing in our teams and helping them succeed – so I’d love to hear what that looked like for you.

It really began because I started with the company early in my life, honestly. I started with them pre-college, but it was just some of the small things, just to make sure that I stuck around and was there for them the whole time. While I was in college, they were allowing me to work remote as much as I wanted when I was early in my career, they made sure that I always had a mentor and somebody internally that could help me grow.

That’s one thing I always tell people that are early in their careers – finding that mentor is so much more critical than another five thousand dollars or whatever it may be. Those mentors are one of those things that are just going to catapult you in your career, so [they] provided me the opportunities [to connect] with mentors internally, and those mentors stretched from engineering mentors – where I was learning new things and new practices that I didn’t know before – to business operation mentors; people that included me when I was an engineer on a product. I was in the meeting deciding, how do we sell the product? How do we market the product? How do we service the product?

‍

Those mentors are one of those things that are just going to catapult you in your career.

— John Harden

‍

Now, that probably [resonates a lot more] with some of the startup groups that we have here internally. And it’s changed a lot over the years. But the big thing was really just investing, and knowing that I’m here for the company, and the company is here for me. So it’s that kind of relationship that you can’t put right into words, but when you come in day-to-day, you know you’ve got somebody who’s got your back, and they know I’m here to get their back as we grow and scale.

‍

So now that you’re in the position to make sure that mentorship happens, how do you know when to take those training wheels off, and what does that look like for folks on your team?

Yeah. So there’s always a little bit of a joke I tell the people in the interview phase: Kerauno isn’t a shallow and deep end – it’s the shallow end of the Mariana Trench.

So I’m probably a little bit aggressive – I’m probably a little over the top when it comes to taking off the training wheels internally, because when I came in, those training wheels were ripped right off and thrown away. But what I think it does is it grows the individual really quickly.

Now, here’s the thing: that works as long as that individual that you’re working with understands that they’re allowed to fail.

It’s not fair to put somebody in the deep end and then hold their head underwater if they start sinking. So it’s all about what I think is a great phrase that one of our leaders, Don, likes to say a lot:  get comfortable with being uncomfortable. So I try to really instill that on my team members that I’m working with. It’s about being uncomfortable, and that’s something that’s beyond just being an individual or an engineer… you need to be comfortable with being uncomfortable; it needs to be OK to fail.

And if you focus on growth and focus on failure as an opportunity for growth, I think it’s just a whole different way of looking at things. Just that small way of looking at things is what makes people feel comfortable with failing, and I think as long as you embrace that, your team is going to grow pretty naturally.

 

‍

One of the most common stories I hear about hires that didn’t work out is, [they were] given a big project, went dark, didn’t ask for help, failed, and that became unacceptable because they waited too long. Versus what you’re saying is: failure is important, and that involves raising your hand [for help]. How do you help your team know that they need to raise their hand, and talk about failure of before it’s too late?

You know I’ve been here at Kerauno when we were five [people], so I get the “give a guy a project” or “give a gal a project” and let them run with it. But I think everything’s got to be really team focused, and I think you’ve got to have a healthy mix of those engineers that really put their heads down and won’t ask the questions, with the people that might annoy that person [with] too many questions. So finding a good, healthy balance and striking that.

I do think it’s okay to fail, I can see where you’re coming from though – it’s not okay to fail and not try to get help. There are stage-appropriate process in every business, so you don’t want to overwhelm anything with process.

 

‍

What does stage appropriate process look like for you to help folks not to go heads down too long and fail?

We’re big fans of things called “Tech Jams” here. So we like to do Tech Jams quite a bit. Anytime we’ve got a new story or a research spike that we’re looking at, we always try to put a Tech Jam together with a healthy mix of people.

We try to get the typical people that are going to be working on that component, but then pull in other engineers that are working on other things. It’s just an exercise where it’s an hour or two where you’re talking from the bottom up on the problem, but just getting people in a room and talking about the problems can really unveil a lot of things.

‍

Any engineer that’s been around the block for a while, no matter how good or how bad they may be, they should at least be able to admit that by bringing everybody together you’re gonna come to a better solution.

— John Harden

‍

It’s super easy, and [it’s] that kind of startup, scale-up mindset where we just have to get things done – there’s no time to stop and think about it. We just have to get it done. We’ve already got a customer with a two week deadline. We don’t have time to stop and talk. But any engineer that’s been around the block for a while, no matter how good or how bad they may be, they should at least be able to admit that by bringing everybody together you’re gonna come to a better solution. So I think Tech Jams are a really good process.

We have research spikes, which are basically the next work we’re going to do in the following sprint, and then we try to do Tech Jams before the sprint gets here, so we don’t have that impending feeling of, “Oh no we’ve got to get it done.”

So trying to get the spikes in front of the actual work is a beneficial way to make sure that everybody is communicating, and that those people that were in that tech jam will collaborate together as they’re working on the project in the next sprint – even if they’re not talking they can always kind of bounce ideas back and forth.

‍

I love that Tech Jam idea – swarming a problem early to get brains on it. Can you talk us through some things you’ve learned about how to run [a Tech Jam] effectively, or maybe just talk us through an example of one you’ve done recently?

Tech Jams are really healthy as long as you keep it concise, right? So everybody’s been in one of those meetings where the topic started as one thing, and by the time 20 minutes has gone by you’ve switched between 15 different topics, and you’ve talked about 100 different things. And they all might be around the problem, but they’re not talking about the problem itself. So the key focus there is focusing on the problem.

Now, depending on the problem, [that meeting cadence might look] different. But really making sure that you’re taking active insight onto the tech jam, and making sure that you’re talking about the topic is key. I know that sounds really fundamental.

‍

How do you keep that? How many folks we have in a room right now at this Tech Jam? Are we like three people, are we six people?

We recommend keeping it anywhere between three to five [people]. We try to keep it pretty small… You can’t see us here on the podcast but every room here at Kerauno has at least two or three whiteboards. So we just go in one of the whiteboard rooms, clean everything off from the day before, and we get after it. We try to at least have somebody running the Tech Jam so it’s not a free-for-all. [They’re] setting the agenda before the Tech Jam… these are the x amount of topics that we want to tackle, etc – whether it’s just five things, whether it’s, what is the right technology? What is the right tool? What is the right platform? What does the scale look like?

[It begins with] identifying some key questions and then tackling it and then just trying to make sure you walk out of the room with the answers. But having a leader in the room [who’s] going to run the room and make sure that people who might be a little bit more quieter get their opportunity to speak – and making sure that everybody in that room knows that they’re not wrong. So if somebody says an idea, it needs to be a comfortable room [that allows your team] to say ideas that sound crazy, because it’s that crazy scale of ideas that eventually lead to that one idea that you’re like, “wow that’s genius.” So I think you’re on a fine line of conserved and crazy before you get to that genius scale.

‍

So we need to have a facilitator that’s going to make sure that [quieter] folks get a chance to talk, and that we’re working through a preset agenda, and that we’re setting a culture of… building on each other’s ideas. I love that. I love those guidelines.

‍

 

 

Now I’d like to switch and talk about boot camps and coding academies. I understand you’ve had a lot of experience there. Could you tell us about your experience working with the coding academy graduates?

I’m a curriculum advisor over at Eleven Fifty Academy. I’ve been with the academy now for two and a half years since they were back at Scott Jones’ – I like to call it “The Castle” but if you’ve ever seen it, it really kind of is a castle.

‍

The wooden slide is an interesting experience in somebody’s house, yeah.

[Laughs] So I’ve been with them, and then I also mentor over at Kenzie Academy – so I’ve got a little bipartisanship here – but I’ve really been involved with them early with Kerauno as a way to engage and kind of get into that talent pipeline and identify a unique source of talent. I’ve been with them since the very beginning; I’ve done everything from mock interviews with the actual engineers that are going through the camp, I’ve done curriculum review at the end of the graduating cohort to help them understand what Kerauno needs and what we’re seeing is a need in the area. And [we’ve added some of these graduates to] the Kerauno engineering team; we’ve had three engineers join and be promoted internally within the organization, two of which are still here, and one that’s taken an opportunity to go to a new startup here in Indianapolis, trying to get back at that foundational layer that I had gotten [into Kerauno] at.

‍

Pair programming is absolutely critical.

— John Harden, on training bootcamp grads

‍

That’s sounds like some broad experience – I would love to learn more about what you’ve learned. You’ve hired three. You’ve seen success with all three. What are some things that you know now that you wish you would have known back at the beginning before you hired those folks?

So, first off to say it’s been an it’s been an amazing experience. It’s one of those things where I didn’t anticipate the amount of success that we’d have with it.

You’ve got to keep in mind that if you’re hiring from one of these boot camps, you’re not hiring a seasoned engineer; you’re not hiring somebody that’s going through a traditional four year schooling, and may have done a few years of programming. You might be hiring somebody that’s as short as 16 weeks [in terms of their experience].

We hired a veterinarian technician, [for example] – she was a vet tech for two years, and decided it was time for her to career to change. Then she switched into being a software engineer and she joined us three months later.

What I learned from that experience is that you’ve got to have a process in place to make sure that these people are successful, and that these academy graduates are successful, and it’s not a copy paste from any college hire pipeline that you might have, or any college hire onboarding strategy. It’s really different. Pair programming is absolutely critical, I think, when you bring in those junior engineers because as a senior engineer… you understand that learning a code base is a vast challenge. Just understanding the principles that they’re doing, understanding the methodologies that they’re doing, and then finding the skeletons in the closet, making sure you get what’s going on there.

But with a junior engineer they don’t know really where to even begin – this is their first time ever coming into a code base, coming into an actual product. So starting them off with something small but pushing them into a lot of different areas of the product.

‍

Could you maybe lay out the first couple weeks? You hire a new bootcamp grad, you’re excited. You know preparing is important. How does that operationalize? What does that look like for their schedule?

Yes so the first week is always about learning the product. I think that they’ve got to be able to understand the product that they’re working in – both its features and functionality.

I think that there’s a lot of one-on-one training, we assign them what we call an “ambassador” which is a person that they can ask anything. So it doesn’t matter what it is – whether it’s [explaining] what our H.R. policy is, because for some of these people this might actually be the first job they’ve ever had.

‍

Is that ambassador typically an engineer or someone on your team or does it matter?

Yeah we try to grab a senior engineer. You always want to make sure that you’ve got at least a two to one, or at least a one to one ratio of senior talent to junior talent. You asked earlier what were some of the mistakes we made, and at one point we were having such wild success with the juniors, we were like “Well, can’t hurt to bring in another?”

And that’s when we were two-to-two and we brought in two-to-three, and we started to realize that our one-to-one training kind of fell apart. So the ambassador is big.

And making sure that you have a lot of time booked out – this is one of those things that’s going to cost a lot upfront to gain the value of the back end. You’re not going to be able to hire an academy graduate, and be able to flip them around and have them adding to the sprint within even maybe the first month. Obviously they’re adding value, but the value you’re getting out of it is nowhere near the amount of time you’re investing into it initially.

So in that first month, are they getting assigned to any stories from the backlog or are they just pairing with someone else who has stories?

Yes – as a way to get them more engaged in the team we always try to give them the stories and then make them use their pair programming time to work on their project or on their task at hand because that’s gonna make them have ownership. That’s one of those things as an engineer you need to learn early – is the ownership of your work.

So we try not to put them in a position where they’re pair programming with another engineer on [that engineer’s] tasks because what’s going to happen there is that [senior engineer] may be towards a deadline, and the priority of training [the new engineer] goes right out the window because you’re focusing on getting your work done, versus actually helping them. So making sure that the new academy graduate has their own workload is really important because they’ll own it.

Everybody wants to own their work so giving them all enough work, you know, it’s probably the deep end with them – not quite the Mariana Trench. We’re giving them a good enough amount of work that they can sink and swim and then trying to make sure that they know that they can go to people [for help]. I think that open community, that open culture of everybody here is willing to help is super critical for success for those kind of people.

‍

 

‍

Anywhere you start new, it doesn’t matter how confident are you, you see smart people, [and] they’re busy, and you don’t want to take their time. How do you help that junior engineer know what the appropriate amount of time to ask for?

To take the pressure off for the first couple weeks when a new engineer joins at Kerauno… they actually have a schedule the first two weeks; they have pair programming on their calendar and it’s on that engineer’s calendar, so it forces those interactions.

[You’re right], it doesn’t matter who how competent you are – if you’re going into a new space with a bunch of new people that you don’t even know it’s really hard to break that ice. So a structured ice breaking, I suppose we’ll call it; forcing functions and forcing meetings to happen. Everybody hates the “meeting overwhelm” but at the end of the day, once you get them past those first couple weeks – and I try to get them to pair program with every engineer – I look at pair programming as an opportunity obviously to get work done and to learn engineering principles. But it is a good opportunity as a social opportunity for engineers that may not feel as confident reaching out to everybody. to meet each person on the team.

That works at our size when we’ve got 12 to 15 engineers – when we’re scaling up to 30 we’re going to have to scale that back. But right now even with 12 to 15 people across different scrum teams it still makes sense to make sure that they pair program with everybody, because we are all a team…

‍

I love that idea. So I’m if I’m the 16th engineer in my first two weeks I’ve got 15 – are we talking like one hour blocks of pair programming?

Yeah we do about an hour. You know, the ideal pair programming scenario is 15 minutes on, 15 minutes off, 15 minutes on 15 minutes off as far as, you’re switching behind the keyboard – but really there’s not that deep of a structure to it; it’s whatever is working for them.

At the end of the day if it’s 15 hours of pair programming and zero code gets produced, but [the new hire] met everybody on the team and they feel confident in talking with everybody on the team, then that’s a worthwhile exercise either way.

‍

Yeah I think that even underplays the value of pair programming. I know, personally, pairing with someone who has no idea what’s going on, just the act of explaining that to another person, I write better code. And I’ve found that over and over. I love that scheduled pair programming idea.

So thinking about when I can hire a boot camp grad, versus when I need someone a computer science degree, how do you think about the roles you have open, and when you can pull from either one of those worlds?

‍

At the size Kerauno is at, and where startups and scale-ups are at, I think that you’re really not going to get too much difference of a value out of either.

I think that bootcamp grads have the advantage in that they’ve already gone through the agile mindset – all those academies are doing scrum teams, they’re doing sprint life cycles, they’re teaching them the practices of agile, and their entire lifecycle and they’re entire training is based off of agile mindset.

Now, the computer science graduates are obviously gonna have a lot more of those deep fundamental programming skills. They’re gonna be able to come in and a lot of them are going to have a lot more mathematical skills. So if you’re looking at data, or you’re looking at building out processes and business process automation or something like that, you might find an advantage with a comp sci grad there just because they’ve got some of those math and computer science underpinnings.

But I wouldn’t say that we target boot camp grads versus comp sci grads on different roles. Really Kerauno, at least, is always just looking to hire great people. And either way, whether they’re a computer science grad or an academy grad, there’s going to be an expensive amount of time we have to invest into it.

So I’ll tell you quite honestly at the end of the day for me… it doesn’t matter what your credentials end up being. The training that you get through the academies [is] gonna give you an opportunity to write code immediately; you’re going to be able to come in and be able to contribute to some layer. But it’s all about that will, and that drive, and that ambition, and those aren’t things that you learn at an academy or that you learn at a school. Those things just resonate in interviews, and it’s really hard to put a pin on it. You can’t put a data point during an interview and say well this guy’s got a 10 out of 10 on ambition – but you can feel it.

So I would say that I don’t know if there are certain things that I would pit them up against for certain tasks – maybe, like I said, if you’re looking more mathematically you might lean towards somebody with like a computer science degree.

‍

So you’ve hired three boot camp grads. Is there any capability, any experience or skill they come in with that you found to be better than what you would expect from a computer science, 22-year-old college grad?

Yeah I think the soft skills end up being a little bit better.

Computer science grads that are going for their degree are trained in how to be computer scientists, right? But they’re not trained in how to do interviews. They’re not trained in how to work in a professional setting. They’re not trained in how to sit in a Tech Jam while on a scrum team and interact with their entire team.

Whereas these academy graduates are actually going through real world training – at least in both the academies I’m familiar with. They’ve done mock interviews multiple times before they actually graduate. They’ve already interacted with businesses in the local area – [whether that’s] just shadowing an engineer… or that… might be the meet-ups that they were incentivized to go out to [attend]. So I think that a lot of the times, you’re getting some advantages from the boot camps around those soft skills. Not to say that comp sci people aren’t going to walk out with soft skills, but it’s something that they have to want themselves, and they have to focus on, whereas the academy makes it part of the structure and part of the curriculum.

‍

That is a drum I like to beat, about the lack of team skills in computer science and software engineering curriculum. There are still big universities here in Indiana that you can graduate with computer science degree without using source control. It’s still a little bit embarrassing to me.

Absolutely.

‍

If you could spread one belief out into the Zeitgeist about hiring an engineering management that you think would really push our industry forward, what idea would you spread?

So I know this one sounds like it’s an expensive endeavor, but I really think that ratio that I brought up earlier  – two to one or one to one – of keeping junior talent and senior talent is really critical.

‍

So two seniors to one junior, up to one to one but not more juniors than seniors?

Yeah. More seniors than juniors. And I know that that sounds like a lot because you’re spending a lot of time onboarding, a lot of time training. But we invested in this group of… juniors probably two years ago and we invested a lot of time, and a lot of training. But I can tell you when I look at our team, I mean, these are… really critical contributors… because these are the people that know that we took the risk.

These are people that are invested in the company, and they’re cornerstones of our team, quite frankly. And not to say that the seniors are not, but when you take somebody and you give them that opportunity, and you take a risk on them and they know that you’ve done it and they know that time you’ve invested in them, they’re really a lot more inclined to be sticking around with the organization, and they really are going to be able to stick around just because they have so much growth opportunity.

You know a lot of engineers… I joked earlier that there’s kind of a two to three year lifespan. It might be because what they’re finding is they’ll go into a company and they feel locked into their position. If you’re coming in as a senior, it might be really hard to move to that next caliber. But when you’re coming in as a junior and you’ve got a ton of malleability, and a ton of opportunity for growth, I think you’re going to get a longer lifespan and I think you’re going to get a lot more value because they’re really contributing, and they’re determined to make the team successful because you’ve invested into them and you’re instilled those layers of we want to invest in people, and that resonates for the people that we like to hire here.

‍

I love the medium and long-term benefit. Let’s say someone listening is skeptical and they say “I love the medium long term, that makes sense, but I’ve only got three recs open this year – I’ve got to make every hire count.” Do you think there are any short term benefits to hiring these juniors that might be able to pay off, to help persuade that marginal hiring manager?

Well I think that if you look at the industry rates of hiring junior engineers, that’s an advantage that the academies promote; if you can hire one great talent you might be able to squeeze in two junior talents. So you see your three recs might actually go to four.

But besides the economic advantages, the juniors are going to come in with a lot of questions that I wasn’t ready for. And they’re going to fine tune processes that you may not have fine tuned. It’s interesting how much somebody that does not have that experience forces you to fix flaws in your process.

Everybody’s probably heard the analogy as a company scales: the cracks in the sidewalk get bigger and bigger and bigger because the sidewalk gets bigger. But when you bring in somebody that’s got little actual business experience, or little professional experience, or engineering experience – they kind of find all those little cracks and trip before they get too big.

So it’s kind of an interesting exercise because you really have to push yourself as an engineering leader, and as somebody that’s really investing in people, and you have to ask yourself, “How am I going to make sure this person is successful?” I can tell you it’s a lot different of an answer than if you ask yourself, “How am I gonna make a senior successful?” because you take a lot of things for granted with senior talent. But when you really bring somebody in that’s fresh, and that’s green, it does force you to look at your strategy and your process a lot.

‍

Fix those cracks in the sidewalk while they’re still medium size, whereas if you wait another year, or wait two years to hire your first junior, they’re going to fall in those cracks. I love that analogy. I think folks familiar with the benefits of continuous delivery and the counterintuitive nature of “deploy more often have less bugs” – I think this is very analogous of that.

‍

So John now we’re going to move into the rapid fire round. I’m going to give you a short question and then going to give me your rapid fire response. You ready?

Absolutely. Let’s do it.

‍

What does a best possible culture fit look like a Kerauno?

Somebody that understands that we’re a startup scale-up but that we’re a scale-up that wants to focus on growth, and somebody that wants to invest into a company that is going to be here for a long time and that’s going to be really big with a lot of opportunity. So an opportunity-taker.

What do you think is more important, soft skills or hard skills?

Right now I’m going to say soft skills at our stage. That’s probably going to change over our growth, but you can’t have any prima donnas on the team, and you can’t have anybody that’s not willing to grow. So those soft skills. We can grow the hard skills here at Kerauno, but I think the soft skills [are the thing] you’ve got to have coming in.

‍

What’s a mistake you’ve seen someone make in an interview that they didn’t realize they were making?

I think the biggest mistake I’ve seen somebody make in in interview that they didn’t realize was, they were answering questions that they didn’t know [the answer to] and it was really obvious. I think they thought they were tricking me [laughs], but it was very clear. So I think that that’s kind of the biggest mistake you can do is try to act like you know something you don’t.

‍

Walk me through the interview that has had the most lasting positive impression of a candidate.

We had a candidate come in – they’re now on our team. But during the interview, everybody always gives that question, “What are your weaknesses?”

So we asked that question, and beyond just giving the weaknesses, they were really self-aware of where they were strong and weak. But when they focused on their weak points they actually said, “When I joined Kerauno, this is how I want to help fix those weaknesses. And this is why I think your company’s the fit to help me fix those.”

So they didn’t focus on just the weaknesses. They proposed solutions that made a difference. And I think that’s a whole different way of looking at it.

‍

John Harden, thanks for joining us on Scaling Software Teams.

Wes, thanks for having me.

‍