Things to consider before joining a bootcamp

Bootcamps, bootcamps, bootcamps... They're everywhere, and everyone has an opinion.

On one end of the spectrum are the hard-skeptics. The hard-skeptics believe that bootcamps are selling snake oil–it's impossible to teach what they claim in 3 months. If you went to a bootcamp you were a victim.

On the other end of the spectrum are the evangelists. In their view, the fact that software engineering bootcamps work proves one of their priors: traditional education is broken, bloated, and corrupt. School has a lot to learn from bootcamps.

If you're only exposed to strong opinions, it can be disorienting. It's challenging to know what to believe. It doesn't help you want to believe in bootcamps and there are pushy sales people feeding into your desires.

I consider myself relatively well informed, if a touch out of date. I was the first instructional hire at an early, highly successful bootcamp. I helped write curriculum. I conducted admissions interviews. I even opened our second campus in Chicago. I firmly believe that we were doing good, interesting things. The vast vast majority of our students got more than we promised. I brought in friends and family as students and staff.

It worked, basically. That's not to say it was flawless. There were problems. But, at the end of the day, students were hired as software engineers and are today enjoying successful careers^[1].

On the other hand... there is absolutely snake oil on the market, and if you or someone you know is considering attending a bootcamp you should tread carefully. Just because bootcamps can be executed successfully does not mean the one you are looking at is. Just because a bootcamp was terrific 5 years ago doesn't mean it is today. If you're like most people, the tuition is a non-trivial amount of money, and you could absolutely leave with nothing to show for it.

So what are you to do? I hope to offer some guidance.

Good bootcamps have real admissions processes #

One of the biggest red flags to look out for is when there's no admissions process or when admissions feels more like a sales pitch than an interview. Admissions exists for a reason. Selectively for its own sake is gross, but, selectivity can have a vitally important function: determining if the student is likely to be successful in the program. You want them to be cautious about taking your money.

There are all kinds of reasons why a student might not be successful, the biggest of which is that they don't enjoy programming. Of those students who do enjoy programming, some may not have the space in their life to dedicate to an immersive program. Others might struggle with the format of bootcamps. The list could go on.

While I believe that everyone has a right to be exposed to technology, and that not enough people have access to tech education, it's just not the case that you could plop a random person in a room for 3 months and turn them into an entry-level software engineer. There is variance in the human experience, and a lot of it. The amount of time it takes to go from first line of code to professional engineer varies. The experience level of the applicant pool varies more.

There's a lot of BS gatekeeping in tech. I believe that the vast majority of people who like programming can get jobs doing it. But, the path looks different for everyone, and there are a lot of people who aren't set up to succeed at a bootcamp.

Good bootcamps screen out students who are not likely to be successful for the sake of the student. Good bootcamps take the attitude, "we're not going to take your money and your time if we don't think you are going to be successful after our program, and in order to know that, we have to spend some serious time talking to you."

If a program does little to no screening, that can mean one of two things. Maybe they have developed a curriculum so good that it can support students from all walks of life and get them all on a level playing field in 3 months... Or, maybe it's snake oil.

(A big caveat to this... if a program isn't making any claims about the job market or outcomes, then maybe this isn't true. Theoretically, there could be a school just focused on exposing people to programming and adding value in a set period of time. I think this type of thing would be fantastic for kids.)

Good bootcamps are serious about metrics #

What percentage of students are hired after 6 months? When was that data sampled? 2017?? Why?

Be skeptical of data and ask questions. Good bootcamps treat data gathering a serious task, not a marketing activity.

Good bootcamps hire some of their own, but not too many #

I've seen some bootcamp skeptics say it's a bad sign when bootcamps hire former students and TAs. Before I worked at a bootcamp, I might have also been somewhat skeptical. But, I've seen it work really, really well. We had a smart, talented and energetic student body. They knew our curriculum, and we knew them. Why wouldn't we hire them? Instructor-alums also remember what it's like to not understand something. That can make them very effective teaching partners.

I worked with instructor-alums who made tremendous contributions to our curriculum (in some cases far more consequential than my own), were dynamic and effective in the classroom and were extremely well liked by students. It's not a red flag if a school hires former students. I actually think it says something good: people went through this program and didn't want to leave.

But, I think there is a precarious balance to strike. When a school relies too heavily on recent alums for its staffing needs, things can become insular. When questions come up about how things work in the "real world" no one knows who to ask. It's a good idea to ask bootcamps about how many of their staff are alums. Make sure that some of the people teaching you have non-bootcamp software engineering experience.

Good bootcamps strike a balance with curriculum updates #

Tech changes really fast. The languages, libraries, and techniques you learn at a bootcamp won't be the ones you're using in 5 years, and they might not even be the ones you're using at your first job. Bootcamps can't write their curriculum once and be done. They need to keep it current enough. That said, if they're constantly rewriting it, it can be unstable. Good bootcamps strike a balance. They make curriculum updates often enough that the lessons aren't stale, but not so often that every cohort is in alpha mode.

Good bootcamps know what they aren't #

Bootcamps are not a replacement for computer science programs or college. They have very different ends. Computer Science is an academic discipline. Computer Scientists are in the business of discovery. Bootcamps are entirely industry-focused. At a great bootcamp you learn to assess computational complexity and get a solid overview of data structures and algorithms, but it's not a CS degree. Sadly, many students who graduate from bad CS programs do so with less practical understanding of Computer Science than students who went to a great bootcamp. I taught several CS grads/dropouts (from pretty good undergrad programs!) who were not planning on continuing on in their academic CS career and also weren't job ready.

Bootcamps are not a panacea. They are not the solution to every problem you can think of. You can't take a random laid-off worker, stick them in a bootcamp, and expect consistently good results.

Why do bootcamps work anyway? #

I've sometimes joked that our school could have been just as successful if we had no curriculum. This is an intentionally provocative statement, but I really wonder if it's true.

Most of our success can be explained by a few factors.

• Our students were highly motivated. They had put their lives on hold and were all-in.
• Staff was bought in. We were right in there with the students, so much so that we risked burning ourselves out.
• Our students were ready for what we were teaching (see admissions above). To get in you needed to be able to recurse through several data structures in your language of choice. Day 1 wasn't "Intro to Variables" it was "Let's write our own hash table"
• Students' play time wasn't rate-limited. Unlike in so many fields, they didn't need to wait for any external parties to get feedback. Students never waited for me to grade their programs to see if they worked. The computer told them it worked!
• We could get them unstuck. Getting stuck is one of the biggest obstacles to learning how to code. It's hard for a student to know the difference between productive and unproductive struggle. When you spin your wheels for too long, your motivation starts to degrade. Once that happens, you're done.
• The community was supportive and motivating. If you were in a rut, you could look around and see peers that were on the same journey. You weren't alone.

• Next: Lessons learned from a recent job search
• Previous: Micro-business update: name change, software coming together