Ask HN: As an interviewer, how do you prepare for an interview?

A quick glance at the resume for a starting point is usually all I do.

I have a look at the headlines on the CV. Then try and confirm with HM or recruiter what I'm assessing them on, then write up a skeleton interview plan (basically, questions I want to ask or things I want to learn about the candidate).

What you present is sadly what most interviewers do. Which if you ever read books on interviewing they say many people received your resume 10 minutes before, if they even got it. That said I like to be very thorough, which makes my bosses roll their eyes.

1) Scan resume for applicable skills.

2) Scan for transferable skills, i.e. similar but different

3) Look for inconsistencies - most common is a job person was at for a short time but with huge description - indicates they either could not work well with others and got shifted, or they are taking credit for a project where they only attended meetings.

4) Derive specific questions based on their resume that explains how much involvement and what role they played. Here I am trying to find a reason to like them. But also trying to uncover bad habits.

5) I then sprinkle the questions from 4, with my standard list of questions, so as to avoid hammering them in one area. Save the file so I can then add their answers.

During the interview I jot down notes and scores, scores are usually 'Good', unhappy face, 'ok', 'perfect', or a check mark. Part of the scoring is based on the answer. e.g. I see in your current job you use Java, is that the primary language? An answer of yes, does not show me YOU did any Java at your job. The answer Yes we use the current version, and libraries xyzzy and plugh, we use the abc development environment and .... Shows you are very engaged. Getting more into the weeds tells me how much you understand about Java.

Of course I am technical guy, if you are applying for a business analyst job, then I am 'yeah sure, whatever', let me look over the resume five minutes before the interview.

I have only really done technical interviews. My process is to give the resume a once over to understand what technologies and project they have used that I have a deep understanding of. I then prepare a few questions around those areas and order them in increasing difficulty. First I'll ask someone to describe the project, then I'll hit em with a question that proves that they actually did what they claim, then I'll ask them a question meant to push their limits and see how they react. Finally I get to my most important part, which is taking whatever project they described to me and then asking what they would do if their boss came in today and tweaked the requirements. I'll use a requirement change that would force a serious re-architecturing. Exe you built a crud app, what if you needed to support 10,000 concurrent users? You made a data extraction tool, what if it had to extract 1000 Gb of data instead? You built CI for your project, what if that project had 30 developers? These types of questions tend to show how a developer thinks. The hard part is making sure they are comfortable enough to brainstorm with you, as many technical folks would tend to close up under a lot of pressure. Basing it off of a project that they already know well tends to help give them a starting off point.

In addition to this, I like to give them a real problem that the interviewing team has experienced recently that is within their claimed knowledge base. For example if someone claims to be an aws microservice guy, I'll ask them about a time when our AWS ECS jobs needed to decrypt files that were bigger than the maximum allowed disk size. There are many different ways to get around that limit, but they all have tradeoffs.

> I don't tend to spend any longer than 5 minutes preparing.

If you've got more candidates than you need and you suspect the most people will probably be good enough, then why bother spending more? If you're looking for the very best people and want to impress them, you're going to have to spend more time.

Start by honestly evaluating what case you fall into. Many people think they're the second case but aren't. Very few roles require the very best people.

The way I prepare when I want to impress someone is to start with broad questions and then prepare multiple follow up questions based on their response. Go a few levels deep if you can. Also be ready with different levels of hints if they get stuck on a question.

Also anticipate their questions and their follow ups. Do this by reviewing questions your last batch of interviewees asked. Pretend they're interviewing you instead of the other way around. Be ready with explanations of what you hope they'll accomplish in 1 week, 1 month, 1 quarter, 1 year. Be ready to sell your company/team compared to what else might be out there.

I generally spend an hour preparing for each candidate I interview in person. But I work at a small company where every hire is more impactful and we don't hire that often.

This is the problem with most interviews. How can you make a determination if you don't have data to back up a decision. Interviews are pointless if you aren't planning on extracting information that determines whether the candidate is a good fit for the role you are hiring them for.

I take a first principles approach to hiring.

1) We need X. What skills/characteristics are required/desired/ideal for executing X.

2) Read through resume, and look for potential experience that supports the skills/characteristics you are looking for.

3) Craft questions that help you paint a picture of how qualified the person is to do X and whether they will fit into your org. I usually build a few questions to understand the following about a candidate:

How involved were they in projects that are relevant to X. Dig into the technical on those. Ask some questions that only someone who did what they said would be able to smoothly answer.

Open ended creative problem solving question to assess creativity, persistence, and working knowledge.

Deeper technical expertise question. This is usually language specific, coding, and a rabbit hole of a question, where you can keep pushing till you reach the limit of their understanding.

General communication skills, personability, and interests, I pick up on over the coarse of the interview.

The other thing is, if you are an individual contributor and are left on your own to figure out what the role requires, and what to focus on, then I'd argue that the interview process at your company is flawed. A manager should brief his team on what they are looking for, and distribute points to assess for amongst the panel. Otherwise you will inevitably have a lot of overlap, which will result in false positives.

The three most important things I do are:

1. Imagine the perfect candidate personality and skillset for the position

2. Design a list or scorecard with questions to ask about those skills and also general background / personality based on their resume

3. Ask for theoretical explanations and more importantly concrete examples of those skills in practice

I find that the two biggest mistakes in hiring are confusing theoretical knowledge with practical skill, and hiring somebody who generally seems like a smart or nice person but who doesn't fit the role (and doesn't seem likely to grow into it).

Although my company did interview coaching, resume creation and LI Profile enhancement (support services for the interviewee), hopefully this is useful. Many interviewers are in risk minimization mode in the beginning. So they are looking for good fit and also inconsistencies in the career path. Life is messy with fits and starts but an overarching good story and understanding the thought process behind career moves goes a long way to lowering risk concerns. That should be aligned in both the resume and the oral interview. Employers want a problem solver with a general record of focus, attention, and seeking improvements. The right questions will allow these qualities to surface.

A company I used to work for a few years ago did it pretty well.

To begin with, we agreed on who is asking questions if there were multiple rounds for the interview. If I recall correctly, it was just a straight up spreadsheet with the people interviewing, questions to ask, goal of questions, and possible follow ups. These are questions tailored to the engineer using things on their resume. Instead of being like "tell me about a time you showed leadership" questions (which suck) the questions were about specific things on their resume. Eg: "Susan will ask about how they built a replacement for their payment processing platform, with the goal of seeing if they can describe the challenges of leading a team end-to-end on a project."

For the white-board interviews, we did mock white-board interviews with my current coworkers. These were white-board questions that were less about a "right" answer, and more about how the candidate thinks about problems. By doing mock interviews with these problems, we achieved two things: we made sure we're asking questions that are useful (our current coworkers should be able to answer them) and we made sure that had answers to compare against the candidate. For example, if the candidate had an answer that sounded a lot like someone that we already worked with, then no one can say they "didn't pass" the question.

On the whole I think we spent about a 1:1 ratio of hours of preparation to hours of interviewing.

1. I'd know the Job Description pretty intimately, it's likely I wrote it, or a large part of it.

2. Spend about 30 minutes reviewing the CV. There's always a story. Career gaps are fine, constant progression is fine. That's the beginning of the conversation. If I'm inviting someone for an interview that's going to be 1-2 hours of my time, potentially more, and likely 1-3 others' time too, so 30 minutes seems minimal prep time. I feel quite excited at each opportunity to meet someone new.

3. I don't care for looking up someone's social media and judging them on that. 3rd parties do background checks verifying identity, that's fine.

Also,

Prefer one-step interviews. Multiple stages suggest internal chaos - a lack of ability to decide who's in control. I'm hiring manager, I hire. Sometimes I may hire for another team who's manager is 'very busy'. I hate that. People are the most important asset of any team - team, the clue's in the name. HR are at an arms's length for sourcing the individual and doing paperwork on hiring and legality.

In employing people you're taking responsibility for their lives, and they're making a commitment to you - their mortgage, potentially kids and dinner time conversations about their new job, potentially life if relocation. Don't play with people's lives because you're 'very busy' to only spend 5 minutes on a CV.

Also x2,

I'd always escort someone out, wishing them a good day. For confirmed hires I'd walk them around the office to meet the team before on-boarding, see their new desk or room, that's important too.