11 ms·

The case for language agnostic hiring

77 points by datanerd613 4y ago

PaulKeeble 4y ago
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.
- neonsunset 4y ago
  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.
bluetomcat 4y ago
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.
jdmoreira 4y ago
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
- dontlaugh 4y ago
  Perhaps if workers were treated and paid better, they'd have less incentive to leave every two years.
  - brigandish 4y ago
    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.
    - hwntw 4y ago
      The FCA (one of the financial regulators) stepped in for the insurance market, which is why that change has started being made.
  - mguerville 4y ago
    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? »
celdon25 4y ago
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.
- q-big 4y ago
  > 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.
  - cardanome 4y ago
    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.
    - celdon25 4y ago
      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.
schroeding 4y ago
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.
- fileeditview 4y ago
  Seems like generally good policy to give (paid) time to them if you expect them to learn something new.
- mynameisvlad 4y ago
  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.
- salty_biscuits 4y ago
  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?
  - treeman79 4y ago
    There is a pool of people that can invite calculus on their own. Another for those that can learn it on their own. Another for those that can learn it in a multi year schooling system. Limiting yourself to hiring from the smallest possible sets is challenging.
another-dave 4y ago
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".
- bluetomcat 4y ago
  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.
  - mynameisvlad 4y ago
    “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.
  - another-dave 4y ago
    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.
roland35 4y ago
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!
- gpjanik 4y ago
  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.
  - q-big 4y ago
    > 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.
  - anonymoushn 4y ago
    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.
  - 4y ago
BerislavLopac 4y ago
When a company I'm interviewing for a role at is quoting Uncle Bob, that is a huge red flag for me.
- grenoire 4y ago
  What exactly does that signal to you?
  - petesergeant 4y ago
    dogmatism over pragmatism
  - wiseowise 4y ago
    Incompetence. https://qntm.org/clean https://qntm.org/clean
  - BerislavLopac 4y ago
    Essentially, that they have no idea what they're asking, while making a big effort to appear like they do.
- phillipcarter 4y ago
  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.
matthewmacleod 4y ago
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. TLDR one size does not fit all.
oytis 4y ago
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.
- julik 4y ago
  How about "you have some knowledge of stack X and you are committed to learn that particular stack and finding joy in using it"?
  - oytis 4y ago
    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
    - anonymoushn 4y ago
      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).
julik 4y ago
>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.
- matt_craig 4y ago
  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.)
  - julik 4y ago
    This.
  - teh_klev 4y ago
gpjanik 4y ago
Can't wait to hire that C developer to sort out my webpack config.
- oytis 4y ago
  I am a C developer and would probably be able to do that, but definitely not something I enjoy (so you won't be able to hire me :) )
  - gpjanik 4y ago
    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.
    - wiseowise 4y ago
      They interview for your company already, so they know what type of job you do. Unless they’re idiot.
    - marcosdumay 4y ago
      > it's tedious, annoying, and often hard to debug, but not conceptually difficult Just to check again, that line is about webpack, right? Not C programs?
ottoflux 4y ago
100% i always have pushed to hire based on how the developer approaches problems and thinks about logic. the hype around memorizing referenceable facts about a specific language/stack has always been overblown. i’ll take a hacker who learns and digs in quickly over a recalcitrant developer stuck in their ways any day.
yakshaving_jgt 4y ago
"You should focus on hiring good programmers who are able to think beyond just one language", says man who cannot think beyond dynamic typing and TDD.
thesuperbigfrog 4y ago
Master Foo and the Recruiter 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. Upon hearing this, the recruiter was enlightened. Source: http://www.catb.org/~esr/writings/unix-koans/recruiter.html http://www.catb.org/~esr/writings/unix-koans/recruiter.html
pyb 4y ago
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.
cik 4y ago
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.
- nilsbunger 4y ago
  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.
techsin101 4y ago
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.
irrational 4y ago
> Languages are ephemeral. They come and go. 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.
- indymike 4y ago
  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.
  - anonymoushn 4y ago
    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)
carapace 4y ago
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.)
nkantar 4y ago
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.
jrochkind1 4y ago
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.
- c7DJTLrn 4y ago
  >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.

77 points by datanerd613 4y ago

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.

neonsunset 4y ago
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.

bluetomcat 4y ago

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.

jdmoreira 4y ago

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

dontlaugh 4y ago
Perhaps if workers were treated and paid better, they'd have less incentive to leave every two years.
- brigandish 4y ago
  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.
  - hwntw 4y ago
    The FCA (one of the financial regulators) stepped in for the insurance market, which is why that change has started being made.
- mguerville 4y ago
  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? »

celdon25 4y ago

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.

q-big 4y ago
> 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.
- cardanome 4y ago
  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.
  - celdon25 4y ago
    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.

schroeding 4y ago

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.

fileeditview 4y ago
Seems like generally good policy to give (paid) time to them if you expect them to learn something new.
mynameisvlad 4y ago
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.
salty_biscuits 4y ago
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?
- treeman79 4y ago
  There is a pool of people that can invite calculus on their own. Another for those that can learn it on their own. Another for those that can learn it in a multi year schooling system. Limiting yourself to hiring from the smallest possible sets is challenging.

another-dave 4y ago

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".

bluetomcat 4y ago
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.
- mynameisvlad 4y ago
  “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.
- another-dave 4y ago
  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.

roland35 4y ago

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!

gpjanik 4y ago
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.
- q-big 4y ago
  > 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.
- anonymoushn 4y ago
  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.
- 4y ago

BerislavLopac 4y ago

When a company I'm interviewing for a role at is quoting Uncle Bob, that is a huge red flag for me.

grenoire 4y ago
What exactly does that signal to you?
- petesergeant 4y ago
  dogmatism over pragmatism
- wiseowise 4y ago
  Incompetence. https://qntm.org/clean https://qntm.org/clean
- BerislavLopac 4y ago
  Essentially, that they have no idea what they're asking, while making a big effort to appear like they do.
phillipcarter 4y ago
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.

matthewmacleod 4y ago

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. TLDR one size does not fit all.

oytis 4y ago

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.

julik 4y ago
How about "you have some knowledge of stack X and you are committed to learn that particular stack and finding joy in using it"?
- oytis 4y ago
  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
  - anonymoushn 4y ago
    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).

julik 4y ago

>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.

matt_craig 4y ago
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.)
- julik 4y ago
  This.
- teh_klev 4y ago

gpjanik 4y ago

Can't wait to hire that C developer to sort out my webpack config.

oytis 4y ago
I am a C developer and would probably be able to do that, but definitely not something I enjoy (so you won't be able to hire me :) )
- gpjanik 4y ago
  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.
  - wiseowise 4y ago
    They interview for your company already, so they know what type of job you do. Unless they’re idiot.
  - marcosdumay 4y ago
    > it's tedious, annoying, and often hard to debug, but not conceptually difficult Just to check again, that line is about webpack, right? Not C programs?

ottoflux 4y ago

100% i always have pushed to hire based on how the developer approaches problems and thinks about logic. the hype around memorizing referenceable facts about a specific language/stack has always been overblown. i’ll take a hacker who learns and digs in quickly over a recalcitrant developer stuck in their ways any day.

yakshaving_jgt 4y ago

"You should focus on hiring good programmers who are able to think beyond just one language", says man who cannot think beyond dynamic typing and TDD.

thesuperbigfrog 4y ago

Master Foo and the Recruiter 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. Upon hearing this, the recruiter was enlightened. Source: http://www.catb.org/~esr/writings/unix-koans/recruiter.html http://www.catb.org/~esr/writings/unix-koans/recruiter.html

pyb 4y ago

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.

cik 4y ago

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.

nilsbunger 4y ago
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.

techsin101 4y ago

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.

irrational 4y ago

> Languages are ephemeral. They come and go. 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.

indymike 4y ago
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.
- anonymoushn 4y ago
  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)

carapace 4y ago

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.)

nkantar 4y ago

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.

jrochkind1 4y ago

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.

c7DJTLrn 4y ago
>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.