6 ms·

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing abou

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems. The stack an engineer has experience with can be one indicator of the areas they excel in.

throwaway981211 7y ago
Is this the right way to hire? Not saying it’s wrong but I’ve taken a different approach which has generally worked out. Even if I was hiring for a specific role (front end), I care less about familiarity with specific bundlers or frameworks and something more like - “Can this person problem solve and deal with varying levels of ambiguity? Do they seem capable of figuring something out without a ton of direction?”
- mcv 7y ago
  That is exactly the thing I select for. I recently had to hire 4 developers, and I was not all that interested in how many years of experience they had in javascript or typescript (our main language), and even less if you know Vue or Express (our stack). I mean, it's good to know javascript, and certainly ES6 or typescript, but I'm much more interested in: can I discuss stuff with you, do you have interesting opinions, can you make clear decisions in the face of unclear requirements, are you creative, and can you fix stuff and build features without anyone having to hold your hand? In case of doubt, knowledge of ES6 or Typescript or any relevant front-end framework (Vue, Angular or React) can make a lot of difference, but I'd rather hire someone who knows a dozen languages we don't use than someone who only knows exactly the one language we do use.
  - scarface74 7y ago
    And then when you need to ship now you have a bunch of dead weight while you wait for them to ramp up. Also, since now you are taking time from your devs who do know the stack to mentor your new hires and code reviews because you can’t trust them to do good work without messing up your code base. They are now doing “negative work”.
    - bcrosby95 7y ago
      Compared to what, needing to ship now and not being able to find any "qualified candidates"? It really depends upon the exact situation. We can all make up bullshit examples to make either option look stupid.
      - scarface74 7y ago
        It’s “bullshit” to open req to hire a developer because you need to ship a product within the next six months and you need more bodies? Why are you hiring if you don’t need the extra people? If you didn’t need the extra people for a year until they ramp up, wouldn’t it be better just to take your time hiring until you found someone that didn’t have to spend a year learning on your dime and then leave in two years?
        mcv 7y ago
        I needed extra people, but not merely warm bodies to fill a seat. I need people who don't need a year to ramp up, but can do so in a few weeks.
    - james_s_tayler 7y ago
      But if you're in a secondary employment market as opposed to startup heavy SV you might work with this person for a very long time or have a high chance of working together in the future. So the right, right now isn't always what people are optimizing for.
      - scarface74 7y ago
        After spending 10 years at one company and suffering from not learning anything new but just as importantly salary compression, for the next 8 years, and 5 jobs, I learned the best way to make more money is to do Resume Driven Development and change jobs. While your market value goes up tremendously, HR departments insists on giving 3-4% raises to existing employees while being forced to bring in new employees at market rates. This is the “secondary employment” market where HR policies aren’t optimized for in demand fields like software development. The immediate managers are usually helpless to do anything about it and see employees they spend time training leave for greener pastures. Being that is the reality, what other course is there but to find people you don’t have to train?
- JMTQp8lwXL 7y ago
  There is no "right way to hire". All "ways" are flawed and miss things. If hiring could've been solved by now, it would have already happened.
irrational 7y ago
I think what he is saying is, if you are hiring a React developer, but someone only has experience in Vue, would you not hire them because of their lack of React experience?
dcolkitt 7y ago
> the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. Almost all of these concepts could easily be learned in a few weeks by a talented engineer with strong fundamentals in software design and computer science. Polyfills aren't exactly quantum mechanics. They're not some radically different mental paradigm that takes years to develop fluidity. If you already have a sound basis in the major software engineering concepts, learning polyfills is just a matter of reading the docs to learn the details. Let's not forget that Jordan Walke was working on back-end infrastructure code just prior to inventing ReactJS. Miso Hevery was working on Java testing frameworks just before inventing AngularJS. So it's not like there's a history of front-end being such a unique problem domain, that it's impossible for outsiders to pick up. The only major sub-domain of software that I think this may potentially be true of is embedded systems. And even then, that's a big maybe.
- JMTQp8lwXL 7y ago
  As atomic points, I agree. Polyfills aren't rocket science. If the browser API is not defined, the use the polyfill function (at least, that's how most work, but then there's ponyfills, which don't pollute the global scope). But front-end development of complex applications isn't done in a vacuum by one person. It's done by multiple teams, possibly distributed across different physical locations. As an architect, what is your polyfill story? Does each team ship ES Modules that are later compiled by Webpack? Is each team responsible for loading their own? It's probably more efficient to handle it globally --knowing what all teams need at once as part of a build step-- to prevent duplicative loading of the same polyfill by 5 different teams. It gets nuanced quick. Nobody can master all these concepts --and reasonable ways of managing them in distributed team environments-- in a few weeks. And if you think JavaScript is "simple", I encourage reading "You Don't Know JS". What does "this" mean, in JavaScript? I could ask a handful of questions from the multitude of sections in this book, and people writing JavaScript for years wouldn't be able to answer all of them. React and Angular are such a thin slice of the overall problem. Even simple projects will require a dozen or so more NPM packages until you have something remotely useful.
  - dcolkitt 7y ago
sdenton4 7y ago
That's more a question of overall area of past work, though, than particular language or framework. If you've been working on frontend stuff, problems of layout, matching redlines, response latency, etc, should be in your deck regardless of which programming language you've been using.

throwaway981211 7y ago

Is this the right way to hire? Not saying it’s wrong but I’ve taken a different approach which has generally worked out. Even if I was hiring for a specific role (front end), I care less about familiarity with specific bundlers or frameworks and something more like - “Can this person problem solve and deal with varying levels of ambiguity? Do they seem capable of figuring something out without a ton of direction?”

mcv 7y ago
That is exactly the thing I select for. I recently had to hire 4 developers, and I was not all that interested in how many years of experience they had in javascript or typescript (our main language), and even less if you know Vue or Express (our stack). I mean, it's good to know javascript, and certainly ES6 or typescript, but I'm much more interested in: can I discuss stuff with you, do you have interesting opinions, can you make clear decisions in the face of unclear requirements, are you creative, and can you fix stuff and build features without anyone having to hold your hand? In case of doubt, knowledge of ES6 or Typescript or any relevant front-end framework (Vue, Angular or React) can make a lot of difference, but I'd rather hire someone who knows a dozen languages we don't use than someone who only knows exactly the one language we do use.
- scarface74 7y ago
  And then when you need to ship now you have a bunch of dead weight while you wait for them to ramp up. Also, since now you are taking time from your devs who do know the stack to mentor your new hires and code reviews because you can’t trust them to do good work without messing up your code base. They are now doing “negative work”.
  - bcrosby95 7y ago
    Compared to what, needing to ship now and not being able to find any "qualified candidates"? It really depends upon the exact situation. We can all make up bullshit examples to make either option look stupid.
    - scarface74 7y ago
      It’s “bullshit” to open req to hire a developer because you need to ship a product within the next six months and you need more bodies? Why are you hiring if you don’t need the extra people? If you didn’t need the extra people for a year until they ramp up, wouldn’t it be better just to take your time hiring until you found someone that didn’t have to spend a year learning on your dime and then leave in two years?
      - mcv 7y ago
        I needed extra people, but not merely warm bodies to fill a seat. I need people who don't need a year to ramp up, but can do so in a few weeks.
  - james_s_tayler 7y ago
    But if you're in a secondary employment market as opposed to startup heavy SV you might work with this person for a very long time or have a high chance of working together in the future. So the right, right now isn't always what people are optimizing for.
    - scarface74 7y ago
      After spending 10 years at one company and suffering from not learning anything new but just as importantly salary compression, for the next 8 years, and 5 jobs, I learned the best way to make more money is to do Resume Driven Development and change jobs. While your market value goes up tremendously, HR departments insists on giving 3-4% raises to existing employees while being forced to bring in new employees at market rates. This is the “secondary employment” market where HR policies aren’t optimized for in demand fields like software development. The immediate managers are usually helpless to do anything about it and see employees they spend time training leave for greener pastures. Being that is the reality, what other course is there but to find people you don’t have to train?
JMTQp8lwXL 7y ago
There is no "right way to hire". All "ways" are flawed and miss things. If hiring could've been solved by now, it would have already happened.

irrational 7y ago

I think what he is saying is, if you are hiring a React developer, but someone only has experience in Vue, would you not hire them because of their lack of React experience?

dcolkitt 7y ago

> the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. Almost all of these concepts could easily be learned in a few weeks by a talented engineer with strong fundamentals in software design and computer science. Polyfills aren't exactly quantum mechanics. They're not some radically different mental paradigm that takes years to develop fluidity. If you already have a sound basis in the major software engineering concepts, learning polyfills is just a matter of reading the docs to learn the details. Let's not forget that Jordan Walke was working on back-end infrastructure code just prior to inventing ReactJS. Miso Hevery was working on Java testing frameworks just before inventing AngularJS. So it's not like there's a history of front-end being such a unique problem domain, that it's impossible for outsiders to pick up. The only major sub-domain of software that I think this may potentially be true of is embedded systems. And even then, that's a big maybe.

JMTQp8lwXL 7y ago
As atomic points, I agree. Polyfills aren't rocket science. If the browser API is not defined, the use the polyfill function (at least, that's how most work, but then there's ponyfills, which don't pollute the global scope). But front-end development of complex applications isn't done in a vacuum by one person. It's done by multiple teams, possibly distributed across different physical locations. As an architect, what is your polyfill story? Does each team ship ES Modules that are later compiled by Webpack? Is each team responsible for loading their own? It's probably more efficient to handle it globally --knowing what all teams need at once as part of a build step-- to prevent duplicative loading of the same polyfill by 5 different teams. It gets nuanced quick. Nobody can master all these concepts --and reasonable ways of managing them in distributed team environments-- in a few weeks. And if you think JavaScript is "simple", I encourage reading "You Don't Know JS". What does "this" mean, in JavaScript? I could ask a handful of questions from the multitude of sections in this book, and people writing JavaScript for years wouldn't be able to answer all of them. React and Angular are such a thin slice of the overall problem. Even simple projects will require a dozen or so more NPM packages until you have something remotely useful.
- dcolkitt 7y ago

sdenton4 7y ago

That's more a question of overall area of past work, though, than particular language or framework. If you've been working on frontend stuff, problems of layout, matching redlines, response latency, etc, should be in your deck regardless of which programming language you've been using.