Having Success With Code Bootcamps: Hiring Lessons For Employers

Posts

Hiring

As far as I can tell, the bootcamps are all the same in at least one way: You get out what you put in. Not every graduate is created equal. We interviewed many dozens over months to get the final eight we ended up hiring.

Your criteria are likely to be different from ours, but, fundamentally, we put strong communication, work ethic, curiosity and analytical thinking ability as our top (and really only) criteria, believing that we were hiring more for raw talent and growth potential than their current skill set. Related to that: We didn’t hold a super high bar for their actual coding skill, but did care if they could communicate and reason analytically about their code.

Expect More

Bootcamp grads are eager to dive into basically any project, and the more you expect of them the more they’ll work and try to deliver. Our experience has been that they are absolutely not afraid of the keyboard and will sit down and start coding toward basically any goal, even without fully understanding the full picture (more on that in a minute). They are eager to learn and prove themselves; give them space to do so.

That said, we did ramp up projects over time, starting with very basic data transformation problems to help get their feet wet at the company and get some wins on the board before dramatically amping up to larger, more strategic projects. This “ramp” was one month for us, and very steep.

Teach How To Structure A Project

Generally speaking, fresh bootcamp graduates not only have no idea how to plan a project, they don’t even really know that they should! Which makes sense; they’ve been taught how to start and go, not how to take a step back and design. So, the first thing you should focus on with new grads is breaking down a problem.

We do weekly iterations (most projects they’re working on currently are 1-4 weeks), and in each iteration, every project has a deliverable milestone with real value to the company. At the start of every iteration, we have them build block diagrams of the major components of the project. Each component has a description on what its responsibility is, and how it connects to the other components. If this sounds like basic object-oriented design, it is!

Next, we have them outline each component in code by creating the set of methods needed where the body of the methods are blank. This forces them to think through the project holistically at a level of detail that brings to light early any areas they don’t understand.

Together, drawing the box diagram and outlining the code also allow you to give feedback to them early on in the project, and helps minimize the management time you might feel you need to spend on a day-to-day basis stalking their GitHub repos.

Teach How To Focus On Risks And Unknowns

When given a large project, everyone (even experienced developers!) will tend to bang out the parts of the project they know how to do and will, consciously or not, avoid the parts that are unclear and unknown. We push our bootcampers to focus on the unknown early in order to de-risk projects; we learned this the hard way.

Frequently, a project would appear to be on time during an iteration, then slip, often by an entire iteration, because they would leave the scary parts for last, and uncover a task at the last minute that either requires rewriting of much of the project or much more work than anticipated.

If this lesson is followed, it makes it easier to identify which tasks are the scary ones to get them help early.

Leave Space To Fail

I’ll be honest, this one is really difficult for me — but is so very important. You know much, much more than the fresh bootcamp grads. Any task or project you assign them will take them much longer than it would take you. And when they get stuck on something seemingly trivial, it’s tempting to jump in and save the day. Resist this temptation.

Although it’s hard to remember, most of us in tech got where we are by banging our heads against the wall on problems and gaining deeper clarity and appreciation for certain solutions, patterns and challenges through that struggle. It’s important not to deny them the same frustration, as this will help them grow.

That said, we have a standing rule that if someone is stuck for more than a few hours, get help. There is no sense in wasting days in this pain.

Hire In Packs

We hired eight bootcampers almost all at once, for several reasons:

Most bootcamps teach pair programming. They are used to working in pairs.
They can lean on each other. If they are working on different projects, different individuals or pairs will pick up different skills, and the next time the skill is required by someone else on the team they can help each other, easing your coaching burden over time.
Hiring in a pack lets you build an education program that they all go through simultaneously.
They have a buddy going through the same growth and the same pain. Camaraderie matters.
People are competitive, consciously or not. For the same reason you should never hire one salesperson at a time, you should never hire one bootcamp graduate at a time. This job is really hard; if one person is growing faster than the others, they will work to catch up. If you’re going to hire one, I can’t recommend strongly enough to hire two instead. It’s more than twice as good. If you can’t afford to hire two, then maybe you should wait.

Coaching Is A Full-Time Job

This is generally a tough lesson for both new managers figuring out how to delegate and startup founders who are used to doing everything. If you hire a batch of them, you must have someone to manage the program full time, including doing daily coaching, code reviews, design sessions, planning sessions, one-on-ones, communication outside of the group to gather requirements, etc.

Moreover, this person should be respected throughout the organization, as getting the program started and effective is going to be a bumpy road that will draw on company resources even beyond the coach (e.g., engineering to answer integration questions around your core product, product managers to oversee the requirements of specific projects, etc.).

Without a strong, respected leader, you risk the group being marginalized from the rest of the company. Having a full-time leader also enables you to scale the program rapidly.

If you’re going to hire two and devote a senior technical leader to coaching them, why not hire four? Or eight? There is a very large supply of these people out there, and if you’re a startup looking to own a market, product speed matters a lot (preaching to the choir I’m sure, but it doesn’t hurt to be reminded that there are many aspects to driving speed and scale).

Modularize Your Product

Bootcamp graduates cannot work on the same project as our core engineers. Our core product is a massive, highly complicated Rails application with a single-page, mostly Ember front-end. Our engineering team is gaining a well-deserved reputation in the community for producing some of the most valuable Rails projects (Goldiloader and delayed job worker pool are two that have gained acclaim), largely because we’re pushing Rails into places that it wasn’t really designed to go.

So instead of working on the core product, we’ve architected Salsify to be extensible in a number of ways via microservices. Our bootcamp graduates can build stand-alone applications (Sinatra, Rails, etc.) that run outside of Salsify’s core and interact with it by known APIs, message buses, webhooks and other means.

This has the two advantages of insulating the engineering team from the bootcampers as well as pushing the product to become a more modular platform that can be extended much faster than any one team could do on their own.

Celebrate Wins, Have Fun

I’ve been very impressed by the work ethic and hours the bootcamp graduates have put in. They really are eager to grow and have successes, and really, really want this career transition to work. So celebrate the work, their growth and successes big and small whenever you can. They deserve it, and all people like to know that what they sweat and toil over matters.

This is another benefit of having short, weekly iterations with defined deliverables. There’s always a milestone to celebrate.

We have the whole team present their progress every week to anyone in the company who is interested, which always includes product management and engineering leadership, as well as many members in the sales and customer success teams who often can use their projects in the field immediately.

And don’t underestimate how important it is to have others in the company swing by, ask what they’re up to, ask for demos and generally be interested in the whole process.

Continuing Education

Because we view this program as a farm system for engineers and other members of our team (see the previous post), we put together what is essentially a practical computer science program for graduates to build upon the very basic education they received from the bootcamps.

We have office hours during regular business hours in which members of the team are available to go over problem sets and answer questions related to the work, but generally we expect the courses to be a nights-and-weekends kind of investment, which they are all happy to make.

Here’s our practical CS degree program:

Stanford’s Introduction to Mathematical Thinking
Stanford’s Data Structures and Algorithms Part I
Stanford’s Data Structures and Algorithms Part II
Design Patterns (we’re teaching this one ourselves; we couldn’t find a great online course for it)
The Hardware/Software Interface
Introduction to Databases

We believe that this can be completed in roughly 1-1.5 years, and that it’s sufficient for most engineering jobs out there. Design Patterns, in particular, is rarely taught to undergraduates, but is so important to being effective in the real world.

At the risk of drawing the fury of the CS mob out there for omitting one subject or another, we felt that many of the “core” CS courses really aren’t that critical for becoming very productive engineers, especially at the beginning. I’ve never had to write a compiler or operating system in my career, and the last time I thought about finite automata was 2001 when I was studying them myself.

That said, we do have a set of other courses that we might push them into once the first year is complete, including Programming Languages, Machine Learning (increasingly important, these days) and a few others.

Part 3: Tips for bootcamp grads on where to work and how to succeed once in the door.