Ways to conduct an effective technical interview in a short timeframe? [closed]

Question

Our HR department keeps scheduling on-site technical interviews for shorter and shorter times due to availability and scheduling restrictions. Generally 2-3 hours seems like enough time to have a broader technical interview: introduction, white boarding, logic, coding.

I have 45 minutes to interview a candidate.

Take away 15 minutes for set up / general questions, etc.

I have 30 minutes total to interview a candidate for a Senior Software Engineer role.

I could spend 30 minutes on just white boarding and questions - which would provide me high level context about their systems thinking skills, but that would not allow me to see their programming craft.

I could spend 30 minutes on a programming "build X" exercise, but that would not provide me insight into their ability to design a system.

Looking for suggestions on ways to have an effective technical interview in a very short time period. Thanks!

Answer 1

Keep in mind that you're being squeezed on the "interview time" scale, but not on the prep time leading into the interview or the post-interview evaluation time.

So my advice would be to structure the interview in such a way that it takes more time for you to prep and evaluate... but that time doesn't get in the way of the interview.

Let me give some examples.

• You want to white-board, to get a sense of design skills. But that requires a lot of time during the interview for the person to sketch out facets of the system. Instead, imagine presenting them with an existing whiteboard, and ask them what they think the weaknesses are. Suddenly, they're not having to come up with a full plan on the spot - you've already done that ahead of time. Then say, "We're adding Component X to this problem. How would you approach that?" Or even quicker, "We're adding Component X to this problem, and we've got three possible approaches - A, B, and C. Which is the best in your opinion?"
• You want them to build some code. Great... but that takes time as well, coming up with a lot of different things on the spot and taking up time. How about asking them to do incremental additions to an existing sample of code?

... the thing these have in common is, they're a lot more work for you up front (they require you to come up with existing dummy whiteboards and programming solutions, etc.) But they minimize the time the applicant during the interview needs to display the skills you want to test.

Answer 2

I would argue that you can not do an effective technical interview in a single interview of 30 minutes of technical questions.

There will certainly be candidates that eliminate themselves before the 30 minutes expires, but I would not be too confident in the candidates that made it that far. Proper technical evaluation takes time and there's not much point in doing it if you are not given the time.

In the back to back scenario, work with the other interviewers to agree on who will cover different technical areas. Focus on one area only in your 30 minutes. Meet with the other interviewers to combine your feedback into a recomendation.

Answer 3

You can't do it. I'm sorry, but if what you have is 45 total minutes -- not "45 minutes for me, and 45 minutes for the other guy, for a total of X hours" -- it realistically can't be done for any candidate without a professional record that's in the public domain.

Your best bet is to get your candidates to provide you with publicly available information about themselves. That means, publications, conference proceedings, patent applications and grants, publicly verifiable awards. For a true senior level candidate, they will have them. You will then have to research what they provided, verify it is correct, determine if it is applicable, then formulate your questions.

If this sounds like a LOT of time, tell that to your HR department. Because what they are asking you to do is unreasonable to the point of being just about impossible.

Answer 4

You beat me to it. The bean counters are being "penny wise, pound foolish" and your comp[any will not be able to determine the best candidates, with the obvious consequences. @antopug, it might be time for you to consider polishing your CV and looking around.

If these are permanent, not contract candidates, then you would hope/expect for them to spend years with the company, so surely you can invest the time to interview them.

If part of the problem is not having enough qualified staff to interview them, then it is even more important to get top quality candidates on-board.

Importantly, please remember that an interview is two sided. While you are giving sub-standard interviews, the better class of candidate is asking themselves what that says about corporate culture and whether they want to work there.

We have the occasional question along the lines of “the interview was too short to really achieve anything; is this a red flag?”, which shows that some people consider these things.

Personally, when the end of the interview comes and you , the interview, ask me , the candidate, if I have any questions, that’s when my interview really begins, and I can’t do my part in less than 15 minutes, asking about Processes, methodologies, toolchains & the like.

You don’t want these interviews to be toooo long, so maybe an hour could suffice – if there are multiple rounds of interviews. Use the first hour for screening, then bring back the best candidates, so that you don’t need to give 2 or 3 hours to everyone. You do not mention multiple rounds in your question, so maybe that is a possible solution.

Tl;dr – if you don’t invest time and resources in interviews, then you deserve the candidates you accept.

Answer 5

Our HR department keeps scheduling on-site technical interviews for shorter and shorter times due to availability and scheduling restrictions.

Well, is there any way you can work around one of those? Let me explain what I mean.

You might have only 45 minutes on-site time, but maybe you can have more prep time for both yourself and the candidate?

A combination of off-site and on-site tasks

Give them a coding task and 2-3 days in which to complete the assignment and then you can spend an hour or so looking through the code. In doing so you give:

• the candidate enough time to explain their code and a realistic environment for writing code away from the stress of an interview room
• yourself get enough time to evaluate their code and their choices.

Additionally you might get a good chance to decide your interview questions beforehand and the technical conversation already has a general direction. Use this time to further understand their thought process.

Answer 6

Nonsense.

You can do a lot in 45 minutes. A senior developer is not somebody that can write code fast. They are somebody that will be able to help the other developers. They have the ability to quickly grasp a problem, and propose possible solutions. They have the ability adapt their work flow if the job requires an IDE or language they aren't skilled in. They have experience.

Asking them to build something in code doesn't tap into that experience.

Doing something on the whiteboard only gets at that experience if you do it correctly. You should be looking for how they approach a problem. I remember that the best senior developer I worked with wasn't the best coder; they had the ability to listen to your situation and propose solutions. They could write pseudo code that could get you going in the correct direction, even if they didn't have experience in your domain, or your language.

You need to present them scenarios and talk to them about what their approach would be. You need to make sure they are comfortable coding the development style you will be using. You need to know if they will use the version control system they way the company does, will they do nightly builds, testing, continuous builds the way your company/project does. You need to know these things because if they won't do it, then the others won't either. You need to know they will push the rest of the developers to do these things.

Answer 7

With such narrow window to interview a software engineering candidate, the entire interview panel needs to be very streamlined. There needs to a high level organization of what competency (or competencies) each interview will cover. This will then allow each interview to be shorter, because they are more targeted.

I recommend preparing:

• at least two whiteboard problems with progressive complexity (one question is backup) for one 45 min interview slot, and
• a software system design critique or high level design for another 45 min interview slot.

Generally those 2 interviews gives us enough information on technical skills. I would add one that's more assessing leadership and EQ skills by talking through previous projects and situations.

Answer 8

I've found that a take-home mini project done before the interview as part of the screening process works better than whiteboarding in person. People work better with their own computer and internet access; unless someone is a professional interviewer, they'll generally be much more comfortable solving technical problems sitting at their computer alone rather than being placed in the hot-seat.

Providing a skeleton of a project can remove much of the set-up work, and you can give them specific areas to implement, depending on what skills you're looking for. For example:

• Have them take an existing service, and add a cache layer
• Have them identify performance issues with existing database connection code
• Have them implement specific changes to a UI

Then, in your 45 minute time slot, you can use the code sample they've created to talk through their solutions.

Answer 9

While other answers have covered how you could speed up the process by using pre-screening or other asynchronous ways, here is what you can do in the given 45 minutes.

1. In the first 10 minutes get the environment setup and ask the candidate about how he spends his typical work day and other general questions you want to know about.

2. For the next 10 minutes, give him a problem to solve on an IDE with a source control. The choice of the problem should be such, which you'd expect a Senior Software Engineer in your team to solve in 10 minutes. The expected output could be something as simple as a console application.

3. In the next 15 minutes, make him refactor the code. Ask him to generalize his code, extend his code and write unit tests. The aim is to make the solution production ready.

While he does all of that keep observing the way he uses the IDE, its shortcuts, the way he talks out loud on the decisions that he makes while coding, lookout for standard coding principals being followed like SOLID, any design patterns and abstractions he uses.

4. In the last 10 minutes ask about how he would deploy the code to a particular environment, what quality control measures he would use (e.g. code coverage, gated builds), ask whether the code is readable, robust (with unit tests, yes) and hence easily maintainable, how does he decide to commit the code to the repo and so on.

You need to tweak the above questions and format slightly depending on the tech stack and processes you follow and are looking for in a candidate, but you get the idea.

Answer 10

IMHO, For coding skills send series of short (5 lines) methods (3-5) with 1 bug / syntax error / logical error each prior to the interview on the same day and take 5 minutes to review their thoughts about them during the interview

Or have these methods on papers and hand it to candidates while they wait for the interview

Second option can give you their coding / reading speed as well :)