I've been a hiring manager for a couple of years now, and have nearly 10 yrs professional dev experience in the industry.

Bootcamps are a red flag for you? What? Do you have any rationale for that? Makes zero sense to me. If someone has done a bootcamp, that's a big plus. Online college is neutral.

The rest I agree with.

I've hired from bootcamps multiple times, it's a great source of junior developers. It is however a show of the absolute minimum amount of skill a person could possibly have before you take them on as a developer.

If this person says that they've been coding for years, then that puts them at a way higher level than a recent bootcamp grad.

Instead of doing a bootcamp, spend a week or two building simple apps in whatever category you want to work in. If you want to be a web dev, a little node.js backend with a react frontend perhaps, or similar with Django or Rails.

Plonk it on your github, make sure you put on your resume that you're a junior that's been coding for years but never put anything in production, and you'll definitely be ahead of the bootcamp grads in my book.

That still doesn’t make bootcamps a red flag. Also, there are many self-taught programmers who complete a bootcamp just to gain confidence, make connections, etc.

Agreed

I think it's a red flag when it's also attached to a certain kind of confidence that their bootcamp experience was on-par with years of experience or education. As in, the kind of attitude where that they feel that because they went through the exhausting bootcamp stage, everything next is just an application of what came from the bootcamp. It's something I've only seen with programmers from bootcamps.

Honestly, never encountered that. In my experience bootcampers are usually self-conscious about their background. Maybe they behave differently at small companies/startups (my experience is at a big tech co)?

That could be it. I work outside of "tech" these days at smaller orgs that naturally attract people with significantly different personal motivations to those in the tech world.

I know someone who took a bootcamp after completing a college CS degree because he felt that the CS curriculum didn't actually give him enough practical programming experience. Some CS programs are terrible, so I'm not surprised he found the bootcamp to be a benefit.

Yea, this is weird. Bootcamps can be useful or useless (depending on a course, instructors and a person), but surely they don't do any harm?

Not everyone goes there to get technical skills, there are people going there for soft skills (practicing working on assignments, especially group assignments, etc.) and networking (at least some bootcamps advertise they have some relationship with recruiting agencies).

His red flag for bootcampers is a red flag for his managerial skills

Contributing to open source can be a valuable sign. It shows the candidate could navigate a large repository, communicate with the maintainers, and successfully merge something-- the ancillary soft skills needed when developing software in a team environment.

Sorry if I gave the wrong impression when I mentioned the OSS angle... My (hindsight: almost meaningless) point was that the whole "open / vs closed source ideology" doesn't matter. You could contribute to the Donald Trump C# repo for all I care... It's the contribution that matters to me.

If an "amateur" (or whatever) programmer can contribute to OSS... That means so much! You list the implications very well, so thank you.

I try to hire based on ability, not qualifications (welcome to Arbitrary Definitions 101?).

Boils down to: if you work at a gas station, and get a PR merged into the Linux Kernel... Yeahhhh... We can talk about that senior dev position ;) Is five weeks vacation okay with you?

I've been training juniors and taking part in technical interviews for a few years now, and I can say that bootcamp hires were generally the best performant.

Particularly those in late twenties/early thirties who were coming from an entirely different field - we had tons of applications from former architects and biologists for some reason - tend to outshine younger software engineers fresh out of school in just a few months.

I could understand this opinion to be controversial, but considering bootcamps a red flag vs just a hobbyist programmer with no education? Sounds ridiculous to me.

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

Long time hobby programmer. I wasn't able to get into college programs for comp sci because I had transferred under a different major. I decided to do a bootcamp just to get connections

It ended up working pretty much exactly as planned. Made some lifelong friends, one of whom seems to people in every city in the country. She got me an interview and I'm now making more than many people I know who went through a full 4-year CS degree at my very expensive university

Interesting. I’ve hired At least 100 developers in my career And have never seen coding challenges or boot camps as Red flags, rather I see them as someone going out and trying to learn and improve. On the contrary certain universities and employers certainly are( too much indoctrination(and ego in some cases) to undo). I know a number of boot camp graduates working in FANG level companies.

Coding challenges are very important, leetcode questions come up a lot in interviewing loops at most big companies and I think their use is expanding. As much as I hate LC, it’s still a good skill to have if wanting to become a software engineer.

I’ve never once looked at a candidates GitHub. There is no proof they wrote anything there. Plus I’ve usually worked in domains that always required tools and knowledge you most likely wouldn’t have anyways, no point in testing, so I hire based on if your a good person with the propensity to learn, grow, and do good things.

I don’t have hiring authority, but I was on a lot of technical interviews at my company for a while.

When people put their GH handle on their resume, I definitely checked it out. Sometimes I would even see if I could get it running on the first try. This has been an indicator of some of practices they have.

But it’s only ever a small piece of the picture. Some people push their code to github when they are very junior, and it doesn’t represent where their skills are currently at.

There is the issue of forgery, but I lump it in the same category as lying on a resume- the deception is equally as serious.

That’s what I see a lot too. Old code from when they were learning stuff, usually not reflective of their current levels. Most things you do for an employer can’t be shared, so that’s why I’ve always given it low credence.

I absolutely check out somebody's GitHub if they include it on their résumé. Usually I'll pick out some parts of the code during the interview and we'll discuss why they made certain decisions (both architectural and technical). I find that this weeds out forgeries relatively quickly.

Ah crap, I messed up here, and I'm quite sorry.

I was wrong when I said that bootcamps were red flags.

When I stated "Don't do bootcamps. It's a red flag for me"... I should have said "Don't have bootcamps be nearly your only source of experience." Like, if a person rolls up with either a super-expensive boot camp, or a side project that they've kept up with for two years... It's no contest. I certainly won't be mad at you taking the bootcamp. The criticism in the replies is valid.

Again, sorry. I'll continue to work on that whole "maybe you should type what you mean." thing.

As an aside: I forgot to mention how much I care about attitude. I'll take someone with two years of experience and a genuine hunger to learn over a guy with four years' experience who has an attitude. /shrug.

> I certainly won't be mad at you taking the bootcamp.

Why would anyone expect you to be mad? Weird.

it's an American turn of phrase, possibly related to the Tupac song "I Aint Mad At Cha." Casual sarcasm.

See also: "I wouldn't kick her out of bed for eating crackers."

Thank you, a very insightful comment. I've recently started adding to my Github, I will keep it up and be honest about my level of skill. I find it hard to know where my level is though, as I don't have much to compare it to other than seeing Stack Overflow answers and the stuff I find on Github.

Aw crud... I completely forgot about Stack Overflow @.@. I think because I'm off today, and don't have it opened in 17 background tabs...

A Stack Overflow profile is another wonderful thing on a resume. It demonstrates you're curious and/or helpful (among other things, I suppose).

A note on your Stack Overflow profile... I don't care if you don't have a lot (or any) points from answering questions. Points for asking is just as good (to me).

Tips on actually building up rep on the site (hope they're mildly useful; I had a hard time TBH):

* If you're legitimately stuck on a problem, and have actually tried finding the answer elsewhere, take 30 minutes (or whatever you can spare) to write up an intelligible question. You [usually] won't be downvoted for asking a question that is well put together and hasn't been asked before. Most of my rep comes from asking esoteric questions about Git or Visual Studio, rather than answering them.

* Don't be afraid to answer old questions with new answers. Just make sure it's actually useful, and not a copy/paste (or rewording) of what someone has already said.

* Don't feel bad if a reply is blindingly obvious in hindsight (most of mine have been). You're asking an extraordinarily large number of nerds for help.

Cheers.

In my experience working as an interviewer I am far more interested in passionate side projects that you've worked on then a checkbox indicating you went to some fly-by-night six week code camp.

>This can be said for any 100% online college.

I'm curious about this part. Do such students tend to underperform at interview?

They absolutely do. Without fail.

Agreed on the boot camp thing.

I’ve interviewed more than a few folks who got their start with boot camps but couldn’t answer some basic questions about web development.

Not knocking those who are motivated to go through a boot camp, just saying you can’t stop there. The content covered in a boot camp is just a single slice of a much larger pizza.

Fingers crossed I can make it happen this year! Thanks for your tips!

The counterpoints to all of this:

No brownie points help as you still have to pass the technical interview, 99% of the time. Places with technical interviews have recruiters. Recruiters are not technical and will not actually be gauging you on any of this, they just need to be able to find you. They look for githubs and linkedin profiles.

This person is someone avoiding coding challenges and has just as arbitrary metrics as a replacement.