7 ms·

As someone running a technical recruitment agency, I can assure you that it is true that someone having built stuff in Clojure is more likely to be considered a

As someone running a technical recruitment agency, I can assure you that it is true that someone having built stuff in Clojure is more likely to be considered as a good engineer than someone who did JQuery all the time. Recruiters use an intuitive approach to conditional probability. Given only the info alone (if someone did JQuery or Clojure) exposes you to two bell curves, with the X-axis being "programming ability". The first bell curve that has all JQuery people is more on "the left" and the one having all Clojurians is more on the right. The Clojure bell curve has shitty engineers and some really good people are part of the JQuery one. Prejudice is sort of rational. If a recruiter looks at one datapoint, it's unlikely that it is at the tails of the bell curve, so the Clojurian applicant will get more attention. If you are treated unfairly because of the group you "belong to", I am sorry - but this is reality.

throwawaymath 8y ago
> As someone running a technical recruitment agency, I can assure you that - statistically speaking - it is true that someone having built stuff in Clojure is more likely to be a good engineer than someone who did JQuery all the time. Would you care to share those statistics? While we're at it let's also be sure to define "good engineer."
- parrellel 8y ago
  He just said it was holistic.
  - throwawaymath 8y ago
    The commenter said "statistically speaking" to justify part of their point. I am directly challenging their assertion and requesting evidence that they have 1) actually quantified something in more than a hand wavey manner, and 2) found the (falsifiable) conclusion they stated, based on that analysis. I'm deeply skeptical. People like to throw around percentages and references to statistics to justify their biases, but I don't think the commenter has done nearly enough to motivate the conclusion that the modal Clojure developer is more likely to be a "good engineer" than the modal JavaScript developer.
    - sonnyblarney 8y ago
      Next time you have a blocked toilet, and the plumber says it's a problem with 'ABC' why don't you just tell him that's not quantifiable! and then tell him you think it's 'XYZ' that's the problem. If someone who interviews thousands of people and finds a correlation between those who have some clojure experience and quality, I believe him. For the simple reason that most programmers don't try very hard and anyone taking the time to even learn a rarely used language is demonstrating a positive quality that most don't.
      - throwawaymath 8y ago
        If the plumber can explain to me in coherent reasoning why the problem is likely with 'ABC', I'm not going to challenge it. Especially if they don't handwave about statistics they almost assuredly don't have and I have no domain experience in plumbing. That analogy doesn't work. I stand by my point: using words like "statistically" and "correlation" perpetuate biases which may not have a rational basis. In this entire thread no one has explained why Clojure programmers are more likely to be "good" than JavaScript programmers (nor has "good" been defined!). I could just as plausibly state that someone tried to learn Clojure because they perceive it to be a buzzword, just as JavaScript programmers are often accused of playing buzzword bingo with web development frameworks. Empirically speaking, we haven't ended up anywhere. No matter how sure you are of this phenomenon, unless you try to make its observation more robust, it will continue to be a microcosm of the tech hiring industry. Heuristics often belie subtle biases that do not actually have a foundation in truth.
      - gaius 8y ago
        most programmers don't try very hard and anyone taking the time to even learn a rarely used language is demonstrating a positive quality that most don't. Once known as the Python Paradox http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html Nowadays I suppose it would be the Clojure Conundrum or the Haskell Happenstance
- s3nnyy 8y ago
  Experience looking at thousands of CVs and talking to people who are behind the CVs.
  - throwawaymath 8y ago
    That's not a statistic, nor is it quantifiable. I'm not taking issue with your experience, I'm taking issue with the fact that you've implied your claim has quantitative rigor to it, because I'm extremely skeptical that's the case. For what it's worth, I'm challenging you as someone who is neither a JavaScript developer nor a Clojure developer. I'm of the opinion that biases like the one the author laments are perpetuated (in part) by this leaky arguments from "statistics" that never appear.
    - scarejunba 8y ago
      Don't get hung up on the language. People sometimes say "statistically speaking" to mean "Based on my experience over a large number of tests". It doesn't mean "I applied a test of statistical significance to arrive at my conclusion". You're then meant to combine their stated experience with their stated credentials and your assessment of their trustworthiness to arrive at some conclusion. This imprecision may annoy you but it is a common way of speaking English so it's probably not in your interest to fight over the choice of wording.
      - throwawaymath 8y ago
        Sure, I understand what you're saying. But I'll continue to challenge the use of language like that. In my opinion, saying something is true "statistically speaking" is more grievous than saying something like, "I'm 99% sure." Both are artifacts of the English language, but I think the former carries much more quantification behind it, implicitly speaking. In that sense it's not just about informal use of language. This is because saying something is true "statistically" is a claim made in both scientific and casual contexts. It's mentally taxing to figure out which context is in play - someone could have come into this thread with actual statistics and said the same phrase, verbatim. Therefore (as I see it), it's realistically plausible that someone could read the original comment and come away believing recruiters have done actual statistical analysis a la TripleByte to arrive at their conclusion.
machiavelli1024 8y ago
Yep. Funny that HackerNews seem to be unable to wrap their head around the fact that prejudice is just applied Bayesian statistics.
- MusaTheRedGuard 8y ago
  I'm gonna say prejudice is actually not applied Bayesian statistics
  - bastijn 8y ago
    and you would be right. Say I have a broken phone which is an Android. A prejudice would be that androids are likely to break. Mathematically we could represent as P(broken|android) =~ P(android|broken) We see from Bayes rule that this is false, since P(android) >> P(broken)
    - braythwayt 8y ago
      Even worse, what actually happens with prejudice is that if I think that Androids are shitty phones, when I see a broken Android, I add it to my collection of “Shitty Android” data points. But when my iPhone breaks, I take it into Apple for service and add it to my collection of “Apple gives great service” data points. Saying that prejudice is just applied statistics completely mischaracterizes prejudice.
  - mrexroad 8y ago
    I’d argue that prejudice and bias applies most all statistics, but most often we just don’t notice or care. E.g. The biases inherent to specific domain, of those who captured the data, those who selected the data, selection of statistical techniques, real-world outcomes reinforced by usage of these statistics, etc.
- dang 8y ago
  Please don't take HN threads on generic ideological tangents. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
raiflip 8y ago
That is definitely a good strategy for a recruiter. However the context of the author's experience seems to be how the author's coworkers treats them. If I'm working with someone and I get to see their code, or I can take a look if I'm curious, IMO it becomes a vice to use Bayesian probability when you can look at the person's actual code and judge their skill. A different way to put it is Bayesian probability is good in a situation of uncertainty, but if you are not in a situation of uncertainty it just becomes lazy/ prejudicial.
panic 8y ago
Presumably people are paying you to find good engineers, not just people who match particular profiles. If "rational prejudice" doesn't always find the good engineers, why justify it like this? Wouldn't it be better to take this as evidence that your approach could use improvement?
- darawk 8y ago
  No. You have limited resources to sift through people. Heuristics like this are an efficient way to reduce your search space. That is sort of the whole point of statistics.
  - deleted 8y ago
    [deleted]
- curun1r 8y ago
  > people are paying you to find good engineers No, they're paying them to find engineers that will pass the interview process. It's a subtle, but important distinction since prejudices that exist among engineers will naturally develop in recruiters. It's the recruiting equivalent of teaching to the test. And like it or not, the kind of signaling the article describes is real. When an engineer says they can write clojure, it indicates a curiosity that ability to program JavaScript does not. Almost no one is forced to learn Clojure because of some job, project or even job prospects. It means you likely cared enough to devote your own time to learning for the sake of learning. And a lot of engineers look at this kind of thing as important and screen for it in interviews. A recruiter operating any differently would be like a machine learning algorithm that ignores its training data.
  - gaius 8y ago
    It means you likely cared enough to devote your own time to learning for the sake of learning. And a lot of engineers look at this kind of thing as important and screen for it in interviews. The curious thing is, I think the number who regard it as important is likely far higher than the number who actually do it. Which is understandable; once you reach a level of seniority you also have many other demands on your time and may not be able to be a hobbyist anymore on top of day job, family commitments and so on. So maybe once you learnt every new language but now you don’t have the opportunity, or you have decided to “go deep” in just a few, established languages. So the power of the signal is highly variable depending both on where the interviewer and interviewee are in their lives. Also, knowing JS in the late-90s did indicate a curious and ambitious developer. It only went mainstream later...
ender7 8y ago
It's true that, based on my interviewing experience, candidates with only a jQuery background are unlikely to have the skills to cut it developing large-scale software at a large-scale company, which is what I am hiring for. At the moment I interview mostly front-end candidates, and it takes a lot of sifting to find qualified hires. However, the implicit companion assumption that a resume with lots of clojure experience will have those skills is not something I've seen any evidence for. Many Clojure-focused candidates are unproductively dogmatic and are at risk of wasting everyone's time by trying to rearchitect our codebase because it doesn't meet their particular taste. In general, if a candidate is an adherent to a niche programming language they need to be able to explain to me when its use would be appropriate and inappropriate. If their answer is "this language and/or dogma is always better" then you're adorable but you need some more experience before I'm going to hire you. It's also important to point out that, while my core requirements are the same for both jQuery and Clojurey candidates (ability to function in a large, complex codebase & ability to manage your own code's complexity), the specific skillsets are very different. Most clojure enthusiasts are actively bad front-end engineers. Which is fine! But many positions require engineers to at least be able to dabble in UI work, and if I get the sense that you would find it beneath you to do so, its probably going to mean better luck somewhere else unless I have a very specific position to fill.
- s3nnyy 8y ago
  Oh yes. Based on my experience hiring on behalf of different firms, arrogance among engineers correlates with the degree of mathy-ness of a stack.
- bm1362 8y ago
  This is my experience hiring Clojure engineers in a small startup- things became dogmatic and opinionated at a time when we were existentially challenged with building a product.
k__ 8y ago
I never talked to a recruiter with any technical expertise in my whole 12 year career.
- oblio 8y ago
  https://i.redd.it/bka1gb843z7z.jpg https://i.redd.it/bka1gb843z7z.jpg
  - lifeisstillgood 8y ago
    Funny, but presumably just selecting for recruiters with deep knowledge of pokemon, not programming languages.
    - minikomi 8y ago
      And you're assuming pokemon trainer abilities aren't congruous with tech recruiting.
  - k__ 8y ago
    It's really sad, because I get called by 2 of them a week :/ Their websites sound like they are the pinnacle of the industry, but on phone/email they sound like a bunch of HS dropouts :(
  - 1123581321 8y ago
    Which is krebase? Google seems to only return references to this image.
    - oblio 8y ago
      Beats me, not my image :)
21 8y ago
Now apply this logic to men in tech and woman in tech bell curves and see how that works out. Is it still rational?
- lifeisstillgood 8y ago
  Women in tech would presumably have the same signalling as Clojure users - greater probability of being competent ? Is that the point you were making?
- wellpast 8y ago
  Your question assumes that the programming talent bell curve for men and women are different, which I wouldn’t expect to be the case.
  - __blockcipher__ 8y ago
    Seems like an interesting assumption. I’m mot convinced there is a difference, but neither am I confident that there isn’t one.
    - troupe 8y ago
      If there was a difference, are you allowed to note it or will you get fired for it? Programming skill is hard to measure. Chess is an interesting area that is a bit easier to quantify.
    - wellpast 8y ago
      Yeah I have no instincts in this because my experience has always been so fewer women than men on the engineering team. So this is totally anecdotal. But the few women I’ve worked with have always been in the upper part of the talent scale, while there has been much variance among the men. I.e., I’ve encountered many low talent (and high talent) men but not one low talent woman. Maybe there are enough hurdles for women (even if the only hurdle is that there are so few _other_ women) that you kinda have to be interested & reasonably good at the job to stick around. If this is true the bell curves may be better for women applicants. However amy anecdotal experience could be simply wrong and it somehow is even or worse for women or something other like overlapping curves of different shapes.
braythwayt 8y ago
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.
- karmakaze 8y ago
  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.
- 8y ago
mlthoughts2018 8y ago
I think it’s pure hubris to say that anyone can distinguish overall skill at a statistically significant level between these different populations. Heck, I’d even say if you only look at the population of engineers who you have directly observed doing a good job on some interview trivia or code test, you still cannot reliably conclude that draws from that population are statistically significantly more likely to be acceptably good at a job once hired than draws from a different population. People and processes capable of detecting skilled engineers are extremely rare. Skilled engineers are also somewhat rare. What we set up as tech hiring processes are mostly just crap-shoot just-so stories we tell ourselves, mixed with a ton of hubris.

throwawaymath 8y ago

> As someone running a technical recruitment agency, I can assure you that - statistically speaking - it is true that someone having built stuff in Clojure is more likely to be a good engineer than someone who did JQuery all the time. Would you care to share those statistics? While we're at it let's also be sure to define "good engineer."

parrellel 8y ago
He just said it was holistic.
- throwawaymath 8y ago
  The commenter said "statistically speaking" to justify part of their point. I am directly challenging their assertion and requesting evidence that they have 1) actually quantified something in more than a hand wavey manner, and 2) found the (falsifiable) conclusion they stated, based on that analysis. I'm deeply skeptical. People like to throw around percentages and references to statistics to justify their biases, but I don't think the commenter has done nearly enough to motivate the conclusion that the modal Clojure developer is more likely to be a "good engineer" than the modal JavaScript developer.
  - sonnyblarney 8y ago
    Next time you have a blocked toilet, and the plumber says it's a problem with 'ABC' why don't you just tell him that's not quantifiable! and then tell him you think it's 'XYZ' that's the problem. If someone who interviews thousands of people and finds a correlation between those who have some clojure experience and quality, I believe him. For the simple reason that most programmers don't try very hard and anyone taking the time to even learn a rarely used language is demonstrating a positive quality that most don't.
    - throwawaymath 8y ago
      If the plumber can explain to me in coherent reasoning why the problem is likely with 'ABC', I'm not going to challenge it. Especially if they don't handwave about statistics they almost assuredly don't have and I have no domain experience in plumbing. That analogy doesn't work. I stand by my point: using words like "statistically" and "correlation" perpetuate biases which may not have a rational basis. In this entire thread no one has explained why Clojure programmers are more likely to be "good" than JavaScript programmers (nor has "good" been defined!). I could just as plausibly state that someone tried to learn Clojure because they perceive it to be a buzzword, just as JavaScript programmers are often accused of playing buzzword bingo with web development frameworks. Empirically speaking, we haven't ended up anywhere. No matter how sure you are of this phenomenon, unless you try to make its observation more robust, it will continue to be a microcosm of the tech hiring industry. Heuristics often belie subtle biases that do not actually have a foundation in truth.
    - gaius 8y ago
      most programmers don't try very hard and anyone taking the time to even learn a rarely used language is demonstrating a positive quality that most don't. Once known as the Python Paradox http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html Nowadays I suppose it would be the Clojure Conundrum or the Haskell Happenstance
s3nnyy 8y ago
Experience looking at thousands of CVs and talking to people who are behind the CVs.
- throwawaymath 8y ago
  That's not a statistic, nor is it quantifiable. I'm not taking issue with your experience, I'm taking issue with the fact that you've implied your claim has quantitative rigor to it, because I'm extremely skeptical that's the case. For what it's worth, I'm challenging you as someone who is neither a JavaScript developer nor a Clojure developer. I'm of the opinion that biases like the one the author laments are perpetuated (in part) by this leaky arguments from "statistics" that never appear.
  - scarejunba 8y ago
    Don't get hung up on the language. People sometimes say "statistically speaking" to mean "Based on my experience over a large number of tests". It doesn't mean "I applied a test of statistical significance to arrive at my conclusion". You're then meant to combine their stated experience with their stated credentials and your assessment of their trustworthiness to arrive at some conclusion. This imprecision may annoy you but it is a common way of speaking English so it's probably not in your interest to fight over the choice of wording.
    - throwawaymath 8y ago
      Sure, I understand what you're saying. But I'll continue to challenge the use of language like that. In my opinion, saying something is true "statistically speaking" is more grievous than saying something like, "I'm 99% sure." Both are artifacts of the English language, but I think the former carries much more quantification behind it, implicitly speaking. In that sense it's not just about informal use of language. This is because saying something is true "statistically" is a claim made in both scientific and casual contexts. It's mentally taxing to figure out which context is in play - someone could have come into this thread with actual statistics and said the same phrase, verbatim. Therefore (as I see it), it's realistically plausible that someone could read the original comment and come away believing recruiters have done actual statistical analysis a la TripleByte to arrive at their conclusion.

machiavelli1024 8y ago

Yep. Funny that HackerNews seem to be unable to wrap their head around the fact that prejudice is just applied Bayesian statistics.

MusaTheRedGuard 8y ago
I'm gonna say prejudice is actually not applied Bayesian statistics
- bastijn 8y ago
  and you would be right. Say I have a broken phone which is an Android. A prejudice would be that androids are likely to break. Mathematically we could represent as P(broken|android) =~ P(android|broken) We see from Bayes rule that this is false, since P(android) >> P(broken)
  - braythwayt 8y ago
    Even worse, what actually happens with prejudice is that if I think that Androids are shitty phones, when I see a broken Android, I add it to my collection of “Shitty Android” data points. But when my iPhone breaks, I take it into Apple for service and add it to my collection of “Apple gives great service” data points. Saying that prejudice is just applied statistics completely mischaracterizes prejudice.
- mrexroad 8y ago
  I’d argue that prejudice and bias applies most all statistics, but most often we just don’t notice or care. E.g. The biases inherent to specific domain, of those who captured the data, those who selected the data, selection of statistical techniques, real-world outcomes reinforced by usage of these statistics, etc.
dang 8y ago
Please don't take HN threads on generic ideological tangents. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

raiflip 8y ago

That is definitely a good strategy for a recruiter. However the context of the author's experience seems to be how the author's coworkers treats them. If I'm working with someone and I get to see their code, or I can take a look if I'm curious, IMO it becomes a vice to use Bayesian probability when you can look at the person's actual code and judge their skill. A different way to put it is Bayesian probability is good in a situation of uncertainty, but if you are not in a situation of uncertainty it just becomes lazy/ prejudicial.

panic 8y ago

Presumably people are paying you to find good engineers, not just people who match particular profiles. If "rational prejudice" doesn't always find the good engineers, why justify it like this? Wouldn't it be better to take this as evidence that your approach could use improvement?

darawk 8y ago
No. You have limited resources to sift through people. Heuristics like this are an efficient way to reduce your search space. That is sort of the whole point of statistics.
- deleted 8y ago
  [deleted]
curun1r 8y ago
> people are paying you to find good engineers No, they're paying them to find engineers that will pass the interview process. It's a subtle, but important distinction since prejudices that exist among engineers will naturally develop in recruiters. It's the recruiting equivalent of teaching to the test. And like it or not, the kind of signaling the article describes is real. When an engineer says they can write clojure, it indicates a curiosity that ability to program JavaScript does not. Almost no one is forced to learn Clojure because of some job, project or even job prospects. It means you likely cared enough to devote your own time to learning for the sake of learning. And a lot of engineers look at this kind of thing as important and screen for it in interviews. A recruiter operating any differently would be like a machine learning algorithm that ignores its training data.
- gaius 8y ago
  It means you likely cared enough to devote your own time to learning for the sake of learning. And a lot of engineers look at this kind of thing as important and screen for it in interviews. The curious thing is, I think the number who regard it as important is likely far higher than the number who actually do it. Which is understandable; once you reach a level of seniority you also have many other demands on your time and may not be able to be a hobbyist anymore on top of day job, family commitments and so on. So maybe once you learnt every new language but now you don’t have the opportunity, or you have decided to “go deep” in just a few, established languages. So the power of the signal is highly variable depending both on where the interviewer and interviewee are in their lives. Also, knowing JS in the late-90s did indicate a curious and ambitious developer. It only went mainstream later...

ender7 8y ago

It's true that, based on my interviewing experience, candidates with only a jQuery background are unlikely to have the skills to cut it developing large-scale software at a large-scale company, which is what I am hiring for. At the moment I interview mostly front-end candidates, and it takes a lot of sifting to find qualified hires. However, the implicit companion assumption that a resume with lots of clojure experience will have those skills is not something I've seen any evidence for. Many Clojure-focused candidates are unproductively dogmatic and are at risk of wasting everyone's time by trying to rearchitect our codebase because it doesn't meet their particular taste. In general, if a candidate is an adherent to a niche programming language they need to be able to explain to me when its use would be appropriate and inappropriate. If their answer is "this language and/or dogma is always better" then you're adorable but you need some more experience before I'm going to hire you. It's also important to point out that, while my core requirements are the same for both jQuery and Clojurey candidates (ability to function in a large, complex codebase & ability to manage your own code's complexity), the specific skillsets are very different. Most clojure enthusiasts are actively bad front-end engineers. Which is fine! But many positions require engineers to at least be able to dabble in UI work, and if I get the sense that you would find it beneath you to do so, its probably going to mean better luck somewhere else unless I have a very specific position to fill.

s3nnyy 8y ago
Oh yes. Based on my experience hiring on behalf of different firms, arrogance among engineers correlates with the degree of mathy-ness of a stack.
bm1362 8y ago
This is my experience hiring Clojure engineers in a small startup- things became dogmatic and opinionated at a time when we were existentially challenged with building a product.

k__ 8y ago

I never talked to a recruiter with any technical expertise in my whole 12 year career.

oblio 8y ago
https://i.redd.it/bka1gb843z7z.jpg https://i.redd.it/bka1gb843z7z.jpg
- lifeisstillgood 8y ago
  Funny, but presumably just selecting for recruiters with deep knowledge of pokemon, not programming languages.
  - minikomi 8y ago
    And you're assuming pokemon trainer abilities aren't congruous with tech recruiting.
- k__ 8y ago
  It's really sad, because I get called by 2 of them a week :/ Their websites sound like they are the pinnacle of the industry, but on phone/email they sound like a bunch of HS dropouts :(
- 1123581321 8y ago
  Which is krebase? Google seems to only return references to this image.
  - oblio 8y ago
    Beats me, not my image :)

21 8y ago

Now apply this logic to men in tech and woman in tech bell curves and see how that works out. Is it still rational?

lifeisstillgood 8y ago
Women in tech would presumably have the same signalling as Clojure users - greater probability of being competent ? Is that the point you were making?
wellpast 8y ago
Your question assumes that the programming talent bell curve for men and women are different, which I wouldn’t expect to be the case.
- __blockcipher__ 8y ago
  Seems like an interesting assumption. I’m mot convinced there is a difference, but neither am I confident that there isn’t one.
  - troupe 8y ago
    If there was a difference, are you allowed to note it or will you get fired for it? Programming skill is hard to measure. Chess is an interesting area that is a bit easier to quantify.
  - wellpast 8y ago
    Yeah I have no instincts in this because my experience has always been so fewer women than men on the engineering team. So this is totally anecdotal. But the few women I’ve worked with have always been in the upper part of the talent scale, while there has been much variance among the men. I.e., I’ve encountered many low talent (and high talent) men but not one low talent woman. Maybe there are enough hurdles for women (even if the only hurdle is that there are so few _other_ women) that you kinda have to be interested & reasonably good at the job to stick around. If this is true the bell curves may be better for women applicants. However amy anecdotal experience could be simply wrong and it somehow is even or worse for women or something other like overlapping curves of different shapes.

braythwayt 8y ago

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.

karmakaze 8y ago
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.
8y ago

mlthoughts2018 8y ago

I think it’s pure hubris to say that anyone can distinguish overall skill at a statistically significant level between these different populations. Heck, I’d even say if you only look at the population of engineers who you have directly observed doing a good job on some interview trivia or code test, you still cannot reliably conclude that draws from that population are statistically significantly more likely to be acceptably good at a job once hired than draws from a different population. People and processes capable of detecting skilled engineers are extremely rare. Skilled engineers are also somewhat rare. What we set up as tech hiring processes are mostly just crap-shoot just-so stories we tell ourselves, mixed with a ton of hubris.