If you'd like to know more about the process described in the article, we've recently blogged about it:
https://www.compose.io/articles/compose-hiring-scaling-to-10...
We have a bunch of postings up right now for those of you who are looking to give something like this a try (you may have seen us looking in the latest Who's Hiring):
If you have any questions, I'll be more than happy to answer.
The "instructions" for the sample test were either purposely obfuscated or just badly written and it reflected poorly on the merit of your documentation methods more so than anything else.
To be quite honest, you are nothing more than an arm of IBM at this point and I would never work for a company that so carelessly devalues developer time and then comes into a forum arguing with random developers that they are right and everyone who disagrees is wrong.
In all seriousness though, what do you guys even do? Set up etcd for a cluster? Or PostgreSQL? etc.? Do you have any idea how simple that is these days?
For all interested: the work sample was focused around alerting DevOps via third-party services like Slack and PagerDuty. In other words: I imagine the developer positions here are simultaneously "on-call" operations positions as well! haha!
Good luck, Compose Team. You're going to need it! :)
If you were an applicant of such impressive, world renowned stature the answer would be: yes, (sir), you still need to go through the regular hiring process.
It isn't an arbitrary request, like building a JavaScript calculator. The samples we ask that you complete closely resemble the type of work you'd do in the role.
When hiring engineers for example, we take a piece of our application, take a chunk out, then ask you to complete it.
If you're a major talent, it's maybe 2-3 hours of work.
If you were to circumvent this, or feel you "shouldn't have to do this", what message does that send to the rest of the team?
We're a remote, self-managing, and loosely structured group - would it be wise to suggest that you are to be treated differently than the rest of us?
It sends a poor message and reflects on the (entitled) attitude of the candidate.
Team work makes the dream work.
Each region needs to have a "proxy" manager to take care of the employees within that region. As we had Canadians and folks from London with us at the time of the acquisition, we were set-up respectively.
We hired an excellent engineer out of Germany before we were clear on the processes, and it's added a significant amount of time to getting him into the the swing of things.
To avoid this discomfort, we're narrowing the region.
Hopefully, this is something that will ease in the future - it stings every time we have to turn away someone potentially brilliant from places like Brazil or Israel.
For your edit: The former is correct. Anyone with the right to work in/through the UK. You can work _from_ anywhere you'd like! I prefer at home in my jammies.
Typo:
"Our two main offices are located in San Fransisco, California..."
should be: "...San Francisco..."
Also, why does your map show SM, CA, rather than SF, CA? Did you move and not yet update the map?
We need to update the map...
Thanks for pointing that out.
For developers, we extract some production application code, remove some features, and give people relatively open ended "implement a feature to solve X problem" instructions. The criteria for those range from "idiomatic code" to "good enough to ship right now" to "good UX", depending on what specific type of dev we're after.
For support, we pull actual tickets and ask for responses + documentation. Criteria for those are things like "technically accurate" and "doesn't overpromise".
Others could be writing samples (we have a new feature, write a how-to) or even a marketing plan.
After the sample project, we do a "work day" in place of a series of interviews. These are typically continuations of what the sample project was, and involve a whole day on Slack / video / whatever with people they'd be working with.
People are poor judges of value in other people, and don't want to spend that much time on it. So how would you "know" someone is a diamond-in-the-rough, and not just rough? That would require a lot more knowledge, perhaps a referral in the team of someone who has already identified them as good talent. Or you could just hire all the roughs and fire the ones that don't turn out to be diamonds.
It is like hiring someone with a criminal record. Ya, great value! But wait, what if they go back to their old ways? Biases are optimizations based on experience (or perhaps cultural influences); they are not perfect, but they often have groundings in reality. The best companies are able to work through all the pros and cons rationally, and known when the risks are worth it.
But it's actually really hard to do what we're doing. It's not hard in the "can I get a rocket to land itself?" sense, it's more of a grind and commitment problem. It's hard to spend the time developing a new position in a way that works with our process (2-3 weeks of work, minimum), it's tiring to keep up with people who apply, it's painful to fight for rigorous hiring criteria. I can see why places just go with the default.
