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.
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.
This seems to be more of a mind reading test than anything else. I think you would probably get more consistent results if you ask candidates questions directly rather than play a game where the candidates need to guess the question you are really asking.
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.
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.
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.
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.
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.
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).
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.