How to decide on an interview process, to hire software developers?

Question

Some parts of the interview process for software developers seem pretty clearly established. Having a fairly brief initial phone screen of some sort seems like a generally good idea, for example. Additionally, the need for a larger software-development-specific part of the process also seems to be well motivated and quite common.

But, recommendations for how the exact form of the larger software-development-specific part should be done vary wildly.

Some examples in no particular order:

• Ask the candidate to solve some programming problem, perhaps one from a standard book of such questions, like Cracking the Coding Interview, or perhaps something simpler. These questions can be done either as a take home exercise, with or without a time limit, or while the interviewer(s) watch.

• Ask the candidate several short knowledge/intelligence testing questions. I've seen mentions of asking the candidate to respond to I.Q. test questions, generic brain teasers, Fermi estimation questions, or hypothetical scenarios like "What would you do if you were shrunk to size of a nickel and put into a blender?". Or perhaps just asking the candidate to regurgitate technical facts about one or more relevant technologies.

• Ask the candidate to informally describe a previous project they worked on. Variants on this include asking about the most difficult project they had worked on, their favourite project, or to ask about a particular part of a given project. The book Peopleware recommends a particular variation on this called an Audition, where the candidate is told ahead of time to prepare a 10 - 15 minute presentation on a relevant topic of the candidates choice, to be presented to a small audience of the candidates potential new coworkers. The audience and the hiring manager then have a debriefing about the presentation and the candidate.

• Another possible option is an unstructured interview, where the interviewer(s) just wing it, and more or less see how well they get along with the candidate. As the sole portion of an interview, this probably only works, to the extent it works at all, with experienced interviewers. But adding some time like this into an interview with a structured portion seems much easier to justify.

One could, of course, mix and match the above across one or more interview sessions, if desired. Additionally, most of these sessions could reasonably have single or multiple interviewer(s), of varying technical backgrounds. For example, one interviewer with a strong technical background can focus on evaluating the candidates technical skills, and another interviewer can focus on evaluating the candidates soft-skills.

The correct answer for any particular hiring scenario, will more than likely depend on the particulars of the actual development work to be done, the company's available resources, etc. But it seems to me that there would probably be some aspects that would be common across most scenarios, and/or a general set of things to consider when choosing a process for a particular scenario.

How should someone think about how to decide on a software hiring interview process?

Answer 1

Ask the candidate to solve some programming problem, perhaps one from a standard book of such questions, like Cracking the Coding Interview, or perhaps something simpler. These questions can be done either as a take home exercise, with or without a time limit, or while the interviewer(s) watch.

You can. But make it simple and not necessarily something that can be learned by heart form the internet, like FizzBuzz. I've used that, but I've often asked for a factorial function, both with recursion and without. You would be surprised how many can solve the recursion one because they saw it in various interview questions, without actually knowing how it works, and fail miserably on writing a simple for loop.

Don't look for syntax, or lacking semicolons, or things like that. Look for having a solution written down on paper that then can be explained by the candidate. Even if they mess it up in the code itself, if the reasoning is the correct one, and they can explain what is supposed to happen at each step (like how the stack grows and shrinks for the recursive one), then that gets them points.

Ask the candidate several short knowledge/intelligence testing questions. I've seen mentions of asking the candidate to respond to I.Q. test questions, generic brain teasers, Fermi estimation questions, or hypothetical scenarios like "What would you do if you were shrunk to size of a nickel and put into a blender?". Or perhaps just asking the candidate to regurgitate technical facts about one or more relevant technologies.

HR has this knee jerk reaction of asking for IQ tests. Sometimes they work, sometimes they fail. I wouldn't bother.

Definitely don't do crap like "What would you do if you were shrunk to size of a nickel and put into a blender?" How is this relevant? Does the job require being transformed into a nickel and being thrown in a blender? Stop this. This was "fancy" invented by "fancy" companies to look "fancy" and even those companies gave it up eventually, because although interesting to learn about some responses from candidates, they don't actually prove anything.

If you want this sort of questions, do logical brainteasers. These are basically short problems with a given set of initial information that you need to reason through, come up with a solution, apply it and get the answer. One, single, correct answer. Not imagining how coins feel in blenders and putting that into any combination of words.

Software developers need to be problem solvers, first and foremost. These sorts of logic brainteasers show those problem solving skills. Even if they get it wrong, again, you can discuss how they went about it and if the reasoning is the correct one, then that gets them points.

Ask the candidate to informally describe a previous project they worked on. Variants on this include asking about the most difficult project they had worked on, their favourite project, or to ask about a particular part of a given project. The book Peopleware recommends a particular variation on this called an Audition, where the candidate is told ahead of time to prepare a 10 - 15 minute presentation on a relevant topic of the candidates choice, to be presented to a small audience of the candidates potential new coworkers. The audience and the hiring manager then have a debriefing about the presentation and the candidate.

This can raise red flags. Do I need to come to the interview with PowerPoint slides besides a copy of my CV? Don't do this!

Definitely ask about previous projects, what they found challenging, what they liked, what they didn't like, why not, or how they solved things. Discuss that. Be curious. Be engaging. Don't just sit there like corporate drones staring at a presentation while the audience (your words) probably check their phones for messages and emails at the same time.

Another possible option is an unstructured interview, where the interviewer(s) just wing it, and more or less see how well they get along with the candidate. As the sole portion of an interview, this probably only works, to the extent it works at all, with experienced interviewers. But adding some time like this into an interview with a structured portion seems much easier to justify.

Never do unstructured interviews. Never.

Go in prepared. Have a list of topics, and things you want to ask about (see my last point in the answer below). Go through the topics with the candidate.

You obviously need to also evaluate "for fit" and see how you get along with the candidate, but this should be one part of the interview, not how the entire interview will unfold.

Have structure in place for the interview and try to stick to it, otherwise you risk going into some tangent that then consumes your entire interview time, and then you need to make a decision to hire or not based on some discussion that might have been interesting but not fully relevant.

For example, one interviewer with a strong technical background can focus on evaluating the candidates technical skills, and another interviewer can focus on evaluating the candidates soft-skills.

This is a good idea. You can do this. But agree before the interview what the roles will be and who will ask what questions, just so the interview goes smoothy, or you'll make the candidate feel like attending a tennis match and switch their attention from one interviewer to the other all of the time. Again... structure.

But it seems to me that there would probably be some aspects that would be common across most scenarios, and/or a general set of things to consider when choosing a process for a particular scenario.

Unfortunately, the most common scenario I've seen is for companies to not pay enough attention on the preparation of the interview itself.

Most of the times it's sending in the wrong people to conduct the interview, without preparation, or people without a plan that then just "wing it".

And the second issue, is that HR has this expectation that the candidate needs a CV tailored for their job posting and company for example (I've seen some HR personnel actually complain when that's not the case). This basically means that the expectation from companies is that a candidate should potentially build 10, 20, 30 specific CVs, depending on how many job applications the candidate might go after, because that's what it adds up to when you look from the lens of the candidate, not that of the company.

But you know what the companies themselves do in this regard? They use generic hiring processes without actually customizing the interview for the actual job position that needs to be filled.

So the last point, and the most important one, is to ask things that are relevant for the job. Spend some time to figure out what skills or knowledge is needed for the job you are trying to fill, and create questions or look for things that are actually relevant and important for that job requirement. Then ask and look for these at the interview with candidates.

Answer 2

Interviewing is a bit of an art. Here is what works best (IMO)

1. Prepare it properly. Make sure every interviewer has a the job description, the resume and a clear assignment what they are supposed to poke at. These are
2. Technical skills A, B, C ...
3. Ability to learn new skills
4. Communication: how well can they talk about complicated technical or people issues.
5. Dealing with mistakes
6. Dealing with conflict and disagreement
7. Ability for team work
8. Staying organized, ability to work on multiple things at the same time without getting frazzled, ability to estimate time an effort for deliverables
9. Commute, family constraints, relocation, etc (if applicable)
10. Career goals, why are they looking, what worked and didn't work well in the past
11. General culture: intro vs. extro, chatty vs quiet, what makes them happy/unhappy
12. etc.

Not all of these apply to every role or are equally important, hence it's important to tailor the interview process to the mix required to make a good decision.

Ask for SPECIFIC EXAMPLES wherever possible. "How do you handle conflict?" will just give a generic or abstract answer which is useless, "Tell me about a time when you had to deal with conflict" will be way more interesting.

Answer 3

The other answers I see focus on the tactics of the interview itself, and that's great. I am mixed in my agreement on some of the topics. I think you need to focus on the "why" first. Why are you hiring this person? What do you need them to do? How do you need them to behave? Too many companies focus on the tactics of the process and end up grilling some person on the vagaries of binary search and bubble sort when they need someone who is going to be able to teach the fundamentals and basics to a team of junior engineers.

Craft an effective job description that outlines the basics of the tasks required to be completed by this person. Then expand on those tasks into the tertiary elements. This person needs to be coding - do they need to help plan that code? Estimate? Analyze? Troubleshoot? Meet with stakeholders? Write down any task that may become relevant to the position, and then use that list to compile the list of skills.

Great, the tactics are covered. What about the non-tactical? What does your team need? Do you need a critical thinker? Do you need someone who can handle leading a team of other people? Do they need to be able to coach/mentor/guide? Do they need to be able to work with non-engineering segments? What will their customer exposure be? Compile the traits that describe the individual you're looking for.

Superb, the soft skills are accounted for. What will this role's objectives and key results be? Will they be building something new? Maintaining something? Adding new functionality to existing work? How will this role be measured for success? Write down all of the expectations of delivery and accountability that will come to define "success" for this role.

You now have what you need to understand what the interview process will look like and how in-depth you need to go into each skill. This will help you determine if you are able to perform the interview yourself through your own understanding of these skillsets or if you need to seek assistance in performing these evaluations. The process shouldn't hammer on someone until they break. It should give you a solid confidence that you're able to understand and measure the person's capabilities against the list of requirements you drew up.

Answer 4

The best way to interview is to decide on the faculties that an ideal candidate would have, and then test those. For example, if you require coding skill in Java, then you should probably have an interview component that asks the interviewee to write some code in Java. If you want to know if the interviewee knows software architecture, then you should ask them to talk about some kind of software architecture problems they've solved, or suggest one to them to try to solve. If you're looking for particular soft skills, you should ask about those, e.g. social skills or why they left their last company, or how they work in a team.

The trick is to make the interview match the real requirements of the job. Obviously you don't want to have them actually solve problems in your company, that's asking for free work and is frowned upon and borderline illegal. You also don't want to ask them to solve LeetCode problems, unless your company's business niche is solving LeetCode problems. So you need to figure out how to pose an interview problem that is relevant to the job that you can accurately assess skill, while also not frustrating the interviewee; every interviewee has been asked to write FizzBuzz a zillion times, so if your interview is "write FizzBuzz" they'll probably ask (or at least think) "is FizzBuzz really something that's an applicable skill at this company?" and judge you based on that.

One suggestion I would make is to not test the interviewee on trivia that is easily researchable on Google, just to "see if they know it". Unless your company has a policy of not using Google to solve problems, that is. It seems esoteric to say "you can't use Google in this interview, but you can use it on the job"; in this case you're not testing the skills the person needs for the job, because on the job they would use Google. So you want to think of problems that are complex enough that the answer can't simply be copypasted from Google, but also simple enough that the individual components to solving it are either "obvious" (to someone of appropriate competence to your company/position) or are easily found on Google, and the puzzle for the interviewee is figuring out what those components are and how to use them, rather than the fiddlyness of reverse-engineering everything from scratch, which is not how your company works (probably, I hope).