Despite nearly every company having coding interviews as part of their hiring process, poor developers get hired. Somehow having people write code from college exams in web-based IDEs while a clock is ticking is failing the industry. The reason for that is that it doesn't resemble the everyday reality of a software developer.
Writing code is such a small part of development having a candidate to do it in a game show environment isn't going to provide much helpful information. Ask a software development what they do all day long and typing code into an IDE would probably be less than 15% of their job. A good developer has been able to look at a code base that he hasn't written, gain a working knowledge of what it does and how it does it, and somehow make a change without breaking everything.
I don't have any official data but I am willing to bet that 99% of the time that code change is not inverting a binary tree in under thirty minutes.
According to Frederick Brooks' inescapable Mythical Man-Month, the average developer spends half of their time doing some kind of testing. How many coding interviews involve writing a unit test? Has there ever been a coding interview that asked a candidate to dig through an APM or log aggregator to find the reason an API call is failing? Instead of pulling a hard question off of LeetCode, could we just give a candidate several hours to fix a failing Maven build and get better hiring decisions?
Enough complaining, what is the solution? What is the NFL Combine of the Software Development world?
It's the GitHub Open Source Pull Request.
The biggest poorly kept secret in the software world is that also every commercial software product relies on a myriad of Open Source Software and the second biggest poorly kept is how overworked and underappreciated Open Source contributors are.
Critical OSS projects, like log4j, have hefty backlogs of bug fixes and security issues. What if we could help address those issues and improve the hiring process?
It begins with the hiring manager selecting an appropriately sized and difficult fixes for OSS that the company depends upon. The candidate would have the opportunity to read requirements, learn a code base, follow a build and testing regiment, and conform to a submission process. Ultimately having a group of their peers accept the PR.
The standard interviewing process often produces little to no value. The code is thrown away as no one needs a solution to a non-existent problem. The PR Test creates actual value and that value is not owned by the hiring company so there is no awkward feeling of exploitation. Whatever happens with the job opening, there will still be some value created and released into the world.
Imagine if log4j was fixed by a candidate before it was exploited. Imagine if developers had an intimate understanding of the libraries they use because they were part of the development effort. Imagine finding out the guy who can solve the Towers of Hanoi in 5 lines can't solve a simple bug without re-writing several modules from scratch?
After the PR test, in the follow-up interview questions should be asked about challenges and design decisions. This helps gain insight into the candidate's thought process and also an indication if they actually did the work themselves.
There is one missing piece though, the acquisition of new knowledge. Pick a topic that the candidate is unfamiliar with and give them a week to learn it. A thought exercise in an interview could ask the candidate to use the topic in a hypothetical problem. Not a pass/fail but doesn't provide insight into how the future employee could be directed in their professional development. Pro tip: people can learn how to learn better.
Better developer interviews lead to better hiring decisions and better professional development. For an industry that believes in better efficiencies and less waste, that should be reflected in the hiring process.
