Live coding is a part of the interview process. The best way to prepare for live coding is to practice, practice, practice. Today we will see a strategy for solving live coding problems and we will get more practice in class.
Watch a demonstration of the live coding process, focusing on the steps followed. An interviewer is more concerned with your problem-solving process than the correctness of your answer, so following this detailed, logical, step-by-step process is the best way to demonstrate your skills.
Gather Requirements
Break the Problem Down
Pseudocode
Write Syntax
Test
Make Changes
In the video, the interviewer gave us requirements but they were intentionally vague. The first thing the interviewee had to do was to gather additional requirements to have a strong understanding of the problem.
This required communication on the interviewee’s behalf. They went as far as to talk through the given input, and create an output that was verified as correct by the interviewer.
After successfully gathering the requirements, the interviewee broke the problem down into two separate pieces. Identifying what needed to be done first, and what needed to be done next.
Breaking the problem down gives the interviewee the opportunity to focus on one aspect of the problem at a time.
Once the interviewee has a hold on the separate pieces of their intended solution, they can begin working on the logic of the problem.
For the first chunk of their proposed solution, the interviewee wrote “Loop over input, remove vowels”.
For the second portion of their proposed solution, the interviewee wrote “Loop over vowel-less str, remove odd index chars”.
Psuedocoding the problem promotes communication around the proposed solution. It is a way to share thoughts with the interviewer without starting to code.
Now that we have a plan, and a map drawn out in the form of our pseudocode, we can start coding!
You’ll notice the interviewee is talking through their actions as they write code down. This shows the interviewee has the ability to communicate effectively with another developer.
As you write syntax, you may find that you still don’t have all of the requirements. In this video, the interviewee did not know if the letter ‘y’ was considered a vowel. To overcome this confusion, they simply asked the interviewer for more clarity on the requirements!
While writing their code, occasionally the interviewee would realize they didn’t declare a variable before, or forgot to include something above their already written code. That is okay! You want to show the interviewer your problem-solving process. Very rarely will you write something perfect from top to bottom. Don’t hesitate adding new lines above your already written solution if you need to declare more variables!
After the interviewee finishes the first version of their solution, they need to test it! As programmers, we don’t usually get the right answer on the first try. Without our debugger to point us in the correct direction, we are left to walking through a test case ourselves.
You’ll notice the interviewee keeps track of the variables throughout the entire program by writing them on the board and updating them as they step through the program line by line.
At the end of the program, the interviewee can compare their produced answer and compare it to the answer that was agreed upon when they gathered the requirements of this problem.
When testing your solution, you will more than likely find that you made a mistake. It may be a small mistake, or a big mistake. Making a mistake can be a great thing in a live coding session. Take a step back and try to figure out where the mistake is happening. This is usually very apparent in the testing phase if you test line by line.
You want to show the interviewer you have strong problem-solving skills and part of problem-solving is being able to figure out mistakes you have made in your own solution and then fixing them.
If you find a mistake in your solution, great! Fix the mistake, and test your solution again.