skip to content W3C SVG

What I learned doing 250 interviews at Google

2015-06-14
  • Moishe Lettvin
    • 2013-06-26

    • Big time sink: 3 hours to do a 1 hour interview

    • Stressful

    • Random bias: noisy, inaccurate, arbitrary

      • communications problems (one can’t understand the other)
      • candidate or interviewer having a bad day
      • writing code on a whiteboard/paper is not natural, even adding a few lines in the middle is hard/impossible
      • could interview the same candidate with the same group of interviewers on different days and get a different result
      • steve yegge idea: for each person already in the company, it should be possible to find an optimal interview panel (one that would always give that person a hire), and a pessimal interview panel (one that would never hire that person)
      • some people might be consistently hard interviewers. Some people might be desperate for headcount.

    • You can’t directly ask about the things that matter.

      • i.e., is the person focused on genuinely improving things, or just on maximizing some KPI (either adding a kludgey hack, or are you willing to rewrite something that’s making difficulties)

    • Be prepared

      • When someone starts interviewing, give them a training!
        • What’s a good general structure?
        • what kinds of things are you looking for (positives and negatives)?
        • What are ways we think are good to elicit that?

    • Pair inexperienced interviewers with experienced ones so you can guarantee you still get a decent signal.

    • Primary goal: happy candidate

      • If you risk upsetting a candidate to get a good signal, you are doing it wrong.
      • It doesn’t take much to gain notoriety.

    • goal: Answer the question, “Would I love to work with this person?”

      • Supplementary litmus test: “Would I be happy carrying the pager when this person commits their week’s work?”

    • goal: Help the candidate answer the question, “Would I love to work at this company?”

    • Good questions are like onions – you can keep asking versions of them, details about them, for the entire duration.

    • Higher bandwidth communication media improve

    • It’s artificial: you can’t simulate real working conditions and performance evaluation, so accept that. This artifice, by the way, is where your noise comes in.

    • Aim to reduce the noise and amplify the signal

      • Your goal as an interviewer is to help the candidate shine

    • Q&A

      • “They’re good enough for Google, but not good enough for my team”

        • At google, we’d always shoot that down in the hiring committee

      • Talking between interviews, yes or no?

        • Good thing: I’m not sure on this aspect, maybe test it further
        • Bad thing: Seeing a senior person’s opinion will introduce/amplify bias that doesn’t need to be there. It is important to say what particular questions (or general aspects) have already been hit on.

      • What do you want to see

        • Good questions: algorithmic, coding, design.
        • Detailed feedback: ways the candidate attacked the problem. where hints were vs were not needed.