> ... And this 'news release' from Compose.io is the business equivalent of a vulture feasting on the carcass of its own mother.
That is brutal, for conjecture.
A fledgling open-source DB winding up on an as-a-service provider can provide mutual benefit; the database gets users running their product on a stable, consistent platform and the provider can profit from the margins on the value-added deployments they provision.
Hardly 'a vulture feasting on the carcass of its own mother'...
This is already possible through the onMessageToOperator and onMessageToVisitor hooks in the Olark JS API (https://www.olark.com/api). I'm excited to see what people will do. :)
Olark is actually entirely done over XMPP, so you could theoretically connect directly to Olark with any standard XMPP client. Trillian is doing some cool stuff in their latest Mac OSX beta using some of our XMPP extensions.
What: Databases-as-a-service. We offer production grade, auto-scaling, automatically backed-up, add-on compatible MongoDB, PostgreSQL, Redis, and more.
$: All roles start at 100k and scale up based on experience. MacBook Pro, pension match, health.
Hiring Process: Blind hiring! First, a light application. Second, all candidates who complete the application receive a work-sample resembling the work one would do in the role. No deadline. Final step is a paid work day ($500).
Compose has grown into a vibrant group where folks can feel comfortable being themselves, living a balanced life. We welcome you to enjoy comfort when taking risks, collaborate with spirited peers, and to unleash your creative and talented personality.
* Work from anywhere!
* Many neat conundrums to solve.
* Self-managing, distributed decision making. Choose your projects. We're deadline averse and quality focused.
I tried this process because it sounded pretty fun and unique.
One warning I have for anyone interested is that there are some big waiting times involved. I'll share my timeline. Some of the lags were on my end, but I was assured I had as much time as I needed.
- Day 0-6 - First contact
- Day 7 - Assigned work sample
- Day 21 - Submitted work sample
- Day 62 - Work sample results returned
- Day 72 - Paid work day
- Day 79 - Work day report completed
- Day 85 - Final decision
Overall there were 21 days where they were waiting on me and 47 days where I was waiting on them. This seemed to me like a lot of waiting but maybe it is normal.
I probably worked 15 hours on the work sample, 8 hours on the work day, and 8 more hours putting together the report after the work day.
Oof, bummer. Your experience is slower than average. We ran into a grading crunch when we launched our Enterprise product. When you submit your work to us, your submission is anonymous. Three engineers grade each submission.
Platform Engineers will experience the greatest wait periods. The other roles tend to be quicker.
Expected time-frame:
* Proceed from application to work sample: 24 hours.
* Complete work sample: Up to the candidate. We build them to take 2-6 hours.
* Grade work sample: 1-4 weeks.
* Schedule work day: 1 week.
* Receive decision: 2-5 days.
Thanks for taking our time to try the process out, it is appreciated. The method is constantly under improvement.
It's hard to see how you can have much success with this method. Current recruiting strategies involve getting from recruiter telephone call to final decision within 2 weeks, or 1 if possible. The faster you move on a candidate the more likely they end up working for you. At my current employer initial phone conversation, telephone interview and on site were all within 7 days.
While I'd never argue its a "good" thing to have a slower pipeline, in the past when I had pipelines with timing similar to this companies, it didn't have extreme negative impacts on the success of the pipeline.
I don't know why that was, but my suspicion was that our highest qualified leads were those coming from candidates that were "happy enough" at their current positions to not be frantically searching.
As long as we seemed like a good place to work, and we did a good job of communicating why back logs were happening, we didn't lose many of the candidates we were most excited about.
my experience is that I am mostly happy where I am, and I am not in market when I am Happy, but when I am not happy, I want to get out asap and wait times as high as a month is a real turn off
It seems you truly care about feedback and the quality of your process. FWIW: I'm glad you are making these timelines transparent so people can decide whether the position is a good fit or not for them. As someone who is in the field for over a decade, it strikes me that this timeline is really long and you run the risk of getting people who couldn't get a better offer from another top employer faster. In addition, I personally have stopped engaging any hiring process that has a take home exam. My view is that my degrees and track record are sufficient evidence of my competence. Also, my time is really valuable .. so engaging with companies who are forced to waste their engineer's time as well as mine seems fair. Just one person's opinion :)
Agreed. That's kind of ridiculous. I don't understand this whole "we are not interested in speaking with you as a real human being but 'here', here is some homework for you to do' Seems really silly.
It has its tradeoffs. The point is, if they're going to go that route the assignment should be short and sweet, and the response should be quick. Especially since we can pretty much tell, like, right away whether we like someone else's code or not, now can't we?
Basic, common-sense considerations which a lot of places don't seem to appreciate, unfortunately.
And to not respond at all is just a gratuitous insult.
He's understating what he's done a bit. We're vastly more consistent with candidate feedback than we used to be, largely due to tooling + process changes that grayfox has put in place. It's improving, we'd like to turn evals around in <1 week for everyone.
Apologies,but this process feels really lame. I know that many companies do it, (like atlassian, for example) - but it feels as though one is interviewing for a slavery post. Let me explain:
You hire people. People have lives. But this type of process just illustrates that you're a Corp and not really having the best interest of the people you're hiring. The reason I state this is because corporations don't give a fuck about anyone who under performs and they shall fire anyone at will. You're not a family, you're (the corp) not going to put in nearly as much effort as the candidate did to get the job, in order to keep said candidate.
You make them take many weeks to apply and get the job, but even for trivial reasons (we lost that customer/contract or we don't have the funding) you'll kick said candidate to the curb without a second thought.
It's a one sided position in the favor of the corp, and for that reason I would never choose to work at any company with this method for hiring - and especially a company that has this example of how long that fucking process takes.
The point is, you think you're looking for "the best fit" but you're actually alienating people who would be a good fit.
Of course they're a 'corp', and of course they're looking after their own interests over yours. Looking after your interests is your own job, no one else's.
The employer-employee relationship is partly a fight. The best you can hope is that it be a gentleman's one, with no hits under the belt, rather than an all-out brawl or backstabbing.
grayfox is showing you cards that the average employer would hold back and would only release at gunpoint: salary range, internal details of hiring process, how long the process takes... seems this is gentleman's territory for now.
The long process selects for people who are happy with their jobs, which is the situation of most experienced and skilled people. I have seen worse.
Edit: I'm realising this is more aggresive than I like. I'll leave it as is, with the addition that I once thought like you, and this here is the state of mind I've come to have now that I've been on both sides of the recruiting fence.
I sympathize with you and also dislike long evaluation times. I also have kids and a life outside of work. Personally I think 6 hours is too long to design a work sample around but it's not that bad, I've done work samples (early in my career) that took 3 days and that I would've billed out for $3k when I became a consultant later.
In grayfox's timeline, things really seem to hang up around the time it takes to evaluate the sample, asking for 1-4 weeks. This is another point in favor of minimalist work samples (smaller sample = less time required to review). IMO work samples should be a simple problem where the candidate demonstrates his basic awareness of the core skills needed to perform the daily work and the bulk of the hiring process should occur in a discussion between parties.
Anyway, I'd suggest that they tighten up this process by a) minimizing their work samples and b) making it priority to review work samples as they come in, which means adding more resources for this purpose if necessary. It shouldn't take more than a week to hear back at any step of the process.
Minimalist work sample tests don't work. The work sample test is the test. There is no other criteria involved in whether to hire someone other than their performance on the work sample test. Otherwise it's not a work sample test; it's an intro.
This is a step forward for our industry. For those who don't like it, there are plenty of jobs where you can do the traditional whiteboard hazing.
I've had a lot of success hiring with minimalist work samples.
>Otherwise it's not a work sample test; it's an intro.
Well, like I said, I think the work sample should only be needed to show basic awareness and that the rest of the process should be based upon the course of a discussion around the candidate's relevant experience, the company's needs and intended role for the candidate, etc., so perhaps it's not wrong to call the code sample an "intro". I referred to it as a "litmus test", meaning it's a simple pass/fail; they are either able to throw something together in 1-2 hours showing that they have basic awareness and competence dealing with the problem space, or they're not.
Overall fit is much more important than something like "candidate Y has better indentation habits". Human cycles are thousands of times more valuable than CPU cycles. It's better to choose the good fit candidate whose coding habits can be trained up over the course of his employment than the unstable abrasive candidate whose code ran 1.5x faster than anyone else's.
>whiteboard hazing
Heh, I don't suggest this either.
The frightening reality about hiring is that it can't really be reduced down to a formula. There are subjective judgments that have to be made (in both directions, meaning that you shouldn't be absolutist about things that are correctable in their code sample) if you're going to get good hires and a cohesive team. Questions like "Is this person an active, curious learner?", "Is this person able to field fair critiques of his work product professionally, reasonably, and humbly?", and "Is this person's personality going to mesh OK with the rest of the team within a professional work-day setting?" are all much more important than a raw benchmark of their code sample.
I know that a lot of people don't like that subjectivity, especially when they're on the wrong end of a subjective judgment, but I don't think it's a good idea to discard evaluation on those metrics. We just have to hope hiring managers are using reasonable subjective criteria, and if they're not at the company we want to work for, we gotta move on. Fortunately for us, there are plenty of fish in the sea looking to employ programmers right now.
Our sample projects are meant to tell us that a person is technically capable of doing the individual work for a given job. The work day that comes after answers "can they work well with us?"
The criteria for both project/workday is predefined ahead of time, and the part we spend the most time on. Sample projects have ~40 criteria, nothing quite so minute as "indentation habits" but we do give points for "idiomatic use of golang" on the go work.
What we found when we were putting processes in place is that we just shifted our bias. As an exampe: if a recruiting process judges abrasiveness during a traditional set of interviews, it's probably biased. It's better to put people into a work scenario and judge their actual work and how they interact with other people.
A self-contained project that gives the candidate room to demonstrate a basic grasp on core skills. It should take no more than an hour or 2 hours at most if the candidate chooses to stay within the constraints of the project (in my experience, candidates will often throw in a few extra features since we're not monopolizing their time with a demanding list of requirements, which provides really awesome insight into the candidate). In most cases, if the candidate is capable of a simple project like that, they'd be equally capable of a larger project, and there's no use wasting anyone's time on a larger thing (unless you're focusing on the wrong stuff, like specific knowledge of one particular library).
For my purposes, I like variations on a project that asks them to implement a very basic listing call from a public API. I let them use any language they want. This shows that they can put together a project in some language, look up API and/or library documentation, provision an API key, reference external API docs and code a function that reads against it. I understand that Compose covers a different space and would need to tailor a different minimalist project.
For me, if they're capable of this minimalist code task, it demonstrates basic competency and filters out almost all of the guys that aren't worth wasting time on. It doesn't demand too much of their time and allows them maximum freedom, which allows us to see a lot of information not only about their organizational skills but also about their code ideals. It doesn't penalize a great asset for not having run across a specific language, platform, library, algorithm, or data structure in his/her past; those things can be learned quickly by good candidates. It doesn't depend on knowledge of trivia or number of times they've seen the problem in past interviews/tests. It's not overly academic and doesn't depend on how long it's been since they reviewed their compsci textbook.
The rest of the information needed to make a hiring decision is derived from an extensive discussion on their background in the field, their attitude and goals, and their immediately relevant experience.
Agreed with (b), we've gotten lots more consistent and turnaround on all the evals has improved substantially (largely because of the person you're all responding to).
I love the hiring process at Compose. I myself have applied here. I also love it how they understand the pain points in the hiring process and sympathize with potential candidates.
However, I am a little disappointed. Given the process they have and the ranking procedures, unfortunately, the process is very time taking. Been 8+ weeks after I turned in the coding exercises and haven't heard back anything (positive remarks or a rejection) yet. So far I have been to a decent amount of hiring procedures (have been extended 2 offers and declined), and the entire procedure is usually 6-8 weeks. But again those hiring procedures are quite "traditional" compared to how Compose is performing. I guess, patience is virtue :)
Anyways, overall I enjoyed working on the problems and exercises. Good luck!
I must correct myself here. @mrkurt apologies for misleading information. What I meant was I haven't heard about the next steps or about a rejection. However, I was notified that my submission is in queue and to expect a decision soon. I am 100% in support for the hiring procedures followed by Compose :).
What was disappointing was, overall the timeline has been 8+ weeks since submission of coding exercise and a decision on the same isn't available.
Yeah 8 weeks is terrible, and I'm pretty sure it means something broke. I'm happy to look it up (incidentally, people are very hesitant to email us and ask what's up because they're worried about seeming pushy. They shouldn't be, if a company thinks you're pushy for respecting your time you shouldn't work there).
Your hiring practices and willingness to disclose pay are refreshing. It would be interesting to read a more detailed case study on how this works for you.
For me, the paid work day was 8 hours in a Slack chat asking a lot of questions of 1-2 employees. My task was to get familiar with their existing systems by querying these employees. I was asked to prepare a report about what I found.
The guys seemed busy so for a lot of the day I was on my own, waiting for more information.
It was intense, but by the end of the day I had a pretty good sense of the internals. I think it was a good test overall.
It sounds like it worked like we want, kind of! The work days should be more interactive than what you experienced, I think. The really good ones seem to be super busy for the first 4 hours, with 3-4 existing employees interacting. The latter half is frequently quiet if people are on the right track.
I can guess which position you were going through the process for, and it's something that we've been talking about a lot.
One thing we've noticed is that even when it's not perfect, the process we have helps a lot. You had an imperfect work day, but got a good idea of what the actual work is like. I'd rather you have a perfect workday though.
By "legally work" do you mean "pay taxes"? Because AFAIK European people can legally work in UK and live or pay taxes in their origin countries (France, Germany, Spain, etc)
It's tricky. The hiring pool can technically include the whole EU, but people need to live in the UK while they work here (I believe). We can't hire someone in Germany and have them be employed in the UK.
> people need to live in the UK while they work here
Not really. The only issue is where the employee wants to pay taxes (and get social benefits), in the UK or in the country of residence. This also applies for UK nationals living abroad in Europe.
Generally you're forced to pay local taxes when you spend 183+ days living in the same country (you automatically get resident status), but most of the EU countries have bilateral income tax agreements in order to prevent double-taxation. (you can live in Spain and request tax exemption/return from the UK or Spain gov) and viceversa.
It's trickier than simply hiring EU contractors but it's definitely doable (I know some cases) and opens a whole new talent pool for an UK company.
Same, I've upvoted everyone who provided a salary estimate. I saw this in action last month and think it's a great principle so I encourage others to do the same.
While I admire your "blind hiring," I've become increasingly aware that when it comes to team dynamics, EQ matters as much as IQ and social skills/empathy matter as much as ability... (Perhaps that accounts for your $500 "first day.") Has this method been working for you?
The work-day would be where we assess EQ. It is difficult to stay objective and consistent when assessing soft-skills. It provides the risk that biases and could-be-wrong impressions dictate your hiring decisions.
Two things, in my eyes, have helped us find bright and 'good' people:
First, by using consistent criteria that are as specific (binary) as possible, we have been able to find people who are not just talented, but conscientious contributors.
Secondly, the way we write/pitch/communicate during the process sets the tone for both the people we want and the environment we want to create. If you go through an uncomfortable, even aggressive, hiring process, what would you expect from the environment and the people within that environment? We try for good-ness from word one.
Yes. Our process actually meshes with IBM's reasonably well, people still have to go through the IBM recruiting system (very late in our process) but it's not used for any screening / decisions.
Our Support Engineers and Technical Content Creators do real intensive technical work.
The role is not important at Compose. The system is built to best groom out 'core competencies'. A Support Engineer is a strong Ops/Systems Administrator with great communication and customer skills. A Technical Content Creator is a strong developer with excellent written communication skill.
Our Analytics is maintained, built, and improved by a 'Content Creator'. Our hiring, too, is ran by a 'Content Creator'. Similar folk contribute across the app, and apply skills in various areas.
It is a mature way to work. To get the best people, you need to offer competitive wages.
I'm not interested in applying, but very curious as to what kind of work sample you might have for a systems profile. Is it okay to 'apply' just for the sample?
If you are looking to join a forward-thinking industry with a stable outlook (databases-as-a-service), we have a tremendous challenge for you and a terrific team willing and able to support you through it. Compose hosts production grade MongoDB, PostgreSQL, Redis, RabbitMQ, etcd, RethinkDB and more to come.
The Compose family has grown into a vibrant group where folks can feel comfortable being themselves, living a balanced life. We welcome you to enjoy comfort when taking risks, collaborate with spirited peers, and to unleash your creative personality.
Some great things about Compose:
* Work from anywhere! (As long as you're legally able to work in the United States, Canada, or the United Kingdom).
* Many neat conundrums to solve.
* Self-managing, distributed decision making. Choose your projects. We're deadline averse and quality focused.
* Ruby/Go.
* Fantastic salary and benefits - MacBook Pro.
* Join a thriving and respectful international team.
Our hiring process is nifty. We request a work-sample upfront that closely resembles the work you'd be doing within your role.
Once you submit, your answers are anonymized then graded by 3 different people following pre-defined criteria.
We want to know, objectively, who is going to both enjoy and crush the work. We have several positions open for candidates:
* Now hiring Team Anchors: If you have deep knowledge within MongoDB, Elasticsearch, RethinkDB, or RabbitMQ, we would like you to be the nucleus of one of our DB teams. We want you to help ensure our individual DB offerings stay excellent.
For the full postings checkout https://compose.io/jobs or email jobs+hn@compose.io if you'd like to have a chat with us to see what we're all about.
If you're looking to join a forward-thinking industry with a stable outlook (databases-as-a-service), we have a tremendous challenge for you and a terrific team willing and able to support you through it.
The Compose family has grown into a vibrant group where folks can feel comfortable being themselves, living a balanced life. We welcome you to enjoy comfort when taking risks, collaborate with spirited peers, and to unleash your creative personality.
Some great things about Compose:
* Work from anywhere! (As long as you're legally able to work in the United States, Canada, or the United Kingdom).
* Many neat conundrums to solve.
* Self-managing, distributed decision making. Choose your projects. We're deadline averse and quality focused.
* Ruby/Go.
* Fantastic salary and benefits - MacBook Pro.
* Join a thriving, respectful and family-like international team.
Our hiring process is nifty. We request a work-sample upfront that closely resembles the work you'd be doing within your role. Once you submit, your answers are anonymized then graded by 3 different people following pre-defined criteria.
We want to know, objectively, who is going to both enjoy and crush the work. We have several positions open for candidates:
* Platform Engineer
* Support Engineer
* Technical Content Creator ('Developer Advocacy' type of role)
* More!
For the full postings checkout https://compose.io/jobs or email jobs+hn@compose.io if you'd like to have a chat with us to see what we're all about.
Funny, the last two people I know who moved to Hawaii, moved back a year later. I'll have to find out why. But they must have a good reason - this is Iowa, and its currently 16 degrees.
I know people who love it. But it's expensive and it's a long way from anywhere. You either live in a pretty soulless city (Honolulu) or in effectively a beach community of some sort that's often dominated by tourism.
I appreciate why some people are attracted to it but I could easily see it getting old quickly even if living in a condo near a beautiful beach and ocean initially seemed like the perfect life. (OTOH, it's sure better than Florida IMO.)
Developing software appeals to those who love to solve puzzles and apply their brain power -- and also to those, in our experience, who like working from home in their pyjamas. If you're looking to join a forward-thinking industry with a stable outlook (databases-as-a-service), we have a tremendous challenge for you and a terrific team willing and able to support you through it.
Here are a few things that's great about our team:
* Work from anywhere! As long as you're legally able to work in the United States, Canada, or the United Kingdom.
* Self-managing, open culture. Choose your projects. We're deadline averse and quality focused.
* Ruby/Go.
* Fantastic salary and benefits - MacBook Pro.
* Join a thriving, respectful and family-like international team.
* Fair and objective hiring. Participate in 'blind-hiring'.
Our hiring process is nifty. We request a work-sample upfront that closely resembles the work you'd be doing within your role. Once you submit, your answers are anonymized then graded by 3 different people following pre-defined criteria.
We want to know, objectively, who is going to both enjoy and crush the work. We have three positions open for candidates:
* Platform Engineer (More back-end)
* Application Developer (More front-end)
* Technical Content Creator ('Developer Advocacy' type of role)
For the full postings checkout https://compose.io/jobs or email jobs+hn@compose.io with a quick tale about a database you loved, or didn't love and which role intrigues you.
If you have any questions, we'll gladly answer whatever you'd like. Everyone gets a personal response and a fair, respectful 'go' at the process.
> As long as you're legally able to work in the United States, Canada, or the United Kingdom.
You know, that's far from "anywhere"... :)
What's wrong with working from mainland Europe assuming one can work within UK hours? (and send invoices at the end of months..., aka long-term contracting)
You can _work_ from anywhere, but we can only employ people who are legally able to work in the US, Canada and the UK. We don't like this restriction, but it's a side effect of being part of a very large organization with processes for hiring in every country already in effect.
Thanks for the clarification. Big companies are usually able to hire contractors - i.e. not a regular employee within some country, but just an independent service provider. Companies just pay invoices. No [health] insurance, no [paid] vacations, no work-permit sponsorship needed, etc... It would be great if this is possible for Compose "department" as well.
Trust me, we haven't missed an easy workaround for this. Big companies also have processes for getting contractors in place, and in many cases it's harder than hiring someone on full time.
So what if I were, say, a US citizen living abroad? I am legally able to work in the US and in my home country, but of course since I'm not actually living in the US some companies might find that problematic. Do you?
They are but it's rather difficult to get national insurance number and open a bank account if you don't live there (and have proof for it, of course).
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. :)
That is brutal, for conjecture.
A fledgling open-source DB winding up on an as-a-service provider can provide mutual benefit; the database gets users running their product on a stable, consistent platform and the provider can profit from the margins on the value-added deployments they provision.
Hardly 'a vulture feasting on the carcass of its own mother'...