I was just reading a series of tweets about interviewing for a job and this one in particular reminded me of an interview process I endured once:

Let me tell you, the thing that makes a candidate do the worst is when the interviewer just does NOT GIVE A FUCK and doesn't even listen

For this particular job, I applied online. It was the first time I'd actually approached a company in a while. I was excited because it seemed like a great company doing cool things with sweet tech.

Start with a Code Challenge

Their first response to me was "here, take this 2-hour code challenge". Obviously, they were more diplomatic about it, but that was the meat of their response. There wasn't any real conversation, just schedule a code challenge. I thought, okay, sure, this is dumb, but I'll just get through it and then the interview process will begin for real.

The thing I don't like about on-your-own code challenges as part of the interview process is that you can't talk about your own process as you go through it. Well, I mean, you could, but they won't hear you, so it doesn't count. If you get stuck on something, they can't hear you say "at this point, these are the possibilities I've got in mind for how to solve this …". All they see is the finished product (for some arbitrary definition of "finished") of some amount of time you spent on a contrived problem intended to trick you that you only learned about minutes before you started. If you did get stuck, it only looks like you didn't finish, not that you thought of three different ways to go about it only to realize partway in that two of them didn't work because of the contrivedness of the problem.

What makes it even worse in this particular case is that they knew nothing about me yet. They had an interview-quality program from me with zero humanity attached to it because they hadn't spoken with me at all at this point. It is really significantly easier to dismiss a piece of code in a vacuum than it is if you have an actual person associated with it with whom you've actually had a conversation.

After this, I had to submit it college-style by zipping it up and emailing it to them. Maybe we'll discuss my code during the interview, right?

Finally, the Interview

I got a response the following week. Someone at the company set up a 30-minute video interview with me. Thirty minutes. They made me do a 2-hour code challenge but will only spend a quarter of that time talking with me? Totally not getting a good vibe here.

She launched straight into the interview questions after minimal pleasantries. She didn't tell me what her role was at the company and I didn't feel comfortable asking — I didn't want her to think that I assume she's not an engineer because she's a woman — so I decided to roll with it and try to figure out based on the questions she asks. This made me a bit nervous because who you're talking to matters. An HR manager's eyes will glaze over if your answers are overly technical and a developer will likely not care about "HR-style" responses.

Her first question: "What are you career goals?" Well, that sounds like a very HR-like question. I also had no friggin' idea how to answer it. I dunno, I just wanna work with great people and fun tech on cool stuff that gets people what they need or want.

Maybe I should've gone with that answer, but I'm never sure what kind of answer people want to that question and I'm not comfortable saying "I just wanna use fun tech to make great software" because then I feel like I sound like a novice.

Second question: "What is one thing you're strong at?" Another very HR-like question. Also another question I'm not comfortable with. Talking about what I think I'm good at feels indistinguishable from bragging. I'm not even sure how I responded, but I probably stumbled through something for at least 2 full minutes trying not to sound like an idiot and failing miserably.

Third question: "What is another thing you're strong at?" Uhhh … shit. Another one?

Fourth question: "What is another thing you're strong at?" Wait, what? Three times in a row? Making this three separate questions has really made me nervous. Why didn't she just ask for 3 things in a single question? Is she repeating it because she didn't like my first two answers and she's trying to give me a third try?

Fifth: "What is one thing you're weak at?" Well, I saw this one coming after "what are you strong at", so at least I wasn't surprised.

Sixth: "What is another thing you're weak at?" I probably should've seen this coming.

Her next question was surprisingly not a third repetition of that one: "What are the names of your previous 3 bosses?" Finally, not a subjective question! I responded and then realized that that was a really odd question to ask. "We contact them as part of the interview process to rate your performance." Ah, right, because why would you care about references I supply willingly?

You might recall from the beginning of this post a quote about the interviewer not giving a fuck about your responses. Well, during this entire video call, she hadn't been looking at the camera at all and her facial expression never changed. She was clearly not interested in this interview from the get-go. This was the equivalent of having lunch with someone and they're dicking around on their phone the whole time. Even if they're actually holding conversation with you, it doesn't feel like you have their attention. What was the point of this being a video call? Wouldn't audio have sufficed?

I knew by this point that this interview was pointless, but I kept going because we only had 10 minutes left out of 30.

She asked if I had any questions of her. Bear in mind that I still wasn't 100% sure she was an HR manager.

I asked what technologies they use. "Rails on the back end, legacy stuff is Angular, and there's some React — without JSX — and all new stuff is in Elm."

"React without JSX". The fact that she specified that means she's almost certainly a developer. Shit. I'd been wrong this whole time. That means I gave pretty stupid responses. Ugh.

We discussed the tech a bit more and suddenly she's looking at the camera and her eyes are lit up and she's actually showing facial expressions, especially when we discussed how they don't use JSX. This is the interview I wanted the entire time: flapping our gums about nerd shit. Unfortunately, this was only for less than 5 minutes of the interview.

This seemed like a great time to bring up my submission for their code challenge. "Oh, no, I didn't evaluate it." The dev interviewing me for a dev position had never laid eyes on the code that got me this interview.

But then she realized our 30 minutes were up and signed off the call pretty quickly. I was sure I bombed the interview.

The Verdict

The next day, I received an email from someone else saying, sure enough, they didn't want to move forward:

After some internal conversations, we decided that the developer we're seeking right now has a different set of strengths.

I can only assume this is in reference to the three things the interviewer asked about me being strong at — what else could they possibly know about my strengths? Or maybe he was talking about the code submission that nobody ever once talked to me about.

This isn't some enterprise megacorp. This is a reasonably well known startup that's doing great things with cool tech and they want awesome devs to do it, but this doesn't seem like a good way to hire awesome devs. Nothing about this went well. Nothing.

Ways to Improve This

Obviously, complaining about this interview process is one thing, but without talking about how they could've done better, I'm just whining. This can be cathartic, but it isn't helpful.

Talk to me first

If you want to get to know me, talk to me. Appreciate me as a human being and let me know it. The majority of that interview wasn't an interview. It was an interrogation. There was no discussion. It was "I ask a question, you answer it". They were open-ended questions, certainly, but after I responded she offered no conversation in return. Just went straight to the next question. That does nothing to put people at ease, especially if you launch into it almost right away.

If a candidate approaches your company about a job, they're putting themselves out there. That's hard for some people, even exceptionally talented ones. I personally suffer from anxiety, which makes it pretty difficult to talk one-on-one with someone for the first time even under optimal conditions. If you don't treat me like you actually care to learn about me, I guarantee you won't learn much.

If the candidate approaches your company in earnest, it means you probably have the upper hand because they want the job. You have to appreciate that and not abuse it.

Code with me

Pairing is a great way to learn how someone works. Even if they're both driving and navigating, just get them to talk through what they're doing, why they're doing it, and what their thought process is if they're not actively writing code. And even if they are actively writing code, their thought process is still useful since you'll get to see what alternative methods they're considering and discuss why they aren't choosing those.

Pairing also helps you connect with the candidate as a person. Both driver and navigator have to appreciate each other as people in order to get anything done.

Talk to me about my code

Demanding code before you talk to me is bad. Demanding code that you're never going to discuss with me is unacceptable.

If you're not going to pair with a candidate but instead require them to submit to a code challenge, discuss it with them. Tell them what you liked. Don't tell them straight away what you didn't like, but instead ask them why they made decisions you don't agree with. Just because someone doesn't solve a particular problem the way you would have, it doesn't mean their solution is wrong.

Also keep in mind that a code challenge is essentially unpaid work. I'm not going to handcraft a 100% artisanal, locally sourced, free-range solution to your contrived problem because that takes time.

In this particular case, I had a 2-hour time limit, so every moment I spent thinking about one aspect of my solution was a moment I couldn't spend thinking about it another way. When I got stuck because I overlooked something silly, the time I spent figuring out where I got stuck was yet more time I couldn't spend on being productive.

If you don't give the candidate an opportunity to talk about their code, you have no way to know about things like this. You only make assumptions about what you think you can intuit. These assumptions may be dead-on, but they may also be way off. You won't know unless you bring it up with them.

Interviewing Is Hard

Yes, I get it. Interviewing is one of the hardest parts about hiring. People are different. Some people don't interview well (myself included). Some people don't do well on code challenges. How do you evaluate them as candidates?

As if that's not bad enough, maybe you don't have time for interviews because you've got too much to do. Your feature-request and bug-report backlogs are getting out of hand and time spent on interviews is time you're not chipping away at these "more urgent" matters.

The thing is, the more time you spend on making your candidates feel comfortable, the higher the probability of finding the right candidate — or at least narrowing it down to a few, at which point it probably doesn't matter whom you choose. If you interview everyone like the experience I had here, your chance of finding the right person is no better than if you just flip a coin for each candidate.

And finding the right candidate will boost your team's productivity significantly, helping you reduce the workload that's keeping you from spending time on interviews. If finding the right candidate is truly a priority for you, you'll find more than 30 minutes to invest in talking to them and your team will be better off for it.