markdown guide
 

Honestly being the interviewer can be just as hard as being the interviewee. You really have to pay as close attention as if you were doing the problem yourself. Prepare yourself mentally for a solid 30-60 min of being 100% on. If you go in thinking you can slide through while the other person works neither of you will get much out of it.

I also find it's a good idea to always come prepared with questions ahead of time so at least if you run out of ideas of things to ask you can just go off the questions you wrote down.

 

I've been helping my company interviewing quite a few candidates in the past few months. Honestly being an interviewer is just as stressful as being interviewed.

Usually I spend 1-2 hours before the meeting to study the candidate's resume - mostly focusing on recent experiences. If they have any publicly available profiles (personal site, github, linkedin, etc) I'd take a look as well to see if there's anything I'd love to learn more. My company usually sends out small take home projects a couple of weeks before the interview so I take my time to go through the submissions carefully and write down notes (bugs I found, stuff I don't understand, or things I find interesting and would like to learn more)

Personally I usually try to avoid asking "trivia" questions - like what is X, tell me about Y, solve this sorting problem with impossibly efficient algorithms. For me I would like to discuss the candidate's experiences, interesting past projects, the solution she/he submitted, side projects, etc.

This definitely doesn't apply to everyone. I think the important thing is to be clear about what's your goal for the interview.

 

I've participated in recruiting fairs and next-day interview sessions as both the interviewer and interviewee. If there's anything I've learned, it's to be organized and follow loose questions or talking points with room to flex the discussion. I personally like having conversational interviews versus hard question/answer as it tends to make both parties slightly more comfortable and honest answers aren't fluffed up by the complexity of a question on paper. If the person being interviewed is answering questions thoroughly and completely in Q/A format, I'll try not to disrupt unless the topic drifts too far from the original question.

There are times when I discover a burning question as the interviewee is talking as well as feel stumped on questions to ask or where to go next. I resist interrupting their flow and try to really focus on the point they're trying to make, and ask for clarification the second I don't understand something before my thought process gets derailed because of a minor misunderstanding. If I run out of points to discuss or get lost in thought and time is running low, I like falling back on questions like "Do you have any takeaways you want me to leave with from our interview" or "We're coming close to the end of our discussion, do you have any questions for me, or topics we might have missed that you'd like to talk about?"

Time management is important always but especially important for solid interviews. I realize this because those I host which wrap up 5 or 10 minutes early tend to be the ones I have the most uncomplicated time remembering and digesting. Personally my thoughts get cloudy if I realize I have less time remaining than expected or no time at all, so I always target wrapping up early by a few minutes to debrief and allow the person being interviewed to talk about something that may have realized last minute.

 

I've had my fare share of bad interviews and all are attributed to 2 main causes.

  • Irrelevance with the topic
  • Not being prepared which fuels irrelevance

The following are not advice but my approach into this process and you can extract the good or the bad.

As an interviewer I do the following though not always very professionally:

  • Preparation
    • Print out the candidate's CV and mark the things that strike out and could be interesting
    • Prepare a list of questions/topics that I would like to talk about
  • Interview
    • When the candidate mentions anything interesting, add it to the above list
    • Write any interesting comment or answer to any of my previous highlighted topics
    • Before the end, run through my list and see if there is still something worthwhile asking

In general I let the candidate tell their story. When I feel that the candidate struggles to tell a story then I try to help him and guide him with the story telling. If the candidate lacks enough story because of inexperience, then try to drive the story and figure out his skill by discussing other aspects of life.

I don't hesitate to go off script. I don't approach skills as a checklist and with questions like how many years etc. If you have read the CV and hear his story then you know the basic levels.

I go after evaluating the potential of the person and not if he has a 100% match. I let the candidate asks questions to let him evaluate my side as well and help him understand better.

I don't think why doing interviews could be stressful. It's an exchange of stories between two people. As long as both sides are relevant then it is as easy as having an informal discussion. The information should flow normally.

 
 

I've been writing a series on this :) you can read it on dev.to: dev.to/seankilleen/better-technica...

(edit: fixed broken link)

Classic DEV Post from Jun 22 '17

Moving from a Java Monolith to Microservices at Squarespace

Julian Applebaum stopped by to discuss the challenges of moving Squarespace's Java monolith to a service-oriented architecture.

Kim Arnett  profile image
Senior iOS Developer at Expedia. I enjoy watching my creations work wonders while making a positive impact on the population. Interested in technology, feminism, mental health, and Iron Man.

👋 Hey dev.to reader.

Do you prefer sans serif over serif?

You can change your font preferences in the "misc" section of your settings. ❤️