Let’s face it, coding interviews are challenging.
As a seasoned software engineer who has been on both sides of a coding interview at both small and big tech companies, I know what it's like.
And while it's definitely not the only way to measure your ability as an engineer, technical interviews do give employers important signals about candidates.
Below I’ve written the 4 most important things that you absolutely must do in every coding interview.
1. Understand the problem.
This is not only the first thing you should do, but also where I've seen most candidates fail.
There’s nothing worse than diving straight into a solution without asking any questions. Especially when the solution doesn’t solve the exact problem at hand.
Even if the problem is obvious, it’s important to repeat the question and meet an agreement with your interviewer on what problem you’re solving.
This is also the best time to verify your assumptions, and talk through any edge cases. Some edge cases may be important to consider, while others the interviewer might not care about as much. Sometimes your interviewer might not even require you to solve edge cases at all.
Find out exactly what the interviewer wants you to solve for.
2. Discuss your initial thoughts.
Once you’ve understood the problem, still, don’t code yet.
Pause for a moment to think through one or two possible solutions. They don’t have to be the most optimal.
This is where a solid understanding of data structures and algorithms comes in handy. With enough practice, you’ll be able to solve coding problems using common algorithms and patterns.
Take the time you need to learn these concepts often tested in coding interviews. Take a look at my online course on data structures and algorithms to solidify your understanding.
Once you’re ready with at least one solution, clearly articulate the approaches at a high-level with your interviewer. Feel free to talk through the approaches as well as draw diagrams to help explain your thoughts.
Remember, coding interviews are not only testing you on your ability to come up with a solution. You’re also being tested on your communication skills.
This gives the interviewer an idea of what it would be like for the team to actually work with you on a technical problem.
Finally, I highly recommend asking the interviewer if they have any questions about your solution. Make sure to refine your solution based on your discussion with the interviewer.
3. Code a solution.
Now that you and the interviewer have some sort of understanding about your solution, you can finally write it up.
Obviously, you want to make sure to write clearly written working code. Again, it’s more important to come up with a working solution, even if it’s not the most optimal.
I usually use Python for coding interviews, since it has good standard libraries and its syntax looks most similar to English. This helps me explain the solution better (more on that soon).
But it’s always best to use the language that you’re most comfortable with. This gives yourself the best chances of coming up with a working solution within the time constraints.
One critical tip I have here is to go ahead and use those standard libraries to do boilerplate work for you. As long as you explain to the interviewer what’s happening under the hood, and its underlying time and space performance.
For example, if you want to convert an array of integers into a hash table of each elements counts, go ahead and use Python’s collections.Counter(arr) instead of manually writing out a for loop that updates a dictionary with each element’s count. As long as you explain what collections.Counter does, and the underlying time and space performance.
This will save you time, and let you focus on the actual problem at hand that the interviewer cares about most.
4. Explain your solution.
If you’re able to explain what you’re doing while you’re writing code, great!
If you can't, its okay. It’s more important to write clearly-written working code. You can explain your solution to the interviewer afterwards.
When talking through your solution, it's important to express the solution's performance in terms of memory consumption and run time with respect to the input size.
We formally call this Big O Notation in computer science.
Next, step through your code with an example input and explain how your solution would handle it.
Make sure to talk through edge cases and how your solution would handle them as well.
As you go through your solution, refactor your code wherever there's a meaningful opportunity to do so. Your goal here is to make your code as easy to understand as possible. This gives a signal to your interviewer that code readability matters to you.
In reality, code is read more than it's written. There's a high chance that someone else will have to read and even change your code.
Finally, retrospect on your solution. Often times you might run into something you didn't think about.
This is totally fine, as long as you express how you could correct it. After this reflection, discuss the pros and cons of the approach you went with.
Conclusion
Software engineering interviews can be pretty challenging.
No, you probably won’t have to use a linked list in your next job.
And yes, there are many other important factors that go into a hiring decision, beyond the coding interview.
But coding interviews can give employers key signals about how you work as an engineer.
With enough practice, you can give put your best foot forward in any coding interview.
Best of luck!
Rohit is the Founder of Stack Bash, the ultimate guide to coding interviews for both new and seasoned software engineers. While much of the course is free, you can upgrade to the full course with the discount code DEVDOTTO50 for 50% off for a limited time.
Top comments (0)