Month: March 2015

Josh Rivers

A better interview, a better employee

Did you hear about the company that got amazing, industry-leading efficiency and results from their engineering team, by having them spend 45 minutes meditating, twice every work day, before starting to code? If you haven’t read this one, go do it now! Robert Glass, in Facts and Falicies of Software Engineering, writes “The most important factor in software is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves. … Tools matter. Techniques also matter. Process, yet again matters. But head and shoulders above all those other things that matter are people.” I think most of us know that the 10x developer exists. Some people are simply more productive and capable than others.5743450139_e920e959b8 10x developers are responsible for the success of new techniques, new tools, new practices. 10x developers make their managers look awesome, and their companies immensely profitable. I like to think that most people can become 10x (or at least 8x or 6x) developers given the right management, mentoring, environment, and motivations. That is not, however, my current point. The point here is that there are very good developers available to hire. People who code are not reproducable, replaceable parts. People who code are not identical or even roughly equivalent. If you can accept this fact, then it follows pretty clearly that a hiring process that is focused on filtering out the lowest-quality candidates, and passing whoever is left is aiming for a very low level of success. A disqualification process can only give you low-average results. What if we had a process that focused on detecting the very best developers and capturing them?

We thought [we needed to have a disqualification process]. But the (nearly) resume-blind process we settled on quickly converged on a nearly all sleeper candidate pipeline; in several years, we hired I think just 2 people that had our field on their resume. … Recruiting is two problems: outreach and qualification. … the changes we made to qualification were critical, instrumental, fundamental to our success. Most of our best hires could not have happened had we qualified candidates the way we did in 2009, and the way most firms do today.

–Thomas Ptacek

Recruiting is ‘two problems’. The first one is outreach. Almost all of us completely ignore this side. We put up the ‘help wanted’ sign, and wait for people to show up. A very few companies will play host to local developer user groups, and show off their cafeteria space. Those companies are the stand-outs. They could do even more, but they don’t.

Just a little bit of marketing and differentiation can go a million miles in filling up the candidate pipeline with high-quality people. You can give your employees 20% time, make everyone a manager, give every developer a private office, let everyone work from anywhere, or make each team directly responsible for their software’s operation. It doesn’t take a lot to stand out of the crowd of employers for software engineers, and most of the “concessions” you have to make are, unlike pinball machines and free beer, going to make your team more productive, creative, and profitable. Why are you not doing this?

The important thing is that this is not, and should not be, a gimmick or a useless perk. It just needs to be some concrete, tangible, lasting indication that your company values the people and the work over the safety of status quo ‘best practice’ nobody-ever-got-fired-for-buying- type management. Shout out that your people are important, and you’ll be very different from the others that just write ‘people’ in their mission statement and proceed to mine their human resources. My next post will be on culture, and have a lot more ideas along these lines, but the barrier to entry for being a better place to work is pretty low, and it can have a big impact.

I work at a just fine company. I work with great people. I have absolutely no problem recommending my company to anyone I know who is unemployed, getting abused at their current job, or just needs a stable place to be for a while. What I cannot say is “dude! you have to quit your job and come work with me, because this place is DIFFERENT!” Um. Because it’s not. The good developers that I know get job offers for companies that are ‘fine’ so fast that we probably can’t schedule a phone screen before they sign an offer letter somewhere else.

One last note on the subject of outreach: factor in the Dunning-Kruger effect. The people who are least likely to be qualified for your needs are the ones who are going to confidently knock on your door. The people with a depth of understanding or a flowering genius on a technical aspect are more likely to underestimate their skill and believe themselves to be un- or under-qualified to work with you. Compassionate ourtreach is a tool for getting people to talk to you and creating relationships with those people who have the capacity to be your next tribe of super-performers.

Thomas Ptacek implemented a better hiring process at Matasano and his new firm. I don’t think I can write a more powerful description of his point than he did, so we’ll just do the long quote:

The software developer job interview doesn’t work. Companies should stop relying on them. The savviest teams will outcompete their peers by devising alternative hiring schemes. Years from now, we’ll look back at the 2015 developer interview as an anachronism, akin to hiring an orchestra cellist with a personality test and a quiz about music theory rather than a blind audition. Being good at navigating hiring processes requires a basket of skills that isn’t correlated with job performance. The world is full of people who can speak expertly about programming, but can’t effectively code. The majority of people who can code can’t do it well in an interview. Our hiring process therefore systematically misprices candidates. It’s a moral problem and a market failure. Profit from its correction.

As an aside, Ptacek talks in his second section about unexpected world-class genius. If this interests you, definitely go spend an hour listening to This American Life: Batman.

The first thing that we need to eliminate from our hiring process is the hostility. Hostile judgement of the candidate, their personality, their intelligence, their life work, and explicitly telling them that on the basis of a 30-minute phone screen or a 5 hour line interview, that they don’t measure up is…evil.

Also, we need to work to have the process not feel so hostile within ourselves. As interviewers and hiring folk, what do we have to fear? Let’s address those fears and mitigate them. If we are afraid that we will be slowed down by hiring a new person, we should avoid hiring when it’s a bad time for the team. If we are afraid that we cannot escape a bad hire, if things sour, then we need to be explicit and quick about trial periods. Even if the boss-men won’t let you fix your organization and force you to hire unneeded people, that doesn’t mean you should torture your candidates. They don’t deserve it.

Next we need some formal standards that define a good hire. Even when we run interviews with seemingly objective topics, we tend to have a rather subjective and arbitrary judging criteria. For the most time, however, our interviews are entirely subjective.

Random employees conducting random interviews based in part on subjective psychological assessments, each producing not data but a “hire/no-hire” recommendation, reassembled by a hiring manager into a decision that would be made only marginally less rigorous if it also involved a goat sacrifice.

–Thomas Ptacek

Prepare the candidates. Make the process clear. Give them confidence. Train them to take your interview. Let them interview on their own ground. Let them know if they aren’t quite ready, then prepare them to come back. I think it’s very possible to design a recruitment workflow that is clear and transparent, and lets people who have any interest in working with you learn more, and gradually learn from you, teach you about them, and develop a commitment to joining your team. I think this can contain an interview, but should be much more.

It should also generate some data that is measurable about the person. Hiring shouldn’t be the last step in a series of gut-checks and emotional judgements. It should be the result of of some collected measurements that can be objectively evaluated for the hiring decision, as well as subsequently evaluated to find out if what is measured correlates to the results of the hire.

If you are hiring people to develop software, and testing them on their ability to do so, does it make sense that you should develop some code for them to be evaluated within? Unless your jobs involve starting new projects from scratch constantly, don’t ask your candidates to prove themselves in a new project. Give them a existing pile of legacy code (or a mockup of it) and have them show some work within that. Give them a set of virtual machines to work within that can build and run the test code. Give them a working environment for builds and debugging. Do as much work setting up the test as they have to put in in oder to take the test.

Then use the same test for all your candidates. Get the same facts and learn the same things about each of them, so you can experiment, measure, and improve upon your qualification tools and processes. Check your job interview into source control, and keep track of how it changes.

Make sure your candidates are prepared to take your test. Give them tech support while they are working on it. Make sure someone in the interview process is responsible, not for disqualifying the candidate, but instead for showing them in the best light and advocating for them. If things don’t work out, give the candidate some help and ask them to go away and improve. You could buy them some books, or some online training. You could give them some mentoring and support in finding a position somewhere else.

The people we are interview are people. They are our future co-workers, or the friends of other people we will work with in the future. Their contributions at our company, or another company, are part of the ecology of technology and either enable or limit what we as an industry will be capable of and allowed to do in the future. Every serious candidate should be invested in and treated with dignity.

The results will come back seven fold.

photo credit: Hiring Nerds! via photopin (license)

Josh Rivers

Interviews, Irritated

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.

Thomas Ptacek:

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.