A lot of bootcamp / self-trained devs went into front-end JS for the money. Now that it's saturated, time to move onto the next buzz word. A foundation of CS fundamentals will still be lacking.
When I stopped feeling like I was getting anywhere with front-end I started to take on more back-end projects and sell myself as a full-stack developer.
I've never been in a situation where I've felt "man, I really should have gotten a CS degree": but what do I know; I'm just a web developer.
Maybe we're not talking about web developers?
No advanced engineering skills have been required to make the frontends/backends/architect a system for Fortune 500s and local businesses that I've been involved with. (I'm speaking of things I would have learned in school with CS and math principles had I been able to get past CS 101).
-- college dropout with successful programming career.
Wanted to know for my own financial planning.
I am a bootcamp grad who specialized in undergrad in electrical engineering. I worked for a few years as a research for the one of the top tech universities in the country; I have found that I have a stronger math and physics background than many CS grads. However, many times when doing something I have been stopped by saying "wait aren't you a bootcamp grad? can you even understand this?"
I'm not alone; my bootcamp had plenty of STEM majors. One of colleagues was a biomedical engineer and worked in a research lab and now works in the front end at a top firm in SF. Another was a math major at an Ivy before working full stack. The top guy at my bootcamp went to Berkeley in Biochem and was way way smarter than me.
So stop generalizing. I understand that they are unaccredited institution so you get a wide variance of talent but you can't shit on everyone.
To be honest, your issues probably in how you screen talent. My current company has found success in hiring bootcamp and top schools in the area (Berkeley, Stanford).
It's just a very simple fact that 90% of the bootcamp grads can't program their way out of a paper bag. In fact, most self-trained programmers are vastly better than even the best bootcamp graduates.
The problem with bootcamp grads is that they don't know what they don't know. And they don't know a lot. Undoubtedly some of them will turn out to be great programmers, but not after 3 months. Or even 6. Or even a year.
I took them both to mean "no formal schooling" and "self-taught". In my brief experience with I.T. training; some knowledge already had to be assumed.
And you know how I know what I don't know? I constantly read, get mentorship from senior engineers at my company, build side projects, etc. The learning process hasn't stopped and it hasn't for many of my colleagues.
I do agree self trained programmers are better, because frankly thats way harder.
I don't even know why you are screening these candidates, the profile you are talking about doesn't even hit our hiring team usually or gets binned within 5 minutes.
I really think you have a recruiting process problem.
As a bootcamp graduate, what do you want me to ... do? I can't go back in time and major in CS. My employer is satisfied with my work and I build things I'm asked to build independently. Should I give up a startup salary, inflated as it may be, and ship myself off to a CS monastery?
It's awesome. I have a library stacked full of software and CS books. Maybe try to get your bachelors at night? I got my master's at night while working.
This is a craft. If you want to be an expert, train like an expert. Realize 3 months of a bootcamp isn't going to cut it, not at least until you've been working for 4, 6, 8 years.
If you can't tell me what inter process communication is, what it's used for, pipes, signals, etc. then I think you have some pretty big gaps in knowledge that preclude you from being an expert at this point.
Frankly, the recommendations @seibelj is making are in a particular niche--OS fundamentals--and one that I'm guessing makes him feel smart knowing about. But they aren't necessarily relevant to you, or important to know. It depends on what you work on. Some people have trouble realizing that their pet interview question isn't actually as universal as they think it is.
PS: IPC is "Interprocess communication," and it's how you can have multiple processes coordinate with each other. You may have heard of pipes or sockets--those are for IPC. (Technically, so are files.) If not, don't worry about it. I have over 20 years' experience as a professional developer and while IPC primitives like pipes and sockets have come up from time to time, it's hardly central to my work.
Not to mention starting every task with implementing a linked-list or sorting algorithm from scratch.
In more than a dozen years of programming, never once have I had to talk to someone about IPC. And if someone pulled that sort of higher-than-thou test-by-acronym-recogition at a job interview I would laugh at them unless the salary is literally 200k and in an area which involves kernel hacking, which is pretty much the only situation in which I think it would be reasonable.
Reality is that there is a bias against hiring self-taught people and many common practices like these are basically screeners against that as opposed to measures of actual skill and expertise. One tip if you are job-hunting is to ask potential employers to review your code before you jump through their interview hoops. The places/people who are serious about hiring will do it. Those who will not are more likely to filter using this sort of arcane minutiae and are not worth your time unless they are paying for you to attend the interview.
Your salary expectations are also quite reasonable fwiw.
What most people mean is something like COM(Windows), Named pipes, memory mapped files, etc that allows processes on the same machine to communicate with each other.
If I was hiring for desktop software or pure server software, I would expect someone to know some IPC mechanisms.
Day to day, I don't think I know anyone who would actually use the acronym IPC over the expanded term "interprocess communication", assuming the subject even comes up.
The generic term just isn't particularly useful, given the wide variety of mechanisms included. Instead, you will hear developers talk about pipes, sockets, ports, connections, queues, and so on as may be warranted.
Knowing when to use a pipe and when to use a socket is important, but the fact that both are grouped together as "interprocess communication" mechanisms along with a bad idea like shared memory really isn't.