3 ms·

> 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

> 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
  > 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. How does that sentence show that, exactly? All it shows is that they're interested in new technologies. That says nothing about whether or not they are interested in "[solving] problems the business has like too many bugs, or slow runtime, or missing features". Those two are not mutually exclusive; one can certainly care about both. Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.
  - snovv_crash 4y ago
    > How does that sentence show that, exactly? On its own, it doesn't. But if they don't show some interest in what the business is doing as well, it's a red flag, because they will probably end up building something the business doesn't want or need, or fulfill requirements without foresight or understanding into future business direction, but rather based on what they find stimulating (aka more complicated than necessary, at the limits of their understanding). > Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything. Anybody working in a small team where you have embedded people from all aspects of the business and work together to make the company successful. So, me, and everyone I'm interested in working with? If you're in a giant company and the only satisfaction you can get from your work is the toys you get to play with, to me it's just a sign of corporate disfunction and misalignment between business and engineering.
- pmarreck 4y ago
  But interestingly, some of those examples you cited are literally solutions to some of the problems you cited, so... For example, a language like Elixir that has "trivial concurrency and immutability" enables a test suite that can run across all of your cores at once and is deterministically guaranteed (assuming you watch how you touch shared mutable state outside that code, such as a database) to not step on itself while doing so. Compare this to any one of a number of mutable languages (such as Ruby) that claim concurrency but in actuality often contain deep software bugs that result in flagging, nondeterministic tests UNLESS they are run single-core. That is absolutely a solved engineering problem that then may prevent other mitigations like having to run the test suite across 25+ cloud machines (in single-core mode) and waiting 25 minutes for a test result before being able to continue, which then directly increases developer productivity. Also, being interested in those 2 things is not mutually-exclusive. I LIKE that this is a tangible business result of a fundamental language design decision.
wpietri 4y ago
> So basically you want to hire non-technology-lovers That is pretty far from what I said. Try again?
- pmarreck 4y ago
  Alright, I will. > One kind of bad hire is the technology-lover who values their own preferences over the needs of the business. OK. This is not a mutually-exclusive relationship. One can prioritize both of these; the best team player will prioritize the needs of the business (and the team) more, however. This to me seems like you're really addressing the problem of "vanity/primadonna devs" who are not team players, and not just devs who really like certain technologies which will possibly blind them. I also think experience tempers this quite a bit. I've certainly had dev experiences where I became enamored with an idea or trendy tech, felt I absolutely had to implement it, and then ended up regretting it later. I think this happens a lot with younger devs and that's OK because that's how you learn. (Make sure they get assigned the mess cleanup when it doesn't work out though. LOL)
  - wpietri 4y ago
    At hiring time, it can be very hard to tell the difference between "vanity/primadonna devs" and "devs who really like certain technologies which will possibly blind them". And even among the latter group, there are tradeoffs in hiring them. There are many reasonable places to set the dial on how much a hiring manager wants to take risks on that. But I maintain that, as with many other hiring criteria, erring on the side of caution is a reasonable choice. As I said, I think being excited about a cool language is a mixed signal.

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
> 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. How does that sentence show that, exactly? All it shows is that they're interested in new technologies. That says nothing about whether or not they are interested in "[solving] problems the business has like too many bugs, or slow runtime, or missing features". Those two are not mutually exclusive; one can certainly care about both. Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything.
- snovv_crash 4y ago
  > How does that sentence show that, exactly? On its own, it doesn't. But if they don't show some interest in what the business is doing as well, it's a red flag, because they will probably end up building something the business doesn't want or need, or fulfill requirements without foresight or understanding into future business direction, but rather based on what they find stimulating (aka more complicated than necessary, at the limits of their understanding). > Taking it a step further, who gets excited about "[solving] problems the business has like too many bugs, or slow runtime, or missing features". That certainly sounds like what someone would say to please their interviewer more than anything. Anybody working in a small team where you have embedded people from all aspects of the business and work together to make the company successful. So, me, and everyone I'm interested in working with? If you're in a giant company and the only satisfaction you can get from your work is the toys you get to play with, to me it's just a sign of corporate disfunction and misalignment between business and engineering.
pmarreck 4y ago
But interestingly, some of those examples you cited are literally solutions to some of the problems you cited, so... For example, a language like Elixir that has "trivial concurrency and immutability" enables a test suite that can run across all of your cores at once and is deterministically guaranteed (assuming you watch how you touch shared mutable state outside that code, such as a database) to not step on itself while doing so. Compare this to any one of a number of mutable languages (such as Ruby) that claim concurrency but in actuality often contain deep software bugs that result in flagging, nondeterministic tests UNLESS they are run single-core. That is absolutely a solved engineering problem that then may prevent other mitigations like having to run the test suite across 25+ cloud machines (in single-core mode) and waiting 25 minutes for a test result before being able to continue, which then directly increases developer productivity. Also, being interested in those 2 things is not mutually-exclusive. I LIKE that this is a tangible business result of a fundamental language design decision.

wpietri 4y ago

> So basically you want to hire non-technology-lovers That is pretty far from what I said. Try again?

pmarreck 4y ago
Alright, I will. > One kind of bad hire is the technology-lover who values their own preferences over the needs of the business. OK. This is not a mutually-exclusive relationship. One can prioritize both of these; the best team player will prioritize the needs of the business (and the team) more, however. This to me seems like you're really addressing the problem of "vanity/primadonna devs" who are not team players, and not just devs who really like certain technologies which will possibly blind them. I also think experience tempers this quite a bit. I've certainly had dev experiences where I became enamored with an idea or trendy tech, felt I absolutely had to implement it, and then ended up regretting it later. I think this happens a lot with younger devs and that's OK because that's how you learn. (Make sure they get assigned the mess cleanup when it doesn't work out though. LOL)
- wpietri 4y ago
  At hiring time, it can be very hard to tell the difference between "vanity/primadonna devs" and "devs who really like certain technologies which will possibly blind them". And even among the latter group, there are tradeoffs in hiring them. There are many reasonable places to set the dial on how much a hiring manager wants to take risks on that. But I maintain that, as with many other hiring criteria, erring on the side of caution is a reasonable choice. As I said, I think being excited about a cool language is a mixed signal.