5 ms·

Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very e

Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very expensive. Personally, I think being excited about a cool language is a mixed signal. An interest in technology is great, but on the clock that has to be thoroughly suppressed in favor of actual business needs and constraints. At home, I like fucking around with all sorts of stuff. At work, I'm a confirmed member of the Boring Technology Club. [1] [1] https://boringtechnology.club/ https://boringtechnology.club/

duxup 4y ago
If all you want is something to thin a stack of resumes why not be honest and just randomly throw out the required number?
- wpietri 4y ago
  Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. One kind of bad hire is the technology-lover who values their own preferences over the needs of the business. E.g., a friend of mine took over a team with a couple of strong FP advocates on it. They had written a core tool in very FP-ish JS. They enjoyed the novelty of the greenfield work, but once it was down to just making the changes users needed, they got bored and moved on. The remaining part of the team tried picking it up, but it was too alien, either because of the FPness or just because the code was opaque. Either way, they eventually had to rewrite it. Or personally, I have made a lot of good money coming in after some would be brain genius, ripping out their supposedly cutting edge work, and replacing it with something boring. I remember one place where a core part of a system was build on the 0.7 version of then-fashionable technology. Except it wasn't even 0.7 as released, but something with custom patches applied. None of the people there could maintain it. Looking at git blame and doing a little web searching, it turned out the developer responsible had then done a self-promoting conference talk about their amazing work, and then quit shortly thereafter. After I removed it and replace it with something much simpler, not only could the people there maintain it, but it worked better than before.
  - pmarreck 4y ago
    > Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. I'm certain you could increase the odds of a good hire in all sorts of other ways by seeking correlational stereotypes, but some of those (age, gender, race) would be seen as... very bad, possibly illegal, and some others (traditional-ness of first name, for example) would possibly also work but would be highly questionable. Heck, I bet you could find a correlation with whether or not the person used an AOL email address or not. What makes filtering by this stereotype correlation superior, ethically, to those other stereotype correlations? If "interest in new tech" is an immutable attribute of the person's personality (which it almost entirely likely is), then in both cases you're filtering based on immutable attributes, so they should be considered ethically equivalent on paper, where you have a lot of false negatives, but your "good hire" rate goes up. > One kind of bad hire is the technology-lover who values their own preferences over the needs of the business. So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see.
    - snovv_crash 4y ago
      > So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see. No, you have it exactly wrong. What you describe are good development practices that provide actual long term business value. What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features. Engineering is about solving problems, and technologies are tools to solve them.
      - mynameisvlad 4y ago
- heelix 4y ago
  Of course you blindly throw out 30% of the resumes -- you want to filter out the unlucky candidates. :P
_the_inflator 4y ago
I totally agree. I engraved Angular 2016 in our Tech Stack. Fast forward 7 years now, and we are on Angular 14. Accomplishments so far? Large and stable platform as well as a Low Code Editor on top of it. We systematically componenized every useful piece of Frontend there was and evolved from a library into a platform, while other departments jumped ship every now and then (jQuery, React, Vue, etc.). After years of resistance all finally joined out platform, because it is fast, stable, convenient. Moral of the story: consistency is everything. A tool is a tool.
- wpietri 4y ago
  For sure. I used to be a real tech snob. And I still like experimenting. But I've had to admit that the particular technology used just doesn't make the difference I would like it to. E.g., PHP is a "fractal of bad design" [1], but Facebook seems to be an ok business. Or Javascript was clearly a frightful hack job to start, barely adequate for mouse rollovers and a little form validation, but now you see plenty of companies doing fine using it front end and back. These days I would much rather have a good team and a good culture than my favorite technology. [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
  - valenterry 4y ago
    Facebook hired dedicated people to invent their own hack-language over PHP to deal with PHPs problems. Sure, a business can succeed with a crappy language. But that doesn't mean the language has no impact, otherwise Facebook would have just sticked to it.
    - wpietri 4y ago
      I don't believe that I said language had no impact. What I said was, "the particular technology used just doesn't make the difference I would like it to".
      - valenterry 4y ago
CoastalCoder 4y ago
> Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very expensive. I think it depends on how you define "fine". Perhaps "fine" for the hiring company, but it externalizes the cost of wasted job leads for candidates.
mrighele 4y ago
If you think that a technology/language/etc is cool and better than the rest but it is not as common as <mainstream thing>, of course you’d be excited to learn that a company is using it. If you’re a company that chose a very niche language because <a number of reasons> and discard an applicant because he likes the same very reasons, LOL, you’re a bunch of idiots
- satvikpendem 4y ago
  Well, they're moving away from said language, so why would they want to hire someone who joined because they liked Elm but then doesn't get to use Elm at work? They're more likely to leave the company than someone who doesn't really care so particularly about Elm (or whatever language or tool it may be). So in OP's case, it's a sound business decision.
  - javcasas 4y ago
    Adversarial take: if your company says it does Elm, then hires people (who took Elm as part of the decision of joining) and then decides to stop using Elm, why should we push the guilt of leaving to the employee? I mean, it looks a bit like bait-and-switch, and "We the company altered the deal, pray we don't alter it any further". How is that employees should be loyal to any decision upper management does? What's the limit? What if the company decides to go into JBoss/JQuery? What if the company decides to stop doing software altogether? What if the company becomes a mercenary army a-la-Wagner? Where do we place the line between employee is guilty for not continuing/company is guilty for changing everything that matters?
    - satvikpendem 4y ago
      I think you're reading guilt where there is none. I just mentioned that it's a sound business decision, as well as a better decision for the employee who likes Elm, to not hire people who like using a tool your company no longer uses. There's no guilt on either side, it's just pragmatism.
- wpietri 4y ago
throwawaymaths 4y ago
I mean it depends, right? There are several technologies out there that are fantastic because they are less annoying, have fewer footguns, easy to debug, easy to read, good tooling (docs, tests, package management), and respect the programmer's sanity. Is it wrong to only want to work with such systems? If some company rejects me because I'm a tech stack fanboy without asking and understanding why I care about the stacks that I do, that means they don't respect my sanity. Hate to say it, but most "boring" technologies with a legacy from, say, pre-2000-ish, cared zero about those things. So, great. Buh-bye. Nb: many technologies post-2k also don't care about those things. So yeah, don't be shiny new on those either.
- wpietri 4y ago
  Sure, but you're now evaluating the technology in business terms. That's very different than somebody who loves the ideas of a language. I don't want to start a language war, so I won't name one. But consider all the developers who were very excited about "blockchain" not because it improved anything practical for their projects, but because it was a hot concept.
  - throwawaymaths 4y ago
    The point is there are languages where the "ideas" of the language are these "business" ideas. Technical choices can also lead to good/bad developer ergonomics.
    - wpietri 4y ago
      Do you really believe that there's an experienced developer who doesn't believe, "Technical choices can also lead to good/bad developer ergonomics"? Maybe try assuming I already know the basics of the field.
marcosdumay 4y ago
The plenty of fish on the sea argument don't hold if you enforce a systematic bias.
ajmurmann 4y ago
This is the right attitude. I make a conscious effort to find reasons not to use a technology in excited about at work because my excitement otherwise will bias the decision in the other direction.
bcrosby95 4y ago
It's funny because that slide shows why we use Elixir. With the clustering BEAM offers out of the box we've been able to eliminate things like memcached, redis, and rabbitmq from our production environment. But most people wouldn't call Elixir "boring tech".
- ParetoOptimal 4y ago
  > But most people wouldn't call Elixir "boring tech". In the sense most people mean boring, Haskell with sum types, pattern matching, and pure functions is the most boring someone could ever hope to get. However, most people wouldn't consider that boring either :)

duxup 4y ago

If all you want is something to thin a stack of resumes why not be honest and just randomly throw out the required number?

wpietri 4y ago
Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. One kind of bad hire is the technology-lover who values their own preferences over the needs of the business. E.g., a friend of mine took over a team with a couple of strong FP advocates on it. They had written a core tool in very FP-ish JS. They enjoyed the novelty of the greenfield work, but once it was down to just making the changes users needed, they got bored and moved on. The remaining part of the team tried picking it up, but it was too alien, either because of the FPness or just because the code was opaque. Either way, they eventually had to rewrite it. Or personally, I have made a lot of good money coming in after some would be brain genius, ripping out their supposedly cutting edge work, and replacing it with something boring. I remember one place where a core part of a system was build on the 0.7 version of then-fashionable technology. Except it wasn't even 0.7 as released, but something with custom patches applied. None of the people there could maintain it. Looking at git blame and doing a little web searching, it turned out the developer responsible had then done a self-promoting conference talk about their amazing work, and then quit shortly thereafter. After I removed it and replace it with something much simpler, not only could the people there maintain it, but it worked better than before.
- pmarreck 4y ago
  > Because you're looking to thin it differentially, such that the odds of a good hire go up, or at least the odds of a bad hire go down. I'm certain you could increase the odds of a good hire in all sorts of other ways by seeking correlational stereotypes, but some of those (age, gender, race) would be seen as... very bad, possibly illegal, and some others (traditional-ness of first name, for example) would possibly also work but would be highly questionable. Heck, I bet you could find a correlation with whether or not the person used an AOL email address or not. What makes filtering by this stereotype correlation superior, ethically, to those other stereotype correlations? If "interest in new tech" is an immutable attribute of the person's personality (which it almost entirely likely is), then in both cases you're filtering based on immutable attributes, so they should be considered ethically equivalent on paper, where you have a lot of false negatives, but your "good hire" rate goes up. > One kind of bad hire is the technology-lover who values their own preferences over the needs of the business. So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see.
  - snovv_crash 4y ago
    > So basically you want to hire non-technology-lovers who simply "GSD" and don't care about things like long term maintainability or test coverage (or test runtime, or code quality, or...) because at the end of the day that's just added fees you can charge to the client when you have to revisit the codebase in the future. I see. No, you have it exactly wrong. What you describe are good development practices that provide actual long term business value. What you want to avoid is someone saying "yeah I'm excited to use the nested lambdas and variants and callbacks and asynchronous systems" because this shows they just want to play with toys, not solve problems the business has like too many bugs, or slow runtime, or missing features. Engineering is about solving problems, and technologies are tools to solve them.
    - mynameisvlad 4y ago
heelix 4y ago
Of course you blindly throw out 30% of the resumes -- you want to filter out the unlucky candidates. :P

_the_inflator 4y ago

I totally agree. I engraved Angular 2016 in our Tech Stack. Fast forward 7 years now, and we are on Angular 14. Accomplishments so far? Large and stable platform as well as a Low Code Editor on top of it. We systematically componenized every useful piece of Frontend there was and evolved from a library into a platform, while other departments jumped ship every now and then (jQuery, React, Vue, etc.). After years of resistance all finally joined out platform, because it is fast, stable, convenient. Moral of the story: consistency is everything. A tool is a tool.

wpietri 4y ago
For sure. I used to be a real tech snob. And I still like experimenting. But I've had to admit that the particular technology used just doesn't make the difference I would like it to. E.g., PHP is a "fractal of bad design" [1], but Facebook seems to be an ok business. Or Javascript was clearly a frightful hack job to start, barely adequate for mouse rollovers and a little form validation, but now you see plenty of companies doing fine using it front end and back. These days I would much rather have a good team and a good culture than my favorite technology. [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
- valenterry 4y ago
  Facebook hired dedicated people to invent their own hack-language over PHP to deal with PHPs problems. Sure, a business can succeed with a crappy language. But that doesn't mean the language has no impact, otherwise Facebook would have just sticked to it.
  - wpietri 4y ago
    I don't believe that I said language had no impact. What I said was, "the particular technology used just doesn't make the difference I would like it to".
    - valenterry 4y ago

CoastalCoder 4y ago

> Most hiring rules have notable false negative rates and that's fine because you have multiple applicants per position and because getting it wrong can be very expensive. I think it depends on how you define "fine". Perhaps "fine" for the hiring company, but it externalizes the cost of wasted job leads for candidates.

mrighele 4y ago

If you think that a technology/language/etc is cool and better than the rest but it is not as common as <mainstream thing>, of course you’d be excited to learn that a company is using it. If you’re a company that chose a very niche language because <a number of reasons> and discard an applicant because he likes the same very reasons, LOL, you’re a bunch of idiots

satvikpendem 4y ago
Well, they're moving away from said language, so why would they want to hire someone who joined because they liked Elm but then doesn't get to use Elm at work? They're more likely to leave the company than someone who doesn't really care so particularly about Elm (or whatever language or tool it may be). So in OP's case, it's a sound business decision.
- javcasas 4y ago
  Adversarial take: if your company says it does Elm, then hires people (who took Elm as part of the decision of joining) and then decides to stop using Elm, why should we push the guilt of leaving to the employee? I mean, it looks a bit like bait-and-switch, and "We the company altered the deal, pray we don't alter it any further". How is that employees should be loyal to any decision upper management does? What's the limit? What if the company decides to go into JBoss/JQuery? What if the company decides to stop doing software altogether? What if the company becomes a mercenary army a-la-Wagner? Where do we place the line between employee is guilty for not continuing/company is guilty for changing everything that matters?
  - satvikpendem 4y ago
    I think you're reading guilt where there is none. I just mentioned that it's a sound business decision, as well as a better decision for the employee who likes Elm, to not hire people who like using a tool your company no longer uses. There's no guilt on either side, it's just pragmatism.
wpietri 4y ago

throwawaymaths 4y ago

I mean it depends, right? There are several technologies out there that are fantastic because they are less annoying, have fewer footguns, easy to debug, easy to read, good tooling (docs, tests, package management), and respect the programmer's sanity. Is it wrong to only want to work with such systems? If some company rejects me because I'm a tech stack fanboy without asking and understanding why I care about the stacks that I do, that means they don't respect my sanity. Hate to say it, but most "boring" technologies with a legacy from, say, pre-2000-ish, cared zero about those things. So, great. Buh-bye. Nb: many technologies post-2k also don't care about those things. So yeah, don't be shiny new on those either.

wpietri 4y ago
Sure, but you're now evaluating the technology in business terms. That's very different than somebody who loves the ideas of a language. I don't want to start a language war, so I won't name one. But consider all the developers who were very excited about "blockchain" not because it improved anything practical for their projects, but because it was a hot concept.
- throwawaymaths 4y ago
  The point is there are languages where the "ideas" of the language are these "business" ideas. Technical choices can also lead to good/bad developer ergonomics.
  - wpietri 4y ago
    Do you really believe that there's an experienced developer who doesn't believe, "Technical choices can also lead to good/bad developer ergonomics"? Maybe try assuming I already know the basics of the field.

marcosdumay 4y ago

The plenty of fish on the sea argument don't hold if you enforce a systematic bias.

ajmurmann 4y ago

This is the right attitude. I make a conscious effort to find reasons not to use a technology in excited about at work because my excitement otherwise will bias the decision in the other direction.

bcrosby95 4y ago

It's funny because that slide shows why we use Elixir. With the clustering BEAM offers out of the box we've been able to eliminate things like memcached, redis, and rabbitmq from our production environment. But most people wouldn't call Elixir "boring tech".

ParetoOptimal 4y ago
> But most people wouldn't call Elixir "boring tech". In the sense most people mean boring, Haskell with sum types, pattern matching, and pure functions is the most boring someone could ever hope to get. However, most people wouldn't consider that boring either :)