4 ms·

we hired a confident 2 year out bootcamp grad that was able to pass our interview process and he nearly destroyed our company, twice. There is a reason the inte

we hired a confident 2 year out bootcamp grad that was able to pass our interview process and he nearly destroyed our company, twice. There is a reason the interview is difficult to pass, being a dev is a job with an insane amount of responsibility, you do not want bad people in there.

onion2k 5y ago
you do not want bad people in there It sounds more like your company has failed to implement robust processes to catch mistakes before they're big problems to me. No individual should have the power to destroy the company except maybe a CTO or a lead sysadmin. For everything else important there should be layers of security and QA checks, with automated sanity checks on config and data for really important stuff. If a new hire can deploy stuff without multiple people seeing it before it gets to production then everyone in the company is responsible for accepting a process that can lead to serious issues.
- 0xB31B1B 5y ago
  Yes, we have a bad process, show me a company with < 8 devs and traction that has a good process lol.
  - onion2k 5y ago
    You recognise this and you didn't implement processes to catch problems after the first mistake (obviously, because there was a second mistake). If there's a third mistake I think you're going to have to accept it was partly your fault.
    - adwn 5y ago
      > after the first mistake (obviously, because there was a second mistake) What makes you think those two fuck ups by the same person where the same kind of mistake, or even related?
      - onion2k 5y ago
        I don't think that. I think that when someone fucks up so badly it almost ends the company you review all your processes and work to limit the possible damage any one person can do. That would be a matter of putting in lots of additional checks for things to start with, and then removing them as you figure out what things don't need multiple people's oversight. That sort of bureaucratic process is horrible and annoying, but it's less horrible and annoying than everyone losing their jobs when the company fails. We're very fortunate in tech that we can automate 99% of this stuff. Stopping someone pushing bad code that fails tests or hasn't been peer reviewed is a straightforward case of adding some deploy rules to a repo. It's much harder to fix processes where things are manual checklists people need to follow.
- adwn 5y ago
  This is what I call the "Perfect World Fallacy". Yes, in a perfect world, you'd be absolutely right. But that's not the reality we're living in – in particular, that's not the reality small and young companies are living in. When you're scaling up, or when you're short on staff, and there are fires to be put out everywhere, you just don't have the capacity to design and test those perfect processes. Where are they supposed to come from? > layers of security and QA checks, with automated sanity checks on config and data Ha! I've never, ever seen any company which comes even close to that platonic ideal.
  - onion2k 5y ago
    Yes, in a perfect world, you'd be absolutely right. A lot of companies choose not to do process oriented work, and just wing it instead because they believe they can go faster. That's fine. It's a choice driven by resources. What's not fine is complaining that someone you hire is "bad" because they get stuff wrong when you're forcing them to work without a process-based safety net. People will always make mistakes. If your belief is that everyone should be perfect because you've chosen the no-safety route then you don't get to complain when someone nearly sinks the company. Expecting people never to get things wrong is unreasonable, and it's the exact reason why we have processes to catch problems.
    - adwn 5y ago
      > If your belief is that everyone should be perfect [...] Well, you seem to believe there's such a thing as a perfect process. How is a non-perfect employee (or a group of non-perfect employees) supposed to come up with a perfect process? > [...] because you've chosen the no-safety route [...] Who said anything about no safety net? Maybe there was a process, or a safety net, but it wasn't perfect and didn't catch those mistakes?
    - 0xB31B1B 5y ago
      I didn’t fire him because he made 2 mistakes. I fired him because I was giving him 10-15 hrs/week of coaching and mentorship and he wasn’t improving at all. The process that was bad was our interview process and our process change was changing our interview process.
- renewiltord 5y ago
  Pretty strong disagree on this. I prefer working on teams that optimize for execution speed and just hire people who won’t go up in flames in that environment.
  - 0xB31B1B 5y ago
    this so much. Focusing on process and making the safest process will kill your team. Your best team members don't want to be hampered by a process that slows them down to protect them from their worst team members. The advantage you have as a startup is speed, don't throw it away so easily.
matsemann 5y ago
In a company there are seldom human failures, those are process failures. If deploying means sshing into prod server and messing around, anybody is going to eff that up sometime. That person is then not a failure, having to do those error prone tasks is the failure.
baetylus 5y ago
How can one person come close to destroying your company twice? Don't you have security measures in your pipeline to prevent this?

onion2k 5y ago

you do not want bad people in there It sounds more like your company has failed to implement robust processes to catch mistakes before they're big problems to me. No individual should have the power to destroy the company except maybe a CTO or a lead sysadmin. For everything else important there should be layers of security and QA checks, with automated sanity checks on config and data for really important stuff. If a new hire can deploy stuff without multiple people seeing it before it gets to production then everyone in the company is responsible for accepting a process that can lead to serious issues.

0xB31B1B 5y ago
Yes, we have a bad process, show me a company with < 8 devs and traction that has a good process lol.
- onion2k 5y ago
  You recognise this and you didn't implement processes to catch problems after the first mistake (obviously, because there was a second mistake). If there's a third mistake I think you're going to have to accept it was partly your fault.
  - adwn 5y ago
    > after the first mistake (obviously, because there was a second mistake) What makes you think those two fuck ups by the same person where the same kind of mistake, or even related?
    - onion2k 5y ago
      I don't think that. I think that when someone fucks up so badly it almost ends the company you review all your processes and work to limit the possible damage any one person can do. That would be a matter of putting in lots of additional checks for things to start with, and then removing them as you figure out what things don't need multiple people's oversight. That sort of bureaucratic process is horrible and annoying, but it's less horrible and annoying than everyone losing their jobs when the company fails. We're very fortunate in tech that we can automate 99% of this stuff. Stopping someone pushing bad code that fails tests or hasn't been peer reviewed is a straightforward case of adding some deploy rules to a repo. It's much harder to fix processes where things are manual checklists people need to follow.
adwn 5y ago
This is what I call the "Perfect World Fallacy". Yes, in a perfect world, you'd be absolutely right. But that's not the reality we're living in – in particular, that's not the reality small and young companies are living in. When you're scaling up, or when you're short on staff, and there are fires to be put out everywhere, you just don't have the capacity to design and test those perfect processes. Where are they supposed to come from? > layers of security and QA checks, with automated sanity checks on config and data Ha! I've never, ever seen any company which comes even close to that platonic ideal.
- onion2k 5y ago
  Yes, in a perfect world, you'd be absolutely right. A lot of companies choose not to do process oriented work, and just wing it instead because they believe they can go faster. That's fine. It's a choice driven by resources. What's not fine is complaining that someone you hire is "bad" because they get stuff wrong when you're forcing them to work without a process-based safety net. People will always make mistakes. If your belief is that everyone should be perfect because you've chosen the no-safety route then you don't get to complain when someone nearly sinks the company. Expecting people never to get things wrong is unreasonable, and it's the exact reason why we have processes to catch problems.
  - adwn 5y ago
    > If your belief is that everyone should be perfect [...] Well, you seem to believe there's such a thing as a perfect process. How is a non-perfect employee (or a group of non-perfect employees) supposed to come up with a perfect process? > [...] because you've chosen the no-safety route [...] Who said anything about no safety net? Maybe there was a process, or a safety net, but it wasn't perfect and didn't catch those mistakes?
  - 0xB31B1B 5y ago
    I didn’t fire him because he made 2 mistakes. I fired him because I was giving him 10-15 hrs/week of coaching and mentorship and he wasn’t improving at all. The process that was bad was our interview process and our process change was changing our interview process.
renewiltord 5y ago
Pretty strong disagree on this. I prefer working on teams that optimize for execution speed and just hire people who won’t go up in flames in that environment.
- 0xB31B1B 5y ago
  this so much. Focusing on process and making the safest process will kill your team. Your best team members don't want to be hampered by a process that slows them down to protect them from their worst team members. The advantage you have as a startup is speed, don't throw it away so easily.

matsemann 5y ago

In a company there are seldom human failures, those are process failures. If deploying means sshing into prod server and messing around, anybody is going to eff that up sometime. That person is then not a failure, having to do those error prone tasks is the failure.

baetylus 5y ago

How can one person come close to destroying your company twice? Don't you have security measures in your pipeline to prevent this?