Senior Developers Are Getting Rejected for Jobs

It does scare me when experienced developers can't write FizzBuzz though, in any language of their choosing, in a reasonable time frame. The thing I tell myself is that there are so many "gotcha" style programming interview questions that people might just be nervous that there's some trap waiting for them in the question.

A few years ago I instituted an "interviewing code of conduct" for my teams with a few tenants that we've refined over the years, but the first one was "We will treat every candidate with respect and empathy in our interview process". The team has adopted some attitudes and techniques to do so while also not compromising on the talent or skills we are looking for. We've gotten very positive feedback on our interviews, so we think it's working.

We need to take this to its logical conclusion. If the claim is that these kinds of interviews don't work, then what should we be seeing out there? Are companies that employ these techniques less successful, or less productive, or less something-else? Because its not easy to tell someone they're doing it wrong, when what they're doing is working for them and making money. Without actually showing how these kinds of interviews are detrimental to their bottom line, its only going to fall on deaf ears.

I take a completely different approach to hiring, and I've gotten fantastic results.

Instead of throwing tricky algorithm questions at a candidates, I scour their detailed employment records for the most relevant experience for the first project. In other words, I'm looking for relevant experience rather than top-of-the-head algorithmic brilliance. In the interview, I pose our project problem, and the candidate who gives me the most impressive proposal to get that done gets a chance to solve it.

I hire from an international pool, often on Upwork, so I can start developers on a project basis.

If the developer does a great job, we hire him/her for another project, and so on. At some point, this becomes a full-time relationship, with stock options and other perks.

Using this approach, we value experience over "raw intelligence," per se, and we end up with a team of self-directed developers who are fabulous at delivering great finished products.

It's amazing how well this has worked out for us. I think there's an arbitrage opportunity to avoid coding tests and hire on this basis.

I think my team has gotten pretty good at this. We address the "flood of applicants" by tossing out any resumes that don't have some sort of CS or programming on them (about 25%), and favoring, in order, people who have held a programming job, people who have done programming internships, and people who have taken CS classes. A decent GitHub profile will bump you up in the two later categories.

Next is a five minute phone screen. We're a Java shop, so I ask them something dumb, like "what's the difference between public, private, and protected?" Something any Java dev would know; I'm just trying to find out if they have ever actually used the language.[1]

People that pass the phone screen get a Skype interview, where they write code in an IDE. The first half hour or so is chat and trivial problems like "sort this array" or "return true of this String starts with a letter between A-Z, inclusive." They're allowed to Google and use the standard libraries.

Finally, we have a "close to real world" problem for them to work on. It's a standalone, mostly-toy CRUD application, and we'll ask them to add a feature that represents the kind of work they'd be doing. Again, they have their IDE of choice, Stack Overflow, etc.

I don't think we've had a bad hire since we started using this process. Have we turned aside some all-stars that interview poorly? Maybe, but the team we've built is really good at what they do, so I'm pretty happy with the results.

[1] We have hired Senior devs that don't know Java. One of our team leads was a C# guy for a decade or so, but he was smart and available, so we scooped him up. Java is easy to learn. Programming well isn't.

> Is it really too much to ask to spend a few days solving some programming puzzles on a whiteboard?

Yes.

It's not a matter of capability - in over 20 professional years I've yet to run into a problem I couldn't solve when I was motivated to do so - either because my job required it, or just because it was interesting.

It's a matter of valuing my time. I do. Companies that want to put me through 12+ hours of interviews and exercises do not. And if they can't value it for interviewing purposes, chances seem very low that they'll value it when I'm an employee.