5 ms·

At another point you just accept you'll have to hire people who don't fit the classic job requirement of "X years experience in Lang" and hire people who don't

by Jach 7y ago

At another point you just accept you'll have to hire people who don't fit the classic job requirement of "X years experience in Lang" and hire people who don't know Lang at all but want to learn. A growing Clojure shop in Seattle seems to be having success with this, onboarding the language is a small fraction of overall onboarding. On the more meta level it's weird what people expect devs to learn on the job or know up front. Companies expect employees to keep up with the latest nonsense in web dev, but can't pick up a new straightforward language? Unless maybe another Algol like Go or TypeScript? This Steve Yegge quote captures some of it: "For some reason, programmers love to learn new stuff, as long as it's not syntax."

amortize 7y ago
> A growing Clojure shop in Seattle seems to be having success with this, onboarding the language is a small fraction of overall onboarding. I can attest to this fact, as part of a unicorn upstart with dev offices in Sao Paulo and Berlin. Clojure onboarding has never been a major roadblock for new engineers. And we never hire asking for "X years of lang experience". Almost everyone in the (~300 strong) engineering team started with zero-to-little Clojure background.
- mooreds 7y ago
  What do you look for? I mean the "X years of experience" is a shorthand proxy for "can get stuff done in the language we use". So I imagine you must have some other way of getting an idea of how a candidate can get things done. Would love to hear more about it.
  - amortize 7y ago
    What we have found is that it is enough to verify 'can get stuff done', and leave out 'in the language we use'. So, much of the interview turns out to be a process of validating two things: 1. can do what is claimed in the language of choice. 2. gauge enthusiasm and interest to pick up our language.
    - lvh 7y ago
      FWIW, that's been our experience as well (both at a largeish publicly traded company and now at a small private consultancy). Go get work sample tests :) (It's fine if your work sample test really just focuses on one language! But then make it part of the rubric if that's the answer you want, and tell the applicant about that rubric.)
    - mooreds 7y ago
      Thanks! I can see 1. being pretty easy to suss out (paid take home coding assignment is how I'd do it). How do you assess 2.?
      - amortize 7y ago
        Mostly in our conversations, in an informal way. I would say the assumption we make is that developers with a penchant for any form of functional prog and/or Lisps, and with an acute focus on testing have an easy time grasping Clojure. And we bias our rubric towards this. Also, we encourage our candidates to choose Clojure for their take-home assignment, even if they do not have any prior taste of it. This, for those of them who choose that option, gives an idea of if they would enjoy working in it. Our rubric however does not have a bias against developers who do not choose Clojure for their assignments, and we make this explicit to the candidates as well.
- erk__ 7y ago
  I guess the difference here is if they have to learn Clojure just to contribute to a single project, then they may be put behind some other things they want to learn and contribute to first.
willtim 7y ago
Yes it seems strange to me that a Java developer is willing to learn Spring, a massive ad-hoc framework which exists in part because of Java's weaknesses, rather than functional programming and Clojure (a lifelong skill that will benefit their Java programming).
- yogthos 7y ago
  I've worked with plenty of devs in my time who don't really understand what they're doing and just copy and paste code from Stack Overflow until it seems to work. A lot of the enterprise takes the monkeys with typewriters approach to software development. I think there are cultural reasons for that because enterprise treats devs like fungible cogs that you replace when they burn out. It tends to be highly dehumanizing environment where devs have no say, no autonomy, and no ownership. This naturally pushes out people who have options, and you end up with a pool of devs who just want any job that pays the bills.
  - kamaal 7y ago
    >>I think there are cultural reasons for that because enterprise treats devs like fungible cogs that you replace when they burn out. Its mostly approach to any work in general. If it were upto them, these are really the kind of the people who would dig earth with spoons and shovels, instead of heavy machinery. The idea is simple, should you use Spring + Java, you are likely to need say 60+ people to run a product well. It could take 15 to make it work in Clojure. But having 60 people has its own advantages from their perspective. Say 10 people decide to leave, they can hire 10 replacements for the lowest prices from the market, train them on the application and get it going. Eventually the whole team could leave and get replaced this way, reducing the problem to a bit like the Ship of Theseus paradox. But it works for them. If they use Clojure, they have to treat people well, pay them well to retain them. Because there teams tend to be small and a exodus puts everything at risk. They have to use spoons and shovels, personnel trained to work on heavy machinery are expensive, training is expensive and replacing them is expensive.
- lvh 7y ago
  Also, to get there, you're already accepting the assertion that the move isn't a management decision :-)
cwyers 7y ago
Well, this isn't a hiring situation, this is a getting contributors to an open-source project. When you're looking for volunteers, the tolerable amount of friction is often less than if you're paying someone for their time.
- Jach 7y ago
  Yes, I was responding mostly to the grandparent's move towards discussing this sort of tradeoff in the commercial space, not just in the open source space. To stick with open source, it could become the case that moving away from Clojure leads to a cooling of contributors, existing or new. If you're looking for an Apache project to start contributing to, there's no shortage of Java projects. But if you like Clojure or want to learn it better, hey look there used to be this Clojure one, cool. If you liked the Storm project specifically and wanted to conribute, I don't think the language would get in the way that much. (Speaking personally if I had more time and energy I'd like to try and contribute to the Godot project despite my desire to never have to program in C++ again. It's a sufficiently cool project to overcome that.) Optimizing for new volunteer contributors goes beyond core language choice anyway. For an interesting description of how the game Battle for Wesnoth tried to do it, see: http://aosabook.org/en/wesnoth.html http://aosabook.org/en/wesnoth.html

by Jach 7y ago

amortize 7y ago

> A growing Clojure shop in Seattle seems to be having success with this, onboarding the language is a small fraction of overall onboarding. I can attest to this fact, as part of a unicorn upstart with dev offices in Sao Paulo and Berlin. Clojure onboarding has never been a major roadblock for new engineers. And we never hire asking for "X years of lang experience". Almost everyone in the (~300 strong) engineering team started with zero-to-little Clojure background.

mooreds 7y ago
What do you look for? I mean the "X years of experience" is a shorthand proxy for "can get stuff done in the language we use". So I imagine you must have some other way of getting an idea of how a candidate can get things done. Would love to hear more about it.
- amortize 7y ago
  What we have found is that it is enough to verify 'can get stuff done', and leave out 'in the language we use'. So, much of the interview turns out to be a process of validating two things: 1. can do what is claimed in the language of choice. 2. gauge enthusiasm and interest to pick up our language.
  - lvh 7y ago
    FWIW, that's been our experience as well (both at a largeish publicly traded company and now at a small private consultancy). Go get work sample tests :) (It's fine if your work sample test really just focuses on one language! But then make it part of the rubric if that's the answer you want, and tell the applicant about that rubric.)
  - mooreds 7y ago
    Thanks! I can see 1. being pretty easy to suss out (paid take home coding assignment is how I'd do it). How do you assess 2.?
    - amortize 7y ago
      Mostly in our conversations, in an informal way. I would say the assumption we make is that developers with a penchant for any form of functional prog and/or Lisps, and with an acute focus on testing have an easy time grasping Clojure. And we bias our rubric towards this. Also, we encourage our candidates to choose Clojure for their take-home assignment, even if they do not have any prior taste of it. This, for those of them who choose that option, gives an idea of if they would enjoy working in it. Our rubric however does not have a bias against developers who do not choose Clojure for their assignments, and we make this explicit to the candidates as well.
erk__ 7y ago
I guess the difference here is if they have to learn Clojure just to contribute to a single project, then they may be put behind some other things they want to learn and contribute to first.

willtim 7y ago

Yes it seems strange to me that a Java developer is willing to learn Spring, a massive ad-hoc framework which exists in part because of Java's weaknesses, rather than functional programming and Clojure (a lifelong skill that will benefit their Java programming).

yogthos 7y ago
I've worked with plenty of devs in my time who don't really understand what they're doing and just copy and paste code from Stack Overflow until it seems to work. A lot of the enterprise takes the monkeys with typewriters approach to software development. I think there are cultural reasons for that because enterprise treats devs like fungible cogs that you replace when they burn out. It tends to be highly dehumanizing environment where devs have no say, no autonomy, and no ownership. This naturally pushes out people who have options, and you end up with a pool of devs who just want any job that pays the bills.
- kamaal 7y ago
  >>I think there are cultural reasons for that because enterprise treats devs like fungible cogs that you replace when they burn out. Its mostly approach to any work in general. If it were upto them, these are really the kind of the people who would dig earth with spoons and shovels, instead of heavy machinery. The idea is simple, should you use Spring + Java, you are likely to need say 60+ people to run a product well. It could take 15 to make it work in Clojure. But having 60 people has its own advantages from their perspective. Say 10 people decide to leave, they can hire 10 replacements for the lowest prices from the market, train them on the application and get it going. Eventually the whole team could leave and get replaced this way, reducing the problem to a bit like the Ship of Theseus paradox. But it works for them. If they use Clojure, they have to treat people well, pay them well to retain them. Because there teams tend to be small and a exodus puts everything at risk. They have to use spoons and shovels, personnel trained to work on heavy machinery are expensive, training is expensive and replacing them is expensive.
lvh 7y ago
Also, to get there, you're already accepting the assertion that the move isn't a management decision :-)

cwyers 7y ago

Well, this isn't a hiring situation, this is a getting contributors to an open-source project. When you're looking for volunteers, the tolerable amount of friction is often less than if you're paying someone for their time.

Jach 7y ago
Yes, I was responding mostly to the grandparent's move towards discussing this sort of tradeoff in the commercial space, not just in the open source space. To stick with open source, it could become the case that moving away from Clojure leads to a cooling of contributors, existing or new. If you're looking for an Apache project to start contributing to, there's no shortage of Java projects. But if you like Clojure or want to learn it better, hey look there used to be this Clojure one, cool. If you liked the Storm project specifically and wanted to conribute, I don't think the language would get in the way that much. (Speaking personally if I had more time and energy I'd like to try and contribute to the Godot project despite my desire to never have to program in C++ again. It's a sufficiently cool project to overcome that.) Optimizing for new volunteer contributors goes beyond core language choice anyway. For an interesting description of how the game Battle for Wesnoth tried to do it, see: http://aosabook.org/en/wesnoth.html http://aosabook.org/en/wesnoth.html