Senior Developers Are Getting Rejected for Jobs

Honestly, command line Linux skills and a take home ( that does x” is far more relevant to my work than some timeboxed HackerRank contrived example.

My favorite screening tools have typically been “here is an app with failing tests, fix the failures.” I have been screened out of all manner of dinky companies from these contrived tools. A reasonable oral technical interview to ensure the candidate can communicate within the domain is far more valuable than contrived tests of solving problems unrelated to the actual job. I can learn more about a candidate asking about use cases of SOA than I can by watching them calculate prime numbers.

1. It is a problem representative of the work the person will normally do in the job (we use an extract of our actual data for it) 2. We provide clear guidelines and criteria for success. 3. They are allowed to implement a solution in any language they choose, using any tools they choose (we ask everyone to bring a laptop with their preferred dev environment, but we do provide one with some common tools for them if they can't). 4. They are allowed to use Google and open-source libraries to help them with the solution (we want to see how they really solve a problem) 5. We are there to interact with them and answer domain specific questions, as well as to offer advice if they are stumbling on something to help them move forward.

I've really, really gotten a lot of good mileage out of this. The range of skills that I've encountered over the years has really surprised me. The problem is pretty straight-forward, and usually involves parsing some JSON, looking at the data, and matching disparate sets of the data together. The basic O(n^2) solution can be done in about 20 lines of code and there is some nuance to the datasets that require them to think through the problem and not what they have memorized in their head. I've had programmers with years of experience from places like LinkedIn take 20 minutes just trying to read a file in from the file system, and I've had people who are self-taught developers crank through a really good solution in the same time. I like being able to see how people are writing code, how quickly they are able to lookup information they might need, and listen to the types of questions they have when trying to solve the problem.

We run about as practical a process as I can imagine. A short take home exercise where you use your own environment and build a very small project and are free to even have a starter ready to go ahead of time to focus on the question asked.

In house we have a project you work on on our code base. Very small. Maybe ends up requiring less than 20-30 lines of code for the day. Most people who come in are always familiar with our stack.

The amount of people that just fall on their face is astonishing. Many people will be fine with Greenfield development but then have zero skills being able to deal with an existing code base with places stubbed out with //todos and the ability to pair with people on the team.

I'm convinced people are getting turned down not because of the interview process, but because they just aren't that good at the end of the day.

Yes. I do not need a bunch of code wizards, we aren't solving if p=np daily. But that doesn't mean I should accept people who can't code I'm hopes of them growing into fine developers. I can do that worth one person, but not when bringing on 8.