2019/09/better-technical-interviews-part-3-the-interview-itself/

[SeanKilleen]

https://seankilleen.com/2019/09/better-technical-interviews-part-3-the-interview-itself/

[SeanKilleen]

Historical Comments

2019-09-23, Disqus User Justin Hill:

This is where I'd appreciate I little bit more detail about the specific types of questions you tend to ask in a more technically-focused interview. Do your interviews tend to be 100% conversational based on what the interviewee has chosen to highlight in their own resume/other professional collateral, when compared against what your organization needs? Do you look at code at all? Your own company's code? Some of the interviewee's code, if available? Otherwise, I'm in complete agreement with the focus on open-ended questions. Back when I was teaching, I was frequently shocked at how even a gentle application of the Socratic method would trip up even college-aged students (and graduates for that matter) who were used to looking for a single "right" answer to a question. Great idea for a blog series - looking forward to reading more!

2019-09-24, Me:

Thanks Justin! This is great feedback and I think I'll be making some updates based on it.

Firstly, I think you just inspired me to write an additional post in the series. :) I specifically refrained from listing any "standard" questions here because I do go out of my way to tailor the conversation and I didn't want to be too specifically prescriptive. However, there are definitely some questions that I tend to use often or have in my back pocket when the need arises. I think I'll do an addendum post with some of these questions and why I've found them to be reliable indicators in the past.

Secondly: at my current employer we do ask for a code sample and if someone takes the time to provide one, we'll review it. I think I'll update this post to speak about scenarios when I'm looking at code with someone during an interview as well. For me, the code we review is secondary to the conversation we're able to have about it.

Agree on the "right" answer aspect -- I don't want someone to think I expect a single right answer (unless it's for a very specific technical question, which I tend to avoid). We work on complicated and complex problems all day long; why would I pretend answers can be simple and tidy?

2019-09-235, Disqus User Justin Hill:

Right on - so no live coding, you tend to focus more on discussing something that's already been created, one way or another. I appreciate that approach. I've heard it said that live coding is "not a big deal" if you just treat it like pair-programming but I don't think that comparison holds water - I've never been in a pair-programming/live problem-solving session at work where:

1. I've jumped in with absolutely zero context (I'm generally at least vaguely aware of the problems people on the team are working on,
   even if I'm not working on them directly, we're all working in the same general tech stack and have developed a culture around how we approach that tech stack, etc), and

2. There has been that big of a power imbalance between the two or more people who are supposedly collaborating.

I'm also starting to seriously question the value of the "take home" interview problem too - it seems like it's very hard to make something that isn't a silly toy problem but also respects the applicant's time. Do your applicants usually provide a code sample from some other project they've worked on (something on github or whatever, if available), or do they usually write something up specially for your interview?