I think it’s because boot camp graduates often have no experience prior to the boot camp, so they’ll often only have 3 months coding experience total. Whereas most other applicants will have much more experience than that even if they have no professional experience.

But in those few months, they were often trained intensively on exactly the tech stack you're looking for, and they built some things, in a team, that look a lot like what's actually done day to day in many businesses. In an up to date way. That helps!

We have only one boot camp graduate, who came from a completely different career. He's been productive from day 1, has carefully listened to all advice he's got since and is always working on figuring out better ways to do things, and he's just very good after two years.

There are knowledge holes a mile wide with bootcamp curriculums though. The programs I’ve seen don’t teach:

- Information security

- Anything lower level than Python/Ruby

- Unix (streams, files, processes and threads, syscalls, etc)

- Debugging. (Except incedentally)

Not knowing these things can be fine in a feature factory workplace. But having an engineer on your team who has no idea about infosec is an active danger. “I make a sql query from this string builder” / “we save the passwords in this database table” / “the AWS credential is here in the javascript code in the repository” / etc.

I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process?

Stronger point even: it is beneficial to have a person capable of messing up that way so you can check that your quality control is working.

A tiny minority of places I've worked do code review for every commit. Or have careful enough processes that they would catch every mistake made by incompetent engineers.

Most companies simply trust their employees most of the time. Hardening a process against programmers you don't trust has a massive cost.

> A tiny minority of places I've worked do code review for every commit.

In the past three jobs I have had, over 13 years, all changes were code reviewed before merge. I don't know the industry's general stance on this, but I wanted to describe my experience here which is very different from yours.

Same here.

> I’d argue that if any of those reach production it’s never going to be the junior dev’s fault. Where’s the review process?

That's true, but issues getting into production isn't the things that might be problem. Junior devs requiring hours of review time for relatively simple tasks can also cause a lot of problems for an organisation, bringing productivity to a halt in extreme cases.

And most college courses also don’t teach that.

Can you substantiate this? It's incredibly hard to believe that the majority of universities offering a programme in computer science would not have a class on operating systems or information security, or anything more abstract or concrete about those topics.

At least at my school, the CS degree was open ended. You take a handful of required corses (intro to programming, algorithms, operating systems) but aside from that, it was up to you to pick the classes which interested you. If you were interested in security, or databases or mobile app development, you could take those classes, but they weren't required.

The things I learned in college which were actually applicable to a software engineering job was:

* A basic ability to program

* Maybe some low level concepts about operating systems. But this is a big maybe, because my operating systems class was pretty early on and was long forgotten 3 years later when I went to apply for a real job.

I learned nothing about version control, the typical client-server model, html/css/javascript, REST, servers, databases, doing a pull request, teamwork, etc. I think those classes may have been available, but I never took them and graduated just fine.

I am not convinced this 4 year CS degree was any more useful than a bootcamp, which teaches you the actual useful things you need to be a junior dev.

I think the difference between CS and a bootcamp is more of intent and followthrough. People often pick bootcamps because of promises of easy money, versus someone who does a 4 year CS degree is possibly more committed and won't give up as easily. But in terms of their actual preparation, I doubt one is better than the other.

The other difference is that one takes 4 years and the other 3 months. That’s 16 times longer, so if you spent only 5 hours a week working on or thinking about programming, then that would be an equivalent amount of time. Which is not mention that sometimes things take a while to sink in.

Most college courses don't but most curriculums have some sort of security class. When we were learning assembly we used gdb to exploit faults in a C program (and we didn't get the source code so we had to read the assembly). There was also one for finding exploits exposed for a website that has a DB in the backend.

Nothing prevents bootcamps from having those classes though.

And none of that has anything to do with

> can be fine in a feature factory workplace. But having an engineer on your team who has no idea about infosec is an active danger. “I make a sql query from this string builder” / “we save the passwords in this database table” / “the AWS credential is here in the javascript code in the repository” / etc.

> Nothing prevents bootcamps from having those classes though.

Time.

They don't have time for things like that. If they took the time to teach low level programming, data structures and algorithms, security, operating systems, networking and so on, they'd need to teach students for 3 years instead of 3 months. And then you may as well get a degree.

The sales pitch for bootcamps is that they can teach you enough to get started in a career in CS in 12 weeks. Then you can get a job and learn the rest while working. This breaks down when you don't learn things that you'll need. And it breaks down around areas you'll probably never pick up on the job, like (for me) learning how page fault handlers work in the kernel by implementing my own. Or how you can use gdb to reverse engineer C programs.

There's only so much you can learn in 12 weeks. And there's only so much your job will take the time to teach you.

I have a CS degree from a top university and I didn’t learn any of the above in college (except for perhaps debugging), including an internship.

Actually 10 years later I’m a senior engineer at a FAANG (mobile specialty) and I still don’t know most of the things you listed. Except for debugging - I got that down!

> he's just very good after two years

Right, but a self-taught developer might well have years of non-commercial experience and be good in two months or even from the get-go.

The word "might" is doing a lot of work in that assertion.

Most likely the difference in performance is due to differences in expectations. The two greatest common failures I see repeated among software developers is:

1) The inability to consider diverse perspectives

2) The inability to differentiate writing instructions from building something larger

For example many developers cannot imagine the career requirements associated with other careers. That could be due to lack of experience diversity, poor empathy, or weak imagination.

Likewise, many developers cannot write original software. The very idea is frequently both horrifying and disgusting. The alternative is just a little help from a tool or framework, because they write instructions not applications. The interesting part of that is how people respond when confronted about it.

I am having a difficult time inferring your meaning for "writing instructions".

I have seen developers confused by the words writing instructions before, suggesting either they do not know what writing is, what instructions are, or that they cannot differentiate between writing an application and writing a few instructions.

Not OP, but I infer that "writing instructions" equates to a lot of basic scripting - change the colour of that button, show a calendar, trigger that animation, send data to the validation script and display an X or a tick depending. As differentiated from, or opposed to, writing complex applications that require thought, design and awareness of best practice.

Bootcamps are a form of training designed for you to pass a job interview and use a scripting language to solve problems within a very well-defined problem space.

Their deliverables require supervision because they don't have the technical depth to identify common non-technical requirements.

Occasionally, troubleshooting the technologies you use is necessary, but this scenario is also beyond bootcamp training.

But if you work in a startup that's making a functional prototype for some web application, where things don't really have to truly work or scale, you can waive the supervision and they may even be "the best performant".

I've worked with bootcamp graduates and I've seen scenarios where they are unqualified to contribute.

But to do them some justice, some universities are worse than bootcamps. And, these days, there's an abundance of material you can learn from... but it takes time, initiative and sometimes, mentoring to know what to prioritize.

I think there's a difference between a professional using a boot camp to switch fields, and someone using a boot camp to avoid going to college or something