Job Interviewing

Tracy Roesler bio photo By Tracy Roesler Comment

Get "hand"-delivered posts.

Hiring. It’s a tricky subject, and a complex problem. How should we be hiring? How should we be interviewing? Can we be ourselves during the process?


The past year or so has been an interesting (and disconcerting) time for job interviewing. The first article of interest to me came out in November of 2016, discussing how the technical interview was a major issue in getting women into tech at all.

Then in February an article was posted, seemingly substantiating this claim. It was based on a trending topic on twitter – how people have failed the dreaded whiteboard question. The article, posted here made me feel better about the times I have struggled, or in a fit of interview anxiety, blanked on the correct usage self referential pointers.

Side Note: I have DEFINITELY failed a white board interview before. So badly that the people interviewing me suggested maybe I should reconsider saying ‘I write code in java’

In case you were curious, my favorite tweet from this is this one:


Then in April, New York Times posted an article about whether interviewing was even worthwhile at all. The fact that the title contains the word “Useless” is probably a key indicator of the author’s conclusion.

So what do we think, does the way we interview today create a culture lacking in diversity? Are interviews a waste of time?

I’m going to side against NYT and respond with a “no”. Job interviews aren’t a waste of time. The article accused interviews of being subjective, which is true. However, the people you are going to work with will have subjective opinions about you; in my mind the existence of selection bias is not such a problem, as long as the interviewer is aware, and doesn’t give it too much weight.

For example: I had an interview once where I really disliked the person interviewing me, and she would have been my coworker. I formed a subjective opinion about her, sure, but it gave me a feel for what my day-to-day would look like at the company.

Which brings my to my second point – interviews are also for the person interviewing. It gives you a glimpse into the culture of the company you’d be working for. Why else would there be pages and pages dedicated to topics like 51 Interview Questions You Should Be Asking. You should take advantage of your interview time to get a feel for your co-workers, or manager, and make a determination about whether you’d be interested in the job.

Tertiarily, making decisions based on solely on paper is equally, if not worse, form. I’ve performed interviews where it’s quickly become apparent that the person has no idea about the technologies they have put on their resume. They merely entered as many buzzwords as they could find. Hiring them would be a huge waste of money, and resources for training them.

That being said, there do need to be some changes into the method of hiring. Today’s technology is a lot about googling, and research, which isn’t always answered in person. I personally really enjoy the idea of a take home technical challenge, which demonstrates a person’s ability to research, compile an idea, and execute upon it.

I’m also not opposed to asking technical questions in person – just limit their scope, and don’t expect 100% response rate to them. Since I work in a technical field, I do expect a question like “[h]ow do you figure out memory usage on a server?” to be a baseline question.

There are other, more radical, approaches. An article in TechBeacon suggests implementing a 4-6 week “trial” period which really forms the basis of the technical interview and decision (cf. How to Fix the Technical Interview). Code2040 suggests setting standards on your interviews, with an emphasize towards your candidates ability to learn.

The thing we really need to get into our interviews is standardization. All people being interviewed should be treated and evaluated similarly. And we need to interview holistically, not too much emphasis on a white board challenge, or on credentials. Instead we need to try and understand a potential employee’s ability for growth, where they are right now, and what they have managed to accomplish. Give them a take home technical challenge with a deadline and evaluate how they attack the problem (do they explain their methodology?), how they document their code (is it commented?), and also, yes, the strength of their code (does it work?, how elegant was the solution?).

We also need to realize that we need to hire different people for the same team; the strengths will balance out and make the team more effective. It’s only when we start considering all of these factors, will hiring really become a much better practice.

comments powered by Disqus