Matt's "technical" "phone" interview process

gistfile1.txt

Goal is to get people with the following traits:
  Good technical communication
  Good reaction to feedback
  Eager to learn
NOT looking for:
  ability to solve arbitrary white board problems in a short time
  ability to write code outside their normal editor
  memorization of algorithms to common coding challenges

  These questions require the interviewer to do a little prep work ahead of
  time to personalize the interview since they're not stock questions, but
  shouldn't all good interviewers be doing this prep work to tailor the
  interview?  I'm frequently amazed at how few interviewers do any prep and
  just ask canned questions.


Can they talk about a piece of code they find interesting (whether they wrote it or not) and explain why it's interesting and how it works?

  This helps find out how well they can communicate about something they should
  know well, which should let them speak more comfortably than the typical
  whiteboard code question and is hopefully the position they'll be in quite
  frequently once they're hired.

  What I look for is a little bit of enthusiasm about anything and the ability
  to express that in a way I can understand.  I don't look for them to tell me
  big(O) of some algorithm in the code.

  This also helps gauge the level they're at a bit based on the complexity of
  the thing they think is interesting

  Usually this helps lead into the next question, because IMO the best coders
  know when they're making tradeoffs, what they are, why they were made

Can they respond in a good way to feedback about something they wrote that has a problem?

  This is pretty obvious, but it's pretty miserable to work with someone who
  can't respond to feedback since *everyone* makes mistakes.  This is basically
  like me leaving PR feedback.

  It might be they didn't know their code had the problem, in which case they
  shouldn't be defensive, or it might be they know but were willing to make
  tradeoff for something like HW code.  Either way should discuss how they
  could fix (beefing up tests always a + to mention).  Maybe I misunderstood
  how things worked and it actually wasn't a problem, in which case they need
  to convince me.

How deeply can they discuss a relevant to the role technical subject before hitting limits, and how do they react to hitting a knowledge limit?

  Everyone has knowledge limits, the goal isn't to make the person feel bad
  about where theirs are, but along the lines of the last question to see how
  they react when they hit those limits.  When they hit those limits if they
  don't volunteer the info ask them where they could find out more about it,
  and why they would or wouldn't need to know more about that limit.

  For example, if the role is for an API designer and you ask something like
  what happens when you load a web page and they get down to discussing circuit
  logic before getting stumped that's great, but they should be able to say
  that circuit logic isn't going to help them much at the higher level
  abstractions.  But if they get stuck on how their code talks to the database
  and they don't know why that's important that's a warning sign.

  Best case for me is they go so deep that I'm lost and I end up learning stuff
  from them as I ask more questions.