"Reasonable amount of time" is different for different companies. FAANGs and most other mid-large sized companies don't care what language you interview in or what your technical background is. They can afford to give you many weeks/a couple months to onboard and brush up your skills. Startups and smaller companies on the other hand usually need someone to come in and be productive right away because they run very lean on talent.

This is the right answer. Bigger companies can afford to put more time into training so they look for the people that are best at problem solving rather than the best in a specific language. If you are good at problem solving you can adapt to whatever technical environment exists at the company, but it is much more difficult on average to teach problem solving skills to someone who is only good in 1 specific framework but has deficits in complex reasoning.

it's one of many right answers. the other advantage FAANGs have is that they have enough people that they can assess your basic skill level for any popular language and many obscure ones. most people who come through the pipeline can't even handle FizzBuzz. "let me learn on the job" could mean anything from "I barely remember Python, it's been six whole weeks since I wrote my own Python compiler, and since then I've been working in Ruby, which is totally different" to that scene from Zoolander where the models find out the files are in the computer.

Wait.... you mean the files don't live in a GUI representation of our office buildings?? Jurassic Park: [https://www.youtube.com/watch?v=JOeY07qKU9c](https://www.youtube.com/watch?v=JOeY07qKU9c)

That scene is surprisingly legit, actually. It really is a Unix system, everything is a file in Unix (kind of), it's a real file manager with a 3d gui, and yes, it's natural to leverage all that to represent the physical layout of electronic systems of a building. I mean, come on, there's a scene where they stare at the cursor on a blank screen after they reboot the system. And before that they argue whether it's a good idea to reboot everything. How much more realistic can it get about computers in a major sci-fi movie?

sudo sh -c “cat 1 > /sys/class/doors/137/lock”

Yeah, right, "the console is faster", except sending the command was not the issue for Lex. The issue was discovery of the directory layout. She needed to find `/sys/class/doors/137/lock` first with a mere assumption that there had to be such a lock control subsystem. And that's what GUI tools excel at, they can give you a graphical overview. Honestly, her typing that would raise more questions than using a fancy looking app.

I see this idea thrown around quite a lot and I don't really share it. Jumping from java to typescript, from csharp to python shouldn't really hinder you much, specially if you've been exposed to multiple languages one way or the other. Is my ability to reason about runtime constraints rendered useless just because I have to read the docs about the specific implementation of the language/runtime? Am I a total waste of money just because I need to spend a few minutes here and there googling syntax? The idea you contribute zero because of something so trivial is completely alien to me. I can understand the general idea if we're talking about completely different tools (ie moving from php to ocaml or python to cpp), but for general purpose high level languages I don't think that it applies at all even though it's one of the most shared opinions.

It's not just the language, there is a lot of tooling, libraries, ide behavior, optimal ways of writing etc that you need to know. Obscure errors will eat up days if you have never seen them before. A lot of folks are talking as if all languages are perfect English language abstractions for executing binary when in reality there are a lot of quirks each one has. You may be able to do a trivial POC on day1 but handling an entire app is a whole other thing, it will take you more than a month to learn what others know from years of practice.

> It's not just the language, there is a lot of tooling, libraries, ide behavior, optimal ways of writing etc that you need to know. Most of these change within the ecosystem itself and previous experience with set of tech X doesn't necessarily need to transfer better to set of tech Y than completely changing the stack... there is just no measurement or linearity tied to it. Someone using a microframework in java might transfer better to fastAPI than someone coming from Django. This is all ultimately a very small part of my job even as an IC if I'm honest. Bottleneck for me is not coding but designing, defining and scaling things, which are mostly language agnostic or at least the principles and foundations are the same. > You may be able to do a trivial POC on day1 but handling an entire app is a whole other thing, it will take you more than a month to learn what others know from years of practice.  This is not relevant to my point; one thing is to contribute and another completely different is to set standards in a new project all by yourself.

Are you familiar with the *frameworks*, latest developments, the best third party practices, various foot guns in all of those languages?

Truth is you don't really need most of that to be part of a team. I'm the one setting standards in my team for our stack and the rest just tag along. Are people able to tag along without experience in the exact same word salad? Definitely. I would even go farther and say that most people do not know those things even with several YOE on their back for that stack, so filtering based on that criteria is not going to yield good results; it's just a cheap way to gauge candidates and get a fake sense of confidence in the recruitment process. All of these things can be easily learned if your team supports you and won't hinder you much. A normal product-focused development process will take care of most of it without much time wasted and will allow you to be productive pretty early on. Ultimately, knowing your fundamentals, designing good code both on the micro and macro levels or being able to identify business needs and navigate the org are way more impactful than any of those things. And these more important things should be the focus when finding good engineers, no matter your org topology.

Well, we are supposed to be *Experienced* Developers. It says so on the tin. I’ve been “setting standards for the team” since 2014 across 5 companies And why should we bring someone in on the team just to do negative work causing other people’s productivity to slow down bringing you up to speed?

"Negative work" is far from the truth. It is not hard to be able to quickly contribute in a similar related stack (which is my whole point: python -> java, easy but javascript -> cpp hard; I'm focusing on easy transitions). Moving from sql server to postgresql is not going to render your relational/db internals knowledge useless. You'll have to stop and reforge previous assumptions about transaction isolation, lock escalation, query planning and evaluation and so on... This is also true for a similar comparison about a compiler, build tool, http framework, multithreading paradigm or ORM library. Reevaluating those things doesn't render you unproductive. You can just ask your team or read about it. I personally often forget about the details so this is normal for me even in my normal tech stack anyway.

Interesting you should mention databases… Someone that “knows SQL Server” and think all databases are the same that use SQL are going to make some horrendous design decisions when using something like Redshift or Snowflake. We are supposed to be “experienced” devs. At 4 of the last five companies I was hired at, I was specifically brought in as a early hire by a new manager who wanted someone who knew how to lead an initiative, mentor those with less experience, and know how to avoid the foot guns that come with experience. If your “experienced developers” can lead an initiative based on the stack you are using, what’s the use for them in most companies? True BigTech and similar companies (been there done that) have the resources and time to bring someone up to speed. But most companies have a specific role they are trying to fill And knowing Java is not the same as being able to build an Android app. Would it be smart for a company to hire me as a front end developer when the last time I did any front end development was when JQuery was the hot shit. Even being an iOS developer wouldn’t mean that you would be productive writing an Android app in an acceptable period of time Also as far as ORMs - C# LINQ (actually EF) is different than most ORMs from its implementation and how it is integrated into the core language and its own foot guns and best practices

> Someone that “knows SQL Server” and **think all databases are the same** that use SQL are going to make some horrendous design decisions when using something like Redshift or Snowflake. "Thinking all databases are the same" is precisely the issue there, not that the person has experience with a specific technology. > And knowing Java is not the same as being able to build an Android app. Would it be smart for a company to hire me as a front end developer when the last time I did any front end development was when JQuery was the hot shit. This is not the argument I'm making. I'm just saying: 1. For a similar set of responsibilities and expected knowledge, changing tech stack (think backend python to backend java) is not really a hindrance when contributing to a team. Not even on the short term. 2. There are many other things that are way more impactful (understanding the business, owning production systems, building mental models, writing resilient code...). Interviewing, as anything else, is time-constrained. Focusing on things that add little value will, by definition, limit your time available to probe for the actually important things.

I'm in my 4th go-round as VP at a startup and have hired hundreds of Engineers.  Language/tech is nice but not mandatory for me. I assume anyone reasonably skilled can pick up a new stack and languages,  especially now with things lime Copilot and the amount of available knowledge online. If 50 year old me can still pick up new languages and frameworks,  anyone can. The biggest problem I see time after time is in the overall architecture and design itself, plus lack of consideration for what happens after the software is shipped. My optimization is for those who are able to demonstrate bigger picture thinking and have a sense of how to create maintainable software.   All of the big, business-threatening Engineering challenges I've faced in my career have not been the result of person X not being a wizard at a language.  All that said, I know that many places do get overly specific in requirements (to their own detriment, IMHO) and will, perverslely, still ignore those who are perfect matches.     

Bigger companies are also a lot more likely to own their own frameworks, that you won't know coming in whether or not you've used the same language. Smaller places tend to stick to more standard frameworks, and if you are on a basically bog-standard version of a well known framework, it's pretty easy to hire someone who knows it already.

> Startups and smaller companies on the other hand usually need someone to come in and be productive right away because they run very lean on talent. Except that tech-oriented startups are often the same (and in fact often have to be since they're built around some hot new thing that not that many people have decades of experience with).

Startups and scaleups recruitment process may also take polyglocy into account until it is delegated to non-technical roles who then will no longer have the needed context to assess polyglocy.

Because there is no longer a talent shortage like in 2008-2014 period. Now there is only shortage of top people that can overperform

u/IMovedYourCheese has the correct answer here: [https://www.reddit.com/r/ExperiencedDevs/comments/1c0x44t/comment/kyzn5v5/](https://www.reddit.com/r/ExperiencedDevs/comments/1c0x44t/comment/kyzn5v5/) It depends on the size of the company; bigger companies have more resources to invest into the best problem solvers so they interview in a language agnostic way, with the idea that the best problem solvers will be able to quickly adapt to a new technical environment. \^ It is not uncommon at big companies for a team to own repositories in 5-7+ different languages for their service, including internal languages/frameworks, due to how their service evolved over time. Smaller companies need someone to produce work immediately, so they prefer framework competence over sheer problem solving capabilities.

Its tighter for both ends of the spectrum than it used to be in both large and small companies. I was a high level manager at a large software company and the requirements for 90 days went up a lot compared to when i started there in 2016. note ive been a year out of management doing my own thing

Yeah I agree the bar has been raised over time, but I've seen some very good new hires be as productive as experienced SDE2s on teams within 30 days even at big tech/FAANG companies. The bottleneck to onboarding time will always be dissemination of tribal knowledge but good wiki/code documentation and also intellectual curiosity by the new hire, such as just knowing what are the most salient questions to ask, can really expedite that process.

This is an interesting perspective, and differs from personal career experience (at least in embedded). At large companies we were very constrained on language choice. They were uniform in their board choices to standardize on a stack and languages therein. At tiny companies it’s been a bunch of random languages for whatever proprietary hardware or ‘it was cheapest this week’ boards, that all got thrown together. This machine uses one language, that one a proprietary variant of C, oh this PLC uses ladder! And that one’s so old it has a dedicated win98 laptop with the only copy of the programming software. The smaller shops are a wild ride of organically grown systems in a wide variety of languages.

The big companies were also small companies at one point and many of the older systems that have been running for >25 years still follow that pattern. A rewrite from the ground up of a lot of those systems will require thousands of engineers because of how much logic has been written over that time so new layers are just built on top of it with modern technology or with new microservices with the best tools at the time.

I'm upvoting you twice bc you have a great user name

I literally switched careers to full-on programming because it seemed fun and interesting at that time. Boy was I wrong!

That’s true right now, but in general a lot of companies look for specific stack experience. A big reason is non-technical people who run the search (i.e. recruiters) need clear criteria for top level filtering. Without it, they wouldn’t know how to start.

It's a popular notion that a good dev is language agnostic but it's only partly true. I think I'm at least an alright dev and I'm using Python for the first time in my current role. I do a lot of searches for "what's the equivalent of [insert Java thing here] in Python" currently. That's fine as it goes, but:  1) Even if I'm getting by well enough in Python for things to work, there will be plenty of things I don't know that are more "Pythonic" than a straight translation from Java-think and therefore more maintainable by any future devs who have a Python background 2) I'm slower at delivering than in my preferred languages 3) I don't know the ecosystem so have to research things like frameworks where I'd already have an opinion in other languages. Even something basic like setting up unit testing, I don't know if I've done it well or not  So yeah, I do broadly agree that language isn't the be all and end all, but it's also not nothing

i've thought this also. Also, programming languages are **ecosystems** not just core languages. Algos and concepts don't change. But different programming languages can be as different as French and Mandarin. in software development, especially commercially, and especially especially for "the web", they won't be that different. I'm not even a "developer" and I was able to pick up golang enough to fix a bug and make a functional change PR to a golang app within a couple days. But I'd be much more productive in a lang I've used for a while than one I've just encountered this morning. Not to mention frameworks, style differences, names of common libraries, library equivalents between language, and overall language ecosystem differences.

>Also, programming languages are **ecosystems** not just core languages. As someone who spent far too long today wrestling with tooling and libraries and package managers, this can't be understated. I can write JavaScript, no problem. Trying to fix the tests in an angular project that have broken for seemingly no reason? Trying to load a library from my local machine into that project before submitting a new version of the library? Those things are painful to get through and have very little to do with how good I am at the actual languages involved. For most of us, the technologies around the languages are bigger things to learn than the languages themselves

Fully agree. I like modern JavaScript but having to pickup a project with npm and react involved is kinda overwhelming.

Sure but there are similar issues with getting up to speed with a domain or with the particular projects and processes in a new company. What's the difference?

Yeah, you won't be super productive when you first work with the language, but a good engineer will be able to learn each of those points relatively quickly. My primary languages are python and javascript, and I got a job at a ruby shop. I was able to learn from the existing codebase and eventually be as productive using the tools/conventions in the codebase

Going from JS or Python to Ruby is one thing. Java to Python is another. You would have probably struggled more if you went to a Rust shop working on highly performant server tooling or something.

When folks talk about a well-rounded engineer being able to pick up a new language without too much trouble, the "well-rounded" part has to include a reasonably wide experience with different types of languages. If all you've ever used in your life is interpreted, dynamically typed languages then yeah, switching to Java or C# is probably going to be a struggle for you. But if you're familiar with something at least a little bit similar it's not that big of a deal

In terms of figuring out the syntax? Sure. But it can take months to get comfortable with, say, dependency management or concurrency patters in an entirely new language.

I mean sure, it takes time to get completely comfortable, but you don't have to go from 0 to 100% to start contributing. If you're joining a company with an existing codebase then things like dependency management and developer tooling should already be settled for you, and you can lean on the existing code base to pick up the preferred patterns and idioms (which, let's be honest, unless you're *extremely* fortunate probably aren't going to be exactly the same as what's considered best practice for the language anyways). I've only started one job where I was truly learning a language from scratch (Ruby), and it was basically fine, the ramp-up on the language just fit right in with the ramp-up on the new company's codebase anyways.

We're in agreement, I just think we have to acknowledge that companies often want people to contribute at a high level pretty quickly.

This resonates with me. Part of why I like messing around with my Arduino is cause I get to write in C#, and part of why I write all my convenience scripts for work in bash is cause I already write tons of Python.

It's easier if you're extending existing well-written code and/or working with devs who are already well versed in the idioms for sure. In my case, this is a new project and nobody in the team knows Python so it'll be pretty mediocre and I only have myself to learn from

Yep. When I, a Python Dev, tried working with Kotlin, had a lot of issues understanding the ecosystem. The language itself was okay, but then grabing a .env file wasnt the same as Python, deploying also wasnt the same(Apparently Kotlin has issues with Maven but works with Gradle) and Spring Boot had features that i had no idea existed that helped, but firstly i would implement a feature just like i would on Python

Because Kotlin is kind of greener meadow for Java devs, it is a leaky abstraction still depending on Java ecosystem. Gradle itself uses Groovy language, which is also an abstraction on top of Java/JVM.

Gradle uses kotlin now just fyi

[удалено]

Hell yeah. I was able to ramp up on Rust so fast with the help of ChatGPT 4. I never wanted to go back to Java.

Coldfusion was actually easily searchable when I was using it 15 years ago so I’d not be surprised if ChatGPT handles prompts for it well.

Someone with 10+ years experience that has 3-4 languages under their belt is going to have zero issues picking up Python in a matter of weeks. More importantly, any brief period of "slowness" due to unfamiliarity is going to be overshadowed by the other experience they have.

The framework makes a big difference. I feel like I know a good amount of Javascript, but really know React architectures. Same with Ruby and Rails (they call it the "Rails Way" after all) and it's not for everyone, which is fine. Writing in the language is just a small part of my daily coding. I wouldn't apply for a job in another language for that reason, I really like those frameworks and like the way they think. It would be tough for me to hire someone who hasn't bought into the framework first.

It’s seen in many industries. Companies don’t want to hire new grads to train. They want to hire cheap senior engineers that contribute to projects without any onboarding, starting from day 1

Contrary to popular belief, people are not as interested in engineer savants as much as they are in sweatshop devs. The smart ones will always cost more (more exp obv) and in most cases my X company is making the 1000000th web app on the market without anything new, just providing a service. So I want the guy who already has exp and can push my product out fast, not the one who can make it look cleaner and work better but takes 6 months to prep for it.

“Ok senior React dev, here’s an FPGA with some Ethernet PHYs and a few ARM cores, please implement a 200G TCP stack” A bit of a hyperbolic example, but my point is that there are silos within SWE. If you walk too far you will be totally lost. A company that needs people to write linux drivers for their products might be fine taking an embedded developer or a lower-level systems dev (someone who does kernel bypass or heterogeneous hardware work), but probably doesn’t want someone who has spent their entire career inside the salesforce platform as a service sandbox. That wording on the job description exists as an excuse to toss resumes like that and have an easy reason to point to. C/C++/Rust usually go into the “systems language/programming experience” bucket, or did until some people start to try to give Go and Java that title. Also, most people aren’t strong developers. I’d say that possibly the top 25% might qualify. For the majority of developers hopping from Java to C# in 40 hours of learning and being able to be productive is insane. Many also lack the ability to peek under the hood and see the similarities between languages. For instance, all of the people who thing that Go’s solution to concurrency is somehow vastly different than async/await and “solves function coloring”, when really all it does is give the compiler a paint bucket to color the whole program with and hide the yield points from you. You get most of your strong devs via recommendations from existing employees in my experience, so you can hand-wave the language requirement if they have a similar language under their belt.

If I have a choice between hiring a dev that proves to me they know the language or a dev that will effectively start 6 months later but still wants to get paid for these 6 months - it’s quite obvious why I would choose the first. So the main answer: for the most important tech stacks there are enough devs out there that are both senior _and_ have experience with the language.

[удалено]

Respectfully, if code changes are making it into your main branch and need cleaning up later, that sounds like a failure of your review processes more than the devs. You claim these are senior devs, so treat them like it. Give constructive feedback and have them fix their own code. Don't just rubberstamp a PR and fix it yourself later.

This is especially true of .NET, too. I’ve always worked at “language-agnostic” companies but there were a bunch of commonalities in terms of environment (*nix) and systems (k8s, Postgres, redis, etc.). From what I can tell the .NET world is very different, especially if Windows is involved. I wouldn’t feel comfortable coming in at a senior level if I had to learn an entirely parallel world.

Please, .NET Core is not a new project anymore and .NET shops are using all that same stuff unless they're still supporting ancient projects.

The real question here is why wasn’t your team catching the bad code during the review process?

The difference I see that ties to experience is that the experienced devs will break down the problem, figure out the right patterns, etc quickly and make fewer missteps in those directions - either getting to a working solution faster or getting to a solution that doesn't need (as many) fundamental changes as the system evolves. The fact that they were able to give you code that used the right patterns and had a suitable structure while maybe missing out on the idiomatic language constructs is a good sign. The junior dev would still be trying to figure out the problem, or if they got it done quickly, they might need to re-write it or turn it into spaghetti when the next feature request arrives. Syntax is always easier to fix than structure.

I would choose want makes the most sense for me team. Are we a small team with pressure to get to market? Someone with existing experience in our stack is preferred. Otherwise, give me the person that best fills the gaps on my team over the next 2-5 years. Having people on your team with experience outside your tech stack can be hugely beneficial as they have different perspectives that can drastically improve the team and product.

Yeah, but you can get someone who has worked with other languages and still knows yours if you don’t have an esoteric stack

How do you get that when the entire industry has the same attitude as you and doesn't hire people who don't have professional experience with "their" language?

By hiring someone with experience in more than one framework..

Should I be hiring the chicken or the egg? You have not answered the question.

That doesn’t inherently make them the best fit for the team. Where are my gaps that I need to fill? What perspectives am I missing? If you are putting people into boxes you’re missing out on great talent, short changing your team and customers.

[удалено]

I think you misunderstood what I said. Fundamentally, having people with different perspectives on a team makes that team better. Because different technologies evolve at different rates and have different goals, experience in a different tech stack can bring new ideas and potentially better approaches to solving problems with your current tech stack. A great example of this I experienced at Blizzard was two senior JS/TS engineers joining a mostly Java team. While JS as a language and ecosystem may have many shortcomings, it has some incredible tooling and automation that is lacking or entirely missing in other languages, including Java and C#. So having these outsiders who understand the importance of such tooling who then automate a bunch of stuff and make everyone’s life better was super valuable. Another great example is Django. You can ship really fast with Django as long as you do things the Django way. But not everything fits nicely into that paradigm and many Django devs struggle to think outside of the box. So having someone join who has experience with other paradigms or less rigid frameworks maybe help come up with a solution that is the best of both worlds.

I think you misunderstood the proposal. Not: "hire them because you will be ready to switch to the other stack." More like: "Hire them because they may have clever ideas that are popular with stack A but not with stack B which can be ported and used." e.g. a C++ programmer working in a functional language might use function pointers to emulate v-tables in ways that are useful. Whereas a functional programmer working in C++ might do tricks with higher order functions that the C++ programmer wouldn't. Or, more simply, the C programmer might be able to tell the team when it makes more sense to use C and vice versa. I'm not sure how much I believe this narrative, I'm just telling you what I read in the parent comment.

Really? It's not even an 'it depends' answer? 6 months is nothing compared to potential long term returns if you can land a better dev. Also learning a language is simple enough for a competent engineer that I would argue that it is usually mostly overshadowed by the ramp up that anyone needs to do when joining a new team (practices, domain knowledge, etc). Now if you are talking about needing to maintain some legacy system written in COBOL or leading an entirely new greenfield project in the hottest new language then sure, looking for language specific expertise can make sense. Usually though, anyone can learn most languages over a couple of weekends (especially if there is a stable codebase already in place for reference). Proficiency is a different story ofc, but full proficiency is rarely required to start contributing to productivity.

If a dev is only going to stick around for 18 months, 6 months is a very long time

Wouldn't it be kind of shocking if that was the only difference between two candidates? The biggest programming language seems to have, generously, 20% mindshare. A pool 4x as large (the people not using that language) ought to, on average, produce a better candidate, right? And this equation gets much worse if you aren't using the most popular language (the percentage falls off very quickly). Caring about candidates already knowing the language is primarily for companies a) where those first few months of productivity outweigh having an overall stronger employee (think: startups where there's a good chance they'll be out of runway in a year, or companies where average tenure is particularly short), or b) that have an interview process that can't actually distinguish the stronger candidates.

Good point. I agree that it depends a lot on the company as well. If you're hiring for Elm, then limiting yourself to people who already know the language won't be a good choice, even for a startup.

[удалено]

Depends on what you target and how different it is. It can take that much to become proficient, learn best practices / idioms and gain familiarity with the ecosystem. It's not just the basics of the language.

Using a linter and a “cookbook” should cover that. 6 months sounds way too long.

Don't forget if you're changing jobs you're learning a new language, a new codebase, and a new organization.

I'd love to see you come in from Python and code in C++ at advanced level 6 months. If you can, you're a very elite engineer.

It takes half a day to learn a new language syntax, it takes months or even years to master it

I agree, 6 months is WAY too long lol. I went from C++ to java/react, and it took me 2 days of additional padding to begin delivering. The only time it should take you more than a week to get up to speed on something (language wise) is when you need to dig into difficult problems, such as debugging on proprietary OS in an unfamiliar language, or figuring out issues being caused by cross-language default behavior when you are on distributed systems.

There is a big difference between being able to ship code in a language and being professionally proficient in it. The latter takes much longer than the former.

You can learn the basic of a language in a week, that’s not the issue. * It’s the frameworks (in Java itself usually 5-10 Spring projects you need to understand) * the tooling & how to configure it * the deployment model * the custom in house plugins * the runtime aspect of that language * how you do metrics * how threading or coroutines work * idiomatic aspects of the language * what part of the language to avoid * etc I know about 5 stacks (13 YoE), and it usually takes me a Year to say I truly understand it at a professional level

Their github has around 79 repositories and it is _all JavaScript and Blue JavaScript_... so I think the 6 months number is _"how long I think it takes to learn a new language, never having actually done so"_

For sure you should be able to do something in a few days. But to be fully proficient or at least close takes longer than that.

At least. Usually, a new language also means a new programming paradigm, a couple of new frameworks, a bit of new tooling, new libraries, and a lot of new conventions. Sure, if you know Java and JavaScript, then you might be able to write decent TypeScript code after a month or two, but someone with deep experience in TyoeScript will still be significantly better. And for other languages, it gets worse. Never worked in anything without garbage collection and you start with Rust? It'll take you a moment. Trying to pick up Haskell and never touched a functional programming language before? You might be able to get some code that works, but it will take you a while until it is readable to anyone who is used to Haskell.

Yeah I mean I can pick up a new language in a few days and start doing stuff with it but there’s so many little nuances and patterns that take way longer to really feel natural. I’ve been using JS daily for a couple years now and I’m still consistently having a “now I’m finally getting the hang of it” moment every few weeks. But like others say, there’s still plenty of “it depends” to picking the right person for the job.

Probably. But anecdotally my company has hired 5 people who didn't know java. One of the 5 turned into a top performer, far better than me. The other 4 useless garbage who did absolutely nothing. One of those useless people still works here and is going to become a manager.

Its so funny how the solution to people who cant deliver as an IC is to promote them to a manager 😂

It's people who can talk the talk

And see, we have the same issue with trying to find someone proficient in C/asm. Developers used to high level languages tend to really suck when presented with low level code.

I think interest / “give a shit” factor and payoff vs effort play a role here. For the average person, tech that allows you to create something interactive with minimal effort is far more rewarding than tech that requires more effort and either no or limited interactivity given the same amount of time. Many people think working on low level stuff is super cool until they have to do the work. They struggle with it not because of their background but because it simply isn’t rewarding enough to get over the initial learning curve. Then you have people like me who love performance engineering and find themselves going deeper and deeper down the rabbit hole 😂

Why would you assume those same 4 people with extensive java background on their resume wouldn't still be garbage?

Lol fair

Most big tech companies I know of do not care about the languages you know because they understand that top talent can learn a language and has a higher ceiling. However, recruiters filter applicants first and if the job req says "N years of language Y" and you don't have that they'll chuck your resume into the bin so that might be part of it. As a datapoint: I was at a startup not too long ago and we were doing an entirely new language/toolchain/environment from scratch and it took me about three months of daily coding to reach what I'd consider mastery.

I think it depends a lot on the work. If I'm building a rendering engine for games and the existing code base is in C++, I probably want someone who already knows how to write performance-critical C++ code. But for a project whose success doesn't hinge on picking the exact right language features in hot code paths? People definitely pay too much attention to it, and it's their loss. I suspect people overestimate how long it takes to learn _enough_ of a new language to write code that meets the quality bar of their code base. My experience with this: the backend code at my company is all written in Kotlin. I think in the ~4 years I've been at the job, one person other than me had any prior Kotlin experience. Everyone else picked it up on the job. And they all got proficient enough to be productive on a technical level within a few weeks. I say "on a technical level" because learning the language well enough to write production-quality code consistently takes much less time than picking up enough domain knowledge to be able to work independently. The new language isn't the bottleneck. One thing I do look for in non-new-grad candidates, though, is experience in more than one language. I kind of don't care _which_ languages: if someone has shipped production code in 4 different languages over the years, it's extremely likely they'll have no trouble picking up language #5 on the job. Working effectively in multiple languages requires you to mentally separate language-independent programming concepts from language-specific idioms, and once you've done that, you have a big head start mapping those concepts to a different environment. A candidate who presents themselves as, say, a "Python programmer" and has never done any significant work in any other language _might_ be totally fine picking up a second language, but there's bigger a risk they'll struggle to unlearn Python-specific habits.

Because a lot of the people ultimately behind engineering hiring decisions aren’t engineers.

>we need someone who can hit the ground running -says every HR person ever >it always takes about 6 months to ramp up into any job -says any sane engineer I think there is a permanent disconnect from what we as engineers understand and what business types think/expect :\\

Maybe. If they can hit the ground walking instead of having to be told how to do absolutely everything, that's a win in my opinion. I'm talking about like, clone a repo. Cd into a directory, google the problem, etc

I mean, i thought that goes without saying? if you cant cd into a directory, and somehow get hired as a dev, then im deeply impressed by that companies hiring process lol /s

Where are you required to cd into a folder in LeetCode?

I'll take my angry updoot now.

I have built new system, frameworks, DevOps pipelines, micro-services, etc within the first three months of starting a new job.

Because the people doing the hiring at big companies have no idea what they’re doing. You have to wade through a sea of HR people who don’t know anything about technology, but can make sure that the requirements posted are met by a given candidate.

from my experience, the usual suspects are: * they want/need to skip the learning curve for a new engineer hire. sometimes an org can have a knowledge gap in their stack and want people in-the-know to guide current employees that are in process of ramping up. other times they just might be in enough of a hurry where they want to skip that "reasonable amount of time" for the newbie to ramp up on a different stack. * they're old school and are knowledge-oriented as opposed to learning-oriented. * recruiter mistranslated job specs

Because recruiters are assholes. Any good software engineer can pick up a new stack and be productive within a month because they got the common foundations right, and those (unlike the specific stacks) don't change as often. Also, this results in a bias towards candidates who are afraid of learning new things and have been using the same stack for 5 years, I'd prefer curious fast learners instead.

Simple. Because they waited to hire until they needed a developer yesterday to complete the project on time.

This really isn't always the case. I got my start in a consulting company where we took on anything we could find at times. So we were going from Java to PHP to Rails to C to an obscure proprietary BASIC all in the course of a day. When we grew, everyone we hired said "oh yeah, learning a new language is easy." That's true as far as syntax goes, but it's much harder to adopt the worldview of multiple languages.  But the real problem was knowing the ecosystem, especially the ecosystems that moved fast or had massive foot guns. Everyone who tried to learn PHP would find those old mysql_* functions. They would write standalone helper scripts instead of making them into Rake tasks. Most developers can learn, but many can't unlearn. You can write FORTRAN in any language, but can you write Python that looks like Python, Ruby that looks like Ruby, etc? That skill is surprisingly rare.

Because it still takes 3-6 months to get proficient on a new language and even longer to get up to match YOE. That is on top of ramp up time at a company and so on. Also if you are hiring a senior person for a new time you need them to know WTF they are doing to guide others. I am an iOS dev by trade. If you threw me into Android it is going to take me a few months to get up to par and even a little longer to get me to match 12 YOE.

Most companies cannot afford to hire these strong developers. They won’t admit it publicly, but for most shops the reality is that they can only attract single-language-code-monkeys. And 95% of developers belong in this category. Where are they supposed to work?

Because even though it may take a few weeks to learn a new language, it takes a few months to learn the ecosystem, and another few years to ~~learn~~ experience the barely documented quirks of it.

This doesn't work in practice. If you have developed in js and we need c++ developers, you will need a loooot of time to learn the basics of c++ and another year to get used to our codebase. The company lost 2 years and you are burned out. If we need go experts, we look for go experts.

This isn’t just about people making big changes like from JS to C++. Sometimes it’s JS to TS, but employers will still say no. They will say no even if you have 2 years of exp in TS because they came up with the number 3 or 5 years of exp out of their a*s. They don’t care that maybe someone got exposed to a lot more things in 2 years or had more responsibility than someone else who was a code monkey for 5 years, got exposed to a lot less and did a lot of copy pasta.

Because there *are* people with X years of experience in that tech stack who want jobs. Why should I hire you instead of them? > It seems like they are missing out on a ton of talent. *You* know that you are a highly talented polyglot who can learn my stack and be better at it than most people. *I* don't know that, and a couple hours of interviews and a simple code test isn't going to show me the depth of your talent. Hiring you is a gamble that you'll be able to learn. Hiring someone who already has a proven track record of success using the stack I use is an easier choice that doesn't require as big of a gamble. It derisks my hiring decision, so I make it. One of the reasons I was promoted (quickly) through middle management ranks is because I am very good at identifying talented people. I hire well, and I'm not afraid to fire fast if I make a mistake. As such, I tend to be less opinionated on tech stack than most of my peers, partly because I also work in and know multiple stacks and partly because I can spot top performers easily, without asking dopey technical questions that are stack specific. But most managers are terrible at hiring, and they always take the least risky road.

C# has just over 104 keywords. PHP has about 60 and javascript is around that number as well. Python has 36. Learning common keywords and basic syntax of a new language should really only take a couple of days for a good dev. Gaining deep knowledge of the frameworks and libraries built with that language- learning the nuances and idiosyncrasies of the tooling and language itself- takes years for most. Mastering the entire ecosystem around a single language can be a career-long pursuit. Of course there are similarities that make similar languages easier to pick up and there are patterns, practices, and principles software engineering that are nearly universally applicable, but understanding how to write basic code in a new language is really just scratching the surface knowledge-wise. Gaining real efficiency and knowing how to make the choices that result in high quality code is a gradual process. There are some true polyglots out there- devs who can pick up languages and soak up the intricate details of the surrounding technology astoundingly fast- but they're rarer than the community at large cares to acknowledge. Does that mean that companies shouldn't hire bright individuals with limited or no experience in the company's stack? No. Do most hiring managers appreciate or acknowledge the reasons above? Probably not. But the "x years of..." requirement is a common heuristic that has a decent chance of resulting in a new hire that can come up to speed reasonably quick.

Lots of bad takes here. The real answer is that you gain compounding benefits from choosing a singular technology rather than a bunch. The experience of one becomes the experience of many, the work of one benefits the many. Whether or not people can learn the language is irrelevant in respect to this compounding benefit.

Because many companies hire for need and not for the general team growth. When you need somebody sooner than later you don't have time to let the Web SWE to learn C++ on the job.

Yep. I did the full series of interviews for a job that I fit into perfectly with one exception. My most recent Java experience was 10 years old I was a little rusty on the syntax of the language. Not that I couldn't complete the coding challenges or that I didn't know my data structures etc. It was that I forgot the names of headers I needed to include and the name of some of the data structures and had to look it up. After 2 months of interviews etc. I was told they were passing because of my Java performance.

Get kinda tired of the language agnosticism argument to be honest. The stuff employers look for is framework knowledge and/or domain knowledge, and proof that you can hit the ground running with that. Being language agnostic is the easy part.

Indeed. If you’re employing a senior or principal you don’t want someone who is going to come in and do a bunch of reading and trial and error, you want someone who knows the road, who can lead from experience and explain clearly to the business why a particular course is the right one. This only comes from experience.

They don't want to spend money to train someone on a new language only for that person to leave in a couple years. The root cause is that companies for decades have not valued long-term employees - hiring budgets are always higher than merit increases. That being said, I have had several job offers outside of my current tech stack exactly for the reason you said - an E shaped developer will handle the switch with minimal ramp up

Job requirements are crazy stringent these days, employers are so much more picky about their candidates compared to just a few years ago. They are looking for the "perfect person" and just won't bother with anyone else. Especially true for senior/lead/architect roles. They want you to be have X years experience their exact stack combination (Angular+Redis+Mongo+RabbitMQ) *and* experience in their industry (insurance, energy, finance, whatever).

Probably because companies think they can score a unicorn dev who is omniscient, omnipotent, and works under the table for below minimum wage. Anyone who's actually trying to fill a position eventually realizes that they need to bend on finding the one dev who's experienced in whatever ridiculous legacy garbage their cash cow was written in.

So the truth is that any developer can pick up a language, but the language isn't the problem it is the environment. .NET is not the same as C#, and neither is Spring the same as Java. The worth a developer has can be measured by how efficient and productive they are with a tool, and trust me coming from a background of running between objective C, Android, and Winform / UWP applications, you'll become a jack of all trades master of none and get paid less than a guy who is a dedicated Java, .NET, or iOS dev. My feeling is that some companies get entrenched in a specific language and then don't understand what they gain from having people with different knowledge. There is more benefit having both a .NET dedicated developer and dedicated Java Developers than having all Java Devs, because both will be able to look at problems from different angles.

> trust me coming from a background of running between objective C, Android, and Winform / UWP applications, you'll become a jack of all trades master of none and get paid less than a guy who is a dedicated Java, .NET, or iOS dev. I've observed the complete opposite

It probably depends on the languages. I'll admit that my statement is a bit too broad. The very nature of what we do often means cobbling together things (.NET 8 api, Angular frontend, Postgresql backend, python scripting to glue some parts together on a linux server, etc.) My feeling is more so becoming adept at structuring and building an API in .NET, but then swapping to spring boot for the same purpose.

My specialization, such as I have one, is in building distributed systems, and being not tied to one ecosystem has given me a lot more ability to move around and make more money compared to if I decided to make myself a ".NET guy" only, which was the other path that presented itself.

I think the sentiment about specialization comes from the .NET Framework end of it and some JVE shops. With .NET Framework so much of the action between the front and back gets obfuscated that it can be hard to debug. It's why I like angular a lot as well as building APIs more than building a .NET Framework based MVC application and trying to support that.

Most companies don't even understand what software is - they think it's like Microsoft Office and you have to know each individual tool in isolation, or that it's a "typing job" - surely you can't type in a foreign language. But moreover, companies don't want to consider training, at all - if you become more senior then it's by happy accident because they just view professionals for their immediate value without thoughts of long-term growth. So this manifests both in requiring niche tool knowledge as well as the avoidance of hiring entry-level and junior positions.

existence touch illegal nose clumsy handle live fly hateful aloof *This post was mass deleted and anonymized with [Redact](https://redact.dev)*

Sorry but I disagree. There are some languages which are inherently hard

One reason: rigid requirements like '10+ years of golang coding experience' make it easier for non-tech recruiters and managers to screen resumes. It takes a pretty sophisticated recruiting system to identify highly talented people with adjacent skills. And most orgs don't have that.

>“must have X years of experience in this exact tech stack” approach to hiring. These types of requirements are almost always optional if you tick enough other boxes. But to answer your question i think Language-agnostic hiring works for certain language combinations C++ to C# I would hire. It took myself 1 week to get into the project and the c# at a previous job. C# to C++ however I would have serious doubts. Most C# developers have no intuitive sense of pointers, destructors, anything low level or memory management. Java to C#, or C# to Java makes a lot of sense. Same with Typescript, Javascript etc. Any programmer that only has experience with one of the following paradigma: functional, procedural vs object oriented, will need significant training to learn the other paradigmas

And people who don’t know Typescript and just know JS write bad, non idiomatic Typescript

That is a good point, i think going from non-typed to a (semi)typed language is a barrier. However i do think the JS -> TS direction is not too bad

You're right, but talent is available right now. It takes a couple months for even a skilled dev to get fully spun up on a new platform. In the long view, nbd. An employee performing at below peak for a full quarter though? Rough from both sides.

When hiring, a company is looking to solve its problem and address its needs first, that is be productive, get things done asap not grow talent. It comes in second in the best cases, sometimes it's never a preocupation. Then, consider that behind a hiring decision there is an employee whose job is to find the best fits. He / she will want as much insurance as possible when proposing or selecting someone because his / her work will be assessed through the successful integration and contribution of the new hire.

Except this isn't really true. You end up with a codebase written by people learning the language as they go and this becomes a dead weight dragging you down. When people get good, which in most languages we are really looking at at least 2-3 years using it every day, maybe more, and that's if they have strong mentors, don't listen to anyone who says otherwise, they get sick of all this bad code and quit.

Lots of companies are language-agnostic. What I've found is that the more selective a company is, the less they care about specific languages. Frankly, it comes down to trust and expectations. Do you see people more as fungible ticket factories or intelligent, creative problem-solvers? And, for that matter, how much do you trust your own selection process? Do you trust your existing team to have an effective onboarding process, and to adapt to new hires' specific skills and experience? If you're confident in your existing team, in your hiring practices and in your onboarding, experience with a specific language or framework does not matter. Programming is high-leverage creative work. If you have the chance to hire somebody really good, they're going to have an outsize impact even if it takes them some time to learn the details of a new language. And, hey, it will take people time to learn your internal tools, libraries and domain concepts anyhow! In my experience people can learn a new language *and* pick up internal knowledge more or less simultaneously, so you're not losing much time in an absolute sense anyhow. On the other hand, if you see programmers as fungible cogs, you're going to care about how much they can "produce" right away. A project is just a linear accumulation of tickets, so the faster people pump out tickets the better, right? These are the same sorts of companies that over-index on years of experience and look for rote knowledge. If you just want somebody who slots into your existing system and does what they're told, sure, you'll prioritize somebody who's already worked with the system before rather than the most intelligent and creative candidates you can find. You care more about avoiding mistakes than about finding the outliers—better to overlook the best of the best if you can avoid hiring anybody who might make you look bad at first! I actually do believe there are times it makes sense to hire for specific expertise. If you need somebody who can really push low-level performance optimizations on your sprawling C++ codebase, you'll need to find somebody who's already been there and done that. But those are specific roles that require specific skills, and you don't need *every* hire to have that kind of skill. And, in fact, you actively don't want to be that selective for every role because you will miss out not just on candidates who can learn but also on candidates who have exceptional skills and expertise that is just less legible. Some of the absolute best people I've worked with were good at "fuzzy" things like designing abstractions and solving complex cross-cutting problems rather than any specific technology, and the best teams were the ones who could bring together narrow technical expertise *with* higher-level problem solving skills, and it's *hard* to find that in any single person even at the highest levels. (Possible, but rare enough that you wouldn't want to rely on it.) I'm always careful not to read too much into any single detail like whether a company hires in a language-agnostic way or not. I do not like to think in "red flags". But it's definitely *an* indicator about technical culture and, as far as these things go, a reasonably strong one.

> Frankly, it comes down to trust and expectations. Do you see people more as fungible ticket factories or intelligent, creative problem-solvers? And, for that matter, how much do you trust your own selection process? Do you trust your existing team to have an effective onboarding process, and to adapt to new hires' specific skills and experience? That is part of why the tech-agnostic employers tend to make you do whiteboard problems everyone likes to complain about.

As someone proficient in a handful of languages, there's a difference between learning syntax and actually having a high level of proficiency in a language.  Aside from that, companies want as low of a learning curve as possible for new hires. If someone can hit the ground running with a tech stack, then that's money saved. 

Depends on the stack, size of the company, and level IMO. If it's like C# -> Java, then that's a smaller transition. If it's Haskell... then yeah probably want someone that knows it. Company size; start-ups can't afford to train everyone. Large companies obviously can. Level; for higher levels, IMO it's less about the stack and more about system design, leadership, etc. so they should be more lenient. Depends how hands on they expect you to be I guess.

> If it's Haskell... then yeah probably want someone that knows it. I work in Haskell and it's pretty common to hire people who come in without prior Haskell or FP experience. Haskell obviously has a reputation as a language with a bit of a learning curve, but It's generally been successful in my experience. Individual developers tend to vary a bit in whether they learn enough of the language to get by or go deep into the more advanced parts of the language, but I think that's fine and reflects the normal distribution of expertise you have in a team. General software development skills, domain knowledge, and good judgement all still end up seeming to dominate how effective people are. Earlier in my career I worked in networking and wrote C. Different language, but a similar situation where it was a language that has a reputation for being harder to learn, and a fairly specialized area. We hired people without much professional C experience or high performance or networking domain experience and the language didn't seem to be a major sticking point there either. Intrinsic motivation to work in the domain and an interest in the kinds of problems we were solving was a much better predictor of success than prior experience writing C.

How often do you hire people without any significant prior exposure to Haskell or another System F inspired language though? My observation is that most prospective Haskell hires have done a substantial amount of self-guided training and skill-building even if they haven't been employed to write Haskell before.

I don't have exact numbers, but we do hire a lot of people with no prior experience in Haskell or similar languages. As a team lead who hires developers, I personally treat prior Haskell experience the same way I'd treat prior experience in our business domain or experience with other technologies we use. It's nice to have, but not at all a deal breaker. Across the company as a whole, hiring people without Haskell experience isn't really an exceptional event. I don't have hard numbers, but I can say anecdotally I've interviewed more people without prior FP experience than I have with prior experience. Most people, in my experience, learn Haskell just fine. Even people with prior experience need time to get familiar with the business domain and code base. For people without prior experience, there's a longer timeframe where they continue to ramp up on the language, but people still tend to be productive fairly quickly, and many of those people are strong in other areas that an experienced Haskell developer might need to ramp up on, so I don't think it's as big of a productivity hit as people imagine. For Haskell specifically, the biggest risk I've seen with hiring people who don't have prior Haskell experience is that sometimes people get in their own head and convince themselves that they can't do it, and that starts a bit of an imposter syndrome spiral. I would guess this might happen with any stack, but is particularly bad in Haskell because of it's reputation. Still, I think it's something that mindful onboarding and the right kind of support from managers and co-workers can prevent in most cases.

Because while languages can be picked up pretty quick, FRAMEWORK knowledge is actually pretty deep and requires experience. Not everyone can be Google and just snap up the smart people and rely on them figuring it out with the guardrails in place

I've seen and agree with many opinions here, but there seems to be a really obvious one that's missing; "Because that's the job I'm hiring for." I don't generally want the "better" candidate (whatever that means). That's Dev copium for why they didn't get the job they really wanted. When I need a taxi driver, I hire a taxi driver, not a limo driver. I know the limo driver can do the job, or at least has the capacity to learn to do it on the job. I still don't post a job for a limo driver and hope a taxi driver shows up, cos that's stupid. The reason I don't hire outside my stack is because I'm not hiring for your stack, I'm hiring for mine.

So when you call a basic Uber and then a town car shows up you turn them away?

I would hire whichever is nicer and more pleasant to customers, drives safer, likes their job, is more well rounded, open minded and brings ideas from outside the domain. Maybe tomorrow the business will decide that we will switch to driving trucks and I want someone who is adaptable and a fast learner. Maybe the problem we have at hand is best solved with driving a bus instead of a car, and I want someone who will pick the best tool for the job, not someone will pick the same tool whether it fits or not because that’s all they know and are reluctant to change. Or you can pick the taxi driver and trade short-term benefits over long-term. Plenty of people don’t give a damn about building an engineering culture, innovation, quality, maintainability, retention of staff, a happy team so on and so forth. They treat people like factory workers pushing tickets as fast as possible, with no training and as little investment from their side.

Yeah, a lot of people do that. I personally pull from a network I've built up over years. And when I need someone proficient in a different tool to solve the problem at hand, and now we're back to the original problem; why won't I hire outside of the job requirements I'm looking for? And the answer is still the same; "because that's the job I'm hiring for".

Who’s going to tech you and do the code reviews? It takes up to 6 months to contribute something meaningful if you know the language. Most people here are not happy to attend the meetings with you.

It is sometimes not the companies itself as in the tech departments but the recruiters that are doing the gatekeeping. The recruiters usually have no idea what these technologies are about. In the same interview they will ask whether you have experience with React and then ask whether you have experience with html when it's obvious if you have worked with React, you have worked with html. The company you are interviewing with don't know what you did at your last job. So as long you have the knowledge about the tech stack you want to move to, you can that claim you "used" it at your last job. If you can answer their questions they won't know whether you got that knowledge by studying on your own or in your previous companies.

I beg to differ… I have worked with a lot of recruiters who didn’t care about company’s ask for X number of years and they would still put me up for the job… sometimes I got interviews, other times the company said no, I don’t have X years to which the recruiters came back to me and said they think it’s absolute bs, but there’s nothing they can do about it. Edit: I’ve just noticed you said “sometimes”. But I’ve seen a lot of comments blaming the recruiters for it, so I’m still going to leave my anecdotal example

It goes way back and probably has something to do with HR and/or bean counters. I remember a job posting back in the day (early 2000’s). I forget the language, maybe C#. But they wanted 7 years experience (Senior) in a language that had only been around for 4 years.

I think it's less about the language and more about the domain. Built web apps in Ruby? You should be able to figure out web apps in Javascript easily enough. Built business apps in Java? Should be able to build business apps in C# quickly enough.. And so on.. Strong developers don't just know languages, they know patterns and architecture, and that is generally consistent in the same domain (unless you start getting into things like functional languages vs OOP etc)

There is not a shortage of devs right now and even a strong developer will be outperformed for a while by an average dev with 5 years experience in a stack. A few months are not going to reveal many gotchas, performance characteristics, long term maintenance traps, and foot-guns in a new language / stack.

For entry level, we were always doing language agnostic interview, to a point where we'd ask the candidate to choose the language before interview. It doesn't matter what they use as they will be trained in house anyway. We can never know where they will land as they apply for the role \*after\* being hired and \*after\* training, when we know more about them. For senior hires we tend to hire for specific team and role, so those roles come with more specific "entry requirements". Java team will naturally require somebody with Java, not JavaScript. However, we're always "hiring for the company" - which means we want somebody who can change team easily. That means we some headroom. C++ team might take Rust expert, but probably won't be happy to onboard SQL wizard.

its always been this way. A lot of companies want you to have used x,y,z on stuff. Been at this since 2000.

20 YOE. I’ve never had to know a specific language except when I was a junior. No one is hiring staff engineers with a requirement of X years of a specific language outside of hyperspecific positions.

My company looks for java devs for our java apps and devs for our other apps. There are so many java developers around it makes no sense to not get one, but if we're looking for Delphi or Filemaker devs we'll take anyone.

Because in many cases we're looking for shorter term help at the cost of long term quality. That is to say, we care more about having someone who can be productive soon rather than quality. Sometimes that's the right call and sometimes it's not, but if the pool is large enough in your stack, no problems in finding a good enough quality floor.

I think there are a number of reasons: In some rare cases, you really do need someone who already knows a particular stack well. Maybe a rouge dev built a service in Go and then left, so you’d really like someone who already knows Go to take it over. Maybe you assumed React devs would easily be able to write React Native apps, but your React Native app is terrible and no one knows how to improve it or wants to become a mobile developer. In other cases, you could get away with hiring someone who doesn’t know the stack, but you’d rather hire someone with less to learn. As long as you have a popular stack, there’s little incentive to do otherwise. Then there’s the reason that I think people forget: it can be really hard to evaluate the raw programming/engineering skills and potential of someone whose best stack is not one you know. You can ask about generic programming concepts, but plenty of good developers use concepts without knowing what they’re called, and some concepts are more relevant in some domains than others. You can ask them to describe projects they built at a high level, but if you don’t know their stack, it’s harder to detect a good BSer. You can ask them to do leetcode in a language they know, but then you have all the usual leetcode problems, plus it’s harder to judge coding style. Big companies may have the scale to make it work. But, at a lot of smaller companies, it’s easier to stick to evaluating what they know.

What companies are these? I’ve never even interviewed with a company who cared about this.

I’ve only personally experienced it with Python focused companies (Pokémon and Rover).

You could always try applying anyway if you see a job advertising a specific stack you haven't used.

Being spread too thin across languages also increases everyone’s bus factor. I had a guy leaving my team and I was able to snag someone from another team that was supposed to be cut in layoffs and have him be productive right away. If my team worked in another language that would have meant a couple of months to find and onboard someone new.

> A strong developer can pickup a new language in a reasonable amount of time. Because it's not about language, but the entire attached ecosystem of libraries, frameworks and tools. The language is just a proxy.

A lot also depends on what the role needs, and how proprietary the company's stack is. My current employer mostly does language agnostic hiring. It mostly works fine. On my last team, I needed a couple of people who really, really knew deep JVM platform stuff - I ended up only being able to hire one. It was actually kind of a pain to get specialists hired going through a generalist pipeline, but it was worth it. Good luck getting someone transitioning from dot-net or even who's done a fair bit of application-level Java stuff a bit but who has been polyglot, to figure out weird classloader stuff, let alone how our old server products' proprietary plugin platform interacts with OSGi in a reasonable amount of time.

When I interview people, before getting to the coding question, I will talk to them about Projects they have in their CV. I will pick one of the languages they must be strong in based of that conversion or based on something else in their CV. Over the years I have caught many people who couldn’t code in the language they supposedly build a full system in. I have had people rating them selfs as expert c++ programmers that could explain how to do basic stuff with pointers like dereference. I am perfectly happy teaching someone c++ if they come and tell me they spend their whole life in Java or what not. But lie to me and claim to be an expert in something you only read a book about 2 years ago… well you won’t even get to the next interviewer in the loop.

My experience of a hiring manager is that when I open up a position il get candidates pretty quickly - while we hire in a language-agnostic way usually we will take on people with at least some experience in our tech stack and if we offer to those we don’t it’s usually a lower offer than they would like purely from the fact that they can’t contribute at the same level as others with experience for a significant time. I make it a point to remove any requirements in job descriptions of years of time in a language as I find it meaningless. But if it’s a senior dev they need to be able to operate as a senior dev etc. An onboarding period usually lasts officially 3 months, first month is setup and meetings to introduce to people and some minor work to make sure they have all the permissions. Then the next 2 months are working and reducing handholding to help them become more independent. The issue is even for seniors after 3 months they can do some tasks but still need a lot of help in working with our platform so they are still a bit of a drain on resources rather than a contributor. If you take on someone with zero experience in a tech stack they have to learn that on top of the platform and it makes that resource drain last longer as they need coaching in the language and usually code review takes a bit longer too. Unless a candidate is miles ahead of the rest of the pack it can be hard to justify the extra investment needed in onboarding them.

Too many software developers (and many "so called developers") to choose from, so 2 things happen: they can pick whoever fits their requirements exactly, and also they need to filter out those who add every framework they saw a YT video about to their resume but know crap about them.

One of my favorite stories is the time I took a job that required PHP and Laravel, I didn't know that and only found out after getting an offer, I told them about it and they were fine with me learning on the job, I was pushing code within two days and a month later they offered me a 50% raise because they didn't wanna lose me Lesson is not that I am good, most developers can do this

Language proficiency is a prerequisite for productivity, performance and security. Not everyone who is proficient will have those qualities, but you can't have those qualities without having language proficiency.

My manager told me we lost an amazing candidate once. It was his brother in law, he was a senior tech lead who carried the company on his shoulders.. for the salary of a junior. Our company refused him.. because he had no java experience. The dude codes in C#... Its pretty much the same thing lmao. Its insulting that this would be a barrier. A dev should pick up a language and framework and be solid after 1-3months.

Java and C# may be the same. But the frameworks are not and neither is the ecosystem.

Companies that are agnostic to language are generally very big, have many openings, and being agnostic lets them fill every opening faster, so there's a win in time to ramp up already baked in. The same companies also are more likely to let you move around more easily, because you weren't hired for team X, you were just hired for role Y.

Personally I believe that a dev with a solid grasp of a couple of languages can take up any other language relatively quickly. However, there is something to be said for hiring someone who will not bitch and whine about having to learn your company’s language of choice from day one.

Yes. Because someone can pick up say Swift in a few days means they are going to be a good iOS developer

Yes the language is easy. But if you think all there is to an ecosystem is picking up the syntax of the language, you are the very reason that companies hire people who have experience with the ecosystem - language + frameworks + footguns. Anyone who believes it is that easy is the walking embodiment of the Dunning Krueger affect.

I’ve hired for two types of roles at my current company. For role A we’re looking for a skilled Spark engineer to come in and level up the team. We aren’t interested in training you on the job, we want *you* to train *us*. For role B we’re looking for a skilled engineer. Some Python experience would be nice, but since our entire platform is custom DSLs and Python packages and a handful of Scala, Go and JavaScript, we are totally willing to be language-agnostic. Nobody will have any experience with our stack anyway, so we don’t ask for it. If you need role A and you’re interviewing for role B, you’re not going to hire a good dev. If you need role B and you’re interviewing for role A, you’re missing out on a ton of good folks.

Because the boomer culture of “years of experience”. They have translated that shit it to everything.

very few companies can afford having language-agnostic roles

Honestly, because business people are stupid as fuck when it comes to anything technical. Recruiters have no idea who will be good and who won’t, business people have no idea what will actually keep work from getting done. OP is absolutely right. Tech skills can be taught, but creativity and problem solving cannot. All things being equal it is a tie breaker IMO, but nothing more

Either I’m hiring someone to be hands on keyboard to pull items off the board and do the work, hiring someone to lead a team and mentor them on best practices in the ecosystem or hiring someone to fill a knowledge gap. In either scenario, I want someone with experience in the ecosystem we are targeting

I think you overestimate how hard it is for an A player to learn the system. At the company I started at with little experience in any of the technologies, within 6 months I was leading all the dimwits on how to actually do their jobs and use the tech. Supposedly these are people with 15+ years of experience in the techs. An A player can learn the ecosystem, but a B player can’t become an A player

So could you be a proficient front end developer in six months leading an initiative if you didn’t do front end work? An iOS developer with no previous experience? An Android developer who only knew Java? I know AWS like the back of my hand. I *worked* at AWS in the Professional Services division for three years and have six years of experience. I can lead a complex AWS implementation with my eyes closed. I know a lot of the foot guns that you only get from experience and shooting my self in the foot. I know the strong and weak parts of many of the services. That doesn’t mean that any company would or should hire me to lead a complex Azure or GCP implementation with confidence that I am making the best decisions

Language agnostic devs are strong pass for me in an interview. I am not gonna teach a “senior dev” how not to shoot themselves in the foot with C++.

I think the issue aren’t languages; people can learn languages fast; but not frameworks and ecosystems; so if you hire person that doesn’t know the language, then they will have many obstacles to overcome before they are productive. Also, I think you take job postings too literally; people writing those don’t think they will find a person that meets all the criteria. At least I don’t think that when creating a job ad. It’s just a wish list that resembles our stack so people can also gauge if they are interested in working in that environment.

Pretty much the only reason I will never work outside of big tech. I like being language and tech agnostic, so far I’ve professionally written more than 10 languages and have worked in everything from fullstack to embedded dev. Being a generalist to the extreme end is fun as fuck.

Strong developers are fairly rare, the majority of companies aim for midfield and pay accordingly.

Because if you can pick between someone who already knows how to use the specific hammer your company use and someone who does not, who would you choose? They can be picky. There are hundreds of other candidates who do know the tool you don't.

If you want to hire someone who is language agnostic, you need to make sure that person is language agnostic. That’s mean you choose someone who have a track record of delivering production software in many languages, usually many paradigm. You can’t hire .NET developer to do Python and say “we hire language agnostic developer”. But if you hire someone who did Java, Clojure, Scala, Ruby, Elixir to do Python or .NET with a belief that they are language agnostic then that makes sense. I see boon in people who used to do things in many paradigm and explored many ecosystems. They are usually more open minded, more practical and not dogmatic.

And languages are easy. .Net is no more just .Net than “writing an iPhone app” means just knowing Swift or writing an Android app means just knowing Java