Zappos employs the same strategy by offering up money for someone to leave. People who take the money aren't the type of person they want at Zappos. They won't fit in.
The military does this as well. Basic training is more than just training. If you can't get through basic training, you aren't the type of person that will work out in the military.
As for cleaning the bathroom: It's not cleaning the bathroom. It's shared ownership in the upkeep, presentation, and workings of the company. It's a small company, so everyone knows everyone I imagine. Someone not willing to clean the bathroom would probably not fit into the company.
You seem stuck on the fact that it's cleaning a bathroom.
What about committing code the first day you're on the job? Being forced to take ownership. What about being handed a computer and being told to put it together?
Lots of companies have rituals their first day. Things the new guy does that essentially boils down to the final test to see if they'll belong. If they'll fit in.
Don't make the assumption that the strategy is only cleaning a bathroom. Don't assume you have to clean a bathroom.
> What about committing code the first day you're on the job?
Wow, talk about another test that would be super successful. I'm not sure I want to work at any place where any first-dayer is made to break the build in the name of shared ownership by checking in code to a codebase he couldn't have possibly had enough time to understand to a necessary level. I suppose he will be fixing it later that evening, in the name of shared upkeep.
Responsibility and desire to belong will naturally drive the new guy (it's not like it'd be a woman, is it?) to commit something small, simple, and in the big picture totally irrelevant. As with all of these tests, what you actually get is a token activity that will tell you nothing useful and that will fail to screen out anyone who doesn't want to be screened out, company fit or otherwise.
The military is the only setting in which these tests will be useful, because there being masculine and doing whatever the boss says the company needs doing with no questions asked is the entirety of the job description.
> Wow, talk about another test that would be super successful. I'm not sure I want to work at any place where any first-dayer is made to break the build in the name of shared ownership by checking in code to a codebase he couldn't have possibly had enough time to understand to a necessary level. I suppose he will be fixing it later that evening, in the name of shared upkeep.
You make an awful lot of wrong assumptions here. Who said anything about breaking a build? And while they may not be major projects, bug fixes go a long way.
I can only say that if those things are the first things that came to your mind, I'd hate to work at the places you've worked out.
> As with all of these tests, what you actually get is a token activity that will tell you nothing useful and that will fail to screen out anyone who doesn't want to be screened out, company fit or otherwise.
We'll have to disagree then. Granted, with the vast number of successful companies employing these strategies, I feel I'm in good company.
Unless you have a ten-line† program or one hell of a suite of unit tests documenting every single interaction with the world your system ever performs‡, you can never be sure that a first-day employee 'fixing' a bug hasn't introduced a new obscure one somewhere.
It's not like being told to put together your computer or your desk, where the only environment you'd be changing is your own.
> We'll have to disagree then.
About which part? Do you deny that this test is trivial to game for those who want to game it? Or do you claim that just passing this test, at whatever motivation, is a useful signal? If so, what does it signal, other than not being philosophically opposed to meaningless tests?
† hyperbole; ‡ most real world brownfield projects don't
> Unless you have a ten-line† program or one hell of a suite of unit tests documenting every single interaction with the world your system ever performs‡, you can never be sure that a first-day employee 'fixing' a bug hasn't introduced a new obscure one somewhere.
New employee creates test to cover bug.
Fixes bug.
Runs test suite. Test suite passes.
Commits code.
All under the watchful eye of another developer.
You keep pushing specific work environments into different situations. Not all tests work for all cases. Stop assuming this. Your entire argument against this strategy is that X doesn't work in Y. You ignore that X works with X.
> Do you deny that this test is trivial to game for those who want to game it?
Yes, if you want to work for a company that does something you don't like, it's easy to game.
> Or do you claim that just passing this test, at whatever motivation, is a useful signal?
If you choose to do the task rather than just game it, it helps in several specific ways. Taking the code committing part, it ensures you have everything set up correct, from development environment, testing suite, VM, connections to dev, intergrated, staging and live, etc. You have your editor setup, connections to source control, understand the ticketing system.
Their is a lot of value knowing that everything is setup. There is also a lot of value with the person knowing they just deployed code.
> other than not being philosophically opposed to meaningless tests?
Just because you assume something is meaningless doesn't mean it is.
> About which part?
About the strategy being useful or not. You think the strategy is useless. I believe it's not, and has proven it's value.
That being said, the only thing you've done is construct hypothetical worst case scenarios and question how it's good, which is next to worthless.
If you have honest questions about the strategy, go ahead and ask. If you just want to play more games with hypothetical situations, let's just end the discussion here.
>> other than not being philosophically opposed to meaningless tests?
> Just because you assume something is meaningless doesn't mean it is.
For the record, I meant philosophically opposed to tests the tested believes to be meaningless - which is the only useful definition.
Your explanations push the hypothetical case far, far away from the test presented initially. It sounds less like the equivalent of cleaning bathrooms and more like actual work. I will end the discussion now.
> For the record, I meant philosophically opposed to tests the tested believes to be meaningless - which is the only useful definition.
Then, for the record, in this case, it helps to highlight people who think they know it all when they really don't.
> Your explanations push the hypothetical case far, far away from the test presented initially. It sounds less like the equivalent of cleaning bathrooms and more like actual work.
Again, confusing execution and strategy.
But then again, you're philosophically opposed to tests the you believe are meaningless.
The military does this as well. Basic training is more than just training. If you can't get through basic training, you aren't the type of person that will work out in the military.
As for cleaning the bathroom: It's not cleaning the bathroom. It's shared ownership in the upkeep, presentation, and workings of the company. It's a small company, so everyone knows everyone I imagine. Someone not willing to clean the bathroom would probably not fit into the company.
You seem stuck on the fact that it's cleaning a bathroom.
What about committing code the first day you're on the job? Being forced to take ownership. What about being handed a computer and being told to put it together?
Lots of companies have rituals their first day. Things the new guy does that essentially boils down to the final test to see if they'll belong. If they'll fit in.
Don't make the assumption that the strategy is only cleaning a bathroom. Don't assume you have to clean a bathroom.