It upsets me greatly, since there is no immediate or obvious solution to an interviewing scheme which will fit every company. Some companies seem to find processes which work for their size and culture, while others struggle to do so. Human resources management is a complex subject, and it’s hard to get right.

I have experience with only a small subset of interviewing techniques, but none of the following interview components I employ seem satisfactory.

Screening

Screenings are usually done by recruiters, employees whose skills are in seeking and evaluating prospective assets to the company. The first problem here is that recruiters are not team members. Recruiters might do a really good job at, say, finding good recruiters - since this is their domain, and something they are inherently good at. But they don’t develop software. Recruiters don’t work with tech leads and team members, they don’t have the slightest real life idea what managers and leaders want from the potential hire. Hell, the problem is - most team leads don’t even know what kind of person they need. And if they do, they don’t have a slightest idea on how to communicate this properly to the recruiters.

In an ideal world, software engineers and team leads would do recruiting themselves. But this way they would not have time to do their own job, and would thus become recruiters. Boom, the company lost a good software engineer. So you end up hiring recruiters, who have not the slightest idea what a team needs (“person has to be proficient in Blah-blah-blah” is like saying that a writer has to be an expert at writing about red cubes).

Is there a solution? Probably, maybe, I don’t know. Maybe recruiters and software engineers have to communicate more. Set up meetings to discuss team needs, go through training in regards to identifying key traits in prospective engineers. Teams of engineers have to communicate their preferences better. Engineers are hired to fit the culture, not to be a “rock star”. Geniuses don’t go through the HR process, future team members do.

Interview with another engineer

This, even though it has a good intent, is a big whopping failure. What this originally is meant to do - is have a potential colleague evaluate the candidate. Sounds like a fantastic idea in theory, and sometimes it even works the way it is intended to.

Most of the time, however, you end up with a competition-driven technological fanatic bombarding an interviewee with smart-ass obscure trick questions they discovered that one time browsing their favorite language’s mailing lists from the year 1990. In the worst-case scenario, the candidate is not able to answer any of those terrible questions, satisfying the interviewer’s ego while she cranks out a negative report to a recruiter.

In a slightly better version, an engineer will give a candidate a set of hands-on tasks which rarely have anything to do with the real job responsibilities. One version of this: pair programming segment, on the engineer’s machine, under stress and with shaking hands. Are we hiring contestants for a hackathon?

When it comes to software engineering, everyone suddenly forgets that writing code is the smallest portion of the day. This might not be the case for junior programmers, but they are not the ones companies are wasting their hiring resources on. It’s the mid-level and senior workers who weren’t even evaluated on half of their job responsibilities. How are their human interaction skills? Are they pleasant to work with? Will they have issues with company policies? Will they fit? These questions are as important as one’s ability to put together a few lines of code.

Maybe interviewers have to spend less time checking how well candidates write code under pressure, and more time evaluating if they will be a good match for the company’s culture. How do they react when you point out their mistake? Can they communicate concepts clearly? Are they good at marketing themselves? You hire people, not code generating machines. Unless that’s what you need, of course.

Home assignments

Home assignments are something I personally like and despise and the same time. And I find it sad that there are a number of big fat minuses with this approach. First, one might find it insulting. “What, I have to write code for you in my own time? Couldn’t you evaluate me on an interview or something?” This method can turn a lot of people off, and unfortunately the ones that stay are not typically the best quality.

As my co-worker wisely pointed out, if you have a choice between two overall equal companies and one requires you to do more work before being considered - you will naturally pick one that accepts you easier. Any job seeker would feel more appreciated and trusted taking that route.

The honesty factor doesn’t play much role here, since you usually can tell if the person did not write everything herself during the one-on-one followup. But the cost does play a role. The interviewer has to come up with a relatively unique assignment, spend time reading and evaluating the written program, give feedback on a follow-up interview. This adds up if you have many candidates.

This technique does make sense when the list of candidates needs to be narrowed down, or when you’re at the top of your domain. Who wouldn’t complete a day-long homework for Google? Many people will happily spend a sleepless night for an employment opportunity. Even more wouldn’t, especially if someone has a number of options lined up in front of them.

What about other methods?

There is a large number of various interviewing techniques out there. Some companies combine the above specified methods to have a bare-bone hiring template. Some make candidates do paid work for a few weeks before being accepted as a new hire. Some don’t bother and just decide to wing it.

This is still a developing area; I am afraid the solution has to be obtained through the method of trial and error. There seems to be no success recipe which works for everyone. There are, however, a number of alternative solutions. I don’t think most companies put enough resources in finding a successful technique, instead opting for whatever method is in season at the moment.

Comments