4 ms·

One of the things I like asking candidates is "Tell me about a time you screwed up so royally that you were sure you were getting fired." Let's be honest, we a

One of the things I like asking candidates is "Tell me about a time you screwed up so royally that you were sure you were getting fired." Let's be honest, we all have one or two.. and if you don't, then your one or two are coming. It's what you learned to do differently that I care about. And if you don't have one, you're either a) incredibly lucky, b) too new to the industry, or c) lying.

mootothemax 14y ago
One of the things I like asking candidates is "Tell me about a time you screwed up so royally that you were sure you were getting fired." I asked similar, and agree that it's a really useful question. I think it's an especially great one for startups, as successful candidates are more likely to come into contact with production systems. For these positions you not only want people capable of recovering accidents, but also people who have screwed up because, conversely, they've been trusted not to screw up. Those who've never been trusted enough to not damage a system are unlikely to be of much use.
blowski 14y ago
This. We all mess up, but only the best ones will deal with it professionally and learn from it. Sounds like the OP is in that group. He didn't try to hide it, blame it on anyone else, or make excuses. He just did what he could to fix his mistake. When people say "making mistakes is unacceptable - imagine if doctors made mistakes" they ignore three facts: 1. Doctors do make mistakes. Lots of them. All the time. 2. Even an average doctor is paid an awful lot more than me. 3. Doctors have other people analysing where things can go wrong, and recommending fixes. If you want fewer development mistakes, as a company you have to accept it will cost money and take more time. It's for a manager to decide where the optimal tradeoff exists.
- jiggy2011 14y ago
  > If you want fewer development mistakes, as a company you have to accept it will cost money and take more time. It's for a manager to decide where the optimal tradeoff exists. This is absolutely it, of course it is possible to become so risk averse that you never actually succeed in getting anything done and there are certainly organisations that suffer from that (usually larger ones). However some people seem to take the view that it is impossible to protect oneself from all risks therefor it is pointless protecting from any of them. The good news is that usually protecting against risks tends to get exponentially more expensive as you add "nines" therefor having a 99% guarantee against data loss is a lot cheaper than a 99.999% guarantee. Having a cronjob that does a mysqldump of an entire database, emails some administrator and then does rsync to some other location (even just a dropbox folder) is something that is probably only a couple of hours work.
- mcritz 14y ago
  > We all mess up, but only the best ones will deal with it professionally and learn from it. This. I don't regret my life's many failures. I regret the times I've flamed out, blamed others, or ran away. Doing things means making mistakes. You can spot a professional by how they deal with mistakes.
- Nick_C 14y ago
  The aviation industry is the same. Most aviation authorities around the world have a no-fault reporting system so that fixes can get implemented without pilots worrying about losing their job.
ismarc 14y ago
Part of our culture/personality/team fit questions is like this. We also have one that's something like "tell me about a time you failed a commitment (deadline, etc) and how you handled it". Numerous people with over a decade claim perfect records, frequently blaming all those around them as having failed. It's been a real easy way to eliminate candidates, particularly because almost every team member we have gave an example that was within like a month of when they interviewed.
- jiggy2011 14y ago
  Interesting, though perhaps they misinterpreted the question. Some companies seem to have a culture where you never admit failure and perhaps they assumed that was the answer you were looking for?
  - ismarc 14y ago
    All of the failed responses weren't just not admitting failure, but directly blaming others. One example was a team lead in charge of a project where they said the developers missed their deadlines and would "whine" about not having enough details to do their job. Someone who didn't have an example of failing to deliver, but had examples of near misses they were able to save would even be good examples. Playing the blame game, though, just doesn't fit.
  - PeterisP 14y ago
    Well, that's the whole point - you really don't want to accidentally hire somebody who is "infected" with a culture of never admitting failure.
pjungwir 14y ago
In my first year as an engineer, I shut off the production application server. It was an internally-developed app server built in & for an internally-developed language, with its own internally-developed persistence mechanism, and it was my first day working with it. I had several terminals open, and in one I'd logged on to production to check how the data was formatted, so I could get something comparable for my dev environment. Unfortunately I forgot to log off, and at some point I issued the `stop server` command, thinking I was doing it on dev. A few minutes later the project leader, one of the most senior engineers, came over and started yelling at me. Fortunately not much was lost (other than a few users' sessions--not a high-traffic site). But I was really appalled at my mistake and I certainly wondered if I was about to be fired. Since then I've taken steps to (1) keep myself off production as much as possible (2) make a production terminal visually distinct from a non-production one. As a sometime project leader myself now, I also make sure newcomers can easily obtain an adequate development environment, and I don't give out the production login to every junior dev. :-)
benjaminwootton 14y ago
I disagree with this. In most companies there's enough process to protect you from the big screw ups.
bashinator 14y ago
Or d) too scared/timid to be an effective employee and learn new skills.

mootothemax 14y ago

One of the things I like asking candidates is "Tell me about a time you screwed up so royally that you were sure you were getting fired." I asked similar, and agree that it's a really useful question. I think it's an especially great one for startups, as successful candidates are more likely to come into contact with production systems. For these positions you not only want people capable of recovering accidents, but also people who have screwed up because, conversely, they've been trusted not to screw up. Those who've never been trusted enough to not damage a system are unlikely to be of much use.

blowski 14y ago

This. We all mess up, but only the best ones will deal with it professionally and learn from it. Sounds like the OP is in that group. He didn't try to hide it, blame it on anyone else, or make excuses. He just did what he could to fix his mistake. When people say "making mistakes is unacceptable - imagine if doctors made mistakes" they ignore three facts: 1. Doctors do make mistakes. Lots of them. All the time. 2. Even an average doctor is paid an awful lot more than me. 3. Doctors have other people analysing where things can go wrong, and recommending fixes. If you want fewer development mistakes, as a company you have to accept it will cost money and take more time. It's for a manager to decide where the optimal tradeoff exists.

jiggy2011 14y ago
> If you want fewer development mistakes, as a company you have to accept it will cost money and take more time. It's for a manager to decide where the optimal tradeoff exists. This is absolutely it, of course it is possible to become so risk averse that you never actually succeed in getting anything done and there are certainly organisations that suffer from that (usually larger ones). However some people seem to take the view that it is impossible to protect oneself from all risks therefor it is pointless protecting from any of them. The good news is that usually protecting against risks tends to get exponentially more expensive as you add "nines" therefor having a 99% guarantee against data loss is a lot cheaper than a 99.999% guarantee. Having a cronjob that does a mysqldump of an entire database, emails some administrator and then does rsync to some other location (even just a dropbox folder) is something that is probably only a couple of hours work.
mcritz 14y ago
> We all mess up, but only the best ones will deal with it professionally and learn from it. This. I don't regret my life's many failures. I regret the times I've flamed out, blamed others, or ran away. Doing things means making mistakes. You can spot a professional by how they deal with mistakes.
Nick_C 14y ago
The aviation industry is the same. Most aviation authorities around the world have a no-fault reporting system so that fixes can get implemented without pilots worrying about losing their job.

ismarc 14y ago

Part of our culture/personality/team fit questions is like this. We also have one that's something like "tell me about a time you failed a commitment (deadline, etc) and how you handled it". Numerous people with over a decade claim perfect records, frequently blaming all those around them as having failed. It's been a real easy way to eliminate candidates, particularly because almost every team member we have gave an example that was within like a month of when they interviewed.

jiggy2011 14y ago
Interesting, though perhaps they misinterpreted the question. Some companies seem to have a culture where you never admit failure and perhaps they assumed that was the answer you were looking for?
- ismarc 14y ago
  All of the failed responses weren't just not admitting failure, but directly blaming others. One example was a team lead in charge of a project where they said the developers missed their deadlines and would "whine" about not having enough details to do their job. Someone who didn't have an example of failing to deliver, but had examples of near misses they were able to save would even be good examples. Playing the blame game, though, just doesn't fit.
- PeterisP 14y ago
  Well, that's the whole point - you really don't want to accidentally hire somebody who is "infected" with a culture of never admitting failure.

pjungwir 14y ago

In my first year as an engineer, I shut off the production application server. It was an internally-developed app server built in & for an internally-developed language, with its own internally-developed persistence mechanism, and it was my first day working with it. I had several terminals open, and in one I'd logged on to production to check how the data was formatted, so I could get something comparable for my dev environment. Unfortunately I forgot to log off, and at some point I issued the `stop server` command, thinking I was doing it on dev. A few minutes later the project leader, one of the most senior engineers, came over and started yelling at me. Fortunately not much was lost (other than a few users' sessions--not a high-traffic site). But I was really appalled at my mistake and I certainly wondered if I was about to be fired. Since then I've taken steps to (1) keep myself off production as much as possible (2) make a production terminal visually distinct from a non-production one. As a sometime project leader myself now, I also make sure newcomers can easily obtain an adequate development environment, and I don't give out the production login to every junior dev. :-)

benjaminwootton 14y ago

I disagree with this. In most companies there's enough process to protect you from the big screw ups.

bashinator 14y ago

Or d) too scared/timid to be an effective employee and learn new skills.