*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 have successfully written some code (it may not be perfect but it exists) and now it needs to be tested.
Test your implementation
Remember those test cases you wrote earlier? This is where they really come in handy. The test cases are designed to ensure that your application stays within parameters and that you eventually get to your desired output. If you’ve written a fair amount of test cases then you may not be able to run through all of them but definitely run through the primary case first to prove that your application works as intended. You want to run through the application line by line and follow the instructions until you complete the application or come across an error. If you do encounter an error, either logical or syntactic, fix it on the spot if you can. You are not being penalized for making errors while you have time to correct them. Errors are expected and your ability to move past the errors towards a working solution is also being judged. Also, as always, engage your interviewer as they’ll likely be able to help you get past your error and get you back on track.
For those who were unable to optimize their solution in the brainstorming portion of the framework, this is another opportunity to do so. If you find that you can optimize parts of your application while having the time to do so, then attempt to. If your application is modular, I suggest leaving the current application intact first so you have reference to what you did and writing the optimization separately. If your application isn’t very modular then you’ll have no choice but to remove the parts you want to optimize and work on them in place or rewrite the whole application. It is best to write the updated solution so that it would satisfy the previous test cases you’ve written but if need be, be sure to add new test cases to accommodate the changes. Also be sure to test the updated solution with whatever time you have.
Final Thoughts
And that’s pretty much it. There’s one more thing I’d like to share in regards to this framework. This is what I write down at the beginning of each problem before I attempt to solve them:
//Define the solution space
Tests:
//Navigate the solution space
Initial Procedure:
Can we do better?:
Updated Procedure:
//Solve the Problem
Solution Attempt:
Obviously on a whiteboard this becomes somewhat complicated to utilize because of spacing but on some form of text editor, this works very well. This presents the framework in the form of questions to be answered or topics to cover and helps you remember the procedure intuitively.
So lastly, while this framework was optimized for use in technical interviews, I want to adapt a form of it for use in writing production code. I’m hoping the tests and talking about the procedure will act as pseudo-documentation for the task being completed and will provide context to anyone doing a code review. So if you have any feedback from this on how to improve it, please feel free to share it with me here or on my social media account.
Thank you very much for reading, I hope you find this series of articles helpful and have a good one!
Top comments (0)