Making the Software Interview Work for You — Tip #1
Whether you love them or hate them, interviews are here to stay. They are a vetting process which goes both ways (take that with as much salt as you need). Particularly in software you may be asked to show your technical competence with skills that may never occur in your day to day life. Algorithms, data structures, whiteboarding, etc all could be a part of the every day at the new job. In a lot of cases they are not though. As a budding engineer it can take a lot of work to both practice and develop your skills to be useful on the job, practice technical interviews, and anything else eating away at the hours in the day (such a job searching).
How can we start to consolidate some of these tasks? If you don’t expect to being doing much in the way of algorithms and data structures (not that knowing more hurts anyone in this field), what can we do to make these useful? Of late, one of my go to tricks is starting to implement testing into my algorithm practice. Many of the code challenge websites have a primary function of checking your submission. Why not turn that to your advantage as you practice? Test driven development has caught a lot of steam, and knowing how to test your code will never be a disservice.
Adding testing to your algorithms or any short form programing challenges has several fringe benefits. First, you have an automated checker for whether or not you finished a challenge. You have full control over what you tested, what you checked for, and all of the quality assurance that provides. Unit testing is not easy, and the algorithms are built to be tested. If it’s meant to be tested we can extrapolate the process of making the tests should be as straightforward as we are going to get. Then you submit it to a coding challenge website and it will also check what you did. Now you know if you thought of all of the elements the original task set for you.
While this is happening you are also practicing a second point. While many interviews may have you in the same room with someone else who can vet fringe case questions, you won’t always. Use the tests to really push your code, does it work in fringe cases? Did you actually understand what what being asked and solve the correct question? Not relying on the ready made tests will help you start to think about the challenges in new ways.
Lastly, testing can really help you break down what needs to happen in a problem. If you are writing out a to do list you might skip some steps, because well they are obvious or nebulous enough to figure out in the moment. With a test covering those elements, you can’t afford that kind of fog, especially if you write the test first. It helps to break down what needs to happen first, second, etc. I find when I am stuck on what should happen next, tests really shine. If I have no idea where to start, why not write your tests in reverse order? Going back to practicing for interviews, you know what is expected of you. You are given x and need to eventually return or write y. Write given x do I get y? Ok, well what would be the first step of getting y to x? From having thought about the problem from two directions you have a greater understanding of the challenge as a whole. Now you just have to find the bridge, and that’s easier to accomplish than flailing in confusion.
Well that’s what I have to offer on a possible way to turn interview practice into a translatable skill. Your milage may very, but aren’t we all interested in adding a new tool to help us be just a bit better?
Thank you for reading! Keep the conversation going with the methods you have applied in the comments below.
