>You might be looking for a <..> specialist but you don’t want to attract people who are only interested in particular languages. Because that person’s narrow focus will hinder their growth.
Exactly what I have been witness to was this taken to the test. Result:
* You hire devs who do not like (or worse: hate) working in the language of the shop. They scold at the application they have to maintain and run, they do not contribute libraries or fixes, and topic number 0 at all larger meetings is "how we should rewrite everything in TypeScript/Go/Kotlin/whatever-tech-the-freshly-hired-senior-person-likes-best"
* You hire devs who do not care about the ecosystem. When the time comes to fix an external dependency which is not up to snuff, they will be saying things like "well if this app was written in $my_favourite_lang instead, this would have been so much easier"
* You create an infighting culture between people who do like to work with the current setup and people who want to destroy it and replace it with their favourite setup, be it for language preference or for "getting promoted" reasons
Briefly: no, I think it is absolutely imperative - especially at a company which is not polyglot - that even if it is not a requirement to be super-proficient in the main tech at the shop, it must be a requirement - and not a soft requirement - that the eng. be prepared to work, explore and develop in that tech. If this requirement is not present or not met, you are setting up your company for turf wars potentially for years to come.
That is exactly the point the article is making though: Do not hire devs that are only happy working in a specific language.
I would add that it cuts both ways: Having developers that are too married to the current tech stack can also cause problems. Sometimes things do need to be rewritten. Sometimes adopting a new tech into the stack can be the right choice and offer competitive advantages. Devs with different backgrounds bring fresh ideas and can help you get out of an local optimum and towards a better global optimum for your goals.
What I am getting at is if you don't hire devs _specifically_ who are happy working in your stack you are setting your team up for trouble. What was "I am more familiar with X" during an interview might as well turn into "We should rewrite in X" on the job, and I do feel like this situation should be explicitly filtered against in the hiring pipeline.
But then again, I am biased by having experienced the negatives of the situation.
Announcing some position as "we want software developers with $qualifications to work mainly on our PHP backend" is completely different from "we want software developers with 5 years of experience with PHP".
Also, you don't promote people for non-valuable rewriting of stuff.
> Also, you don't promote people for non-valuable rewriting of stuff.
You do once it is organizationally perceived as "modernization". Speaking from experience as I been on both ends of this (getting promoted for rewrites which in retrospect were ego-driven as well as seeing others getting promoted even though nobody asked for their rewrite)
I like the suggestion of having an explicit hard requirement that employees be willing to use and engage with the existing tech stack. It makes it easier to point to the requirements and say “you signed up for this”.
I’m surprised, perhaps naively so, that devs apply for roles featuring languages they actively don’t like (or even hate).
What’s more understandable is a dev picking up a new language/tech stack on a job and discovering they don’t like it. (In that case they still shouldn’t actively fight against it, unless it’s actually detrimental to the company’s progress.)
> devs apply for roles featuring languages they actively don’t like
Then that's their problem, not the employer's fault. If you know what stack is being used when applying for a job, and you despise said development stack, then why apply for the job?
But there are other developers out there who aren't that fussed about what development stack they might be working with. Often there are other attractions to the role such as compensation, paid time off, etc.
> What’s more understandable is a dev picking up a new language/tech stack on a job and discovering they don’t like it.
This happened to me once, but I held my nose and just got on with the job.
Opportunism perhaps? "...once they fire all these annoying legacy senior people we can redo everything..." As well as going down in the level of the joint (going from an A-league startup to a B-league startup) in the hope of more authority and ability to determine the choice of tech?
A technical recruiter, having discovered that that the ways of Unix hackers were strange to him, sought an audience with Master Foo to learn more about the Way. Master Foo met the recruiter in the HR offices of a large firm.
The recruiter said, “I have observed that Unix hackers scowl or become annoyed when I ask them how many years of experience they have in a new programming language. Why is this so?”
Master Foo stood, and began to pace across the office floor. The recruiter was puzzled, and asked “What are you doing?”
“I am learning to walk,” replied Master Foo.
“I saw you walk through that door” the recruiter exclaimed, “and you are not stumbling over your own feet. Obviously you already know how to walk.”
“Yes, but this floor is new to me.” replied Master Foo.
Elixir, Haskell et al. require concepts that are not required at all in e.g. Java. The functional programming module at my university had the highest failure rate after the math and statistics classes.
Even something like C can require new concepts. I was a tutor for a university C programming course and students that had no problems with Java struggled hard with direct memory manipulation, pointer arithmetic etc., because those were foreign concepts at that point.
You can't expect Devs to self-teach each other those concepts on the side, that (advanced into their studies, third-year) CS students struggle with hard. If you want your OOP Devs to learn e.g. functional programing, you have to give them dedicated (paid) time for this, IMO.
I'm currently in the process of interviewing and hiring for a dev to work on an Elixir code base and I barely care at all whether or not a candidate has ever used it before.
Last year I worked with an (excellent) ex-Bridgewater dev whose experience was mostly JVM and JS and he ramped up on Elixir and Phoenix very quickly. We pair programmed a couple of hours a day and he was productive in a few days and over 90% of the way there in terms of picking up needed frameworks, libraries, etc in a month. Learning lower-level concepts with C/C++/Rust is a bigger challenge, but still not that big if someone is using it all day at work.
I'd be very concerned about devs who can't self-teach, regardless of whether or not they have a CS credential. That said, I do believe in mentorship on the job and some slack during paid hours for people to learn and improve.
In many ways, learning is the job of a software engineer.
For the project last year, it wasn't a bunch. It was just me and the ex-Bridgewater guy who was learning.
Also, I taught myself back in 2017 while working on my own startup. Even back then, the docs were good and there were lots of helpful people on the internet.
You're very fortunate to have the opportunity to learn "on the clock" then. Most developers are lucky if they can block out a week to learn something that isn't directly connected to "a feature".
A working dev should be well beyond the understanding of a third-year CS student. This is not "advanced" from the perspective of someone in practice, it is the requirement to get in to the practice.
(I know people get programming jobs without CS degrees, but if you can do that, you can teach yourself how pointers work)
I am in a similar situation having a lot of working experience but only in a specific domain (web), and no formal CS education.
I only used pointers in one specific context, while working for about 3 months on a Go codebase. I was able to get my code working without too much trouble, but pointers were a source of some headscratching for me out of ignorance and tbh I didn't work there long enough to fully learn or internalize it... I vaguely remember adding a * or & here or there to make things work.
I've been interested in some kind of class or learning reference for some of the more "CS" topics that I don't use but would still be nice to learn. I started an OSSU course or two but haven't made much progress since I get bored when they go over some fundamentals that I already feel confident on.
I'm familiar with C/C++ and how pointers work, but that part of my mental knowledge never comes into play when I write python code, whether Django or not. And I've written substantial code in these two environments, they don't really intersect.
I mean, maybe once in a couple years you'd run into some weird problem that requires deep knowledge to solve, but "severely limits" might be a bit of an overstatement. (And might be some form of unwarranted gatekeeping IMHO.)
Everyone has limits/gaps in their knowledge, while C and pointers are part of the standard curriculum for CS degrees, not everyone has to be such cookie cutter devs (as long as they do their job and their employers are happy)
When the OP said they "have no idea how pointers work", I took that to mean they don't know know anything about how memory works. Why does does copying this array, not copy the contents of the array. Why does accessing a random value in a linked list take so much longer than accessing a random value in array. What happens when I reassign a local variable.
Developing an underlying mental model of what's actually happening is so much more effective than treating a programming language like a black box.
As far as "severely limits", there are many jobs where you could spend your entire wiring together libraries and asking more senior developers for help when you run into edge cases. But if you want to be one of those people who gets called in to help, you need a basic understanding of memory indirection. You don't need to understand pointer syntax in any specific language, but you need to have some understanding of what happens when you type x = [1,2,3].
At many tech companies, I doubt you could even make it passed the interview without a basic understanding of what a pointer is.
What sort of problems would you need to be doing in Python that aren't already done by libraries like NumPy which would require that sort of mental model?
The only thing that comes to mind would be memory leaks in long running applications caused by your data structures having some link to a link to a link that prevents temporary data from being garbagecollected.
I expect you're much closer to understanding pointers than you think. If you know the difference between a deep copy and a shallow copy then you understand the principle.
If you struggle with pointers and direct memory manipulation in C, you didn't understand Java nearly as well as you thought you did.
There's a distinction between reference and pointer in C++, but in Java they're basically the same thing with roughly the same semantics, up to and including the ability to be null.
In mathematics first year students who have started specializing already have knowledge that PhDs in other mathematical specializations don't. CS is exactly the same.
You can't teach Joy to someone who has only programmed in JS any more than you can do the reverse. The difference is that we have a lot of people who have learned only algol derivatives and don't understand just how _weird_ the zoo of non-standard languages is.
Right, "advanced" into their studies, they weren't freshman but almost done with their bachelors degree.
And yeah, I believe that most developers can learn pointers and FP, sure, but on the side with pair programming and "mob programming", while still working a full time dev job?
Depends on the company. Where I work, the answer is yes. Work/life balance is heavily stressed, which has been a surprise. However, when I started my career, it was with the expectation that staying up to date with technology would require some personal time. I don't personally know anyone that didn't start a technical career without that expectation.
I respectfully disagree. I think CS students struggle with this because they have a general lack of experience rather than a specific lack. I've found that I pick up "new" concepts like functional programming easier now than in college. I chalk this up to being able to link like concepts in the brain as you learn and are exposed to more post-college. New concepts aren't usually completely novel or original. Chances are it's going to be based on something to which I've been at least tangentially exposed to in my career.
Eh, I respectfully disagree to your disrespectful disagreement. Things are just different, there is no way around that.
Citing past experience is cheating, if you had already encountered X before to the point that learning it in detail is a negligible cost to you, then you're not truly unfamiliar with X, you amortized (part of) the cost of its learning over the past encounters.
There is no way, and I mean no way, a e.g Java programmer is going to be productive in a Haskell without a 3/6/9-month (depending on how much learning is "productive") learning phase where they are, most of the time, a "read only contributer". Java and Haskell are just too different computing machines entirely. Bad practices here are good practices there, good practices here are bad practices there, how I can describe it? It's literally programming a different abstract machine, they both eventually compile down to electrons but the journeys they take are vastly different.
I think the post title must contain an implied "And be prepared to mentor them while they are being unproductive". In the jumpy 3-years-at-most-per-job world of most tech jobs, that's unacceptable for employers unless they're really desperate.
Eh, I wouldn’t necessarily correlate university students’ behaviors with those of even a mid-level dev. Their knowledge bases and even opinions and goals are entirely different.
I was certainly a much worse developer in university, and since leaving my desire to self-learn has increased tremendously.
That said, I definitely agree on paid time to learn, I think that’s a core concept that a lot of places lack. And not just for new hires where onboarding is costed in, ongoing learning that is encouraged and paid for is key.
I have just spent most of the past year learning F# as my first real functional language. All in my own time. It took a lot of my own time. I've purchased many books and sunk many hours.
Aren't you kind of paying them to learn directly by doing language agnostic hiring? More that you can't expect them to be productive quickly, but that goes for any hire right?
If you only know java are you even a real (professional) dev?
I'd expect any dev wanting a job using a language he doesn't know to have some understanding all of the concepts you're talking about. It's not language specific, it's just the basics of programming.
"You don't have to know languages in order to be familiar with the concepts."
If you only ever coded in a language that doesn't even offer you the ability to tinker with some concepts, you can't be familiar with those. Reading one article about it without ever touching code, is not being familiar with a programming concept.
I'm not saying you should know 10 languages, but if you want to be anything more than a frontend dev or a bad web dev, you need to be exposed to more than 1 language IMHO. I'm not saying you should be an expert, or used multiples languages for years, but at least trying other languages with concepts not available in your favorite language.
>If you only ever coded in a language that doesn't even offer you the ability to tinker with some concepts, you can't be familiar with those. Reading one article about it without ever touching code, is not being familiar with a programming concept.
I disagree, you're familiar by definition.
You're just not experienced and may be not aware of pros and cons unless the article/book/w.e showed them.
Whether experience is important is up to the thing you're talking about.
For example: stealing Result<T> from other language to replace exceptions in your language doesn't require you to use Result<T> impl. in other lang.
> If you only know java are you even a real (professional) dev?
I'm a polyglot but Java is the language I used the most and I can guarantee you there are many professional dev I met and worked with that only know Java and make their comfy living writing only Java. Java is powering the real world since more than two decades now and the JVM is some rock solid tech with extensive tooling, so they can get away with only knowing Java.
A dev can definitely focus only on Java and, for better or worse, makes all his career, from his first job until retirement (to me it's obvious Java is here to stay and it's going to dwarf COBOL's legacy), writing only Java.
Why on earth would somebody earning their pay by providing value and doing the job they were hired for be a fraud?
Not all programming jobs require a PhD in computer science. There's plenty of people out there writing line-of-business software, and that's the stuff that makes the world work.
That sort of argument is just silly. Do you have a job you get paid for, where the primary output expected from you is code? Congrats, you're a professional dev.
I'm inclined to agree with you. A JVM-based developer with no idea of Scala or at least Kotlin raises questions. But in the last year I have worked with at least one smart guy/productive developer who is not into either. So YMMV I guess..
Sorry, I formulated this a bit unclear, advanced in the "advanced into their studies" sense. Not freshmen. (Thus, "advanced, third-year")
I don't think Devs are lower on some kind of "hierarchy level" than CS students. But they have less time.
That is all. The article wants devs to learn completly new CS concepts without also saying that they need payed time to do so, as they otherwise have to learn in their free time for their job.
I think a key skill to evaluate is the "learning how to learn". Can a developer pick up a new language and are they flexible enough to get their head around a different concept.
I agree that we need to support learning - knowledge can be acquired, but the willingness to go outside your comfort zone is something that is a bit more innate.
We've descended into this clickbait driven world of absolutes, when the reality are shades of grey.
Language agnostic folks are great (awesome) for being able to contribute in multiple places. There's a cost to pay, but one that's well worth it IMHO, in many cases. To be honest, this is my preference, as someone who hires a lot of these folks. It also changes the approach to team building - for the better, in my opinion.
But there are also many cases where this doesn't work. Not infrequently, you're looking for someone who has in depth experience in X domain, or Y ecosystem. This too has its place - and is driven by real business need.
But I won't pretend that someone with zero experience doing natural language development (yup, still a thing) can be effective. Some back end people will never grok front-end, and vice versa.
So, hiring is grey - intentionally, because it's situational.
The article’s argument is to be language-agnostic, not domain-agnostic.
For example, for a Django web app, would you hire someone who
* doesn’t know python but has done full stack web development in another framework (eg rails, express, .NET, etc)
Or
* knows python really well but has never built a web app
I’d rather hire the web developer in that case. A new language isn’t too hard to pick up compared to learning all about how web apps are constructed.
In your example, NLP is a domain, like web programming. Domain expertise takes much longer to develop than picking up another language in the same domain.
Was wondering where this comment was. Yep yep yep. He's a very good salesperson (which is not a negative!) but definitely not worth listening to as a developer.
For most of the popular languages used throughout business this is somewhat true, they have quite similar designs and goals and a team can get by with one person who really knows the language and its ecosystem. There is still years of experience in a language, its packages and tooling (especially in certain languages) that is hard to get any other way so I don't think its simple.
But I also think there are languages that different enough that there is more bending of the brain to do and the fundamentals of how you approach programming change and so that broad base has to include a broad church of languages. Its not enough to learn C#, Java, Python and Ruby because they are all pretty similar in fundamental style, Haskell is going to be a big shift as is Rust, but Go is going to be easy. What languages you come from is going to matter, a team using lisp for a decent sized project is going to be a tough entry for anyone new as they will have developed their own language within it and each concept must be learnt painstakingly with experience and time.
I am just not convinced that language knowledge is irrelevant, certainly throughout my career its been important and I have regularly been able to solve problems others could not because I knew something existed which while obscure has its uses. I don't think its all that quick to learn the languages APIs completely let alone all the primary open source packages and further still open source tooling both quickly and properly. There is a real chance you get stuck at advanced beginner with surface knowledge of everything to do with a language if you don't realise it goes deeper.
Agree, but also not every language is equal in that regard. Switching from writing perf-oriented C# code to Rust is fairly easy - concepts like async/await, stack/heap, ref/references, iterators, expression trees and generic constraints - all of them translate well. Switching from Python or Ruby to C# or Java however - not so much. The more languages have common concepts between them, the better. Migrating from a more powerful language is usually, if frustrating, much easier than the other way around.
All other things being equal, I’d rather hire someone who knows four languages that we don’t use, over someone who knows only one language that happens to be the one we use. Selecting for adaptability and breadth is a better predictor of success IMO. Among other benefits.
> I’d rather hire someone who knows four languages that we don’t use, over someone who knows only one language that happens to be the one we use.
The more programming languages one knows well, the more opinionated one typically becomes because one has seen a lot of different approaches to programming. The strong opinions that the respective programmer has are not necessarily identical to the company's desired approach to programming.
Yeah, but at a certain point of that journey people start getting less opinionated and more pragmatic again. At least that is how it worked for me.
Though yeah I only list languages that are relevant to the specific job when I apply. Sometimes one exotic conversation starter though that hasn't yet worked out.
Kind of ironic that I have too hide some of my programming knowledge because a broad understanding of many languages could allow me to add some really great value to the right company. Hiring prefers narrow-minded specialist though so I will play that part.
Agreed though personally for me I didn’t see great results until close to 8 languages used professionally. Once I knew about 5 of them I had a much easier time landing jobs despite being bad at whiteboarding.
edit: what I mean to really say here is that pragmatism, like any learning, doesn't just happen automatically. You can have a lot of languages under your belt but still only believe in one. You won't necessarily have it with more languages, but you're unlikely to have it if you know just one.
This makes some sense to me conceptually but the reality of the situation nowadays is that a lot of devs change jobs every 2 years. So say you hire someone who is not familiar with the ecosystem, you train them for 2 years and then they leave?
also it's not just about the language. Some ecosystems like iOS and Android are huge. These are not just some backend languages calling APIs these are gigantic sdks that take years and years to master
My former CEO invested significantly in training (I personally received well over $250k worth, including leadership lessons from 2 weeks reliving D Day with military men, rowing with National champion coaches at Yale, etc.) and used to say people challenged him with « what of you spend all this money to train them and they leave? », to which he replied « what if we don’t train and develop them and they stay, isn’t that way worse? »
It's the salary bump. Devs are being treated like customers for car insurance (in the UK). When a customer signs up they get a good deal, then as they remain loyal the deal slowly gets worse. People who change every year or two do the best.
I've heard that this is now changing. Whatever reason the insurance companies have stumbled upon to make this change needs to be communicator to those hiring devs.
This varies from language to language, and from role to role.
If I'm hiring for someone mostly working with Go, I'm not going to be that bothered if they only have experience with e.g. Java, Ruby, and some Typescript. It's a language that's almost explicitly designed to be easy to pick up and work with, and I'd be confident that a developer with a few years of experience would be able to become productive pretty quickly.
If it's about working with C++, that's probably different. In my experience, there's so much hidden knowledge in there that engineers with no previous contact are really going to struggle. I've found it's better in that situation to allow developers from other teams to explore and contribute to the codebase and learn from others as they develop their skills.
Similarly I'm unlikely to hire a frontend with no previous frontend experience, regardless of language – but if you were previously working on games and now want to do robotics, there is probably enough overlap to get started.
In a perfect world, you'll always hire great generalists who can turn their hand at anything and have enough time to onboard them. In reality though, you're going to have different 'holes' in your team shape at various times that will drive who's a potential fit as a hire.
And conversely, you're going to find different candidates in your search — if your codebase is primarily in Java, would you really turn down a strong Java dev, holding out for someone just as good but who's also willing to work on UI code and learn Haskell (even if you've no plans to use it)?
A good chef can probably train to become competent in any station in the kitchen and can train to become competent in any cuisine. But if your head pastry chef in a classic French restaurant leaves suddenly, you're unlikely to replace her with someone who's spent the last 10 years making sushi but says "I have never made mille feuille before but it looks like a good fit here so I will learn it".
A generalist would be someone who is fluent in C, Python, Java, JavaScript and probably Haskell/Clojure/Scala. This would mean that they have been exposed to static and dynamic typing, manual and GC memory management, class-based and prototype-based OOP, and all the important functional programming concepts.
“Fluent” is a strong word. Developers are rarely “fluent” in one language let alone 5.
“Had exposure to” IMO is more accurate here. You don’t need someone who has mastered each and every language in and out. IMO you don’t even need someone to have experienced all of them to be called a generalist.
It’s more about the way they frame a problem and come up with the solution and their ability to pick up key concepts quickly. The specific experience is key to long-term success but that can be taught to someone that is open and eager to learn.
I guess it depends on what you mean by generalist who's fluent in all of those things — is it someone who has broad rather than deep experience, someone who has both broad _and_ deep experience, or someone who's willing to pick up whatever needs to be done and learn where they have gaps.
I think you're describing #2 and the article is describing #3.
Yes and no. The thing is, it's not just the syntactic features of the language. The features of a language (type system, memory and resource management, scoping rules, concurrency model) deeply affect the kind of programming style one adopts. The tooling and the library ecosystem require a considerable time investment, too.
Hiring for "$LANG engineers" happens not because it makes sense, but only because it gives non-technical recruiters something to filter for. This is one of the reasons why recruiters should not be filtering candidates.
If you only know one language you're a technician, not a programmer. If you only know one paradigm of languages you're a technician, not a programmer.
If that sounds harsh to you or you have some sort of negative emotional reaction to that then you're way too personally invested and should probably go have some tea or a little lie down.
There's nothing wrong with being a technician. It's a useful and valuable role.
The confusion between programmers and technicians, though, leads to a lot of wasted time and effort. If you hire a technician when you really need a programmer you're gonna have a bad time. If you hire a programmer when all you really need is a technician they will eventually leave (if you're lucky the technicians you hire to replace them will be able to understand what they wrote.)
Because of all the confusion, it's possible to hire young and inexperienced programmers and pay them and treat them like technicians, but it can be tricky to differentiate them. (The big FAANG outfits just hire everybody and only promote the programmers, but you probably can't afford to do that.)
I agree to an extent. A good software engineer should understand the fundamentals and be able to adapt to most environments. Unless... your team is doing something very unusual.
I like to think of it as a professional sports team (let's say basketball). If you have a chance to sign a skilled player who is an all-star, 7 feet tall, and can hit 3 pointers you sign him and it will probably work out!
In a football team, if you sign a fantastic player and you place them in a position where they can't thrive, they will leave after a counterproductive year. There are plenty of historical examples of it... Just imagine Neymar playing as a center back ;)
The same happens if you hire a C developer for a Node.js gig, game developer for writing a mobile app, or someone who's been building React design systems all their life to help you with your deep learning stack.
This whole article is assuming that smart people can and want to learn anything, which can be true, but for most of cases, it isn't.
Yeah good point! Some sports teams are more specialized than others! I love the analogy because you're absolutely correct. Some software teams are much more specialized and closer to football than basketball.
You can also see it in basketball where even though the positions are less specialized than football, you sometimes have a coach who demands things run a certain system (Phil Jackson's triangle offense is a good example). Sometimes a great player just can't be effective in that system.
But take a coach who is more flexible, and they could make it work.
But which is better?? It's hard to say since there are great arguments on both sides. I think it basically comes down to having the right coach with the right team at the right time.
I would probably hire game developers for basically any role. The nature of the industry causes a large portion game devs to be deeply familiar with many more broadly applicable areas of specialization than is normal, able to produce several times more working code per unit time than web companies will expect from anyone without "staff" or "fellow" in their title, dramatically less likely to ship things that make the user wait half a second constantly or have other forms of nightmarish UX, and used to working inhumane hours for vastly below market compensation. Wow.
>
This whole article is assuming that smart people can and want to learn anything, which can be true, but for most of cases, it isn't.
I consider it as quite plausible that smart people can and want to learn anything. The problem rather is that this does not imply that these people will like or prefer this newly learnt approach.
While the sentiment of the piece—versatility > specialization—can certainly make sense, I can’t help but feel like it’s just a rant idealizing the type of person who invests significantly more than their workday into their craft, which I haven’t at all found to be much of a predictor of ability or even attitude. I know some great software engineers who do a ton of programming outside of work, and I know some great ones who do none.
> I don't want the GUI guys. I don't want the database guys. I don't want the middleware guys.
I don’t want a team of just a "guys", regardless of its and their abilities. Huge omission in a piece ultimately purporting to promote diversity (of thought).
> language specialist AKA snob
Those are two different things. I consider myself a Python specialist because I greatly enjoy working with the Python ecosystem (which is significantly broader than just the language itself) and thus prefer it whenever it’s a reasonable choice, but have also used other ecosystems and continue to do so, partly to learn.
I hate requirements about experience with specific technologies a lot as I enjoy learning new things normally, not doing what I have already done thousand times before.
But what's missing from such rants are good hiring criteria. Leetcode performance? Verifiable successful projects? Being able to appear as a smart guy to team members? All of these are problematic in one way or another.
That's the happy case, yes. But now hiring is a competitive process, and you need criteria to compare candidates. Once you eliminate leetcode, and also eliminate biases related to candidate's class and background what you're left with? You'll have to compare how close their experiences are to the job they want. Still better than considering lack of experience with technology X a deal breaker of course
at one company I was passed off to another team because although I wrote a correct solution immediately to some nontrivial problem in their preferred language, C++, I wrote it in a C-like style instead of using their preferred subset of C++ features (probably this aligns pretty closely with what most people mean when they say "modern C++", which I admitted prior to the interview that I had basically never used because my C++ experience predated a lot of these features).
I think domain knowledge has been under-estimated in general. Which I think applies to tools too, such as programming languages. Knowing the affordances, the options, the libraries available, etc -- matters.
Developers aren't interchangeable widgets.
Sure, a really good engineer will be able to learn a new language. I don't actually disagree that it can make sense to hire developers who aren't yet expert in the language they are using, sometimes it does.
But a really good engineer learning a brand new language to them will still take a year or two until they approach the productivity and quality of decision-making of a really good engineer who was already well-experienced with the language. Will a really good engineer learning a brand new language be more productive than an inexperienced or poor engineer who has messed with the language for a year? Sure, ok.
General programming aptitude matters a lot; but experience with the tools they will be using matters too, it isn't irrelevant.
>learning a brand new language to them will still take a year or two until they approach the productivity and quality of decision-making
I don't agree unless we're talking about something like Rust or C++. Python, Java, and JavaScript are all very easy to pick up once you understand the concepts they share. I would expect any developer to at least know the basic syntax of Python for instance even if they don't write it daily.
To me, if somebody only knows one language but they're an expert in it, it indicates a lack of ambition, curiosity, and willingness to face new challenges which are desirable traits to look for when hiring. And unfortunately for such people there's polyglot experts out there that can be hired for the same price.
i would disagree, if someone is highly specialized in a language X then they are going to be very resistant to learning something new. And if they have to then it'd be a slow process. They would have to learn: language, frameworks, build tools, code base, industry concepts. Compare this to someone who is already familiar with tech stack: they would be only learning code base and industry concepts.
Is this really true? Maybe over the course of centuries, but in my lifetime I seriously doubt the major languages like C, Java, JavaScript, etc. are going to go away.
I've never seen a job ad that was just about the language. Usually there's a language a domain (i.e. AI, video, telecom), and several frameworks or applications. The language is the easy part. Frameworks and applications can be huge learning curves. Domain knowledge is really the hardest. Taking someone who's been doing database CRUD apps with Rails and React and expecting them to pick up writing video codecs in C++ is really where the reach is.
I have recently found that video codecs (and other forms of modern compression) are indeed difficult to casually pick up in one's spare time, but if a company is willing to dedicate even a modest amount of an existing team member's time to training new hires I would expect this to go fine.
The weird thing is that almost no company does this (or, within each company, almost no team does this, and individual team leads or engineers may rebel by doing this and then be punished when perf comes around)
I don't doubt C programmers' ability to understand or use webpack (it's tedious, annoying, and often hard to debug, but not conceptually difficult - definitely easier than day-to-day problems solved by C programmers), the question is this the best use of their time & the most cost efficient way to do it (and IMHO the answer for both is that it's clearly not). It looks like we directionally agree.
Exactly what I have been witness to was this taken to the test. Result:
* You hire devs who do not like (or worse: hate) working in the language of the shop. They scold at the application they have to maintain and run, they do not contribute libraries or fixes, and topic number 0 at all larger meetings is "how we should rewrite everything in TypeScript/Go/Kotlin/whatever-tech-the-freshly-hired-senior-person-likes-best"
* You hire devs who do not care about the ecosystem. When the time comes to fix an external dependency which is not up to snuff, they will be saying things like "well if this app was written in $my_favourite_lang instead, this would have been so much easier"
* You create an infighting culture between people who do like to work with the current setup and people who want to destroy it and replace it with their favourite setup, be it for language preference or for "getting promoted" reasons
Briefly: no, I think it is absolutely imperative - especially at a company which is not polyglot - that even if it is not a requirement to be super-proficient in the main tech at the shop, it must be a requirement - and not a soft requirement - that the eng. be prepared to work, explore and develop in that tech. If this requirement is not present or not met, you are setting up your company for turf wars potentially for years to come.