4 ms·

I'd say it goes deeper than this: there's a greater emphasis today on the candidate being productive from day one. I don't know what is causing it (too much ex

I'd say it goes deeper than this: there's a greater emphasis today on the candidate being productive from day one. I don't know what is causing it (too much exposure to efficient software?), but in many industries hiring managers would rather keep looking for an absolute perfect candidate while leaving behind several that have the skills but need the training. I have heard the stories about managers spending 100 extra hours looking for a perfect candidate instead of hiring the best available and dedicating even 50 hours to train them to speed.

vonmoltke 11y ago
> I'd say it goes deeper than this: there's a greater emphasis today on the candidate being productive from day one. Which drives me crazy. Nobody can be truly productive on day one. You have processes to learn, even if it is just an informal "way we do things". You have existing code to become familiar with. You have team dynamics to work into. It takes time. Personally, I cringe whenever I read a job advert mentioning that the candidate will "push to production on day one". Neither company I have worked for would allow that, let alone expect it. Nor would any company I start in the future, should I ever manage to.
- eropple 11y ago
  I agree that in the general case it's very unlikely for your average developer to be truly productive on day one, but I wouldn't say that nobody is. This is a large part of my value prop: I spend the first day or two getting infodumps to get up to speed, but even during that time I'm building up plans of attack to get done what I'm being paid to get done (and to me and to the people paying for me, that is productive). I'm a consultant/contractor (depending on the gig), though, so the social dynamic is different and it's less about integrating into a team and more about understanding the exact problem domain.
- woah 11y ago
  I think that you don't get it about pushing to production on day one. These companies do that to because they have resilient systems, tests, and tooling, and they push to production all the time. Pushing to production on day one is a way to introduce new hires to the continuous deployment methodology. If you're afraid of pushing to production, there's a problem.
  - potatolicious 11y ago
    I don't think it's the fear of pushing to production on day one, but that a day one employee would not yet be able to produce anything worthwhile enough to push. A very well tested codebase with resilient systems and tooling takes time to learn, it will take time for a person to become productive within it - and that time is a lot longer than the 4 or so hours you get on your first day after the legal paperwork is done ;) So pushing on day one - regardless of dangers it poses to the system - seems like pushing to production for the sake of pushing to production. On another note though - I've worked at companies that have adhered to best practices and done remarkably well with continuous deployment and testing, but the risk of a pushing code to production is never zero. The intent of testing and resiliency is to reduce the odds of catastrophe and increase your confidence in your systems - not to make you overly cavalier.
    - alxndr 11y ago
      At my current job, we aim for a new employee to push to prod on day one not because we want the employee to begin churning out valuable work immediately, but because we want them to quickly become familiar and comfortable with the development, QA, & deployment workflows and tools. The ticket that gets deployed is often as simple as a typo fix or a small CSS tweak, just to illustrate the whole process. The risk of deploying to prod isn't zero, but since we deploy many times a week already, the risk of deploying a typo fix is pretty low to us. It also serves as a test for the existing employees: ideally those workflows are smooth enough that it all Just Works on a freshly-set-up environment and account, and we are comfortable enough with our rollback strategy that (after reviewing and testing) we are not afraid of merging in and deploying our new employees' code.
  - s73v3r 11y ago
    I believe they think that. I don't really believe that they do.
- DaveWalk 11y ago
  It gets to me as well. I thought it might have just been my lack of skills, but I've had this conversation across several fields with recruiters who have said similar things. The best description I've heard is that it's a spectrum from "100% training provided" to "productive on day one." Older recruiters tell me that decades ago the spectrum was too far in the other direction -- willing to hire anyone, and piling on the training. But now it's too far the other way, dropping good candidates who aren't able to perform independently on day one.
- aianus 11y ago
  It's not like you push anything important your first day. You spend two hours doing some simple bug fix that would usually take you 15 min and then spend the next six hours learning how the CI and deployment pipeline works, usually with someone holding your hand.
  - tracker1 11y ago
    CI and deployment pipeline?!? What are you a spoiled millenials thinking... we build local, and copy the whole folder over RDP copy/paste onto the production server. You may laugh, but I've seen that far more often than an actual CI/CD process in place...
    - Terr_ 11y ago
      Don't forget the only documentation is a printout someone remembered they had in a drawer.
      - aianus 11y ago
        ^ Maybe we've uncovered what companies are trying to signal when they say you can push to prod your first day :)
    - tbomb 11y ago
      I've been at more than one place that does this (one just had a sys admin be the one to do it, after it was user tested) :( Both were pretty entry level positions.
wishiknew 11y ago
Glad to know I'm not alone there. I had an interview with this company where I was told technical skills weren't the most important, personality was. Luckily for me, they really liked me. Ten days later, I go to a second interview where they ask me pretty advanced technical questions. I don't panic and I end up doing extremely well. So at this point they've told me my personality was good for the position, and also saw I happened to be a solid programmer. The day after that second interview, they call me: - hey, we're not going to give you that position because you didn't learn the [completely minor] framework by yourself since the last interview. - yeah, I have a job. Also, you didn't ask me to? - we do that on purpose to see if you're independent enough. - OK, I definitely think I am, what should I do? - I can't help you there, spend a week on this, come up with something and we'll see how we like it. - a week?! Also, don't you have a client request example or anything? - nope. Eventually they decided that even if I were to do that, the disappointment on their side had been too huge… The funniest in this is that 'agile' is part of their corporate identity, the word's everywhere on their website, they even criticized the way I'm working with my current employer because he's not 'agile' enough (which is true, but I have no power over this). But then they want to hire somebody and not even have to give him a few pointers, because that's too vulgar for them? What the fuck is this?

vonmoltke 11y ago

> I'd say it goes deeper than this: there's a greater emphasis today on the candidate being productive from day one. Which drives me crazy. Nobody can be truly productive on day one. You have processes to learn, even if it is just an informal "way we do things". You have existing code to become familiar with. You have team dynamics to work into. It takes time. Personally, I cringe whenever I read a job advert mentioning that the candidate will "push to production on day one". Neither company I have worked for would allow that, let alone expect it. Nor would any company I start in the future, should I ever manage to.

eropple 11y ago
I agree that in the general case it's very unlikely for your average developer to be truly productive on day one, but I wouldn't say that nobody is. This is a large part of my value prop: I spend the first day or two getting infodumps to get up to speed, but even during that time I'm building up plans of attack to get done what I'm being paid to get done (and to me and to the people paying for me, that is productive). I'm a consultant/contractor (depending on the gig), though, so the social dynamic is different and it's less about integrating into a team and more about understanding the exact problem domain.
woah 11y ago
I think that you don't get it about pushing to production on day one. These companies do that to because they have resilient systems, tests, and tooling, and they push to production all the time. Pushing to production on day one is a way to introduce new hires to the continuous deployment methodology. If you're afraid of pushing to production, there's a problem.
- potatolicious 11y ago
  I don't think it's the fear of pushing to production on day one, but that a day one employee would not yet be able to produce anything worthwhile enough to push. A very well tested codebase with resilient systems and tooling takes time to learn, it will take time for a person to become productive within it - and that time is a lot longer than the 4 or so hours you get on your first day after the legal paperwork is done ;) So pushing on day one - regardless of dangers it poses to the system - seems like pushing to production for the sake of pushing to production. On another note though - I've worked at companies that have adhered to best practices and done remarkably well with continuous deployment and testing, but the risk of a pushing code to production is never zero. The intent of testing and resiliency is to reduce the odds of catastrophe and increase your confidence in your systems - not to make you overly cavalier.
  - alxndr 11y ago
    At my current job, we aim for a new employee to push to prod on day one not because we want the employee to begin churning out valuable work immediately, but because we want them to quickly become familiar and comfortable with the development, QA, & deployment workflows and tools. The ticket that gets deployed is often as simple as a typo fix or a small CSS tweak, just to illustrate the whole process. The risk of deploying to prod isn't zero, but since we deploy many times a week already, the risk of deploying a typo fix is pretty low to us. It also serves as a test for the existing employees: ideally those workflows are smooth enough that it all Just Works on a freshly-set-up environment and account, and we are comfortable enough with our rollback strategy that (after reviewing and testing) we are not afraid of merging in and deploying our new employees' code.
- s73v3r 11y ago
  I believe they think that. I don't really believe that they do.
DaveWalk 11y ago
It gets to me as well. I thought it might have just been my lack of skills, but I've had this conversation across several fields with recruiters who have said similar things. The best description I've heard is that it's a spectrum from "100% training provided" to "productive on day one." Older recruiters tell me that decades ago the spectrum was too far in the other direction -- willing to hire anyone, and piling on the training. But now it's too far the other way, dropping good candidates who aren't able to perform independently on day one.
aianus 11y ago
It's not like you push anything important your first day. You spend two hours doing some simple bug fix that would usually take you 15 min and then spend the next six hours learning how the CI and deployment pipeline works, usually with someone holding your hand.
- tracker1 11y ago
  CI and deployment pipeline?!? What are you a spoiled millenials thinking... we build local, and copy the whole folder over RDP copy/paste onto the production server. You may laugh, but I've seen that far more often than an actual CI/CD process in place...
  - Terr_ 11y ago
    Don't forget the only documentation is a printout someone remembered they had in a drawer.
    - aianus 11y ago
      ^ Maybe we've uncovered what companies are trying to signal when they say you can push to prod your first day :)
  - tbomb 11y ago
    I've been at more than one place that does this (one just had a sys admin be the one to do it, after it was user tested) :( Both were pretty entry level positions.

wishiknew 11y ago

Glad to know I'm not alone there. I had an interview with this company where I was told technical skills weren't the most important, personality was. Luckily for me, they really liked me. Ten days later, I go to a second interview where they ask me pretty advanced technical questions. I don't panic and I end up doing extremely well. So at this point they've told me my personality was good for the position, and also saw I happened to be a solid programmer. The day after that second interview, they call me: - hey, we're not going to give you that position because you didn't learn the [completely minor] framework by yourself since the last interview. - yeah, I have a job. Also, you didn't ask me to? - we do that on purpose to see if you're independent enough. - OK, I definitely think I am, what should I do? - I can't help you there, spend a week on this, come up with something and we'll see how we like it. - a week?! Also, don't you have a client request example or anything? - nope. Eventually they decided that even if I were to do that, the disappointment on their side had been too huge… The funniest in this is that 'agile' is part of their corporate identity, the word's everywhere on their website, they even criticized the way I'm working with my current employer because he's not 'agile' enough (which is true, but I have no power over this). But then they want to hire somebody and not even have to give him a few pointers, because that's too vulgar for them? What the fuck is this?