The case for language agnostic hiring
alphalist.com
alphalist.com
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.
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.
So it is all about balance.
But then again, I am biased by having experienced the negatives of the situation.
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’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.)
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?
This seems like a much weaker requirement than the sort of requirement the fine article argues against
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
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.
A key ingredient missing in the blog post, IMO. :)
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.
(I know people get programming jobs without CS degrees, but if you can do that, you can teach yourself how pointers work)
How quickly could you pick it up if you had to?
https://en.m.wikipedia.org/wiki/Pointer_(computer_programmin...
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.
Not having a decent mental model of what’s happening a few levels below severely limits the kinda of problems you can solve.
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)
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.
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.
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.
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?
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.
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.
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.
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.
lol, if I were java dev I'd be pissed off.
honestly this unsound argument that dev which knows more languages is better just because of that needs to die.
Concepts are above languages
You don't have to know languages in order to be familiar with the concepts.
Additionally certain languages do not offer real value to the other
For example I've been writing shitton of C# and from time to time I jumped to js/lua
Messing with those languages didnt gave me anything except pain.
Meanwhile one harder project can give you times, times more - try writing browser, compiler, etc.
__________
Software engineering is deeper and more important than fancy language features and handier ways to express things.
But yea, it's easier to mess with people about their lack of understanding of monad than
arguing about system design, practices & approaches to system modeling cuz they do require context :)
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.
Ive jumped from web/desktop dev
to semiconductor industry and worked with the same language.
And the biggest problem was lack of the domain knowledge, not langs.
You can find various langs being used in various places to the point that sometimes you'd be shocked
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.
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.
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.
You surely are, everyone who gets money for developing applications is.
FYI, functional programing and low-level programming isn't even a part of the curriculum in some universities, let alone bootcamps.
(Also, there are tons of languages that don't touch on functional programming concept at all.)
"Professional" means "paid to do it", so, yeah, there's plenty of professional Java developers.
Hum... Do you write programs in exchange for money?
You imply that Devs are lower on a hierarchy level than third-year CS students.
I think he implies that devs have less time to devote to new languages.
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.
Even if they didn't, a strong programmer will pick up them up in an afternoon. Ditect memory manipulation is just not that hard.
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.
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.
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.
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.
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.
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.
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
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.
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.
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".
“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 think you're describing #2 and the article is describing #3.
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 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!
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.
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 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.
> 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.
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.
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.
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 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.
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.
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)
Just to check again, that line is about webpack, right? Not C programs?