← Hiring

Technical Interview

Training

Process overview

This section started an outline of the live training, but can be a living document. Updates welcome and encouraged!

Goals

  • The EM is going to want a thumbs up or thumbs down on proceeding and a rough estimate of their level.
  • I don’t like reducing people to a boolean or a title. You’re going to get the full scouting report from me.
    • Strengths and weaknesses
    • Red flags
    • Areas that I don’t think we derisked.
  • You are comfortable and they may be worried about their livelihood. There’s a power imbalance. Your job is to make the next 90 minutes feel as collegial as possible.

Preparation

  • Look at the code sample you’ll be going over.
  • Have some questions. They can be in the Slack thread. They can be in a notes buffer. But don’t try to sight read the code with a live candidate.
  • Have the resume and some familiarity with it.
  • I like to have both up in a separate browser window that I can share.

The tech interview

Start with introductions (:00)

  • Tell them you’ll introduce yourselves first and then let them go next.
  • Briefly, what you do here
  • How long you’ve been at the company
  • I talk about how long I’ve been doing the language and my open source contributions. This is helpful if you think they recognize you.
  • Geographic location. Not real important, but reminder that we’re remote first.
  • Hand it off to your partner for the same.
  • Turn it over to them.

Lay out the agenda (:04)

  • We’ll start with a review of the code sample.
    • Emphasize that it’s not a whiteboarding session. No gotcha questions.
    • We request these as a conversation starter. We’re going to talk about interesting design decisions and tradeoffs.
    • We’ll ask some hypothetical questions about productionizing the code.
  • We’ll move on to your resume and talk about your experience. This portion will tend to be a little less technical.
  • Interviews are a two-way process. We leave time at the end to turn around the virtual table and let you ask us questions.

Code review (:05)

  • This is not a standardized test.
    • You’re not usually interviewing every candidate anyway.
    • You waste a lot of time on the candidates batting 0.000 or 1.000
    • You’re exploring the peaks and valleys of their skills
  • Circles of competence
    • Try to find something in the center of yours but at the edge of theirs. Are they teachable?
    • Try to find something in the center of theirs and the periphery of yours. Do they teach you something?

Code review questions

Good questions have no right answer!

  • Choice of libraries
  • Scala: tagless final vs. IO
  • Scala: embedding calls to the system clock vs. parameterizing time
  • If they wrote tests, mocks vs. integration vs. property tests

Design questions

  1. Caching

    The weather service has upped their prices. You make a penny per request served, but it now costs you ten cents to call the weather API. How do you stay in business?

    • In memory vs. distributed
      • How does it change when you have multiple instances?
      • Doest it make sense to have both?
      • If you’re routing traffic by geography, what happens during severe storms?
    • Cache keys
      • Precision
      • Don’t grill them on the details of GIS
      • How do you know it’s working?

  2. Observability

    You’ve got the top-rated weather app on both the App Stores. Success is fleeting. How do you know your system is struggling before the reviewers do?

    • Logs vs. metrics vs. tracing
      • Many candidates don’t understand tracing yet!

Resume (:45)

  • I’m mostly interested in avoiding zealots!
  • Find two technologies that are in “opposition” and have them compare
    • REST vs. GraphQL
    • Java vs. Scala
    • Spark vs. FP
  • If you share an obscure technology at the bottom of the resume, go there!
    • Chuckle about it, “nobody uses that anymore, but … is there anything you miss?”
  • Focus on softer skills
    • If they claim to be a teacher, explore that.
    • How do you introduce a new technology to your team?
    • Process questions

Turn the table (1:10)

  • Remind them the third interview is the team interview, so we’re better suited to answering general questions about Jack Henry
  • Be professional, but it doesn’t do either side any good to be dishonest

Post-interview

  • Start a DM with the EM and your partner
    • I like to keep this out of the hiring channel. Today’s interviewees are next year’s interviewers!
    • I don’t disgaree with my partner often, so I worry less about coordinating with them before talking to the EM.
  • EMs are busy, don’t bury the lede. Be bold. They might want to schedule the next one quickly.
  • But this is a weighty decision, and you just invested two hours. Give them details too.