Ask HN: Who is hiring? (May 2016)

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.

Positions: Backend Engineer (Go) / Product Designer / Head of Growth / Solutions Engineer

Online Descriptions: https://github.com/gravitational/careers

Contact: jobs@gravitational.com

Engineering Interview Process: There is an informal meeting or phone conversation with the founders (may be together or separate depending on timing). If everyone (including you) agrees there is a fit, we create a small engineering project for you to work on with our CTO. It is something that is similar to what you would be building full time but is not something we actually use. This gives you an idea about the type of work you’ll be doing and how we work together. If that project is successful we may want to meet in person if we haven’t already to discuss what the future looks like for all of us. Then if we decide to extend an offer, we give you two weeks to respond.

## About us

Gravitational is an early stage systems & cloud startup in San Francisco out of the YC S2015 batch.

* We are changing the way enterprise software is distributed and run.

* Our customers are people like us, engineers.

* We are well-funded by solid investors.

* We are an experienced team: we founded Mailgun (http://mailgun.com) which was acquired by Rackspace (http://rackspace.com), we created Vulcand (https://github.com/vulcand/vulcand) and some other cool stuff (http://www.rackspace.com/blog/onmetal-the-right-way-to-scale...) at Rackspace.

* We are hackers. We love Linux and low level systems programming and we love helping open source communities and other engineers to get things done.

* We are also dedicated to our families, friends, and hobbies outside of work. Our past experiences building companies taught us about the importance of life and work balance.

If this resonates, we'd like to talk to you.

Contact: jobs@gravitational.com

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.