Jonathan Hsieh is a Firehose mentor and tech lead at a startup in the on-demand space. Previously, he was the director of engineering at Akuda Labs which sold to Target. He wrote this guest post for our blog based on his own experiences interviewing and hiring new developers and the conversations he had with our recent and soon-to-be graduates about their biggest concerns around the hiring process.
As a mentor to Firehose students and a former engineering manager, I’ve taken part in just about every aspect of the technical interview process. As an engineering manager, I’ve interviewed tons of new developers and built a team of 10 engineers. As a developer myself, I was on the receiving end of the interview table not too long ago. As a mentor, I’ve helped many new developers understand and prepare for their very first technical interviews.
A Firehose student looking for her first job asked me what she could do about interview anxiety.
How do you prepare for the technical interview so you don’t feel anxious?
Tough question. I’ve been writing code professionally for a decade, and interviewing plus whiteboarding is always stressful. I don’t think there will ever be a way to dampen the experience of someone judging everything I write or say. Even if I know the answer.
I always feel nervous before and during the interview. If you feel the same, then we’re in the same boat.
One question to ask yourself is, “How prepared am I?”
After years of interviews, what I’ve learned is that I’d rather know the answer and worry than have the feeling of not knowing anything. In the end, all you can do is prepare as much as you can for the technical interview.
Whiteboarding is a heated subject and many developers disagree with the method. However, I’ve rarely interviewed at companies that don’t make you endure this process. Given that most companies maintain this standard, if you want a job, there’s only one way out.
And that’s to prepare.
The tried-and-true preparation technique.
I talked to a friend who successfully landed an offer from Google and he gave me his process for acing technical interviews. (It’s important to note that my friend was interviewing for a senior position. This doesn’t mean his technique can’t apply to you if you’re applying to your first position – it’s just significantly more intense than what you’ll want to do.)
He studied 150 questions over a few months and honed his skills to the point where he could write down solutions in less than 20 minutes. For most interviews, you’re given about 45 minutes, so finishing in 20 minutes gives you ample buffer time.
However, being able to solve the question usually isn’t enough on its own. The interviewer is entitled to ask you about the run time complexity, how you could improve the algorithm, and why you chose your approach.
Completing a challenge in half the allotted time can convey the perception of competence.
I know going over 150 questions sounds daunting. My friend is an extreme case. We can scale that number down. For better context, my mentee worked on 20 problems in the month before her first interview. She worked on 5 easy problems and 1 medium problem from LeetCode weekly. She landed her job after her first on-site interview!
When I was looking for a job last year, I studied about 50 questions. I focused on live coding because I noticed this was my biggest weakness when interviewing:
- I worked out problems with pen and paper to simulate whiteboarding.
- I would then code in Ruby and Go – including unit tests.
- I set a maximum time limit of 20 minutes for everything.
In my actual interviews, I never encountered any of the questions I prepared for, but the process helped me really hone the skill of writing code quickly under time pressure. I was no longer wasting time fiddling around for libraries or documentation on unit tests.
My friend’s advice works. I’m now at a fast-growing startup!
If you’re looking for practice problems, Firehose also mentions Codewars as a good starting point. There’s plenty more out there to pick from.
Know the fundamentals.
Take the time to practice implementing the fundamentals from scratch. I’ve encountered many problems which required knowledge of following data structures:
- Array
- Trees
- Stack
- Queue
- Graph
- Hash table
- Linked list
- Heap
Then, look up interview questions which use one or more of the above data structures. Whenever you feel overwhelmed, remember to keep a long-term perspective. Putting in the time is meant for you to improve as a developer over time; your improved performance on interviews is a byproduct of that.
Big O notation is also guaranteed to come up. Rather than rote memorize, walk through the code so you will understand your answers. This is a great guide for Big O notation.
Parting words.
You don’t need to know everything for your first developer job.
It’s critical that you remember that.
I’ve stopped trying to change how I feel during an interview. It’s a unique experience with very little that can be controlled, so I focus on controlling one thing, and that’s how much I prepare.
I believe you can do the job. Firehose gives you a great foundation. Now get out there and distinguish yourself from all the other candidates by acing the whiteboarding problems.
When you feel ready to level up your knowledge on algorithms, read this classic. Take your time and work through the book – I’ve had a copy for years and I’ve used concepts at work. Algorithms don’t show up daily, but when they do, you can make fundamental shifts in performance or a reduction in code complexity. I’ve taken the skyline algorithm into production to solve a problem for many customers.
