Problem-Solving Framework for Technical Interview Questions Part 3: Implement Your Solution

*This is based off of Anthony D. Mays’s technical interview question framework located here. Did some work on my own based on this and felt what I came up with also adds value.

*This article also assumes prior knowledge of data structures and algorithms

So you now have gathered all the data you need to make a solution and you’ve developed the blueprint you are going to follow, all the while getting interviewer feedback on the process. Now you need to...

Implement your solution

Time to code up your solution. Remember to refer to both the write-up on how your application is going to solve the problem and your previous test cases and ensure you stay within those parameters. Outside of that, I have no direct methodology for coding the solution and so what I will offer is advice on how to structure your solution:

1. Self-descriptive everything - If you have a habit of describing your variables ‘foo’, ‘bar’ ‘insert derogatory phrase for the lolz here’... STOP!! One of the key things you are being judged on is code readability. While you want to accomplish the task, you also have to write your code in such a way that the next Engineer can read and easily understand what you’re trying to accomplish and how. So this means variable names, function names and the like should describe themselves and should be easy to discern how they’re trying to accomplish their job.
2. Label your code-blocks - If a code-block warrants explanation, write it as a function or class. It’s all about being self-descriptive and promoting readability. A good idea to practice this is to put the restraint that someone should be able to open your code and read it as close to english as you can.
3. Code modularity - Write your code in such a way that if your code turns out to be faulty or no longer fits the scope of a project in its current form, it should be easy to remove and replace. I don’t have too much direct advice on this as I struggle with this myself but as of right now, my solution to tight coupling is make everything a function or class and just call it when I need it. Please feel free to educate me on this as I’ll be very much appreciative for the information.
4. Y.A.G.N.I. (You ain’t gonna need it) - Pretty simple advice here. Don’t write something you do not need. If you’re not sure if you need something, simply don’t write it until you’re sure you need it. A quick tip, you don’t actually have to build everything that your solution needs if you get interviewer approval. Solution needs a Linked List data structure and writing it would take forever? Ask your interviewer if you can assume a library for the functionality in question exists and make due with that. Not guaranteed though that they’ll agree to the request so try to push for a solution you can build from your own knowledge quickly.
5. Have a deep understanding of your programming language of choice - You will be looked upon more favorably if you show to have a strong command of your programming language of choice. Knowing language specific tools and libraries, quirks that may cause issues and the like. This doesn’t mean though to sprinkle syntactic sugar everywhere, the tooling choices you use should be reasonable and again, easy to read and understand.

Remember to engage your interviewer as you’re writing your code. Ultimately they are the one judging your code so you want to leverage the fact that they may want to nudge you in a specific direction. It’s quite easy to dive into code and emerge 30 minutes later. Also I am far from an expert in writing production-level code so feel free to call upon your own expertise and/or educate me as it will be much appreciated.

In the next article of this series, we will wrap up with testing your implementation and I’ll add some final thoughts to the series.

Until then, have a good one!