How to Approach a Coding Challenge
This chapter covers technical quizzes and coding challenges, which are commonly used in technical interviews.
The coding challenge is the most important part of an interview. This part can consist of a single session or multiple sessions. Some companies prefer to split the technical interview into two parts: the first part consists of a technical quiz, while the second part consists of one or more coding challenges. In this chapter, we’ll tackle these two topics in detail:
- Technical quiz
- Coding challenge
By the end of this chapter, you should be able to sketch a plan of your own to approach the technical interview. You’ll know how to deal with the key moments during the interview, what the interviewer is expecting to see and hear from you, and how to deal with blocking moments when you don’t have a clue about the answer/solution.
Technical quiz
The technical quiz can take on a question-answer format with the technical interviewer, or it can be an on-site quiz. Commonly, it contains 20-40 questions and takes less than an hour.
When the technical interviewer conducts the process, you will have to provide free answers and the duration may vary (for example, between 30-45 minutes). It is important to be crystal clear, concise, and always on topic.
Usually, when a technical interviewer conducts the interview, the questions are formulated as scenarios that require you to make a decision or choice. For example, a question may sound like this: We need a space-efficient algorithm capable of searching millions of records extremely quickly with a decent number of false positives. What do you recommend for us? Most probably, the expected answer is something like, I will consider algorithms from the Bloom filters family. If you came across a similar case in your previous projects, then you may say it like this: We had the same scenario in a project about streaming data, and we decided to go with the Bloom filter algorithm.
Another category of questions is meant to simply check your technical knowledge. These questions are not in the context of a scenario or project; for example, Can you tell me what the life cycle states of a thread in Java are? The expected answer is, At any moment, a Java thread can be in one of the following states: NEW, RUNNABLE, RUNNING, BLOCKED, SLEEP, WAITING/TIMED/WAITING, or TERMINATED.
Typically, answering technical questions is a three-step approach, as shown in the following diagram. First, you should understand the question. If you have any doubts, then ask for clarification. Second, you must know that the interviewer expects you to identify several keywords or key points in your answer. This is like a checklist. This means that you must know about the key things that should be highlighted in the answer. Third, you just need to wrap the keywords/key points in a logical and meaningful answer:
Figure 5.1 – The process of tackling a technical quiz
You will see plenty of examples from Chapter 6, Object-Oriented Programming, onward.
As a rule of thumb, your answers should be technical, articulated in a concise but comprehensive way, and communicated with confidence in yourself. A common mistake of shy people is to provide an answer that sounds like a question. Their tone is like they’re asking for confirmation for every word. When your answer sounds like a question, the interviewer will probably tell you to just give the answer without asking him.
Important note
When you can only partially answer a question, don’t rush to answer or say you don’t know. Try to ask the interviewer for more details and/or a 20-second thinking time period. Sometimes, this will help you provide an incomplete but decent answer. For example, the interviewer may ask you, What is the main difference between checked and unchecked exceptions in Java? If you don’t know the difference, then you can give an answer such as, The checked exceptions are subclasses of Exception, while the unchecked exceptions are subclasses of RuntimeException. You didn’t actually answer the question, but it is better than saying, I don’t know! Alternatively, you could formulate a question such as, Are you referring to the exceptions that we are forced to catch? By doing this, you may get more details from the interviewer. Pay attention and don’t ask it like, Are you referring to the exceptions that we are forced to catch and to the exceptions that we are not forced to catch? You will probably receive a short answer, such as Yes. This doesn’t help you!On the other hand, if you really have no clue about the answer/solution, then it is better to say, I don’t know. This is not necessarily a strike against you, while trying to baffle the interviewer with too much gobbledygook will definitely be against you.
There are companies that prefer an on-site multiple choice quiz. In this case, there is no human assistance, and you’ll have to finish the quiz in a fixed period of time (for example, in 30 minutes). It is important to try to answer as many questions as possible. If you don’t know a question, then move on to the next one. The clock is ticking! At the end (the last 2-3 minutes), you can come back and try to provide an answer to those questions that you passed on.
Nevertheless, there are platforms that don’t allow you to navigate backward and forward between the questions. In such a case, when you don’t know the answer to a question, you are forced to risk it and try to guess an answer. Spending a lot of time answering a single question will result in a poor score at the end. Ideally, you should try to spend the same amount of time on each question. For example, if you have 20 questions to answer in 30 minutes, then you can allocate 30/20 = 1.5 minutes to each question.
One of the best techniques to approaching a technical quiz (no matter what type of quiz) is to perform several mock interviews. Grab a friend and ask him to act as the interviewer. Put the questions in a bowl and ask him to randomly choose them one by one. Answer the questions and act exactly as if you were in front of the real interviewer.
Coding challenge
The coding challenge is the climax of any technical interview. This is the moment where you can show all your coding skills. It’s time to demonstrate that you can do this job. Having working and clean code can help you make a great impression. A great impression may fill in the gaps that you left open during any other stage of the interview.
The coding challenge is a double-edged sword that may radically change the final result of the interview. One edge can cut you off from the scheme, while the other edge can bring you an offer in spite of other shortcomings.
However, the problems specific to these coding challenges are really hard for a variety of reasons. These will be covered in the next section.
The problems specific to coding challenges are meant to be difficult
Have you ever seen a problem specific to the coding challenge stage and found it weird, silly, or maybe pointless and nothing to do with real problems? If so, then you’ve seen an excellent problem specific to the coding challenge stage.
To better understand how to prepare for such problems, it is important to know their characteristics and requirements. So, let’s have a look at them:
- They are not real-world problems: Commonly, real-world problems need a lot of time to be coded, so they are not a good candidate for coding challenges. The interviewer will ask you to solve problems that can be explained and coded in a reasonable amount of time, and such problems are usually not real-world problems.
- They can be quite silly: It is not uncommon to see problems that are quite silly and look like they have been invented just to complicate your life. They don’t seem to be useful for something or serve a goal. This is normal since, most of the time, they are not real-world problems.
- They are fairly complex: Even if they can be solved pretty quickly, they are not easy! Most probably, you’ll be asked to code a method or a class, but this doesn’t mean that it will be easy. Commonly, they require all kinds of tricks, they are brain-teasing, and/or they exploit less well-known features of the programming languages (for example, working with bits).
- The solution is not obvious: Since they are fairly complex, the solutions to these problems are not obvious. Don’t expect to find a solution immediately! Almost nobody does! These questions are specially designed to see how you handle a situation where you cannot immediately see the solution. This is why you may have couple of hours to solve it (most commonly, between 1 and 3 hours).
- Prohibit the common solving paths: Most of the time, such problems have clear clauses that prohibit the usage of common solving paths. For example, you may receive a problem that sounds like this: Write a method that extracts a substring of a string between the given positions without using a built-in method such as String#substring(). There are countless examples like this one. Simply choose one or more built-in Java methods (for example, utility methods) that can be implemented in a relatively short amount of time and formulate it; for example, Write a method that does X without using a built-in solution such as Y. Exploring API source code, participating in open source projects, and practicing such problems is quite useful for solving such problems.
- They are meant to place you in an exclusive range of candidates that receive offers: The difficulty of these coding challenges is calibrated to place you in an exclusive percentage of candidates. Some companies are making offers to less than 5% of candidates. If a certain problem can be easily solved by most candidates, then it will be replaced.
Important note
The problems specific to coding challenges are meant to be difficult and are usually asked in ascending order of difficulty. Most probably, to pass these coding challenges, your experience and coding skills will not be enough. So, don’t get frustrated if, in spite of your knowledge, you cannot see a solution right away. Many such problems are meant to test your ability to find solutions to uncommon scenarios and test your coding skills. They might have ridiculous clauses and/or obscure solutions that exploit uncommon features of a programming language. They might contain silly requirements and/or dummy cases. Focus only on how to solve them and always do it by the rules.
A single coding challenge session is, most of the time, enough for the interviewers. Nevertheless, there are cases where you’ll have to pass two or even three such challenges. The key is to practice as much as possible. The next section shows you how to handle, in general, a coding challenge problem.
Tackling a coding challenge problem
Before we discuss the process of tackling a coding challenge problem, let’s quickly set up a possible environment for a coding challenge. Mainly, there are two coordinates that define this environment: the presence of the interviewer during the coding challenge and the paper-pen versus computer approach.
The interviewer’s presence during the coding challenge
Most commonly, the interviewer is present (by phone screen or in-person) during the coding challenge. They will evaluate your final result (code), but they are not there just for this reason. Measuring just your coding ability doesn’t require their presence and is usually encountered in programming contests. An interview coding challenge is not a programming contest. The interviewer wants to see you during the entire process in order to analyze your behavior and communication skills. They want to see whether you have a plan to solve the problem, whether you act in an organized or chaotic way, whether you write ugly code, whether you are willing to communicate your actions, or whether you are introverted. Moreover, they want to assist and guide you. Of course, you need to strive for no guidance or as little as possible, but a proper reaction to guidance is also appreciated. However, striving for no guidance doesn’t mean that you should not interact with the interviewer.
Keep talking!
Interaction with the interviewer is an important factor. The following list explains several aspects of the interactivity plan:
- Explain your solution before coding: Before you start coding, it is important to squeeze some valuable information from the interviewer. Describe to them how you want to solve the problem, what steps you want to follow, and what you’ll use. For example, you could say, I think that a HashSet is the proper choice here because the order of insertion is not relevant and we don’t need duplicate values. You’ll get a thumbs up or some guidance or advice that will help you obtain the expected results.
- Explain what you are doing while coding: While you’re coding, explain it to the interviewer. For example, you could say, First, I will create an instance of ArrayList, or, Here, I load the file from the local folder into memory.
- Ask the proper questions: As long as you know and respect the limits, you can ask questions that can save you time. For example, it is OK to ask, I can’t remember – what is the default MySQL port, 3308 or 3306? However, don’t exaggerate with these questions!
- Mention the aspects that matter: If you know additional information related to the problem, then share it with the interviewer. This is a good chance to expose your programming knowledge, your thoughts, and your ideas around the problem.
If you encounter a problem that you already know (maybe you’ve solved it while practicing such problems), then don’t blurt 'it' out. This will not impress the interviewer, and you will probably get another coding challenge. It is better to follow the same process that you’d follow for any other problem. Before we cover this process, let’s tackle one more aspect of the interview environment.
Paper-pen versus computer approach
If the coding challenge takes place via a phone screen, then the interviewer will ask you to share your screen and code in your favorite Integrated Development Environment (IDE). This way, the interviewer can see how you take advantage of IDE help as well (for example, they can see if you use the IDE to generate getters and setters or if you write them by hand).
Important note
Avoid running the application after each line of code. Instead, run the application after each logical block of code. Make the corrections and run it again. Take advantage of the IDE debugging tool.
If you meet the interviewer in person, then you could be asked to use paper or a whiteboard for coding. This time, coding can be in Java or even pseudocode. Since your code cannot be compiled and executed, you have to test it manually. It is important to show that your code works by taking an example and passing it through your code.
Important note
Avoid excessive write-delete code cycles in a chaotic approach. Think twice and write once! Otherwise, you will give the interviewer a headache.
Now, let’s take a look at the general steps that are meant to provide a methodological and logical approach to solving a problem.
The process of tackling a coding challenge problem
The process of tackling a coding challenge problem can be done in a suite of steps that should be applied sequentially. The following diagram shows these steps:
Figure 5.2 – The process of tackling a coding challenge problem
Now, let’s detail each of these steps. While applying this problem-solving process, don’t forget the interactivity component.
Understand the problem
It is very important to understand the problem. Don’t start solving the problem based on assumptions or a partial understanding of the problem. Read the problem at least twice! Don’t rely on a single read since, in most cases, these problems contain hidden and obscure requirements or details that are easy to miss.
Don’t hesitate to ask your interviewer questions about the problem. There are cases when details are intentionally forgotten to test your ability to discover the underlying problem.
Important note
Only if you understand the problem will you have a chance of solving it.
Next, it is time to build an example. If you manage to build an example, then this is a clear signal that you have understood the problem.
Build an example
As they say, A picture’s worth a thousand words, but we can say the same thing about an example.
Sketching the problem and building an example will clarify any remaining misunderstandings. It will give you the chance to discover the problem in detail via a methodological approach (step by step). Once you have a working example, you should start seeing the overall solution. This is also useful for testing your final code.
Important note
A sketch and an example are useful for solidifying your understanding of the problem.
Now, it is time to think about the overall solution and decide on the algorithm(s) to use.
Deciding on the algorithm(s) to use and explaining them
At this point, you have understood the problem and even built an example. Now, it is time to shape an overall solution and split it into steps and algorithms.
This is a time-consuming process. At this point, it is important to apply the Communicate What You Think approach. If you don’t say anything, then the interviewer doesn’t know if you are clueless or if you are in a brainstorm. For example, you could say, I think I can use a List for storing the emails, ... hmmm ... no, this is not OK because a List accepts duplicates. While you are talking (even if it looks like you are talking to yourself), the interviewer can judge the correctness of your reasoning, can see your knowledge level, and can provide you with some tips. The interviewer may reply with something like, Yes, that is a good point, but nevertheless, do not forget that you need to maintain the order of insertion.
Most of the time, the problem requires some form of data (strings, numbers, bits, objects, and so on) manipulation, such as sorting, ordering, filtering, reversing, flattening, searching, computing, and so on. Where there is data, there are data structures as well (arrays, lists, sets, maps, trees, and so on). The trick is to find the proper matches between the data manipulations that you need and the data structures. Usually, a proper match means the following:
- You can easily apply certain manipulations to the data structure.
- You can obtain good performance (Big O – see Chapter 7, Big O Analysis of Algorithms).
- You can maintain harmony between the used data structure(s). This means that you don’t need heavy or complex algorithms, nor do you need to perform conversion to move/exploit the data between data structures.
These are the big pieces of the puzzle. Managing to identify the proper matches is half of the job. The other half is to bring these pieces together to shape the solution. In other words, you need to bring logic into the equation.
It is very tempting to start coding immediately after you read the problem or after you’ve understood it and shaped the big picture of the solution in your mind. Don’t do that! Often, this will lead to a chain of failures that will make you lose your temper. Very soon, all your ideas will be surrounded by a dense mist of distrust and you will start to code hastily, even with ridiculous mistakes.
Important note
Take your time and think about the solution deeply before starting to code.
Now, it’s time to start coding your solution and impress the interviewer with your coding skills.
Coding the skeleton
Start coding the solution with a skeleton. More precisely, define your classes, methods, and interfaces without implementation (behavior/actions). You will fill them up with code in the next step. This way, you’re showing the interviewer that your coding stage follows a clear road. Don’t jump into the code too hastily? Moreover, respect the fundamental principles of programming, such as Single responsibility, Open–closed, Liskov substitution, Interface segregation, Dependency inversion (SOLID) and Don’t Repeat Yourself (DRY). Most probably, the interviewer will watch out for these principles.
Important note
Coding the skeleton of your solution helps the interviewer follow you easily and better understand your reasoning.
At this point, you have the attention of the interviewer. Now, it’s time to bring your skeleton to life.
Coding the solution
Now, it’s time to code the solution. While you’re doing so, explain the main code lines that you write to the interviewer. Pay attention and respect the well-known Java coding style (for example, follow the Google Java Style Guide at google.github.io/styleguide/javaguide.html).
Important note
Following a well-known Java coding style and communicating your actions to the interviewer will be a big plus for the final result.
Once you’ve done the core implementation of your solution, it is time to increase the robustness of your code. So, as a final touch, don’t ignore exceptions handling and validations (for example, validating the arguments of methods). Also, ensure that you’ve covered all the requirements of the problem and that you’ve employed the right data types. Finally, it is time to keep your fingers crossed that your code will pass the testing step.
Testing the solution is the final step of this process.
Testing the solution
In the second step of this process, you built an example. Now, it is time to show the interviewer that your code works by passing the example through it. It is very important to demonstrate that your code works at least for this example. It may go to the first key or run successfully after you’ve repaired some minor bugs, but in the end, it is just important that it works.
Don’t relax! You have won the current battle, but not the war! Often, the interviewer will want to see your code working for corner cases or special cases as well. Usually, such special cases involve dummy values, boundaries values, improper inputs, actions that force exceptions, and so on. If your code is not robust and it fails these attempts, then the interviewer will think that this is exactly how you’ll code the production applications as well. On the other hand, if your code works, then the interviewer will be totally impressed.
Important note
Code that works should put a smile on your interviewer’s face. At the very least, you will feel that they are a little bit more friendly toward you and relaxed.
If you made a good impression, then the interviewer may want to ask you some extra questions. You should expect to be asked about the code’s performance and alternative solutions. Of course, you can provide such information without being asked. The interviewer will be pleased to see that you can tackle a problem in multiple ways and that you understand the pros and cons of each solution and decision.
Getting stuck makes you freeze
First of all, it is normal to get stuck. Don’t panic! Don’t get frustrated! Don’t quit!
If you get stuck, then others taking the interview will probably get stuck as well. The main problem is how to handle such a blockage, not the blockage itself. You have to stay calm and try to do the following:
- Get back to your example: Sometimes, it is helpful to detail your example, or to take a look at one more example. Having two examples can help you shape the general case in your mind and understand the pillars of the problem.
- Isolate the problem in the example: Every example has a suite of steps. Identify the step where you got stuck and focus on it as a separate problem. Sometimes, pulling out the issue from its context allows you to understand it better and solve it.
- Try a different approach: Sometimes, the solution is to tackle the issue from different angles. A different perspective can give you a new view. Maybe another data structure, a hidden feature of Java, a brute-force approach, and so on can help. An ugly solution is better than no solution!
- Mock or postpone the issue: Struggling for a long time to solve a step may lead to the unpleasant situation of you not being able to finish the problem on time. Sometimes, it is better to mock or postpone the step that causes you trouble and continue with the other steps. It is possible that, in the end, when you come back to this step, you will have a much clearer picture of it and will know how to code it.
- Ask for guidance: This should be your last resort, but in a crisis, you must apply desperate solutions. You can ask something such as, I am confused about this aspect because… (and explain; try to justify your confusion). Can you please give me a tip about what I am missing here?
The interviewer is aware of the difficulty of the step(s), so they will not be surprised that you got stuck. They will appreciate your perseverance, analytical capabilities, and calmness in trying to find a solution, even if you don’t find it. The interviewer knows that you’ll encounter similar situations in your daily job and that the most important thing in such scenarios is to stay calm and search for solutions.
Summary
In this chapter, we talked about the process of tackling a coding challenge problem. Besides the steps we enumerated earlier – understand the problem, build an example, decide and explain the algorithm(s), code the skeleton, and code and test the solution – there is one more step that will become the objective of the chapters that follow: practice a lot of problems! In the next chapter, we will start with the fundamental concepts of programming.