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):
Yep, I have looked over your sample test. It was in both Go and Ruby. I finished the Go section and then decided against bothering with the rest.
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! :)
So you are telling us that if we had a PhD, multiple awards from previous companies for actual work and not politicking/backstabbing/brownnosing, Coursera/edX certificates relevant to your area of business with almost 100% success rate on their most difficult courses, can program in 50+ languages, you would still ignore our past success and we have to go through your normal hiring process? I am sure this would bring you plenty proven world-class talent... /s
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.
I think you guys will do great for junior folks (where a resume with little experience would be a hinderance traditionally) or perhaps people who are willing to jump through hoops to work from home, but I don't see it catching on (unfortunately?).
> 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?
Does everyone on your team get paid the same? If not, does that not send the same message? Is your HR process willing to let top talent go to a competitor who doesn't require such a test?
(All real questions, not rhetorical)
Are you paid to write hard code, or are you paid to solve a problem? If solving that problem involves things that aren't challenging or "up to your skill level", will you still do them?
I'm a software developer. But, a few weeks ago, the Most Important Thing for me to do was get some art made and printed onto foam-core. Traditionally, that is not my job, and it doesn't match my skillset, but it needed to be done and I was the person best positioned to do it.
This is definitely situation-dependent. I work for the services part of our organization, where it is more important that you do what is needed than what you enjoy or are good at. However, for the pure engineering part of our organization, I want to hire you to do the thing you're good at and I don't expect you to do anything else.
So it depends. Do I need you to be excellent at a rigid set of things, or do I need you to be excellent at seeing something through to completion, whatever that means?
We need people to "be excellent at seeing something through to completion", among other things. That's one of the really nice parts about this process, getting one of these projects done on your own time just because you think it's important is a really good signal.
We've had no issues attracting excellent and talented people. Most of them would be considered "senior".
You might be interested to hear that Juniors are the group most likely to be deterred by the sample. The (great) majority of candidates have backgrounds and capabilities up to or exceeding what we're asking them to do. We actually get very few under-qualified applicants.
The process appeals to people who appreciate a fair and objective approach to hiring as it demonstrates how we value those traits. We "set the tone" early by giving everyone an open and honest shake at proving their abilities, without the awkwardness of dealing with a biased human filter.
I don't agree with the premise of your salary comparison.
The process is willing to pass on candidates and wish them well if they aren't willing to take a test -- again, if it would be so "beneath" their skill and experience, that's a spooky indicator of attitude.
Or it may be an indicator of the attitude/shortsightedness of the hiring company.
From the candidate perspective, one way to assess the viability of the hiring strategy is imagine if most, or a significant number, of companies doing this. This eats significantly into each candidate's time, and edges the job seeking dynamic in favor of the companies, and against the candidate since the candidate is forced to value the cost of opportunity searching versus doing something else. This also dramatically would increase the stress of a job search - I experienced it first hand over the course of last year when a good portion of companies wanted projects done, all which would have totalled maybe 100 hours of extra work on top of everything else normally associated with interviewing.
This is not a sustainable balance for job seekers - ultimately this acts against most job seekers' self-interest. I'm fine with doing project-based tests ability/attitude-wise but this reasoning is why I pass up on them.
From first contact to hire, I think we're probably vastly more efficient with candidates' time than most companies. It's exceedingly rare to get as good of glimpse into what you'd be doing at a given job as you see from one of our sample projects. People who aren't great fits (either for desire or skill level reasons) can decide that very quickly. AND if they take it on, it's entirely on their own schedule, no coordination shenanigans.
From there, we do roughly what you'd do if you flew to a company for an interview (or drove, I guess). Rather than running someone through 3-5 different people, we organize it more as a full day project with the appropriate people around.
For most people, I suspect we spend more time pitching the value of the company than we do getting them to do work for us.
It's sustainable, provided companies act like us. :D We do a lot to explain what's going to happen, what we think makes people successful in our org, etc. My guess is most people who apply and make it through the process aren't out talking to 10-20 companies, they're specifically interested in companies like ours.
Based on feedback we've gotten from candidates, even people we passed on, the process is much more relaxing than what they're used to. We've had it called "more human", which is a little ridiculous, but based on how awful most hiring setups are it makes sense. Getting a job sucks and we really want our process to minimize the awfulness.
Anyone who could not only criticize but also resist straight up killing for the opportunity to work with the only and only grayfox is an anomaly. Either you are incredibly unaware, or on the next level of talented to not recognize this. I'll give you the benefit of the doubt and assume the latter, in which case, stop posting on HN, and start writing books. People need to hear your wisdom.
That's the best part though. We don't have to agree! And that's totally okay.
Are there companies that ask for work samples (like yours)? Yes. Are there companies that rely more on resumes and interviews? Yes. Is the ratio going to change substantially? Possibly! It's an experiment, and like all experiments we're still waiting for the data to come back.
I think interviews and references are far more important than a skills test. You can train or educate almost anyone on most, if not all, skills. You can't train people to be decent coworkers emotionally.
We've actually been doing this for two years already! It's much more sophisticated now, but even the naive version of what we're doing has been tremendously successful.
Your problem would be that such talents don't have time nor need to complete whatever assignment you give to them. What if they programmed a core of enterprise cloud system handling 100,000s threads and millions of messages/second you might be unknowingly using daily, wrote papers about it you might have read already but it didn't occur to you and you are asking them to write a concurrent ring buffer? They would just say you good bye and won't consider ever joining you unless they are in deep troubles, which is exactly state you would like to avoid.
Major talents are usually involved with dozens of side tech & social activities, charity etc. Why should they spend time in proving their worth to you? You are operating on the premise people are equal in capabilities, but they aren't, some may be way ahead of your group specifically in the area you really need, to make yourself competitive. No exceptions rule is IMO a really bad idea - it's like reverse of affirmative action, i.e. penalizing/ignoring visible greatness.
Frankly, 10 years ago I thought what you are doing was a good idea; now I am no longer sure for the aforementioned reasons. Team work is not groupthink/socialism if you want to be successful.
If you treat people inconsistently, you open yourself up to tremendous political problems within an organization. _Particularly_ when it comes to hiring, or performance evaluation, or firing.
I think these mythical candidates who have an impressive body of work are probably going to be more thoughtful about a company they join up with than you'd naturally give them credit for. We pitch the heck out of our org, explain why we think it's awesome, and what people can do if they join up. If we can't get someone to see enough value to put time into deciding if it's right for them, I'm not sure they'd ever work out for us.
Well ... yes. We work really hard on the process precisely so we can find find people who are capable, easy to work with, and self directed.
Part of doing this is being consistent with people. The people who work here welcome a new hire _knowing_ that they've already proven what they can do, and having witnessed it in action. They don't have to rely on weak signals or someone else's gut feeling.
> and reflects on the (entitled) attitude of the candidate.
It isn't about being entitled. It is about valuing the candidates time.
Almost every company I have worked at has been incredibly picky about work samples. Candidates who did a pretty good job were frequently passed over.
This shows that the company doesn't value the 4-8 hours the candidate has invested. It is the company who is acting entitled.
So now when I get asked to participate in a take home project, I simply move on to the next job. If I participate then I am giving up on 4-5 other jobs for a likely rejection.
Do you publish your acceptance rates? I.e. how many people who complete the requested work end up getting and accepting offers?
If you had a high acceptance rate (say over 70%) I would happily complete a work sample. Most places I've worked at are closer to 10% acceptance rates.
We're very, very careful about wasting peoples' time. Most people who complete the sample projects spend an hour or so talking to someone about how the company works, what to expect with hiring, etc. We try and reciprocate on time spent with everyone. Some people don't want that, they'd rather just go off and do the thing, but it's important to us. It _also_ helps us get more completed projects from candidates, so there's a definite benefit beyond warm fuzzies.
That said, we don't have a high acceptance rate. We've noticed that there's a break point for most of these, if you normalize the scores there's a clump of people with >80% and then most are way below that. Depending on the role, and the intensity of the work sample, I think we probably select about 25-30% of completed projects to continue.
It sounds like you're optimizing for the happiness of your junior talent. It definitely seems like the more junior members of the team should be mature enough to handle senior people being treated with the respect they deserve. After all, someday that will be them.
By ignoring past success you will filter out most senior candidates. Why would they even apply when other companies will recognize their market value more fairly?
I think what the GP is asking is this: If Jeff Dean walks through your door tomorrow, are you going to try to make him jump through hoops? Obviously he's a better hacker than statistically ~everyone you've ever met, so it might be silly to not hire him immediately. Plus, it takes some chutzpah to intentionally waste 3 hours of his time.
I don't think it makes sense to base a hiring process on outliers. Still, if he were interested, he'd go through the same process as everyone else. There's a fairly good chance most of our positions require more than being a good hacker, be it some UI skills, or operations work, or even "ability to talk to an angry customer".
OT: Why the USA, Canada and UK only - and not EU/EEC as well (or at least other Commonwealth contries, but maybe that's not a (tax/business)thing any more..?) [Ed: Or does UK really mean anyone with the right to work in/through the UK, and not anyone actually in the UK?]
We were acquired by IBM last year. As we adjust to their HR systems, we have to limit our hiring range.
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.
Thank you for your reply. But I'm a little confused (perhaps the EU/EEC labour marked is more complicated than I thought (or your German hire wasn't a German citizen?): Surely a German is entitled to work in the UK?
Would you need/want EU hires to relocate physically to the UK - and if so, why? (Seeing as you're remote-first anyway)?
This is mostly an IBM process problem. Employees need to have "in country managers". We didn't have anyone in Germany, thus we had to scare someone up to have the new person report to on paper despite working with us. IBM itself can hire in basically any country, but for a lot of really irritating and well entrenched reasons, we're further limited by internal org structure and finance.
In theory, had the person relocated to the UK it would have been easier because we do have in country managers that know what we're up to there.
The HN text box defeats at least Firefox's spell checking.
Saf Farsisco. Falaffel. Hemmoridge. Antidisistablishmintirinismisms. Firifofxofox doesn't appear to caer! This whole comment passes with flying colours.
I'm using Firefox 43.0.3 on Mac OS X. I've got "Check my spelling as I type" enabled, and I don't appear to have changed any spelling-related about:config stuff. I wonder if it's something else affecting Firefox. Very odd.
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.
This one's current, I don't know why but I'm vaguely weirded out about posting it here. It's already public on GH though so I guess I'll power through. :)
Resumes, interviews, and referrals disproportionately favor the BSers, conversationalists, and the well-connected. No surprise that employers have buyers remorse. For how much emphasis companies put on hiring, I'm surprised there aren't better ways to identify diamonds in the rough.
Diamonds-in-the-rough are also a tremendous value. It's very cheap to hire someone that can't (or doesn't think that they can) get a job elsewhere. It really is surprising that more effort isn't spent trying to identify and hire them.
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.
This is only true if you both have the capability and choose to dedicate the resources to skill development. Many places either can not or choose not do this well.
I'm always torn between appreciating guys like this for their good advice, and wanting to scream because the entire rest of the industry still hasn't twigged to this gobsmackingly "water-is-wet" obvious fact. How can so many smart people be so deeply, enduringly stupid?
This used to wig me out a bit. We have people we turn down thank us for having a decent hiring process ... and I think what we have is a good philosophy with an imperfect implementation.
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.
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):
https://compose.io/jobs
If you have any questions, I'll be more than happy to answer.