Technical interviewing can feel formidable. Make it easier by standardizing your interview process.
I’ve conducted a fair number of interviews at Gusto - 75 in the last 2.5 years - and I’ve also taught students at a bootcamp in Denver called Turing how to prepare for coding interviews. After working with so many candidates I’ve learned that there are ways to set yourself up for success when interviewing that don’t require any extra skill or knowledge. Just doing these things and following the process will give you an advantage - no extra thinking required!
At Gusto, we realize that interviewing can feel stressful. Thinking while somebody watches you is hard! To minimize the difficulty, you want to be intentional about how you direct your thought process during and only think about the problem you’re trying to solve.
I’m certainly no expert, but I’ve learned a bit about the brain (through wonderful courses like Learning How to Learn by Barbara Oakley) and I believe these steps optimize for how it actually works in the following ways:
- Your brain is good at thinking about things and synthesizing information. It is bad at remembering things.
- You can store about seven things in your short term memory. When you’re stressed that number goes down to maybe five or three.
- Interviews are stressful. Your brain and body purposely enter fight or flight mode during this stress and de-optimize for complex thinking.
I’ve created a series of simple steps you can follow during a technical interview to increase your chances of success. These steps will make interviews a repeatable process (rather than something you simply survive and then go “well, hope the next one goes better!”) and reduce the mental load you experience as a candidate.
Here are the steps:
- Read or hear the question
- Speak the question back to the interviewer to make sure what you heard is correct
- Begin to take notes in some way, perhaps in the interactive code editor you’re probably using
- Write down an abridged version of the question you just heard and repeated
- Inhabit the problem a bit more and think about edge cases, use cases, and any real world implications of the thing you’re solving
- Ask your interviewer about all these things
- Write down any clarifications you get
- After you feel like you have a good understanding of the problem, sketch out the solution to the problem in comments and pseudocode
- Let your interviewer know you’re sketching out the problem and your approach
- Start writing the plumbing
- Fill in the outlines of the problem by writing classes and functions that match the sketch you created in the step before but don’t fill in the details
- Test that the plumbing you wrote works and produces some simple output
- Start from the beginning of your sketch and fill in the details with code
- Test that each new step works
- After you think you're done with the whole problem, test it to make sure it works
- Spend at least 60 seconds thinking about edge cases, write them down, and then test them
- Reread the problem description and make sure the thing you wrote actually solves the problem you were asked to solve
- Ask the interviewer to see if you missed anything obvious - they might just tell you!
Notice that over half of these steps are prep. To borrow a term from cooking, mise en place, this is all work you do beforehand so you can focus on the tricky bit when it comes.
I guarantee you, even if you follow these steps and feel like you did terribly, the interviewer will still walk away and say “at least they really nailed the process, problem solving, and communication!”
Good luck. Happy interviewing. Go with Gusto!