Coding Boot Camps Get the Boot: Why the Industry Is Shutting Down

I've seen this sentiment being thrown around a lot lately. I don't think it will ever be the case. There will always need to be someone who can build the tools or the tools that build the tools or the tools that build the tools that build the tools.

Let's use your auto assembly line idea to illustrate this. A good portion of auto manufacturing these days is completely automated, the body is assembled by robots for instance. Well, a factory had to build those robots, right? That factory probably bought some robot control software from another company who specializes in that. The company that built the robot probably didn't manufacture all of the components for the robot. For instance, their welding robot may have a wire feed spool that was manufactured by a company that builds welders. However, the company that manufactured the spool probably didn't forge the metal themselves, they bought it from a forging company. That company in turn bought ore from a mining company. The mining company mined that ore using an automated tunnel boring machine. The automated tunnel boring machine was built by another company that manufactures automated mining machinery, and the trail starts anew.

Somewhere down the line in every industry is an engineer who designs and possibly even builds components that are necessary for that industry to operate.

Now, applied to software engineering:

Even if we did have software that could automatically build a web application tailored specifically and exactly to what any given company wanted down to website design and SEO, that software would have still need to have been built in the first place. If that software was built by another piece of software and so on up the line, at some point there is a person who built the progenitor. Regardless of who built the original, wouldn't these pieces of software still have bugs? What if these pieces of software involved more software that could fix their own bugs? Well , who fixes the bugs in the bug fixing software?

Beyond this, what if there is a new feature that needs to be built out? Will the software be able to build out that new feature and integrate it with the existing application? If so, how will it handle conflicts?

As it currently stands, it takes a team of multiple professionals to simply maintain any non-trivial codebase. I don't personally believe that it is possible to design an AI that is powerful enough to do this kind of work without this AI having human levels of intelligence and creativity. In order for this AI to be able to reach this kind of proficiency it would have to be self aware. And then we are forced to ask the question: is self aware AI still AI, or is it alive? We are not ready to answer these questions. Until we are, there will always be a need for flesh and bone engineers of all sorts.

That ended up way longer than I intended.

I guess I wasn't very clear, then. The parent is correct, my argument did include: "ability to think about an abstract problem and come up with a solution to it."

I was trying to use a bit of brevity in my example but these responses make me believe I oversimplified an actual recent problem I had in mind (which is what I believe make the best interview questions). I do try to attach more business needs to the questions I've asked during interviews. Instead of:

"how would you store 1 million strings, search through them while caching results, and make sure only certain individuals can access certain strings"

What I really had in my head was: "We have tens of thousands of PDFs that we need to extract text from to make available. That text needs to be normalized. Only certain members of certain teams should have access to different types of text. Additionally, this is going to produce millions of strings. How would you get the PDFs to a place you could use them, extract the necessary text, normalize it, store it, utilize caching to make retrieving it snappy, and ensure correct access?"

Technical interviews should be more full of questions that spark conversations where additional inquiries come naturally. What kind of software? What version? What framework? Could you do that faster? And so on. Rattling off whiteboard questions is definitely what I was trying to make an example of avoiding.

No, of course it isn't. The only question is how much larger the number is. That is not assuming but extrapolating and is how statistics works.

You know some bootcamp grads that got jobs. Great. That isn't in dispute though. Perhaps some bootcamp grads getting jobs is what led to the "will not hire from bootcamp" policies. Now _that_ is an assumption. Or rather speculation.

Go back to 2004-2007. There were tons of "training schools" for developers. They all cashed out right around the time of the financial crisis.

Then around 2012, they all resurfaced as "boot camps".

Rising interest rates, saturated employment environment and 10 years of insane growth probably means that they don't see much room for growth in the near term so they are closing shop.

They'll be back in a few years under different branding once the environment changes.