I don’t spend much time on social media. To be honest, I’m not sure yet of its value. Democratizing news is a noble goal. Making and keeping connections is a noble goal. Communication is a noble goal. All three of these things are messy though and a continuous flow of low value content and constant reposts and shares with no value add is just noise.
But I watch, and wonder. Sometimes, certain things continue to bubble to the top. One of these things is the current hiring methods for technology professionals, particularly programmers.
I spent the first fifteen or more years of my career as a programmer, then the next fifteen or twenty in a variety of IT roles, literally spanning the entire spectrum of IT. So when I decided to return to my roots, to start programming again, I was blindsided by the change in hiring methods. I was completely unprepared for the modern interview.
Until now, I’ve purposefully avoided adding my own angst and commentary to the noise. I wasn’t sure of the noise to signal ratio of my own thoughts. For one thing, hiring technical people is hard. It always has been. Just because we did it differently in the “old days” does not mean we did it any better. So I understand the intent. Additionally, like it or not, if I want a job as a programmer today, this is the hurdle I face. I can complain or I can adapt. Finally, I cannot really say I have a better idea. Making my commentary likely high on noise, and low on value.
But I am a programmer. Solving problems is what I do. In particular, my specialty, if that word is correct in this case, is troubleshooting. I am not the one who draws up your initial design. I am not the one who keeps your project on track. I am not even the one who reels it all in and plans the after-party. I’m the guy you call when, despite the best laid plans and designs, it just does not work out. If I succeed, the project gets back on track and I move on.
And that’s what this is. A plan that doesn’t work as intended. I mean it sounds sensible right? If you want to hire a programmer, watch him program. But the obvious answer is not necessarily the right answer. And, at the risk of grossly over-generalizing, the easiest answer is usually not the right one either.
Before we go too much further, we should state the obvious. The claim the current interviewing process is a failure is one sided. It comes from the many experienced programmers who find themselves stymied by such interviews. I cannot say I have seen companies complaining about low quality results of their interviews.
That being said, it seems more than passing strange when experienced programmers cannot get past the current gatekeepers.
To keep this short, we will not break down and examine the failures, perceived or otherwise, of the current hiring methods. Perhaps in another article. For this one, let us just assume it is broken and re-examine our goals.
We want to hire good programmers, so I guess the first thing we need to define is what makes a good programmer. We will not list everything, but need something to start from. First and foremost, we have always said IT professionals must be in a constant state of learning and re-learning. We have also said programmers must be multi-faceted. No one-trick ponies. Less commonly admitted, a programmer needs to be a team player (my personal example notwithstanding).
While I do not want to delve deeply into it, I do want to state what should be obvious to everyone. That being, the current mode of over-the-shoulder code interview involving a Leet Code like algorithm challenge hardly demonstrates any of the above. In fact, the only thing it demonstrates is that the candidate managed to pass a Computer Science class on Algorithms and the challenge you gave him was one of his homework problems.
Let us revisit our goals. Find someone with a proven ability to learn, who is multifaceted, and a team player. Starting from there (rather than what we can easily implement), I finally get to the part I did not have to offer up, even a few days ago. I will not go so far as to say I’ve solved it, but perhaps I have a new starting point for our conversation. Again, without offering a complete analysis, compare the above goals with the following scenario.
Choose an algorithm or challenge, but describe it completely. Do not actually assume the candidate knows what a Bubble Sort is. Write it up in detail. Hand them the textbook description. Like, requirements one might say. Then, make a random choice. Roll some dice, pick a name out of a hat, spin a wheel and choose a programming language. But here is the switch up. The language cannot be one listed in the job description. In fact, it should not even be a mainstream language. Think Smalltalk, Eiffel, Forth or any of the many experimental languages. This does a certain amount of level setting across the candidates.
Here are the expected deliverables.
- Document the development environment. Tools, downloads, configurations, integrations, etc.
- Working code
- Automated tests
- Documented code, written as if it were a code review
- Deployment documentation
- User documentation
- Blog post
Then, send them away. Give them a time frame to return, but consider being flexible on the deadline. Ask for updates.
When complete, the interviewing team attempts to recreate the work from the documentation supplied. Before even talking to the candidate a second time, they evaluate the delivered package. Obviously, the code will not be “expert” level. Ideally, the candidate just learned the language being used. But the package as a whole can be evaluated on a variety of levels.
Should the delivery evaluation be favorable, the next interview can occur. This one is old school. Technical skills are not even discussed, having been established by the code challenge. This discussion is the team fit assessment. Feel free to discuss favorite cartoon characters, the validity of pineapple as a pizza topping and even VI vs EMACS.
To sum up, “Ask not what your candidate can do for you during the interview. Ask what they can do for you once hired…”
