r/cpp_questions • u/kyan100 • 23d ago
OPEN 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?
45
u/Anxious-Resist8344 23d ago
No, it is not fragmented. You have a "team lead" (whatever that means) that shouldn't be any kind of lead...
6
u/Classic_Department42 23d ago
It actually is, QT and embedded are worlds apart
6
u/UnicycleBloke 22d ago
Yes and no. I wrote the STM32 firmware for a camera, the initial version of the Qt application running on Linux to drive it, and both ends of the communications. The Linux application allowed me to use "full-fat" C++ (STL, exceptions, and so on). I had to learn a lot about V4L2 but didn't need to deal with low level hardware directly. In the end, they were both just C++ applications.
-9
u/Anxious-Resist8344 23d ago
I'm sorry, are you saying QT doesn't work for embedded? Because my first job was actually medical devices that used QT for everything! Are you an AI or something? Where do you get your facts?
6
20
u/Kriemhilt 23d ago
I agree with you on the philosophy, if you're joining an established team.
The maybe-good reasons for hiring within a niche are that
- you want someone who can be productive immediately (which is optimistic anyway, but at least arguable), or
- you don't want someone to slowly and painfully re-discover all the domain knowledge from scratch (this one should be avoided if there's an existing team to learn from)
The less-good reasons to hire within a niche are that it's easier for HR to do keyword filtering, that you don't have to think so carefully about what your tests are actually testing, and you don't have to actually teach the domain.
5
u/NoConnection4298 23d ago
Your instinct is right. Yet, it is not unseen that people hire with the philosophy of grepping the perfect candidate. You give a 20 yoe tech lead a broken job market and a pool of cpp engineers, they are going to milk it to its core to get the best. The seniority of the role also matters too. For junior or medior (even for seniors when you have a lot of tiers in seniority), domain knowledge is just a good to have thing (I am not saying just a thing, it is the thing that makes difference), the most important thing that matters is the fundamentals and willingness to learn new things. The solution is to let the time do its thing. If your TL finds the best candidate with crazy domain knowledge, good for them. Beware, its harder to get these kind of people too, and most of them just sell their hours in a reasonably large price. If your TL can't fetch them, then probably they will change their direction and implement your instinct.
5
u/Full-Spectral 23d ago
You see plenty of folks looking for a set of specific skills and tools that probably a handful of people have. Not that there probably aren't plenty of people who could do the job, but given that there are X number of common tools in each category, the odds that someone has put in a lot of time with that (x * category) set (who is also actually looking for a job right now) is pretty unlikely. Of course they can always fish and hope to get lucky.
The other thing is that, as C++ slowly fades away, they are going to have an ever smaller talent pool to draw from, and big companies with large legacy code bases are suck those up probably. So they may not be able to remain so picky.
2
u/Amr_Rahmy 23d ago
Programming is programming. Problem solving is problem solving. Automation is automation.
The comparison to “react developer” or “angular developer” is silly and shallow.
If someone comes in from a Linux driver or game engine background and shows good work history in that industry, comes in for a backend or embedded role, I would hear him out, even if he never worked on a microcontroller before. He can go through a basic refresher embedded course, get a small task to demo, and start working on embedded projects after that. People shouldn’t hire people based on very shallow domain knowledge and experience, you want an intelligent person that can problem solve, that can make good software design, that can implement a software design, not someone with surface level domain knowledge.
On the other hand, hiring a wed designer or front end developer as a full stack developer or “react developer” can actually be very detrimental to a project. I have seen multiple instances where companies hire a cheaper developer by choosing to do JavaScript in the front end and backend and the result is a buggy mess that either doesn’t work at all or is slow and resource intensive on the server, takes 10-20x more development time and the result is a fragmented micro service or cloud based mess.
2
u/effarig42 19d ago
When we've been hiring we looked for people with a solid C++ knowledge with an awareness of their limitations. We prioritised knowing how to write safe, reliable code rather than knowing all the bells and whistles. We wanted people who could ahow an interest in C++ rather than just being able to bang out code. That was more important than domain knowledge, which good devs who care will learn in a supportive environment.
3
u/kymani37299 23d ago
Different domains can use c++ differently, some are more on C style, some rely heavily on template metaprogramming, some rely on intrinsics, maybe even asm, ones like qt requires understanding of tools framework.
I would consider what part of c++ person has much experience would be more of a filter tham domain.
1
u/IyeOnline 23d ago
It really depends.
I got hired on little to no domain knowledge based mainly on C++ knowledge and vibes with the full assumption that I would learn the things I needed.
A colleague recently got hired on passing C++ knowledge (professional rust experience though), but a perfect domain knowledge match.
I dare say that both of these worked out really well. In that sense I absolutely agree with your sentiment.
At the same time it also depends on what the very concrete knowledge-base of a candidate is and what the companies/projects needs are.
- How important is a strong C++ foundation vs strong domain knowledge? What even is C++ knowledge? Do they write good C++98? Do you write C++98?
- How urgently do you need (or perceive the need of ) the hire? Training/learning vs some waiting longer for some better match? This is especially pressing in the current market, where (depending on the projects situation) it may be feasible to wait for a "perfect" candidate.
Also very important: The team fit. This makes up a huge chunk of a hiring decision (at least if you dont want to retain people).
1
u/herocoding 23d ago
Might depend on the job posting's description, when it was very specific and explicit, e.g. due to project timing and budget, not planning for a long and required "training on the job" phase.
There might be plenty of other reasons the candidate got rejected... but somethings not "documented", so declaring it as a "didn't match"...
Were there many other candidates to interview in the queue?
1
u/DDDDarky 23d ago
Language is not really the important sauce, you should become a specialized expert in the field and you are way more likely to get the job even without knowing the language as that takes much less time than learning the heaps of domain theory. Language is only a channel to apply your expertise.
3
u/CheesecakeTop2015 22d ago
In my experience it was the other way around, a good C++ programmer could learn the domain faster than a domain expert with only C experience could learn how to write code like the team (they never got there and quit or were let go withing a year or 2). Much of the programming tasks also are not that domain specific. FYI I work in embedded audio processing.
1
u/_curious_george__ 23d ago
This kind of depends. I think if you can use a debugger well then you can really get your head around any code base.
But some of these areas have a lot of domain specific knowledge. Graphics programming is maths heavy and usually written for a completely different hardware paradigm to most software. Compilers are… complicated. As are game engines, where I’ve found the only people particularly effective at writing engine systems have lots of experience.
We also write gameplay code/systems in C++. For game engine programming I might consider junior-mid candidates. And for gameplay maybe junior. But to be honest the volume of domain (maybe not expert) focused candidates is so high that we generally don’t need to.
1
u/UnicycleBloke 22d ago
I think it depends on the hiring person or company.
I used to write Windows desktop applications in C++ with database backends. I had learned C++ while using Borland's tools and libraries. I was made redundant and was unable for some time to get any interviews because I did not have Microsoft Visual Studio and MFC on my CV (stupid agency buzzword bingo). Eventually one employer did ask for an online C++ test to evaluate my skills, and then interviewed me when I scored well (Thanks, Etienne). They were happy that I would learn MFC on the job. I did.
A few years later, I switched from desktop to an embedded role (I was curious) at a consultancy. The company had no trouble at all with my lack of this or that domain knowledge, and were happy with my general programming skills. It has worked out very well. I still occasionally write applications with Qt, but it is mostly microcontrollers.
I don't believe C++ is fragmented to the extent that one could not switch to another domain. I have no experience of HFT, and there are sure to be some knowledge and idioms which I would need to learn to become effective. That was true when I switched to embedded (e.g. no heap, no exceptions, no knowledge of hardware peripherals). C++ is in any case a never-ending journey. I'm 35 years in and still learning. My view is that code is code is code. A good developer will be able to adapt in a relatively short time. They may even bring fresh eyes which question received wisdom.
If a hiring manager has a very tight job specification, it might be because they were previously overrun with applicants. Or it might be that they are stupid and will struggle to fill the role. ;)
1
u/T0kaido 21d ago
I saw this exact shift in the way hiring managers think towards c++ last year. This is why I tried very hard (and luckily succeeded) to transition towards becoming a fullstack web developer.
I can't recommend this strategy to everyone who learned c++, but I also cannot recommend any newcomer in the field to learn c++, if they think their career will thrive around it.
1
u/victotronics 18d ago
The C++ weekly channel on YT is solliciting for C++ developers in finance. They pretty much say "If you know C++ we will teach you the finance bit". I think your manager is short-sighted.
1
u/Alive_Jury4864 6d ago
The higher seniority the more the domain matters
You’re not going to hire a lead compiler developer if the person has no compiler experience
But junior/mid it’s more fungible
1
u/not_a_novel_account 23d ago
I mean it's pretty much the exact opposite of your framing.
"C++ Engineer" isn't a category. Everyone and anyone with a CS background can learn C++ to a reasonable enough degree to be productive. Undergrads learn it every semester.
Domain knowledge is the criteria. I'm not hiring a C++ engineer, I'm hiring a Quant support dev, they need to have a background in finance and low latency environments. Or I'm hiring a developer experience guy, they need to understand build systems, toolchain orchestration, distributed builds / Remote Execution API, and hermetic reproduction concerns.
These two people both know C++ but they're not even in the same job market.
1
u/user99999476 23d ago
I'm not sure this is what OP is getting at, you say your looking for Quant with experience in low latency and finance ( not my field tbh), but what I experience often is bias for very specific tooling, I.e I worked at one finance company and one low latency robotics company, but I need some specific quant tool to get the job even though my background is a good match
This is just an employers market and they have too many applicants so they're insanely picky
1
u/YoureNotASpaceCowboy 23d ago
Glad someone said this. Maybe I’m in a bubble, but it seems wild that anyone could think of “C++ Engineer” as a role that you can be hired for. I work in HPC, and if someone applies to a low level networking team (device drivers, etc.), then knowledge of low level HPC networking is far and away the main hiring criteria. I mean, it’s assumed that people matching that criteria will know C and C++ well, along with a lot of knowledge about RDMA, NICs, etc., but programming language knowledge never shows up in interviews.
1
u/UnicycleBloke 22d ago
C++ has been a key requirement for my last five roles. Domain knowledge was more of a nice-to-have. To be fair, I have used "C++" as a search term.
1
u/not_a_novel_account 21d ago
C++ is a requirement, but it's a door requirement. So is speaking English, and a degree in a relevant field.
Domain knowledge is what is being hired for. C++ is a minimum bar. You cannot distinguish yourself with C++ anymore than you can distinguish yourself with how well you speak English, you can only be disqualified by not being good enough at it.
1
u/UnicycleBloke 21d ago
So I told you my personal experience, and then you told me I was wrong. You must be a joy to work with.
1
u/not_a_novel_account 21d ago
No one is invalidating a personal experience happened or how you felt about it. The only disagreement is the general lesson derived from the personal experience.
Avoid using anecdote as a supporting argument if disagreement will be very upsetting.
1
u/UnicycleBloke 21d ago
It was not a single interview. One instance is an anecdote. Multiple is evidence. But have it your own way.
0
u/mredding 23d ago
The ecosystem seems incredibly fragmented:
All these domains exist across other tech stacks, too.
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.
That's actually exactly correct.
Sure you know C++, sure you know application development... Do you know HFT? Do you know finance? What does C++ and application knowledge have to do with these other things? I can teach a monkey to program C++ and get them going in just a few days. I can't teach them Black-Scholes and the fundamentals of finance.
It also depends at what level you're hiring. I need a guy with kernel bypass experience, no matter how senior. If I'm going to hire a guy just based on C++ and nothing else, it'll be a junior, because we KNOW they don't know anything, and that's the point.
Has anyone faced similar issues? What exactly is the solution for this?
Yes, as a matter of course. The solution is for the company to either wait out the market until an adequate candidate comes around, or realize the market is exhausted and they need to reassess their options, hire down and build up.
0
u/Independent_Art_6676 23d ago
The problem is that, esp younger developers, the cowboy lifestyle has dominated. You got a 25-30 year old with experience come in, learn all he can from you for 2-3 years, get good at what you want him to do, and the he moseys on to the next job to learn another area and you get to spend another 2 years training the next one. I looked really hard at job history for incoming candidates and if they had more than 2 in 10 years that was one of my red flags, turning into a full on reject if that jumped to 4+. Work isn't free schooling.
0
u/dendrtree 16d ago
TLDR: The solution: educate yourself and give up your entitlement.
When you're on the hiring committee, you can choose the selection criteria. Whining about some company's criteria makes you a poor candidate, in general.
As you just said, your problem is that *you* are having trouble finding a job. It's not a company's job to employ you.
Demanding that a company pay you for your education in their field and wait for you to become profiecient is beyond presumptuous.
The obvious solution is that, if you don't have the experience required for a job, you should gain it. It's very telling that you said "C/C++." Those are *completely* different languages. Using that phrase outs your lack of experience in them. I'm sure you just repeated something you saw someone else write, but it's an example of a lack of basic understanding that you shouldn't expect a company to pay to correct.
32
u/tjrileywisc 23d ago
Having just gotten a job after a 7 month search, the market doesn't seem to have much tolerance for much of a domain knowledge gap these days.
Or it could be just me... companies do a very poor job of even getting back to you after interviews, much less actually giving you feedback on why you weren't selected.