Is it a red flag when companies search for [language] engineer?

If you have an existing codebase you need people who can come in and understand it rather than spend their first few months learning the language.

It's a small red cocktail flag to me, something that needs verification and but not bad enough by itself.

As usual read the rest of the ad, talk to the recruiter, read reviews and see if your worries are actually real.

Job ads are placed by HR people that are not always aware of how sensitive we are, they should be and ads should be reviewed by the actual hiring manager but that doesn't always happen.

No it's not. If you're a senior python engineer, that means I expect you not only to be an experienced engineer but to really grok python. I don't want you coming from C and writing python code that looks like C. For experienced engineers, we can learn the basic of any new language fast! But to master any language takes a while. If the language is not specific there are now 3 hurdles for you to scale, learning the language, learning the code base and possibly learning the business domain. The only time a company should not care is if they are doing trivial things or having a hard time filling their pipeline.

It usually just means the hiring manager has less runway to train people.

I've found many positions advertised as say, "Python engineer" end up being more that you are expected to be willing to work with Python, not that you are already a Python expert. Of course this isn't always the case, but in my last 4 or so years of semi-actively interviewing for a new job, I've found this to be the majority.

Also, even if they do require you to be a Python-specific expert, I don't find this requirement any more abhorrent than a company that expects you to be an leetcode expert, especially for a position that is minimally algorithmic.

C++ (with funky pointer math) is a specialized skill. Looking for that specific skill is not unreasonable.

I think it's because the company lost a Python engineer or Java developer and is looking for a replacement.

You could take it as a red flag that it's not a system design position and more of a maintenance role, but then again they're asking for a "developer" and not a "designer" or "architect".

So the hiring company is being pretty direct about what they want.

Probably an unpopular opinion but I don’t see the issue with this at all. The language implies the ecosystem which can imply much more about the tech stack, and why not just ask for people with experience in it instead of masking it behind some veil of “we are language agnostic”?

On the point of soft skills, idk I have never read and trusted what is in listings for those as much as I do technical details. It’s the human part, and humans are insane and complex and rarely ever work perfectly well together. Just probe it on your first call (and subsequent interviews) to get as good of an idea as you can, but it’s still a crap shoot.

It's hit or miss. Sometimes smaller firms want to be clear that they expect someone who's familiar with their stack and not looking to change it right out of the gate, larger firms usually use it because they need a 1:1 swap with some legacy position that someone has recently left.

It's pretty rare that managers care that much about a stack unless they need specific skills and aren't looking to or can't train at the given level of seniority.

Usually special skills do not imply language knowledge - but its not unusual for a job posting to look for [statically typed compiled language] and accept knowledge of any other [statically typed compiled language] as a substitute with the notable exception of anything matching [statically typed native language] or [dynamically typed scripting language].

If you need someone to support a bigger Java or PHP project you better hire someone willing to do the job and experienced with that.

Not in most cases.

C++ and C are complex enough and full of idiosyncrasies that you need experience.

Java is in the middle, you can do a lot with little knowledge, but it's still very comprehensive for large projects you want people with experience.

JS and Python are a little different - usually, the language is not being stressed to do anything, but for specific things, experience helps.

For any niche language however - they should be training. It's not wise to expect people to know Scala or Rust - on one hand, it's probably a very positive signal, and you may in some cases what 'very senior' people, but on the other hand you probably want to train some as well.

I think it's absolutely appropriate and in fact necessary. Languages aren't fungible; sure any skilled developer can in theory learn any language, eventually, but all else being equal I'd rather hire someone who already has the skills I need. Wouldn't anyone?

It strongly depends on what the company does.

When I used to work for Heroku, they hired experts on specific languages for two reasons:

1) to maintain legacy systems written in esoteric languages (e.g. Erlang)

2) to maintain programming language runtimes for that language.

The first reason I was less happy with, but the second makes total sense. If part of the core product depends on a specific language (e.g. running others' code, performance consulting) I think it's actually better that you hire experts.

The only other reason that doesn't bother me is early stage companies or companies that operate in very specialized disciplines who know what their tech stack is and want people to be able to contribute as immediately as possible. In that case hiring a language/stack specialist makes sense, e.g. hiring a Unity engineer at a game studio or a Python/Typescript full stack engineer for a startup with four people whose stack is Python and Typescript.

On the other hand, if a mature company with a deep hiring pipeline is freaking out about you not knowing their exact stack, they can go fly a kite.

Think about how many engineers go to LinkedIn, Dice, etc. and search by language: python, java, etc. Sometimes recruiters and hiring managers are just doing marketing and SEO.

IMHO no. I've had the giant company I work for throw me some recent college graduates to work for our team, but it turns out despite their claims that they knew C, they really only knew how to read the hello-world type of code. It was frustrating to realize they didn't understand our usage of function pointers or the C preprocessor. I also found people who couldn't read very basic Bash scripts, and that was very frustrating too since a lot of our tooling relies on Bash (and no, they're no the horrible stuff you can do with Bash, we migrate to Python once the Bash script gets complicated). And don't even get me started on the Computer Scientist who didn't understand a C++ destructor.

Usually languages come with their own ecosystems.

I am a C++ developer and I did some Java programming and C# programming. From my little experience both Java and C# look the same too me, I consider them like a different dialects of the same language.

When you step into their ecosystems, you notice the huge difference. Frameworks, build systems, CI systems, the way documentation is structured. Even the language that developers use to describe the same programming concepts is different.

Putting a name of the language in the ad is just a sign of the culture you will be expected to integrate into.

Not exactly more like a yellow flag. Perk up your ears for any other warning signs but sometimes you just need to fill a mid level role with someone who can be productive quickly.

I don't think it's a red flag. If the job is to write Java all day, why bury the lede?

On the contrary, I think language expertise is underrated and I want new hires to start doing things immediately with minimal support. Also, people with mastery in one language often prioritize figuring out how to do the same things in other languages if they switch.

Anyone can start coding in a different language, but it just takes that much more time in implementation and code reviews when they lack knowledge of:

- Standard libraries

- Builds

- Debugging

- Etiquette

- Performance gotchas

BUT - if you're going to ask for language expertise you better evaluate it in the interview, because years of experience is a garbage metric.

Put someone in front of their IDE and watch them build and debug exercises. i.e. how do people troubleshoot issues with dependencies, tracing, optimizations, etc. I wish more places would have -relevant- interview sessions about "OK, how much do you know about the tools you use?" Obviously if you're a applying for a position where perf expertise isn't important, it's not fair to ask you about GC internals.

Some people really struggle when it comes to tools or languages outside of their expertise. While I personally don't love working with these types, that doesn't mean they don't have value.

You can be a die-hard JVM guru who refuses to work full-time in any other non-Java language because you're productive as hell and don't want to spend months re-learning how to do everything again. Honestly, I'd much rather work with a team of these types than a team of people owning 5 microservices written in 7 different languages...

(P.S. I love Java for all the hate it gets here.)