Hacker News Reader

Comment by nicoburns | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com