The Story

by Nick

"Ok, so can you tell me what does REST mean in the context of web-based services?"

This was the fifth "softball" question that Jake served out to the candidate Max Wilson. He had already asked the would-be developer questions such as:

"Explain technical debt and describe some things you as a developer can do to address it..."

"What is polymorphism?"

Jake even asked the granddaddy of all easy questions: "What have you been working on recently?"

He would've settled for the proverbial "I don't know" at this point but the interviewee seemed to have an insatiable appetite to make up answers based on the literal interpretation; even when when Jake used acronyms.

"Please, please, just say something related to web services, HTTP, RFC2616, anything!" Jake's inner voice urged.

Jake reassured himself that nothing could possibly out-do the answer given for the question on polymorphism. Max, moments earlier, declared emphatically that poly-morphism was writing software using different languages so that it could be "used" anywhere. Of course recalling this little gem made Jake's eye twitch.

Max was your run-of-the-mill nice guy. He was kind, easy to talk to, and seemed to have more than enough empathy to help drive product needs. Jake knew he just wasn't there technically and even worse, Max didn't know how to say "I don't know".

Jake was pulled back to thoughts when he was first getting started. He remembered how much he enjoyed the act of programming more than he did the theory or the lexicon of the industry. Back then he didn't know what polymorphism was even though he used the pattern in most of his early projects. Someone gave him his first break and somehow that made him culpable for any future developer who wanted to get into the industry.

"Uhhh, well you see it's when the server is not processing any requests and it goes to sleep to be efficient.", Max stated confidently. This response to the "REST" question pulled Jake out of his walk down history lane, shooting him suddenly back to the present as though he was a rock in a slingshot.

Once Jake's cognitive brain matched Max's answer with the only question that might fit he immediately muted the conference phone. Jake had difficulty keeping his internal voice, internal.

"REST, REST! Representational State Transfer. Chapter 5 of Roy Fielding's dissertation! The architectural style for hypermedia!" Jake announced with a sharp displeasure in his voice. Ranting these facts out loud did not serve as a catharsis for Jake; in fact it did quite the opposite - he found himself irritated.

Normally Jake was a fairly humble person. He often mentored other engineers and helped them advance in their careers. He often mused that he was growing more from those interactions than the mentees were. In this moment however, Jake lost himself. This was the fifth candidate this week he was interviewing instead of writing software or working with his team on their current sprint.

"I used to be good at this interview thing," he thought, "now I don't even have the patience to help this fella understand what REST really means!"

Jake passed on the candidate, which was no surprise, but something bothered him.

"Why is interviewing so hard?"

"Are facts, patterns, architectural principles really that important in determining if someone was a great developer?"

"Surely there is a better criteria or litmus test to determine if someone will succeed as an engineer!"

He spent the rest of the week basting in these questions and thoughts. He decided that the wisdom of the masses could pay big dividends in helping him solve this puzzle.

"What makes a great engineer?"

"What are the important soft skills of a great engineer?"

"What does success look like in our organization and on our teams?"

"What attributes do the engineers that others enjoy working with have?"

After a week or two Jake secured enough answers to begin grouping them into categories. He even went low-tech on his aggregation effort and pulled out a notebook and writing stick (people years ago called them pencils). Despite the judgmental looks he received for his analog efforts he pushed on. Once the work was done he discovered something incredibly shocking.

Jake's notions on what was grade-A candidate material had been quite a bit off the mark. He ranked the groups in priority order (based on which ones had the highest count and most emphatic responses). The output of this whole interviewer's pilgrimage were three distinct categories:

"Can the candidate problem solve?"

"Can the candidate communicate well?"

"Is the candidate genuinely excited about the problem space and technology stack?"

Jake noted that the last one almost didn't make the cut because the other two had so many responses it felt as though he was just adding the third one because of the rule of three.

He leaned back in his chair and glanced with satisfaction at his monitor. Admittedly he acknowledged that the feeling he had was a lot like writing elegant code that solved a hard problem. He'd never admit that out loud but he knew he was on to something.

Jake's next interview was in thirty minutes. With a smile on his face he confidently declared, "It looks like I'm going to need to be a little polymorphic and instantiate a different kind of interviewing attitude."

The Application

by Kirby

Interviewing is one of the most challenging tasks as a software engineer or manager. Nobody takes Interviewing 101 in school and many people never get training on how to interview well. Yet it's a vitally important aspect of building a great team.

For the past several years my role has been to build teams at fast growing startups. I've interviewed hundreds of candidates and hired close to a hundred people, maybe more. In many ways, much of my satisfaction as a leader is due to the people I hired and the teams they helped make better. And yes, there were a few regrets along the way.

Why interviewing is so hard

I already mentioned that good interview training is scarce. But more than that, the entire concept of interviewing is challenging by nature. You can't truly know people from a few short interactions, so every hire becomes a judgment call based on limited information. We are also inherently biased towards hiring people like us, but great teams are made up of unique puzzle pieces, not people cut from the same cloth.

Additionally, the construct of an interview itself is socially awkward. The candidate is usually in an unfamiliar environment, they are asked to talk about themselves, and they know that you are weighing every word they say and making judgments. Not exactly the most comfortable environment, is it? If you're new to interviewing, you might also be making it even more awkward for them.

Creating a relaxed environment

This is still something I'm learning to do well despite doing hundreds of interviews. But it's important if you want to actually get to know people. Your job, from the moment the candidate first steps in the door or onto a call is to make them feel welcome and relaxed. Offer them coffee or water. Give them a tour of the office. Talk to them about yourself and your role at the company. Practice small talk and really listen to what they have to say. Whatever you do, don't jump right into your first question. Instead, do whatever you can to put them at ease. Make them run a few laps around the office to relax. Ok, don't do that. That's a terrible idea. But you get the point.

Smile. A lot.

My natural facial expression is serious and intense, so I tell myself frequently to smile during interviews. Smiling will both make you feel great and put the candidate at ease. I can't tell you how many times a smile has elicited a more relaxed and thoughtful answer from a candidate. If they know you're enjoying the conversation, they'll be more natural and give you better insight into what they are actually like to work with.

Don't let anyone tell you that it's good to see what a candidate is like under pressure by putting them through a stressful interview. Just being in the interview itself is stressful enough. Treat people the way that you would want to be treated.

Listen. A lot. And take notes.

As I mentioned, interviewing is really important, so don't waste anyone's time by disengaging from the conversation. Your job is to really listen to what the candidate has to say. Oftentimes, a great follow-up question to their answer will give you deeper insight than their first answer. For example, a great technique is to ask for specific examples if they give you a rote answer. Tell them upfront that you're going to be asking for lots of examples.

Interview people about topics that actually matter

Whiteboard interviews. Ugh. Candidates hate them and they don't give the best insight into whether a candidate is a good fit for your role. Instead, focus on questions that are actually relevant to the everyday work they will be doing. Ask them about some tough problem you just solved and see if they could have helped you solve it.

Beyond that, you should interview people for your future success, not just your current problems. You will rarely talk to candidates who check off every single one of your requirements. But if they are solid and willing to learn and grow, they will be ready to solve your future problems.

Also, if you're interviewing developers, ask them to answer questions based on the language they prefer. It will give you the best insight into how deeply they understand what they needed to understand to do their previous job. That's a good indication of where they'll be when they come up to speed in your environment.

Coordinate ahead of the interview

Candidates are interviewing you as much as you are interviewing them. If every interviewer asks the candidate the same questions, you look bad. On top of that, you're wasting their time and your time. Asked and answered.

Instead, create a pool of questions across a variety of relevant topics. Assign each interviewer a topic area from the pool of questions. This will ensure you get broad coverage and that the candidate doesn't need to repeat themselves.

What to watch out for

Bias

We are all biased by nature, but being a good human is often about going above and beyond our nature. Avoiding bias is difficult, but here are some tips:

• Listen and take lots of notes. Don't take notes like, "They really blew this question." Write down what they said as close to word for word as you can. Don't make decisions during the interview but instead read your notes later in the day and process their actual answers. Snap decisions are the ones most likely to be based on bias.
• Use a prepared set of questions. Beware of bias in unstructured interviews. Compare the candidates answers to other candidates who answered the same questions.
• Don't let one or two answers be the determining factors.
• Avoid assuming that they're a bad fit Just because they answered a question differently than you. You're hiring people to make you better, so leave room for differences.
• Actually ask yourself if your negative opinions on specific questions could be based on bias. This isn't perfect, but just staying aware is a positive step.

Culture fit questions

It's important that candidates share your core values. For example, you might have a strong no jerks culture. You wouldn't want to hire a jerk. However, your goal in all of this is to hire people who make you better. That means they might bring something to your culture that takes you to the next level. So think about how they add to your culture vs fit your culture.

Making a decision

Ok, so you finally finished all the interviews and now it's time to make a decision.

It's important that you gather feedback from every interviewer. Many people like to schedule wrap up discussions with all the interviewers, but I've moved away from those over time. It's too easy to talk yourselves out of good candidates because one person noted one concern and others jumped on the bandwagon. Instead, I like to talk to each interviewer separately and look for themes. If something concerning was brought up by several people, then I'll dig deeper.

Also, don't talk yourself out of a yes because of one concern. Instead, follow up directly with the candidate about the concern. Don't assume because they completed all the interviews that you can't talk to them again. I've hired several great candidates in the past who I might have rejected based on initial interview feedback. They gave great responses to the concerns that were raised and ended up being great hires.

The Candidate Experience

I want to close by talking about the overall candidate experience. As I mentioned before, a good interview process allows the candidate to interview you as you interview them. Keep in mind what the candidate is thinking and feeling throughout the entire interview process. The way they are treated says a lot about you and your company. I've never worked at a company that pays like Google or Facebook, but I've been fortunate enough to hire a lot of great people. I believe much of this is due to a conscious effort to create a great candidate experience. Here are some tips:

• Respond to any requests from them as quickly as possible, but no more than 24 hours after they contact you.
• Tell them what to expect. Who will be interviewing them? What topics are you going to cover? How many interviews will they have? When can they expect to hear back?
• Give them ample opportunities to ask questions, but don't force them to ask questions at every interview.
• Be transparent through the offer negotiation process.
• Treat them with courtesy and respect. It's an honor that they applied, so be thankful.