Complexities, Coding, and Testing

Complexities

Getting our programs to output correctly isn’t the only thing to an appropriate solution. We also need to think about how fast our solution is and how much space it takes. In the previous lessons, we learned about the big-O notation. If we think our solution isn’t the optimal one, we can always try to come up with a better one.

Most interviewers want you to be able to determine the algorithms’ time and space complexity. Whenever you’re working on a problem, you should consider the level of difficulty involved. An important thing to know is that there are certain trade-offs between the space and time complexity of some algorithms. Taking a little extra space can save us a lot of time and make the algorithm run even quicker.

Coding

We’ve enumerated all of the problem’s constraints at this stage, suggested a few alternatives, weighed the complexities of the different options, and chosen the one for final coding. At this point, we need to ask the interviewer about limitations, idea generation, and complexity.

We’re used to writing code in an integrated development environment (IDE) like Microsoft Visual Studio. Being asked to write code on a whiteboard or blank page can seem very daunting! As a result, we can do some practice coding on a piece of paper. Since there is no back button on the sheet of paper, we should consider that before beginning to write our code. Another technique that can help us is modular coding. To keep the code safe and manageable, we won’t write a lot of functions. If a swap mechanism exists, we’ll use it and inform the interviewer that we’ll write it later.

Testing

We’re not done until the code is written. It’s essential to validate the code using a variety of small test cases. It demonstrates that we are value-checking. It also demonstrates that we care about potential bugs in our program. After we’ve finished coding, we should go over the code line by line for some test cases to ensure that the code functions as intended.

We should test a few test cases to check that our code is working correctly.

• Normal test cases:Normal test cases consist of typical scenarios. The emphasis is on the code’s basic logic. If we’re dealing with linked list problems, this measure can include what happens when a linked list with three or four nodes is given as input. Before declaring the code complete, we should still think about these test cases.

• Edge cases: These test cases are used to check the code’s limits. Edge cases can aid in the robustness of our code. To handle these requirements, we must apply checks to the edge cases. For example, we can generate edge cases with the same linked list algorithm to see how the code reacts when an empty list or only one node is passed.

Note: Always follow these five steps. Never jump to coding before doing constraint analysis, idea generation, and complexity analysis. Lastly, never miss the testing step.

Load testing

Load testing means to test our program with a large volume of data. This helps us to see if our code is sluggish or uses a lot of memory.