Show notes
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.
Our TOPPODCAST Picks 
Stay Connected
