How to ace my Software Engineering interview
Over the past few years, I’ve taken part in hundreds of interviews. I’ve been both interviewer and interviewee over the phone, on video chat, and in person more times than I can remember and I’ve refined my tactics along the way. No matter the method or the role I have in the interview, I always try to expose the following traits which I consider most valuable in a great technical peer. These are my own opinion, and I’d appreciate to hear yours in the comments!
Solve problems multiple times, slowly, and vocally
As a junior engineer, straight out of school, seeing a solution may be difficult at first. Don’t hesitate to ask questions for clarification or guidance to help generate ideas and, when you do see a solution, take a pause to consider what else can be done before diving straight in. After seeing enough problems over a couple of years, a mid-level engineer will be able to see a solution immediately; it is still valuable to explain yourself thoroughly and consider what other approaches can be taken before rushing ahead. Senior engineers should be able to immediately see multiple solutions to a new problem, sharing the best ideas that come to mind and discussing which might be the best fit for a given problem is a great way to spend interview time, in my opinion.
The stress it again: talk through your thoughts and questions, this keeps me on the same page which is especially important when you get the job and we’re trying to build something together.
Debug with confidence
We all hit snags every once in a while and demonstrating how effectively you can unsnag yourself is very revealing. If you aren’t comfortable setting breakpoints and generally stick to printing out variables it is well worth taking the time to learn the tools provided by your language. I focus on JavaScript, so candidates who use browser tools to inspect variables, or launch their NodeJS applications with --inspect when they want to dig deep, get the edge over those who don’t venture beyond console.log. In my experience, these tools often go underutilized so even being aware of how to use them is a step in the right direction.
Keep learning
This is the hardest one to evaluate because, while everyone says they do it, only the tenacious few spend the time to make it true. For example: if you work primarily in JavaScript but haven’t tried using TypeScript yet, you’re behind the curve. Software is a rapidly developing discipline and staying up to date is hard but important work.
Read source code
The way you learn is important as well. On my team, you’ll be required to review other engineers’ pull requests, which means reading unfamiliar code for comprehension. A great way of getting comfortable with this practice is reading the source code of libraries that you use, which serves the added benefit of understanding it more thoroughly than the documentation can ever achieve. If you need more motivation, Paul Irish is the one who inspired me with his experience reading through jQuery. This can also become a necessity if a library suffers poor or incomplete documentation.
Contribute to open source
After you’ve been faced with missing documentation and taken the time to read the source you have another amazing opportunity at hand: contribute back to that library by making a pull request to improve the documentation. Even just creating an issue on Github is massively beneficial to the core contributors of a package, assuming you aren’t creating duplicate issues of course. When you get comfortable in that realm you can graduate to suggesting code changes to introduce new features, or even publish your own libraries that others can benefit from.
Understand and incorporate other opinions
When working on a team, one of the biggest benefits is solving problems with someone else. I’m hungry for feedback from teammates and suggestions for how to improve solutions because I’ll probably miss something if I work on my own, but with the help of my team, I’m more confident we’ll consider all edge cases and build some better. Being respectful when giving and receiving feedback is important to fostering a safe space for these conversations, especially because we all need to be a little bit vulnerable to share a half-baked idea.
And that’s it
No secret sauce on how to actually solve problems, other than going slow and being vocal. No recommendations of what problem set to practice over and over again, I don’t care if you can implement bubble sort with one hand tied behind your back as much as I care about our ability to work together. Half the time I interview with others I don’t even solve the problem, but I normally make it to the next round. I like to think my success is because I recognize humans are a far more valuable resource than CPUs, and we should use their time wisely. Performance optimizations can come later.
Now that I’ve given away my secrets, come interview at Volta! We’re hiring for a number of roles across Software Engineering and the rest of the company as well.
