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:

quick intros, try to keep this to a maximum of: 3 minutes
introduction to the question + planning before execution: 5 minutes
pair programming: 45-50 minutes
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.

Is School a Scam??? (ft Joy!)