4 ms·

You can't make that mistake in production. They were right to fail you. Considering these kinds of mistakes happen all the time in production: what exactly do

You can't make that mistake in production. They were right to fail you. Considering these kinds of mistakes happen all the time in production: what exactly do you mean? If such a mistake actually can't be tolerated, there is no way sysadmins would be allowed to log into a production system and run the risk of mucking it up in the first place. They'd be forced to do the responsible thing and implement changes in a test environment, and use configuration management to replicate the change into production. Possibly in a maintenance window, certainly with a rollback strategy. Paradoxically, the no-mistakes-ever environment makes the parent poster's fuckup as even less of a red mark than it otherwise would be. In a more flexible shop, there is some level of chance he made the mistake on a live box, in a controlled shop there is none (excluding some phases of disaster recovery ofc).

quesera 10y ago
I absolutely agree with most of that you've said. But remember, this happened in an evaluation environment. Not a day to day work environment. If you can't fail an eval by locking yourself out and being unable to complete the task, how do you fail? The ideal is proper config management, test/stage/prod envs, automated deployment, etc. I've come close to that ideal at certain points in the past, but it's far from universal. Remember the problem is that OP was using unfamiliar tools and being careless. We have all made that mistake, but for it to happen in an eval or an interview has to be a failure. In day to day ops, it would be tough to justify giving root access. You want to pass or hire the person who will not do that because they have already cleaned up that sort of mess in the past. As OP states in followup, they weren't interviewing for a systems admin position, which does change the equation. If the eval board is sitting on your desk and requires just a firmware flash to recover, then OK, it's safe to not care so much.

quesera 10y ago

I absolutely agree with most of that you've said. But remember, this happened in an evaluation environment. Not a day to day work environment. If you can't fail an eval by locking yourself out and being unable to complete the task, how do you fail? The ideal is proper config management, test/stage/prod envs, automated deployment, etc. I've come close to that ideal at certain points in the past, but it's far from universal. Remember the problem is that OP was using unfamiliar tools and being careless. We have all made that mistake, but for it to happen in an eval or an interview has to be a failure. In day to day ops, it would be tough to justify giving root access. You want to pass or hire the person who will not do that because they have already cleaned up that sort of mess in the past. As OP states in followup, they weren't interviewing for a systems admin position, which does change the equation. If the eval board is sitting on your desk and requires just a firmware flash to recover, then OK, it's safe to not care so much.