Ask HN: How to best interview a candidate?

Get them to tell stories.

I'm a YUUUUUGE Belieber (see what I did there?) in the power of stories. It breaks the ice, and gets both parties into a rhythm of exchange.

With the CV as a "script" I try to get people to tell me a story about how they came to be sitting in this interview with me. I have them start at the beginning of their career and quickly move forward.

I ask open-ended questions and try to get them off topic -- talk about the city/country they worked. Or the tech stack.

Also, get them to tell a story about a side project.

ANd share one of your own. Like the time I thought self-hosting DNS in out office was a good idea, and how that blew up in my face...

Or, maybe you both should crack open a beer, screenshare some youtube clips, and share some favorite vids for 5 mins.

MAKE IT AS HUMAN AS POSSIBLE.

What is a work environment you thrive in and what was your previous work environment like

Don't ask questions, have a conversation, preferably with quite a few people involved from the team they're applying to. Some conversation starters I have used:

* What's the biggest project you've worked on so far?

* What's the worst outage you've had to deal with?

* What do you think about [framework] (vs. [framework])?

An organic conversation with someone on the right topic(s) will give you far more insight into their suitability for a role, and their own personal career goals than any list of questions. Communication is one of the biggest factors when it comes to making a team work well.

You haven't provided enough information for people to provide focused recommendations.

What is your role in the interview process? Are you technical and is the company depending on you to properly vet the candidate for technical skills? Then you need 90 minutes of concrete coding evaluation, etc. If you're just in the loop to make sure the candidate "fits" the culture, I suppose you could have a dialogue about anything... e.g. "soft" questions like "name a time a you and a coworker didn't get along and how did you handle it?"

If it's a technical programming candidate, is it web front end work? CRUD LOB? back end engineering and scaling? custom algorithms work?

The way you've posed your question is really wide open.

I wrote a blog post on this topic a while back: http://timothymorton.com/post/67472164000/on-hiring-develope...

You're doing it wrong.

If you want good candidates - don't have HR screen anybody, don't spend 1.5 hours, that's way too long, and if you don't know what questions to ask, you're not fit to be doing this.

In other words - if you have to ask, you're doing it wrong. The company should hire a senior developer who already knows.

I would differentiate the interviews. If it's a first discussion, more casual talk about their experience might be most appropriate.

If it's a hands on programming role, not seeing them code (or some of their existing code) early on in the process could make for a costly mistake.

A remarkably subtle and effective way to assess the candidate is to let them lead the interview.

Start with this script - "I've read your CV, know you've met with HR -- what questions do you have for me? what areas would you like to discuss?"

The quality of their questions tells you a great deal about their intellection, motivation, and business acumen.

Incidentally, George Bradt offers excellent advice on evaluating candidates> http://www.forbes.com/sites/georgebradt/2011/04/27/top-execu...

Turn off the video link. Go voice only.

My favourite: Tell me about the project your most proud of.

Let it flow from there, either through asking more probing questions or just listening.

1.5 hour is petrifying, for both parties. I'm somewhat introvert, but even the extrovert people I know would struggle to fill that amount of time with useful content when the parties don't know each other and have substantial shared experiences to draw from.

You can see from these comments why everyone hates tech interviews.

Many devs don't want to tell their life stories (introverts eh, go figure). And the devs you want don't want to fluff for 1.5 hours to satisfy your arbitrary time allocation or inane questions.

Focus. You're looking for:

1. Does the candidate have the skills I need. - Ask about their projects and test their skills.

2. Does the candidate fit with the team/culture. - Interview them with some or all the team, take them out to lunch with the team. See if they gel.

Look at the candidates work history that would be valuable to your company. Work down a checklist of things you need. I have a PM who sends the list to candidates, they appreciate the contact and it has led to hiring some talent we didn't deserve at that salary range.

You didn't really provide enough facts to actually answer your question. In general, I'd present realistic scenarios, dilemmas etc. and talk about those. What would you do etc.?

If it's predominantly a dialogue it'll test dialogue skill more than skill at doing the job. Do a work sample test instead if possible.

> Choosing personnel selection procedures could be so simple: Grab your copy of Schmidt and Hunter (1998) and read their Table 1 (again). This should remind you to use a general mental ability (GMA) test in combination with an integrity test, a structured interview, a work sample test, and/or a conscientiousness measure.

http://www.focus.vc/tokenadult-recruiting-faq/

I generally start by asking about their story. While in the story, when they start talking about their experiences, I ask questions to figure out how much of their resume is padded. [Almost everyone pads their resume and the junior the developer the more the padding. Its a personal opinion though]. Once thats done, I ask a system design problem and try to solve it together. Eg. Lets build Facebook newsfeed today! Go as deep as possible and try to solve it "together" as you would be working together and not against each other. This results interesting hacks/stories from candidates. Then I ask about the toughest problem they solved and go as deep as possible with the details. Finally, I ask "why us?". Take ~2 hours if the candidate is exciting or less if not.

Spend 5 minutes making the candidate feel at ease.

Spend 1 hour pair programming (using a remote collaboration editor, something like collabnet) on a real world problem, perhaps a feature you've already built and shipped.

Spend 15 minutes on a STAR[1] formatted question, such as

"Tell me about a time you had to work closely with a developer, but it was a frustrating collaboration."

Spend 10 minutes letting them ask questions and try to leave them with a positive brand experience and feeling good about the interview.

Interviewing is super difficult and uses skills not often used as a coder.

[1] https://en.wikipedia.org/wiki/Situation,_Task,_Action,_Resul...

First, a bit of meta-advice. People who have a lot of time and energy to opine about interviewing techniques are not always the most knowledgeable. And people who know how to hire people probably have better things to do with their lives than to give away their competitive advantage on Hacker News. From the perspective of a job applicant, the interview process sucks and hiring decisions can seem capricious. Since these interviews often determine a lot about our livelihoods, it's easy for people to get emotional about them. Nonetheless, strong emotions do not make someone an expert.

Now to the actual advice. Make it a technical conversation. Talk about systems design. Turn the video-call into a screen-share and review some code together. A 1.5 hour open-ended conversation sounds like hell on earth and doesn't let you evaluate much about the candidate other than how much of a conversationalist they are. Dialogues are fine, but at least make it a technical dialogue through which the candidate can showcase their expertise and skills.

You probably have time for some of the behavioral stuff other commenters are suggesting, but beware--behavioral interviewing is more complicated than people are making it out to be. Are you hiring a programmer or a storyteller? You have to figure out which behaviors you want to evaluate people on and lead them to give you meaningful information about whether or not their behavior fits the desired pattern. To complicate matters, this is an inherently adversarial endeavor, since the candidate isn't going to want to tell you anything that will make you not want to hire them. Behavioral interviewing is great, but it's going to take a lot more than asking random people on Hacker News how to do it before you get good at it.

Don't do dialogue. Their job isn't to chat it's to do.

Give them tasks which are as realistic as possible.

This is my process:

1) Start with a easy (but real) task to get the candidate over their initial period of nerves.

2) Provide positive reinforcement.

3) Gradually ramp up the difficulty of the task, providing positive reinforcement and/or guiding the candidate where you think they've gone wrong.

4) Towards the end put 'traps' in the tasks which you have encountered in real life - i.e. problems which surprised and stumped you. This is an opportunity to spot exceptional candidates who can see the traps.

I'd skip literally all of the conversation and video aspect and communicate solely with text based chat and screen sharing. Unless you have a real need to see the color of the candidate's skin before you make a decision, I suppose.

>Predominantly a dialogue

Use this process and you're most likely going to wind up hiring the candidate with the best conversation and storytelling skills. There are a lot of people who can make themselves look good on paper and in conversation that don't actually have a lot of skill.

If you're determined to go through with it anyway, my suggestion would be to probe deeply into technical details and the engineering decisions they made in the past projects they worked on and what the results were and also to probe for their decision making process when solving a hypothetical or real engineering problem that you have. Note that asking people for deep details on past projects has its own problems; even when the candidate is attempting to answer with full honesty, memory is fallible and highly variable between people.

Look at all the responses you're getting here, and imagine trying to get 3-4 interviewers to reliably and objectively measure candidates by applying them. "Tell me about a time you had to work with a developer". "Let them lead the interview".

Don't waste your time. This isn't going to work. Even the most careful, thoughtful interview processes proposed here are essentially suggesting you hire by gut feel. Make sure you eat a full lunch before the interview! That way you'll be more open-minded and accepting! Wait, no, starve yourself for 24 hours before the interview. That way you'll be more rigorous!

There are two very simple suggestions I can offer for really improving interviews:

1. Replace as much of them as possible with work-sample tests: small, carefully scoped projects that closely resemble actual work you do in your day-to-day, given identically to every candidate. Note the word "replace". Work sample tests do not work unless they offset actual interviews. Lots of people give homework. They're still hiring by gut feel. Don't waste the candidate's time unless you have an exercise that will count as a vote in the final hiring decision.

2. Standardize your interview. Every question, written down. Before you give the interview, write a rubric: I expect answer X for question 1, answer Y for question 2. You don't have to be completely straitjacketed by the rubric, but it should be solid enough that any of your interviewers could give the interview, create the candidate measurement, and hand it back to you on paper, and then you could make a hiring decision from it without knowing who the interviewer was.

I did both of these things at Matasano. They worked wonders. I have since talked to several other shops that had similar processes. All of them swore by them.

The dirty open secret of tech hiring is that it is overwhelmingly optimized to hire people who are good at interviewing. Everybody in this industry knows a bunch of very "successful" people who have bounced from job to better job on the strength of their persuasiveness, calm under fire, likeability, and vocabulary. The reason we remember those people is we've had to work with them, in the real world, where likeability and calm under fire take a back seat to "actually being able to solve problems day in and day out", and the experience hasn't been pleasant. Try not to add to that problem.

Don't hire if they can't write code during the interview in the language they would be working with. Technical discussion and even pseudocode are not substitutes.

I've been on a lot of interviews and the predominant tactic is to ask a pre-determined set of questions that the company/interviewers think you should be able to answer even if the questions aren't in a domain you listed as a skill or something you have knowledge in on your resume/CV.

I, on the other hand, try to tailor the interview and questions to what the candidate has stated they know or what they are proficient in to determine if they truly are knowledgable in areas they say they are. I'll also ask questions tailored to the publicly available job description since, by applying to the job, you implicitly said "Yeah, I can do that", but put less weight on these questions if it doesn't match up with their stated skills and knowledge (so I'm kinda just probing; you'd be surprised at what some candidates know, but don't put on their resume/CV). The prescreen should basically mean, if you pass this prescreen you are eligible for this job, but we still have to validate that what you said about yourself in the prescreen and resume/CV are true.

So for example I'll usually ask questions about object oriented design patterns. When I ask someone how many design patterns they know and to list them and they give me three (and Singleton and Factory are 2 of them) that's totally fine. I would've only been able to give around 3 a couple years ago before I studied hard for interviews. But if their resume says something like "Strong object oriented design skills" and they can only give me 3 design patterns, then that's a mark against them because if you claim to be strong in object oriented design I would expect you to know more than the standard rube (like me) that can only rattle off 3 or 4.

If their resume talks about doing distributed systems I'll ask questions about distributed systems: what's good design, what are common pitfalls, ways to avoid or mitigate those pitfalls, etc. C# is your number one language, then how are parameters passed to methods in C#? What does it mean that C# is a managed language? What sorts of things aren't managed for you in C#?

As much as possible I try to include a question about how they used a skill or knowledge in a real-world application disregarding whether the end result was good or bad. Then discuss why effort ended up good or why it was bad and how they would've done it differently given hindsight.

If the pre-screen didn't cover it then give them a programming problem to make sure you weed out the candidates that can't FizzBuzz their way out of a wet paper bag. But don't make the programming problem the entire focus of the interview. I'm currently scheduled for a Google interview which is going to be 5 hours of non-stop programming puzzles that you have to solve while the interviewer is looking over your shoulder critiquing everything you do and expects you to figure out the "trick", code it perfectly, and do this while simultaneously explaining everything that you are doing. Plus the problems they come up are purposely designed to be tricky and sometimes even confusing. The funny thing is I bet any of those engineers would crumble under the pressure and ambiguity I have to work with right now every day and yet they'll be judging me on how I deal with tricky problems under pressure. You can see I'm not a fan of the traditional coding interview.

TLDR: Tailor the interview to the candidate's purported strengths. Ask for real world experiences and discuss the positives and negatives of the experiences. Probe for knowledge and skills stated as required on the job description, but don't put as much weight in them if the candidate doesn't list them as a strength. Check for basic coding capability, but don't make that the focus.

It's pretty controversial, but where I work, we have two questions we're looking to answer:

1. Can this person do things with software?

2. Do we want to work with this person?

We screen for 1 in a short tech screen. We screen for 1&2 by having onsite pairing sessions, typically a day.

Mysteriously, having people work on real work with real potential co-workers in the way we actually work is a really good indicator of whether people can work on real work with real potential co-workers in the way we actually work.

I feel like a bit of an odd duck in this topic, because I enjoy and value a lot of the interview process. I've had many interviews, and all but two have been greater than or equal to 4 hours. I enjoy whiteboarding, giving presentations, algorithmic analysis, puzzle problems. I think a lot of people complain in this space, because they don't think to practice them. Interviewing for computer science is a public game, there are so many blogs where people describe their interview process that you should be able to prepare for nearly any interview.

I don't believe that all of this is necessarily applicable to a one and a half hour interview.

As far as programming ability, I think that if your company does any pair programming then this is a good exercise during the interview. I interviewed with a company where I was asked to use a computer without internet connection and solve the problem. The problem the script was vague, and my pair was required to be my research arm.

Regardless of if you are doing pairs programming. If you ask a scenario question and you are looking for a specific algorithm, data structure, or solution, this is okay. You are however strongly suggested to stop them before they waste your entire shared time and lead them down the correct path. With obvious hints. Requiring your candidate to discover that you're looking for a breadth first search when you ask them to implement a text based adventure game, doesn't make sense.

I believe that soft topics have become undervalued. Most the time a soft topics interview is done by a manager or an HR person that you're likely not to work with. My best soft topics interview was done with a panel ranging from developer through HR. They asked me about instances of conflict resolution and non conflict resolution that I had experienced. Having the panel meant that many people, caught phrases that I used and asked me in Greater detail that I think would not have happened normally.

It's also important to know the limits of somebody's expertise. There are a lot of topics that your candidit just won't know. But this information is mostly represented by what is missing from the resume. You can ask ask for anything that is missing from the resume, just expect the answer no. For topics they do list on the resume, have somebody who understands that topic discuss it with them. Either the interviewer should stump the candidate, or the other way around. This helps you understand how the interviewer handles somebody else's knowledge gaps, or their own. You can also accomplish this by asking them to give a presentation on the topic of their choice with open invitation to your company. This however can be very time expensive.

I had a company recently asked me do I know how to use an advanced IDE, or terminal IDE. Although my answers were yes, I feel that I miss understood their goals. What they were more concerned about, was whether I knew how to set up my IDE for a large , existing, code base. I think that this is an important skill to have, and I think that the question can be made more clear.