I’ve been thinking about my experience as both a software developer and a hiring manager. Interviewing and hiring practices have become such a ridiculous game that there are books and sites dedicated to “cracking the code.” There are even companies outsourcing their interviewing to other companies because they feel they aren’t qualified to do it themselves. It seems to me that everyone is going about this the wrong way.
Once upon a time, the intent was to find people who were good at solving problems, as fundamentally that’s what we’re doing via software. Puzzles were often used as discussion aide, but along the way the industry lost sight of their purpose; not to know how many gas stations there are in Houston or why manhole covers are round, but to demonstrate critical thinking. Then the emphasis shifted to coding tests, which are akin to memorizing the phone book. A good party trick, but doesn’t actually tell us anything about this person’s abilities beyond rote memorization, in a single area of a professional software developer’s skill set.
So here are some observations about what’s not working and how to fix it.
Observation 1: Publish salary / compensation range, so potential employees know if it is even worth their while. If you are going to ask potential hires to engage in an arduous process, the economics should be made clear.
Observation 2: Asking to see a “portfolio” or code examples is ridiculous. We’re software developers, not writers or artists, so calling it a portfolio is flawed unless the role has a significant visual or artistic component. Even then it might not be appropriate, as the visual design itself might not be the work of the developer. Plenty of code generating billions of dollars has no user interface. Much of the code we write as developers is not our own – it is protected by intellectual property laws, and is not ours to share with future employers. You wouldn’t want us showing code we wrote for you to other companies, would you? Further, anything complex enough to impress me as a hiring manager will take too much time out of my schedule to assess. It’s akin to a writer showing me a dictionary: words, but lacking context.
Observation 3: Take home tests / projects likely aren’t going to achieve what you want. First, if you haven’t told me anything about the compensation, then why am I incentivized to spend my time jumping through your hoops? Then there is the reality that you have no guarantees that it was actually your candidate who completed the work.
Observation 4: The all-day interview process. In some cases I’ve heard of companies that are now asking for multi-day interviews. This puts a tremendous burden on the candidate, plus is often a test of stamina and trivia as much as a valid showing of the candidate’s abilities. It’s also dependent on the interviewing skills of everyone on a candidate’s loop.
Observation 5: The difference between a good co-worker and a bad one seldom comes down to whether they can solve FizzBuzz. It tends to be about:
- Whether they are good at patterns and abstract thinking
- Whether they can stay on task and manage their work
- How they approach working with other people, especially across skill areas
- Their ability to evolve into new challenges and technologies
Fundamentally if you just evaluate on the basis of simple coding skills, you get the proverbial undifferentiated “code monkey.” Is that what you want to hire?
Observation 6: Some people are really good at interviewing, but weak at work.
Observation 7: Sometime a really excellent candidate is just not good in a particular environment. For example, I once hired someone who excelled at getting things done in a highly-politicized corporate environment, but couldn’t keep up with the lean and mean pace of a startup. It wasn’t that he wasn’t a capable professional, it just wasn’t the right fit.
Observation 8: Sometimes companies misrepresent themselves in ways that set up candidates to fail. For example, many years ago I interviewed at a company under the guise of doing Java development. Somewhere in the conversation it became clear that they really needed a lot more Perl. At another company, same kind of thing happened with Smalltalk and Java. Point being, the companies misrepresented the work environment, the nature of the projects and work, and the technologies at play. This is a sure-fire way to end up with a disgruntled employee, which isn’t beneficial to the company either.
You put all this together and it become obvious that the only way to select candidates is to actually see them do the job. The proof for all parties is in the pudding, and I propose this could be accomplished in one of two ways:
- Rather than an all-day interview loop, instead have them do the job for a day. That is, have them be an active participant. They come to the meetings, they work on assigned responsibilities. Perhaps they pair-program on actual tasks, as a way to get them integrated into the group. This is the only way to reliably see how they will function inside your organization. If you subscribe to the sentiments that “people are our greatest asset” or that effective hiring is the most important job of each manager, then it is a no-brainer to actually do this. It’s the most accurate way to get a picture of the future working relationship. They could even be given a small stipend as a reasonable exchange for their expected contribution to the workday, as you aren’t interviewing them so much as expecting them to be an active participant of the team. Yes, it would take some effort on the part of your team to pull this off, but its a very accurate way to assess the person’s actual technical fit with your team.
- If you operate in a distributed team or in some fashion that prevents you from having them spend a dedicated day with your team, then an alternative is to give them a small paid project. Give them some small amount of work, pay them for it, and observe how they approach it, how they interact with your team, and the resulting work product.
In both cases, overall hiring risk is reduced. The candidate knows in advance whether it is worth their time to pursue the opportunity. By integrating them with the team, you are able to assess their technical abilities, their comprehension of the problem domain, and their ability to interact effectively with your team. You know whether they can accomplish the work because you’ve seen it first-hand.