4 ms·

I love the "looking for experts in X" followed by "with one to two years experience". And then I see my neighbor who is an expert in X, can code rings around an

I love the "looking for experts in X" followed by "with one to two years experience". And then I see my neighbor who is an expert in X, can code rings around anybody, but can't find a job after his company shut down. His only fault is he's 60.

itronitron 8y ago
I think there is an assumption that if a candidate doesn't have experience in 'Y' but they have ten years of 'X' (which is similar to, or a precursor of Y) then the candidate is somehow biased against Y or unwilling to work with it. Two decades of OpenGL experience?, sorry we are looking for someone with Vulkan experience. Two years of OpenGL experience? when can you come in?
- was_boring 8y ago
  As someone who does hiring, I have a different interpretation. Let's say I'm a rails shop and I'm looking for mid to sr. level candidates and someone has 10 years of experience working on Java 1.4 spring based application. I think to myself "this is great, they are willing to do some grunt work but I need to know they haven't stagnated". It's the stagnation that leads to lower job offers. You need to convince me that you were a dedicated employee for 10 years (which you are), but you also need to show that you're willing to learn something completely different. This can be a side project (doesn't have to be crazy, but slightly more then just going through the tutorial), certification of some sort, or _something_ that tells me you're not just going to write java-esque rails. I would even go so far as I prefer people with diverse backgrounds, who are really willing to learn, so that we benefit from mistakes they made at previous employers.
  - JustSomeNobody 8y ago
    Really? You can't just talk to the person and gauge their enthusiasm? I talk to devs all the time and they typically wear their tech bias on their sleeves. You know who is hard core C# and wouldn't touch java w/ a ten foot usb cord after just a few moments.
  - naasking 8y ago
    > You need to convince me that you were a dedicated employee for 10 years (which you are), but you also need to show that you're willing to learn something completely different. Have you actually had examples where this wasn't the case? This seems like a common sentiment that I myself have thought, but I honestly can't think of a single instance where a candidate with good experience or knowledge wouldn't actually be willing to learn something new, or wouldn't model code they write along existing idioms.
    - lordCarbonFiber 8y ago
      I can't comment on every sector but it absolutely exists in the financial technology realm. Plenty of people working in tech don't view it as an evolving set of skills and it's common to have candidates come with 1 - 2 decades of experience despite ending their search for knowledge around java 3.
Double_a_92 8y ago
At 60 you just got a few more years to work until you have to retire. It takes 2-3 years to really get comfortable with some bigger code base... So if you are looking for some longterm employee (if such a thing even exists), it's not worth it.
- throwawaymath 8y ago
  I disagree, unless you and I have radically different definitions of what "comfortable" means. If I'm hiring an engineer with the seniority I'd expect them to have at 20, 30 or 40 years in industry then I want them to ramp up inside of a year. I'm not going to expect them to be completely self-sufficient within a month. But they should be capable of implementing performant solutions to nontrivial problems with autonomy and collaboratively reviewing code with their peers. Stated another way - what are they doing for 2 - 3 years before they're comfortable that isn't worth it to hire them?
  - Double_a_92 8y ago
    I meant comfortable as in knowing exactly how to solve something, instead of first having to read and debug through (legacy) code for 1-2 days everytime you touch some new area of the application. For me personally the worst unsecurity is not knowing where to put new code, without messing up some architectural separation that I'm not aware of.
    - b_t_s 8y ago
      I think that level of security is only even possible at companies with small codebases or a high degree of siloing. I totally fit this description as a junior with 2 or 3 years experience at my first job where I wrote half the product. At my current job where I've been for 7 or 8 years I can't imagine anyone on any team ever achieving that. Maybe for a little while when you're working in some corner of the codebase that you happen to know really well, but not long term. There's just too many devs making too many changes and nobody "owns" any area. I bet a third to a half of the code I wrote 3 years ago is gone or heavily modified already.
    - 8y ago

itronitron 8y ago

I think there is an assumption that if a candidate doesn't have experience in 'Y' but they have ten years of 'X' (which is similar to, or a precursor of Y) then the candidate is somehow biased against Y or unwilling to work with it. Two decades of OpenGL experience?, sorry we are looking for someone with Vulkan experience. Two years of OpenGL experience? when can you come in?

was_boring 8y ago
As someone who does hiring, I have a different interpretation. Let's say I'm a rails shop and I'm looking for mid to sr. level candidates and someone has 10 years of experience working on Java 1.4 spring based application. I think to myself "this is great, they are willing to do some grunt work but I need to know they haven't stagnated". It's the stagnation that leads to lower job offers. You need to convince me that you were a dedicated employee for 10 years (which you are), but you also need to show that you're willing to learn something completely different. This can be a side project (doesn't have to be crazy, but slightly more then just going through the tutorial), certification of some sort, or _something_ that tells me you're not just going to write java-esque rails. I would even go so far as I prefer people with diverse backgrounds, who are really willing to learn, so that we benefit from mistakes they made at previous employers.
- JustSomeNobody 8y ago
  Really? You can't just talk to the person and gauge their enthusiasm? I talk to devs all the time and they typically wear their tech bias on their sleeves. You know who is hard core C# and wouldn't touch java w/ a ten foot usb cord after just a few moments.
- naasking 8y ago
  > You need to convince me that you were a dedicated employee for 10 years (which you are), but you also need to show that you're willing to learn something completely different. Have you actually had examples where this wasn't the case? This seems like a common sentiment that I myself have thought, but I honestly can't think of a single instance where a candidate with good experience or knowledge wouldn't actually be willing to learn something new, or wouldn't model code they write along existing idioms.
  - lordCarbonFiber 8y ago
    I can't comment on every sector but it absolutely exists in the financial technology realm. Plenty of people working in tech don't view it as an evolving set of skills and it's common to have candidates come with 1 - 2 decades of experience despite ending their search for knowledge around java 3.

Double_a_92 8y ago

At 60 you just got a few more years to work until you have to retire. It takes 2-3 years to really get comfortable with some bigger code base... So if you are looking for some longterm employee (if such a thing even exists), it's not worth it.

throwawaymath 8y ago
I disagree, unless you and I have radically different definitions of what "comfortable" means. If I'm hiring an engineer with the seniority I'd expect them to have at 20, 30 or 40 years in industry then I want them to ramp up inside of a year. I'm not going to expect them to be completely self-sufficient within a month. But they should be capable of implementing performant solutions to nontrivial problems with autonomy and collaboratively reviewing code with their peers. Stated another way - what are they doing for 2 - 3 years before they're comfortable that isn't worth it to hire them?
- Double_a_92 8y ago
  I meant comfortable as in knowing exactly how to solve something, instead of first having to read and debug through (legacy) code for 1-2 days everytime you touch some new area of the application. For me personally the worst unsecurity is not knowing where to put new code, without messing up some architectural separation that I'm not aware of.
  - b_t_s 8y ago
    I think that level of security is only even possible at companies with small codebases or a high degree of siloing. I totally fit this description as a junior with 2 or 3 years experience at my first job where I wrote half the product. At my current job where I've been for 7 or 8 years I can't imagine anyone on any team ever achieving that. Maybe for a little while when you're working in some corner of the codebase that you happen to know really well, but not long term. There's just too many devs making too many changes and nobody "owns" any area. I bet a third to a half of the code I wrote 3 years ago is gone or heavily modified already.
  - 8y ago