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?
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.
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.
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.