The 3rd part in a 4 part series on how to approach programming interviews, regardless of the topic.
This is the third part of a four-part series. For those who want to jump ahead, here is a link to the entire framework
(Here is a link to the second part)
Code
Now that you’ve come up with a strategy, it’s time to plan and write your code. Before you start writing any code, you should have already figured out how you were going to solve the problem at a high level.
Let’s break down a few specific questions to ask yourself during the coding portion of your interview to help you impress your interviewer.
How cleanly was my code written?
After you leave the interview, your interviewer will be left with a few things:
- A general impression of your skills
- Whatever notes you wrote on the board/document
- Your code
Ideally, your code should be easy to understand while achieving the optimal runtime & space complexities.
Having overly complicated conditionals and inconsistent naming conventions are little things that can just rub the interviewer the wrong way. Some interviewers are sticklers for this kind of thing. Be sure to structure your code as cleanly as possible.
Want to know how clean your code is? Try posting one of your code snippets in the discord here to get feedback
Did I explicitly check for any off-by-one errors?
Anytime you are writing a while loop, manually implementing binary search, or managing any pointers you should always check for off-by-one errors.
Some interviewers over index on these common mistakes. Its best to be thorough and not give them any ammunition to downgrade your performance. If you are struggling with off-by-one errors, try passing a simple example through your code and seeing where the pointers land.
Was I able to predict what functions I would end up implementing ?
Most of the time, you can identify which functions you will end up using before you write a line of code.
If you came up with a solution that leveraged a heap, you may have to heapify, heappop, and heappush (python specific). When you are outlining your solution, you can reference these functions and describe their runtimes/space complexities using shorthand. Doing this before you dive into the code will show the interviewer that you think through your code and its performance before you just starting writing things down.
Did my brainstormed strategy solve the problem?
How well did your plan map out to what you actually ended up coding. Ideally you’ve thought it all through ahead of time and you can just follow the script. Planning out what you are going to code quickly can feel unnatural for some. Be sure to practice outlining your code ahead of time when solving leetcode/hackerrank problems.
How smooth was the coding process?
Were there any hiccups? Did you have to go back to your strategy step for anything? Did you forget your base cases?
Its not a great look to finish the recursive part of your DP solution, only to realize you haven’t thought through any of the base cases or how the cache will be structured!
tldr; The smoother the coding process goes the better.
Was I able to talk through my code?
While coding, did you explain what you were doing or did you go silent. One thing that interviewers hate is when a candidate gets silent when they start coding. The interviewee should be articulating their thoughts as they write.
This is a hard muscle to develop if you are just grinding leetcode. Be sure to do mock interviews with others, and practice solving leetcode questions out loud .
Bonus Points: Did I leverage any interesting functions in my code?
Leveraging not-so-well-known functions in your code is a great way to stand out from others. If you can teach your interviewer about a niche language-specific function during your interview, you will keep them interested and impressed.
Ex. That I used during my interviews
Whenever I would need to define a TreeNode class in python, I would leverage the locals() & update()` functions. Pairing those with a dictionary comprehension would always result in me piquing the interviewers interest. These aren’t the most well known functions, and its not the most human readable code. But being able to comfortably reference a complicated function like this during an interview is a great way to standout.
This code snipper might look complicated to remember, but it never changes. With a little bit of practice, you’ll be able to whip up your own go-to code snippets that will help you impress your interviewers:
Note: While this is less readable than writing the basic approach, this is an example of somewhere that showcasing your expertise outweighs readability.
Conclusion
If there is any take away from this article, it’s that a little bit of planning up front will make the coding portion go significantly faster and smoother. This doesn’t come natural to most so be sure to practice talking with others and solving leetcode problems out loud.
Finally, if you’ve you nailed the coding portion, the only thing left is to review your code! I’ll be adding an article on how to review your code soon
