Or a C++ Engineer. Or a C Engineer. Or a JS Engineer. If a job ad reads anything like that, it's bad. If it's representative of a company's recruitment efforts, it's very likely that you don't want to work there.
I always knew this, the way you know the cinnamon challenge is stupid but you don't truly appreciate how stupid it is until you've done it.
My equivalent for the cinnamon challenge experience was navigating through an interview with a bright and experienced programmer, which went far worse than her eight years of C experience might have suggested to my colleagues in Recruiting. That's because all of them were spent writing software for the financial industry, rendering most of this experience useless in the context of writing device drivers for embedded systems.
(For what it's worth, my would-be colleague suggested we part ways early after we figured out what was happening. Last time I spoke to her, a few years ago, she was on holiday somewhere sunny, so yeah, still in the finance industry. Happily doing stuff about which all I can say is that I understood some of the words in her description and the rest made me feel pretty stupid).
The <Insert Language Here> Engineer job description comes from a paradigm that even the most incompetent organizations now understand as obsolete. It stems from the idea that "coding" is the hardest part in programming, and that basically everyone could program anything, were it not for those weird languages.
It comes from the golden age of 4th Generation Languages (4GLs), a time when many of us imagined that higher-level, English-like programming languages would make many programmers obsolete. The term itself was coined in a book called Applications Development Without Programmers, a title that's oddly anachronistic and, at the same time, oddly far-seeing.
In the meantime, two things reached mass-awareness:
- That understanding the problem and formulating a good algorithm that's adequate for a particular machine or execution environment are the hard parts of programming. Writing the code is, by comparison, pretty trivial.
- That building domain expertise is the hardest part of building a career in a particular domain.
It takes a seasoned programmer a couple of afternoons to learn a language like Python. By comparison, it can take weeks just to understand the jargon of the financial industry, let alone write any kind of software that's useful in this industry.
Similarly, domain expertise is far more portable than knowledge of a particular language. Someone who already understands the intricate business processes of the banking industry can be productive at a new job within a few days, even if they need to learn Go while they're at it. Someone who knows nothing about this subject will need mentoring and supervision for months.
There are still exceptions around -- as in, places where the ad for a C++ engineer is not really a misnomer. My colleagues in the aerospace industry, for example, tell me that this is still practiced in some places -- someone with a fancy PhD writes the formulas and maybe some Matlab code, and hands it over to the C++ engineer implements it in C++. This is anecdotal, don't take my word for it.
But by and large, we're past this stage. We understand that programming languages and libraries and whatnot are tools that a professional programmer should be able to pick up easily.
Where this understanding exists, the focus of mentoring and education ("training" is what you do with dogs, okay?) has long shifted to domain-specific expertise.
Companies in the medical field, for example, focus on building up an understanding of things like fail-safe design techniques and reliability engineering, low-power design, or even physiology or medical legislation. In what language is not even a question that's useful to ask -- in whatever language is best for the project at hand.
(How "the best" is determined is besides the point, but it's not a purely technical matter).
Companies that fail to understand this also fail to build up their teams. Internally, they end up with a lot of "great software guys" who write code which is good, but not quite what they need.
At the end of the day, what technology you use to build something is not what defines your profession. It's what you build that does.