Hacker News new | ask | show | jobs
by dangrossman 5275 days ago
Will an exceptional developer really go through a phone interview, several hours of unpaid coding, a code review, another hour long phone interview, another interview where they must prove "strong opinions about software practices", an interrogatory lunch, an afternoon solving made up logic puzzles, then a pair coding session?

That sounds like torture to me. Don't exceptional developers' portfolios and resumes say enough that they don't need to suffer through all that to get a great job? Are the exceptional developers really the ones applying for your job in the first place?

This isn't the worst interview process I've ever read about. I've heard of developers applying to jobs at Microsoft getting 3, 4, 5 levels of interviews before finally getting a job. But most of the developers I met at Microsoft were competent, not exceptional. Exceptional developers didn't need to waste their time with that kind of process and they know it and they moved much more fluidly between jobs.

4 comments

In practice, I often find that exceptional candidates like a rigorous interview process-smart people often like doing things that feel difficult and selective. And it gives them confidence that the company is hiring smart people.

This is not to say that Braintree's process is perfect-just that the assumption developers are "suffering through it" to get a great job may be flawed. I personally would much prefer going through an overly exhaustive interview to one that I felt could pick up weak candidates.

How are they supposed to know that a particular developer is exceptional otherwise? Even if they have a github or similar account for a potential employer to peruse, that ultimately only shows the end result of their thought process. It doesn't necessarily show that they were able to arrive at their conclusion/solution efficiently. How would you then account for that?
An exceptional developer has done something exceptional. Authored a popular JavaScript library. Founded and grew a business. Lead the team that introduced a new product line that's now used at 5 million businesses. Authored the research paper that led to a new Photoshop feature. Launched an app at a hackathon that now has 30k users and here's the code.

These things speak for themselves. That's what makes them exceptional. These developers are not the norm but they're not diamonds either -- yet, still, they've already proved themselves and their accomplishments are enough that they can get a job without subjecting themselves to this obstacle course of an interview process.

Braintree doesn't really need exceptional developers to work on a 20th century credit card platform, it just needs competent ones that are socially compatible with its team.

We expect anyone applying to Braintree to be exceptional. It's subjective, and naturally some folks are more exceptional than others. Frankly, it's up to the candidate to decide if that label applies to them or not. What we're interested in is whether or not someone will be successful here. That's the sole purpose of an interview. Can this person do what we need them to do? And for the candidate, can this employer provide me what I need in order to be successful?

For us, it's more often the qualities that aren't as easily discernible from resumes and source code that have been better predictors of success. There are certainly companies that are best served by lone wolf, mercenary developers, and would be thrilled to have anyone with strong coding skills or impressive accomplishments. Communication and collaboration are more important to us, and as the post points out, you have to interview differently for those aspects.

I would hardly think a developer who's "Founded and grew a business" would be applying at Braintree. Likewise, if Braintree were interested in hiring them, I doubt they could probably afford his/her salary.

I would probably have a heart attack if I saw a Braintree release that announced they just hired John Resig as a JS developer. This is the league I think of when I hear the word "exceptional developer" being tossed around.

While the process doesn't sound pleasant, a long interview might benefit the potential employee as much as it does the company.

If you're going to be spending a lot of time working with these people..you want to get a chance to get to know them a bit before jumping in. (Same goes for their tools, development process, etc.)

I'm not a developer, so I can't confidently comment on the value of specific code evaluation techniques. In other disciplines however, it can often be fairly easy to sort out the talented folks from the merely competent through a brief screening and interview. The trouble with such a shortened interview process is it's inability to determine if this person will be a good fit with the company's culture and team. Similarly, it can be difficult for a prospective employee to make an informed decision as to whether or not he will actually enjoy working at that company.

You can make a very good case that these types of extensive, saturating interview processes do more to determine one's overall fit with the company than their role specific abilities. You could also argue that this is just as important an indicator of one's success with a company as their role specific abilities, assuming some sort of baseline level of competency.

One thing indicator I like use for "cultural fit" (as we don't have a lengthy interview process for our team) is how much the interviewee asks about our team. Are there any questions? A few generic questions? Or some deeper, probing questions about expectations, design decisions, framework decisions, and general culture? If I'm considering a new position, I want to know as much about my potential employer as they want to know about me.
When I interviewed at a coop they had a specific coop interview (after the technical interview) to see if you would fit the coop world view.

I remember joking that you just ask a potential employee if they cried for Boxer in 1984 if the say no you don't hire them :-)