I’ve been seeing a lot of great discussion on the topic of hiring in software engineering lately, and it’s had my mind spinning and my gut churning. The whole thing is a mess. Some of that mess is just human. Sigh. Humans disappoint me. On the other hand, we can learn, and in so doing make things better a little bit at a time.
One of the reasons that hiring is so frustrating is the cycle of abuse. We are used to companies treating their applicants as adversaries. The company wants you to supplicate yourself to them, begging for their approval to work on their yet-another-enterprise-ball-of-mud-legacy-dig-pit project and prove your passion and commitment to their mission of making quarterly sales goals and not getting middle-managers fired.
In return, they entice you with, um…well, they don’t want to tell you what you will get paid (even though they should) (to be fair, salary isn’t a useful lever for getting better performance either). They don’t have much going on in culture, so they don’t have much to tell you about.
Heck! Why are you applying for this thing anyway? Oh yeah, because you’re desperate. You need ‘a job’ andthis is where you get them. No choice. You’re going to go through this whole painful process, and half the time they will slam the door on your face, never telling you anything useful about what went wrong and crushing the little part of you that was starting to like these people and wanting to see them every day more than your family for years.
If they do let you in, you’ll bear that trial as a mark of pride, and make sure that you don’t allow ‘unworthy’ people join your new ranks. The next applicant better prove herself to you, because you wouldn’t want any rif-raf in here. And the cycle continues.
Taking this pain from the other side, however, I see that TechCrunch recently wrote about ‘Secretly Terrible Engineers‘, mocking the job interview process which requires candidates to prove their basic level of competence. Yet, as someone who has been involved in the interview process, I know that the applicants are there which simply don’t know how to code. At all. They are terrible, horrible, negative contributors which make working at a company bad. They are also concentrated (distilled?) in the stream of candidates spurting through the tech recruitment firms, while the quiet, competent majority sits, shell-shocked from their last trial of new employment, at their desk doing a job they are minimally satisfied by since that is easier than finding you.
An fun anecdote from Hacker News:
I remember, rather vividly, the first time I figured out that an engineer couldn’t program. I was attempting to tell him where a value was being assigned in a program. After failing to do so over email, I went over to his desk and asked him to navigate to the file at issue. He was unable to do so. I told him I would do it, assuming that he was unfamiliar with the directory structure in that part of the program, and opened the file. I then said “So you see, the assignment is made in the fooBar subroutine.” He couldn’t find the fooBar subroutine. I said “It is the third method on your screen.” He couldn’t find it. I said “It is this one, here, which I am pointing to with my finger.” He said “OK, that one. Where is the assignment?”
The fooBar subroutine was one statement long.
A coworker, having overheard the conversation, stopped at my desk later, and explained to me that, if I had pressing engineering issues, coworkers X and Y would be excellent senior systems engineers to address them to, but that Z should be allowed to “continue to devote his full attention to work which he is well-suited for.”
The industry has many destructively untrue beliefs about hiring practices. That there exist at least some people who are not presently capable of doing productive engineering work is not one of these beliefs.
Screening out truly useless people is a requirement of a process, but it’s a step that is made a lot easier by not having a situation where it is the most important or most used part of the process. Better applicants means you can afford a less punative process, and once you are in that place, you can make your screening system less than a interrogation using brain teasers.
Technical interviews often are that bad, too. The argument against coding interviews is a valid one, since not every engineer can succeed at a challenge like that under the pressure of a hostile interview with their livelihood on the line. Good people are valuable and somewhat rare, and we shouldn’t be screening them out by having a hostile interview.
I’ve seen it happen repeatedly over my career; people who’d pass interviews and then, over 15-20 minutes of face-to-face discussion a couple weeks on the job, not be able to comprehend the idea that a C pointer needs to point to valid memory.
That’s what’s so mind-blowing to me about our terrible process today. It aggressively tries to find and dispatch unqualified candidates, so much so that it forcefully repels talented people. And it fails miserably at screening out people who can’t code! It is the worst case scenario of processes.
It’s also really important to remember that the problem is People Who Can’t Code, not “People Not Smart Enough To Code”. Time and again I’ve “worked” with people who could very effectively critique my own code, who could participate in design meetings down to the bits-and-bytes layer, and, having taken responsibility for actually implementing some portion of those designs, could not commit usable code to save their life. I don’t know what the deal with these people is, but they are out there: plenty smart, totally fluent, and completely ineffective.
I was talking to Erin this weekend about the phenomenon and realized that these people not only exist, but are actually favored by the way the market works. A smart person can last many months in a dev role before anyone realizes they’re ineffective. Then, it takes many, many more months to manage them out of the team. By the time the story plays itself out, the bad team member has more than a year on the job, and when they parlay that resume line item to another prominent job elsewhere, their previous teammates aren’t outraged but instead relieved. They end up with gold-plated resumes and tons of credibility.
Add into your consideration this: software developers are very poor interviewers. They have a background in the cycle of abuse, so they are likely to perpetuate it. They have interviewed relatively few people in their lives (a shift supervisor at Arby’s probably does more interviewing), so they have a poor baseline to compare from. They have no specific professional training in the management and hiring process. They are likely to base their decision entirely on emotion and hire based on ego or just hire pretty people (beware the pretty people). Worst of all, your developers are expensive, rare resources in your company that should have something better to do than run interviews (and probably would much prefer doing it).
Using software engineers in a context where they are mainly trying to negatively filter a stream of candidates is an expensive, unproductive waste.
Can we make interviews better? I hope to share some thoughts on that in my next post or two. It certainly needs doing, whether you’re the one interviewing or the one being interviewed. Something better is badly needed.