
Ask HN: As an interviewer, how do you prepare for an interview? - s16h
As an <i></i>interviewer<i></i>, what do you do to prepare before an interview? What information&#x2F;content do you usually look at? How long do you spend preparing?<p>For example, minimally, I&#x27;d like to know the candidate&#x27;s name, how to pronounce it, what I&#x27;m interviewing them for, and their most recent experience on their resume. Although it feels embarrassing to say this, on average, I don&#x27;t tend to spend any longer than 5 minutes preparing.
======
sloaken
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.

~~~
quickthrower2
> which makes my bosses roll their eyes

I think it is fair to explain the importance of getting hiring right to such
bosses. It will increase profit for the following reasons:

Software is a brain game: Having the right people with the right attitudes and
smarts can make a multiplier difference. All the marketing and sales in the
world won't help if the product sucks and nothing can get done due to drowning
in tech debt and bugs. Such a problem leads to the death of the product, and
if the company IS that product, the death of the company. It may take 5-10
years but the death will come. And the growth will not.

Therefore you need to hire the best people you can.

Therefore you need to treat the interview process as being as important (maybe
more so) than the sales process.

The goal is to hire the best people you can afford.

If a good candidate can be sold on the company this increases the outcome of
the final candidate you hire, because from the pool of people you can make an
offer to, more would accept so you can be more fussy.

Reading a CV prior to the interview will help you know that person and tailor
the interview to their strengths, know what makes them tick and come up with
examples of "we do this here".

Also if you prepare or not it is apparent to the candidate in their impression
and evaluation of your company.

If you prepare you can also weed out liars or those with shallow experience,
by digging into their CV with the right questions.

Any boss that rolls their eyes doesn't know what their doing really.

~~~
sloaken
EXACTLY! I did explain that this person will be working with our team 8 hours
a day 5 days a week, so a good fit is critical. She did let me continue on.

------
vogtb
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.

------
paulcole
> 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.

------
zhte415
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.

------
agitator
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_resistence
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.

------
figtil
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).

------
IpV8
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.

------
siadhal
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).

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

~~~
NullPrefix
The question was what you do BEFORE the interview, not during it.

