Welcome to Iteration, a weekly podcast about programming, development, and design.

Article that inspired the episode

Quick notes from this article:

• problem statement: interviewing can be annoying because it's an interruption from deep work
• problem statement: after you've done a ton, it can be boring
• two critical skillsets: attracting talent (making candidates want to work with you) + spotting talent (accurately assessing whether you want the candidate to work with you)
• then it goes on to talk about beginner, competent, proficient, and expert interviewers
• read this article to see where you are in both attracting and assessing talent

Context

How many interviews have you conducted?

JP: At 2 years of Opendoor, I have conducted somewhere between 30-40 interviews. I wouldn't consider this a lot, but my last 10 have definitely been an improvement from my first 10.

John: Pre-tech I did around 50+ interviews. In tech I've done as well 30-40 interviews

What type of interviews do you conduct? Behavioral? Technical?

JP: I've only ever conducted technical interviews

John: I cover mostly behavioral/cultural and cover technical as well.

Take me through your interview process:

what should a candidate expect if they were to be interviewed by you?

JP: I set expectations really early on and give candidates a whole layout for the entire interview. The basic format for my interview is:

1. quick intros, try to keep this to a maximum of: 3 minutes
2. introduction to the question + planning before execution: 5 minutes
3. pair programming: 45-50 minutes
4. closing questions: the remainder

John: I always over-communicate and try to "do" as little as possible during the interview. I prioritize "Async" interviews as much as possible.

• More recent process:
  • Job Listing Job listing with very clear compensation listed
  • Applications Applicants Apply (150+ for last open position)
  • Shortlist Pick the top 10 (or so) I am interested in ignoring name or email address (Hide the columns) and look at the objective experience, read their writing (because we are remote)
  • Code Challenge Email that top 5-10 and offer $100 to do a code challenge, takes anywhere from 2-4 hours. Last time it was implementing an API, they get the $100 when they submit a PR for review. Again set expectations on the start date, role, compensation etc. Set expectations for a review. It's a small test to see how we work together.
  • Async Code Review Sr Developer and I leave comments, ask questions about the implementation Async.
  • Real-time interviews — Then pick the top 2-3 from that phase and do real-time interviews.
    • Re-iterate the position, compensation and expectations
    • We talk background, career goals and motivations for applying to this job
    • They walk me through their code challenge, why they wrote it the way they did.
    • Then I allow time for them to ask me questions about the position.

What would it take for someone to pass your interview?

• JP: We have to fill out a form after we conduct interviews so there is some grading criteria. i.e. code quality, tests, communication, algorithm speed, etc. I try not to nit pick language specific, trivia-like things. For example, it doesn't matter to me if a candidate doesn't know off the top of their head the syntax of setTimeout if they've spent the last year coding mostly in Python.
  • Things are obviously different for hiring a new grad vs. a senior engineer. The bar varies
• John: Core things I am looking for: effective communication (written and spoken), self-motivated individuals (managers of one), skilled learner, Very competent in at least one language or framework (not even my own stack).

Hot tips / Things to keep in mind

JP

Don't let a candidate spin their wheels - try to unblock them. See what working with them would actually be like.

John

My interview style is a bit different.

• Honest — Never set any kind of false expectation, be yourself
• Unpretentious — No trick questions or techno-bable
• Real — Try to communicate and work with candidates as you would in the job.
  • You'd never toss out a question "just to stump" a coworker

Picks

JP: https://github.com/ayu-theme/ayu-vim - I've moved away from Dracula

JP: https://whimsical.com/

John: Book: Every Tool's a Hammer by Adam Savage — Yes, Mythbusters guy but also incredible maker and leader of technical teams building really complex things

• so many great similarities to tech.
• Planning, Working, Creativity, burnout, estimating,
• plus a whole chapter on types of glue and random stories from his special effects days.
• I've really dug this book, doing the audiobook, will be buying a physical copy.