If you’re applying for a software engineering position, chances are you’ll encounter some technical interview or coding challenge. For newer engineers applying for software programming roles, the coding interview is often the most terrifying part. However, with a few interview preparation tips and things to consider, the technical interview will seem a lot less scary and will hopefully be a valuable learning opportunity during your job search. Let’s break down a few helpful tips:
BUILD THE HARD SKILLS
Get in the habit of regularly doing code challenges. It’s a much more effective way to prepare for coding interview questions than trying to cram a bunch of studying in before the big day. It’s important to schedule time each day to attempt at least one code challenge. You’ll get better at solving them, and you’ll also get better at outlining your process and speaking to it. A few great websites to help you practice code challenges in varying degrees of difficulty include LeetCode, Codewars, and AlgoExpert.
These code challenges help build the essential hard skills you need to perform well in a coding interview technically. If you’re applying for a mid-level position as a software engineer, you’ll want to feel pretty solid with these types of practice problems in your interview preparation. If you’re gearing up for your first technical interview as a junior engineer, you’ll want at least some exposure and practice with these.
DON’T FORGET THE SOFT SKILLS
Mastery of coding challenges is only half the battle in coding interview preparation, so don’t forget the soft skills. Throughout the entire interview process, including the technical coding interview, there are a lot of things that interviewers are looking for besides your ability to code. These other skills have to do with how well you communicate your thought process, collaborate, talk about the problem at hand, your leadership skills, your drive to learn, and generally speaking, how nice you are. Soft skills are often overlooked by candidates and can be deal breakers for a lot of coding interviews.
A company that’s worth applying to will want candidates that have strong soft skills, sometimes moreso than hard skills, because they show how well a person can grow within the company and develop those hard skills over time. This is especially the case for junior software engineers.
When you practice your code challenges, see if you can buddy up with someone and take turns doing mock interview. Practice talking through the coding problem as you work, asking questions, giving each other hints here and there, and revealing your ability to lead, collaborate, and persevere through the coding test.
ACKNOWLEDGE MULTIPLE SOLUTIONS
This is the “cherry on top” for an interviewer: a candidate that’s not only skilled enough to work through the problem and has a personality that fits the company culture but can also defend their solution and mention alternative approaches. This shows that you’re not just going with what you were taught or what you read online, but that you also acknowledge that there are multiple solutions to the same problem and have considered which is most appropriate for a given context.
As an interviewer administering a coding problem, I would prefer to see the simpler solution over the best solution, as it will give me more time to talk with the candidate. Now, if that candidate can also suggest alternative approaches and defend why they selected theirs, that’s an instant win. Bravo!
An example of this might be a challenge where you’re asked to system design a search function for a video streaming app. You might use an inefficient algorithm for the sake of quick implementation during the job interview, but then mention a more appropriate algorithm that would otherwise be used in real life. Speaking of algorithms…
STUDY YOUR ALGORITHMS AND DATA STRUCTURES
This goes hand-in-hand with the hard skills but deserves its own section. You don’t need to be a master of computer science to ace a coding interview, but there are some standard algorithms and data structures that you should feel good about referencing, or at least mentioning and talking about. For instance:
- How does a bubble sort work vs. a merge sort?
- What’s the difference between a stack and a queue?
- What’s a linked list? What about a hash table?