This week, I want to focus on one of the most important parts of the interview process; the code challenge. Whether you are working on a whiteboard or are able to code over a shared screen environment, being presented with a question you don't know how to approach can be a daunting task. Perhaps you understand the logic and syntax but don't feel confident getting the ball rolling or you are able to follow someone else's code without a problem and rely on the crutch of too much guidance. What you don't want to do is freeze up and stare at the blank screen.
There can be quite a bit of uncertainty of where or how to start so I decided to write a basic guideline to keep you moving forward.
1. Recieve the question
2. Read the problem. Now read it again.
Give yourself a minute to understand the prompt. If you don't understand the problem properly you can't answer it either. Ask questions, you don't want to misunderstand the directions and waste time working in the wrong direction.
Depending on the prompt, your questions might be along the lines of:
- What am I passing into this function?
- What is the purpose of this function? What will I return at the end?
- What datatypes does this array contain?
3. Plan of attack
This is a good time to write down notes on the board. It will allow you to structure your problem and look for patterns and steps you can eventually optimize and refactor. You will have just established what the purpose of the function is and its parameters in the step above, and you can talk through your strategy by listing it off as pseudo-code on the side of the whiteboard, or just making quick comments in your coding environment. The purpose of this pseudo-code is to help you translate it into code. You can do this line by line in the text editor and provide a clear outline of what you are working to achieve.
4. Answer the Question
Now that you have asked your clarifying questions, organized your plan of attack, and begun to write pseudo-code, its time to translate it into your language of choice and debug. In a text editor environment, I find that I put a console.log() if I'm coding in JavaScript, or puts in Ruby after every line as I'm checking the values of my code and seeing if it is operating the way I intended. What's important is that you come up with a solution. Don't be too good for the brute force solution because the sooner you get that up and running you can move on to your refactor.
5. Simplify
If you went with the brute force solution it's a good idea to mention that you are aware that you provided the brute force or naive solution but that you would improve your code through x and y because of z. If you have time, this is your opportunity to simplify and optimize your code with a refactor. Take the time to consider the space and time complexity of your solution and how it would work on a larger scale. If you're feeling a little fuzzy on Big O notation check out my blog post on it:
6. Practice, practice, practice
Learning to code is a journey, the only way we are going to get better at it, interviewing, and trusting our instincts (not relying on others) is through practice. Welcome constructive criticism, feedback, and make sure to redo a problem especially if you had trouble with it. If you have someone to practice with I highly recommend alternating the interviewer/interviewee position and to put yourself in the hot seat. When you encounter a particularly difficult problem and have to resort to looking up the answer I find that it's super helpful to take the time to write it out with a test dataset to see what your algorithm does at each step of the way. That way you get to dive into the problem and understand how it works so that you can remember it and solve it the next time around.
Remember to not be so hard on yourself and remember how far you've come!
Top comments (5)
In this case it would be better served to write tests and validate code is working the way you intended via assertions.
Yes and no.
Writing tests only really check that the entire function is working as intended. They're nice to have since it can show that you know how to test and that your code works.
The problem is:
You need a way of debugging specific lines are wrong so you know what you need to fix -- The simplest (and best) method is
console.logas Sofia suggests.Writing tests will save time in the long run. Writing them before you write the implementation is preferred.
If your code is structured properly (aka small functions/classes responsible for singular things) unit tests will tell you at exactly which point your test is failing.
While I agree in a general sense, this article is about coding during an interview -- there is no "long-run" if you only get an hour to solve the problem. If you're spending a significant amount of time writing tests, you're not spending that time answering the question.
Wonderful so helpful! Thanks