I have decades of experience hiring people, and what I find is this:
If I randomly select a programmer from all the programmers who write Clojure, working or not, interviewing or not, they are likely to be a “better” programmer than if I randomly select a programmer from all the programmers who write JavaScript, working or not, interviewing or not.
But of course, that’s not what happens when I interview. I meet one person in the morning with three years experience working on projects of types A, B, and C. In the afternoon I meet another with four years of experience working on projects of types B, C, and D.
If one has Clojure and the other JavaScript, I’m much more likely to be delighted to discuss Clojure than JavaScript, but as far as HIRE/NO HIRE is concened, the thing that matters to me are projects Of type A, B, C, or D, and the candidate’s role/contribution.
If the JavaScript programmer’s experience is solid, I do not want a recruiter in-house or otherwise trying to save me an interview and filtering them out.
The bottom line is, there are like 100x as many JS folks as CJ folks. So let’s say there are 100 great CJ people out of 1,000 CJ people. 10% ham!
But that means there are 100,000 JS people. If even 1% of them are great, that means that there are 1,000 great JS people out there, and I do not want to pass on meeting any of them just because there are also 99,000 not-so-great JS people out there.
In my imaginary distribution, a random CJ person is 10x more likely to be good. But there are 10x as many good JS people as CJ people, and my experience is that THEIR experience is a far better signal than their programming language.
—-
p.s. I am competing with people who only want to hire programmers with shiny signals like ClojureScript or the ability to quote “JavaScript Allongé.” Good! Let them ignore the 1,000 good JS people, easier for me to interview them and make a successful offer.
Now that I think about it, please ignore what I just said. Only interview people who build systems out of Lisp, Prolog, and Maleboge.
We're currently interviewing for positions which I haven't done in a while. There are many more developers and even more completion for them. The number of resumes read and interviews conducted for a Sr. position has gone up. I have found selecting candidates with more diverse exposure/interests greatly increases the s/n ratio and gladly do this knowing I'm missing some. It's just more effective in terms of time taken out of team capacity to do interviews.
I have 0 years hiring people, my experience is this. The language(s) you write code in don't mean a thing. It's the ecosystem. I'm a JS programmer, but that is not why you should hire me, it's my experience with the DOM, HTTP, indexeddb, File API, documentFragment, Fetch API, TreeWalker, NPM, WebGL, interactive SVG, the pros and cons of React, when to use Redux, Basic login, NGINX, Docker, etc, etc, etc. My point is this: knowledge of Closure(Script) is a great tool in any programmers tool belt, but it is definitely not the most important one for a solid frontend engineer.
Knowledge of APIs is not a good indicator of ability in my experience (I have many years of hiring people). So, the 'ecosystem' isn't particularly interesting and neither are the devs that just put endless lists of acronyms on their CVs. It's much more useful to listen to a dev tell you how they solved various problems, dig into their CS knowledge, see what they like working on in their spare time (code or not code related).
It's hard to avoid touching the DOM, HTTP, NPM, React, NGINX, Docker, etc. on a daily basis if you're doing any kind of serious work; it's not just some disjoint list of obscure buzzwords.
There's one thing: Hypercard and DigiTalk represent directions personal computing should have gone, but didn't (although that's not relevant to the thread topic)
It's not so much that someone has touched <acronym soup> rather the kind of people that think just listing all that out is useful, are typically not the developers I want.
Ok, the list is distracting. I mean, experience with web dev's ecosystem is more important than the languages you can write code in. Of course a list on it's own is useless, it should be supported with actual projects (hopefully some in production).
If I randomly select a programmer from all the programmers who write Clojure, working or not, interviewing or not, they are likely to be a “better” programmer than if I randomly select a programmer from all the programmers who write JavaScript, working or not, interviewing or not.
But of course, that’s not what happens when I interview. I meet one person in the morning with three years experience working on projects of types A, B, and C. In the afternoon I meet another with four years of experience working on projects of types B, C, and D.
If one has Clojure and the other JavaScript, I’m much more likely to be delighted to discuss Clojure than JavaScript, but as far as HIRE/NO HIRE is concened, the thing that matters to me are projects Of type A, B, C, or D, and the candidate’s role/contribution.
If the JavaScript programmer’s experience is solid, I do not want a recruiter in-house or otherwise trying to save me an interview and filtering them out.
The bottom line is, there are like 100x as many JS folks as CJ folks. So let’s say there are 100 great CJ people out of 1,000 CJ people. 10% ham!
But that means there are 100,000 JS people. If even 1% of them are great, that means that there are 1,000 great JS people out there, and I do not want to pass on meeting any of them just because there are also 99,000 not-so-great JS people out there.
In my imaginary distribution, a random CJ person is 10x more likely to be good. But there are 10x as many good JS people as CJ people, and my experience is that THEIR experience is a far better signal than their programming language.
—-
p.s. I am competing with people who only want to hire programmers with shiny signals like ClojureScript or the ability to quote “JavaScript Allongé.” Good! Let them ignore the 1,000 good JS people, easier for me to interview them and make a successful offer.
Now that I think about it, please ignore what I just said. Only interview people who build systems out of Lisp, Prolog, and Maleboge.