6 ms·

No disrespect intended, and with the qualification that exam-taking is a stressful environment for many people, but.. You can't make that mistake in production

by quesera 10y ago

No disrespect intended, and with the qualification that exam-taking is a stressful environment for many people, but.. You can't make that mistake in production. They were right to fail you. I can see that it was a side effect of being more cautious than usual (so unaware of the effects of your actions), but that demonstrates a different problem. All of which is to say, that you tried and failed, which puts you ahead of the people which didn't try at all, and imparts some hard won learning that will benefit you next time. We've all been there. But you can't overlook a mistake like that. It shows that you were not ready to pass the evaluation in question. The rest of your actions (acknowledgement, discussion of error etc) show that you should be ready next time. But to shortcut it would be a mistake.

forgottenpass 10y ago
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.
wyldfire 10y ago
> You can't make that mistake in production. They were right to fail you. shrug I kinda agree, sorta. It's certainly not what I would imagine is the intent of the test. But I definitely made it so I could not complete the test objectives. > But you can't overlook a mistake like that. I dunno, would you fire me if I'd done it at Amazon? Seems like a simple recovery. Note that the position I was interviewing for was not a support or sysadmin job. I'm a design engineer. I'd have been designing the tests most likely! I even imagined how I could spin it into a feature I could work on to recover/reset the system, scoring that event however they deemed appropriate. Where I've worked, if anyone ever bork'd a system you reload it and move on. We're not supporting customers, so there's never any discipline that would result. The worst you could do is brick a $1-2k devboard or a limited-run early prototype production unit. The latter could cause delays but it's always chalked up to mistakes and that's why they build more than one prototype.
- quesera 10y ago
  Well of course I'm coming from my own context, where remote mission critical servers are the norm. The problem is that the mistake you made was not knowing your tools, and being careless. That can't be an acceptable combination. On the other hand, automated grading is useless, and your role might never involve the same concerns about recoverability. It's a big industry, but in my little corner of it, a person who locked themselves out of root during an interview would be very hard to support in a hiring meeting.
mrbill 10y ago
> You can't make that mistake in production. They were right to fail you. When I took the RHCE exam, someone made an extremely simple mistake similar to this that led to the machine (a VM) being unusable. They knew exactly what they'd done, they knew how it could be fixed, etc - and the instructor sympathized and was apologetic, but it was just not allowed for them to restart that portion of the cert exam over, and it was impossible to pass without this section. The person in question had to pay to re-take the exam at a later date.

by quesera 10y ago

forgottenpass 10y ago

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.

wyldfire 10y ago

> You can't make that mistake in production. They were right to fail you. shrug I kinda agree, sorta. It's certainly not what I would imagine is the intent of the test. But I definitely made it so I could not complete the test objectives. > But you can't overlook a mistake like that. I dunno, would you fire me if I'd done it at Amazon? Seems like a simple recovery. Note that the position I was interviewing for was not a support or sysadmin job. I'm a design engineer. I'd have been designing the tests most likely! I even imagined how I could spin it into a feature I could work on to recover/reset the system, scoring that event however they deemed appropriate. Where I've worked, if anyone ever bork'd a system you reload it and move on. We're not supporting customers, so there's never any discipline that would result. The worst you could do is brick a $1-2k devboard or a limited-run early prototype production unit. The latter could cause delays but it's always chalked up to mistakes and that's why they build more than one prototype.

quesera 10y ago
Well of course I'm coming from my own context, where remote mission critical servers are the norm. The problem is that the mistake you made was not knowing your tools, and being careless. That can't be an acceptable combination. On the other hand, automated grading is useless, and your role might never involve the same concerns about recoverability. It's a big industry, but in my little corner of it, a person who locked themselves out of root during an interview would be very hard to support in a hiring meeting.

mrbill 10y ago

> You can't make that mistake in production. They were right to fail you. When I took the RHCE exam, someone made an extremely simple mistake similar to this that led to the machine (a VM) being unusable. They knew exactly what they'd done, they knew how it could be fixed, etc - and the instructor sympathized and was apologetic, but it was just not allowed for them to restart that portion of the cert exam over, and it was impossible to pass without this section. The person in question had to pay to re-take the exam at a later date.