by s16h on 4/28/20, 4:33 PM with 14 comments
For example, minimally, I'd like to know the candidate's name, how to pronounce it, what I'm interviewing them for, and their most recent experience on their resume. Although it feels embarrassing to say this, on average, I don't tend to spend any longer than 5 minutes preparing.
by sloaken on 4/28/20, 6:05 PM
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.
by vogtb on 4/29/20, 3:39 PM
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.
by paulcole on 4/28/20, 7:26 PM
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.
by zhte415 on 4/30/20, 5:57 AM
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.
by agitator on 4/28/20, 7:31 PM
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.
by the_resistence on 4/29/20, 1:04 AM
by figtil on 4/28/20, 9:51 PM
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).
by IpV8 on 4/28/20, 6:59 PM
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.
by siadhal on 4/28/20, 4:53 PM
by 56782358393 on 4/28/20, 4:42 PM