I've been seeing a number of tweets and posts yet on how to handle an interview, how to prepare for one, what skills you should know.
I chimed in some base thoughts on twitter earlier in the week. While doing that, I realized one conversation that I wasn't seeing much traction on was to run an interview. Over the years I've conducted hundreds of interviews, whether in person, on the phone, over a ZOOM/Teams/Whatever either on my own or with a group.
In all honesty, running an interview so that you get the most out of it and find the best candidate is an art. I've seen Interviewers fail horribly at this and actually turn the candidate off from working with us, great candidates that would have been a welcome addition to the team.
If you're having to lead a round of interviews, here are some thoughts.
If the Interviewee is being asked to come prepared, you better come prepared too. This means going through their resume and portfolio ahead of time. No one wants to see you fuss with your tablet to load an interviewee's portfolio for the first time. How demotivating is that? If they have done something obscure with a language, go check it out. If they are giving you access to a git repository, go check it out. Make the effort to go through their resume - you might be surprised by the hidden gems that you find in it and what they are actually bringing to the table.
The days of having three people sitting across the table hitting you with rapid-fire questions are over. We know some of you can memorize answers and there are a slew of interview question sites out there. Sometimes now, I will ask an interviewee one of these questions just to see if they have been to these sites based on the examples they give me. Look, the person sitting across from you is sweating buckets, and once, you were too. So make the effort to calm them down and relax them. You are evaluating them to be a member of your team, not lead an army. I did a career day a few years ago for my oldest daughter and we ran through some practice interviews. One of the girls I was interested in was very, very nervous (and this wasn't even for a real job). Before getting into the meaty questions, I noticed she had played sports, I asked her to talk about what she thought the parallels to her sport and this "job" she was interviewing for were. As she talked, you could see her relaxing, she gained confidence in what she said and became more excited about what she was talking about. Fantastic - that was the goal.
When I do interviews (in person) I always want a whiteboard handy. If we are doing the interview over a conference call, I ask the interviewee to come prepared to talk about some of the projects they've done. If they can draw out a simple diagram beforehand that is even better. I gave up years ago on asking candidates to write me a recursive function or some fancy sorting method or anything else that was the question du jour.
No, I want you to explain to me one of your projects. I want you to explain it all to me and then I want to hone in on what you did. I want you to walk me through the good, the bad, and the ugly because it's all there for us to see.
As an interviewer, this helps me understand what your role in the project is/was and also lets me know where I should zero my technical questions in on - did you work on the services? The front-end? The database? - let's break it down.
As I said earlier, I want to see the ugly in what you built. Any developer who says it's perfect and they would never change what they built is lying - sorry/not sorry. I wrote code yesterday that I want to fix today. Nothing is ever perfect, libraries change, languages evolve and if you have a keen grasp on the problem at hand, you know what you want to fix in it.
Again, here is where I come in with more technical questions.
You might be applying for Junior, Intermediate, Senior Developer job or maybe a Tech Lead - who knows - but in the back of my head, I'm evaluating you for a job that doesn't exist yet. When you're hiring someone you're presumably doing it because your team is growing. Maybe your role has expanded, your project is growing, your product is doing well in the field, whatever the reason, there is an element of growth behind it - you need more awesome people to meet that growth. As someone close to the problemset, you are probably thinking further out as to what might come next - are we going to need more people this year? Will we have money for it? If the team gets to ten developers will I need a team lead to lighten the load?
You get the idea, I'm looking for someone that has the potential to grow in our team - maybe they become a team lead, maybe a subject matter expert, maybe someone who could help other teams, etc, etc.
Case in point - I once interviewed a junior dev who went through our job description. They only knew half of the technologies. Before the interview, they did their best to learn as much as they could about these technologies and put together a demo geared towards our product line. They brought their laptop and it showed it to us, not everything worked, but the ideas were there.
I left the interview thinking - "We have to hire him" - in a week he learned the basics of what we are doing and put together a demo that somewhat worked. If we change our libraries, he'd be able to pick them up, if we ever need to do some research projects, he's shown himself willing to dive in and learn on his, if we are having product discussions, he's shown the propensity to learn our business model.
Interviews are a two-way street, if you're asking the Interviewee to come in and knock your socks off, you best be willing to do the same. There is nothing worst than making an offer and having the candidate reject it simply because of the interview.