Is C++ systems programming too fragmented for hiring?
I recently saw a manager reject a candidate we were interviewing because his experience didn't exactly match the specific sub domain.
But I found myself disagreeing with the philosophy behind the rejection. My instinct is that if someone has strong C++ skills and has worked on reasonably complex systems, you should at least ask: "Can this person learn the domain?" rather than requiring an almost exact match.
This made me wonder whether this is a particular problem with systems programming in C/C++.
The ecosystem seems incredibly fragmented:
- Embedded
- Linux kernel/drivers
- Graphics
- Multimedia/codecs
- Databases/storage
- Networking
- Telecom
- Game engines
- Server/backend infrastructure
- Qt/GUI
- Compilers
- etc.
Someone can have spent 8 years writing sophisticated C++ in one of these areas and still be considered a poor candidate for another area because they don't have the specific domain experience.
Compare that with web development, where the skill boundaries seem somewhat easier to communicate: "React developer", "Angular developer", "Node.js backend developer", etc. There are obviously specializations there too, but the fragmentation doesn't feel as extreme.
I personally have the philosophy that if someone knows C++ well, understands systems programming concepts, debugging, memory, concurrency, Linux, etc., they should be given some credit for being able to move between domains. The domain-specific knowledge can be learned.
I have faced this exact issues with companies too. They reject you because haven't worked specifically on what they do. This becomes a serious issues when it's already hard to get into C++ jobs. Has anyone faced similar issues? What exactly is the solution for this?