Steps to solve software engineering problem

Hello devs and beginners ,

You might have faced challenges while solving any engineering problem or while attending coding interview questions. Like binary search tree problems or system performance improvement problems or improving execution time or designing applications or systems etc. No worry 😔...sit on chair and take a deep breath and just chill 😁. In this article I am going to give some insights and tips to developers and beginners who are preparing for an interview and facing an issue while solving a problem in their programming work or assignment or official work.

Friendly note : I am not an expert in problem solving, but I follow a few steps as per book "Cracking The Coding Interview" and based on my years of experience while solving problems in the real world. Generally approach I used bottom to top or reverse engineering for routine work. When you are given a problem ( or if you are practicing ), work your way by using the approach below.

Let's get started with understanding about steps and different approaches.

Steps to follow :

1. Listen carefully :
   Pay very close attention to all corner information in the problem details. Ask as much as a question of who raises or given a problem to you before proceeding to the next step. Be sure that you have mentally recorded any of unique value information from problem statement. Many people will rush to solving problem once they received information from sources.

   

2. Example:
   Try to find out one best example, one worst example and one special case example to understand problem input and output behaviour. Get out of chair or position and try to visualise problem and example set. Can use drawing on white board or digital board or notebook.

3. Brute Force:  
   What is Brute Force? Given a reference example at the bottom of this article. For now, in layman terms choose the shortest answer to fix the problem before giving the best one. Like example, if the problem is the API rate limit is exhausted due to excessive calls to third party tools. For this first calculate how much rates are required then try to increase the rate limit approaching a third party till you find to reduce excessive usage of APIs. (Not require code though to give shortest answer it can be workaround)

4. Optimize :

   • Try out some ideas like to find unused information or function calls.
   • Solve it manually or by example, then do a bottom to top approach or reverse engineering to get an answer of how you solved it.
   • Make mistakes and ask questions. Why did it fail? Can you fix those?
   • Make time vs space complexity analysis. ( how much time and memory is taken for execution ) or In reference books mentioned about BUD optimisation.
   • Think about best acceptable runtime.

   BUD optimisation ** -
           - Bottleneck - find out where process is becoming a bottleneck where exhaustion can occur and where process can become slow.
           - Unnecessary - find out which calls or processes can be reduced or minimised to avoid excessive things.
           - Duplication - find out duplicate calls or repetitive processes.
   These are three of the most common things that algorithm can waste time doing. Try of find one of them then can focus of getting rid of it. Keep repeating this approach for current problem.

5. Walk through :
   Take a step back and walk through your optimal solution which you did just before. Make sure you understand each detail of approach before writing code. You can think about writing pseudocode if you would like.

6. Implement :
   The Most favourite line from the book is "Your goal is to write beautiful code". Start writing your code and putting down the approach into a line of code, modularise way. Modularise your code since you wrote the first line. Beautiful code means modularised code, Error check, use classes wherever can use, good variable and function name which easily self explanatory. If you found something you can refactor later on, then keep note or comment in code, so that you don't forget those changes. Try to make common function or lines of code whichever you can.

   

7. Test : There are smart and not so smart ways to test your code. Instead test your code in this ways :

   • Conceptualise test. Walk through your code like details code review.
   • Test code the idea is written or problem statement wise.
   • Unusual or non-standard code.
   • Focus on hot spots like numeric or string or null or empty values
   • Test *corner cases *
   • Test smallest and largest test case at end. Smallest case is faster than bigger one and as effective as.
   • Make sure if you find bugs, fix them carefully.

Understanding of word or concept:

• Hot Spots : Base case in recursion, Integer division, Null reference, Start and end of any iteration or loops
• Corner cases : When highest number of input came like bottleneck.
• Pseudo code: is a concept which is generally used in coding or algorithm based problems. It is a way that allow the developer to visualise implementation of an algorithm. In layman , we can say that it is the cooking instruction to make alogrithm.
• Top to bottom : When you know all system design and architecture then you use this approach to solve problem
• Bottom to top : Exactly reverse of "Top to bottom" approach. When you don't know anything about system or application then pick any feature or text from UI and start searching into code using wild card feature. Then go reverse order to understand skeleton of application.
• Best Conceivable Runtime (BCR): BCR is the runtime you know you can’t beat. For example, if asked to compute the intersection of two sets, you know you can’t beat O(|A|+|B|).

Helpful line : You wouldn't check in code in the real world without testing it, and you shouldn't submit code in an interview without testing it. ( Taken as it from book because it's very helpful )

Case study on above steps:

Problem statement : Third party (take an example of Lead management system (ZOHO or Mautic API) integrated with internal software or application. Suddenly API crosses their daily limit or hourly limit and the limit can be enhanced only the next day. How to solve this problem for time and longer run. In this problem you have to think about faster solution in shorter time span so that business value will not impacted much.

Let's understand how to tackle this problem with help of steps which I mentioned above.

1. Listen : In the above problem, ask a question like why? How? What? Question to problem statements and try to get answers for those. Also, if you don't get an answer for those who ask the person who raised or gave the problem statement. (Don't start till didn't get all your questions answered). I would like to share one incident. When interviewers ask to write a full story about how to develop, what is cost, what are things required, how much effort required etc while developing Paytm kind of wallet in era of when Mobile and internet was not there. And without listening or giving more attention to "Era of when mobile and internet was not there" I started writing a two page story. Submitted for review, then the Interviewer asked me after looking at two page story lines have you first checked whether it is feasible or not ? ahh...😳 then I realised I should listen to the problem carefully before jumping to direct implementing or story writing. In my interview problem, the last line was very important but I pay more attention to the first lines of the problem. That what you have record each and every single word of problem statement and record it properly in mind.

2. Example :

   • High volume: Suppose the system started promotion on social media and google ads suddenly started coming in larger volume when entering lead into the system it is entering into the LMS ( Lead Management System like Zoho, Mautic, Salesforce, leadsquared etc) API. Due to a sudden limit for each hour or minute cross and system all lead become dead or pause state.
   • Low volume: Even after ads promotion only a single lead came with the system.
   • Best volume: General day lead count can be 200-300 per day Based on this example, check whether this above example is sufficient to understand cases to handle the system or not.

3. Brute Force: These steps will be applicable in all problems or not; that depends on how critical the problem is and what the complexity of the application is. But as per past experience whenever a situation comes with hook or crook, we get temporary workaround to tackle a situation. Else check out which majority of services are becoming a bottleneck which can pause for a while. Like creation of a user API doesn't take time but updating might take longer than expected. Those services can pause for a while.

4. Optimise: In above example, try to implement the BUD approach. Suppose, for example, the update API is becoming a bottleneck, check with the system, how often update processes work and come out of scheduling cron jobs instead of real time updating. Find out if the system is calling any 2x or 3x times API. Likewise, do some BUD analysis and then see if you can improve those lines or execution. Example, you have chunk of work that's done repeatedly like finding users. Perhaps you can reduce that from lesser complexity. That will speed up overall runtime.

5. Walk through: List of down approaches or find you find in steps 4 and try to compare with the test case and details out approach if you can. Example, if you decided to target an updated user API, then finalize how you are going to do and what is the impact if you move from real time to crack the job ( might every minute or every 5 minutes). This will help you to give impact of changes.

6. Implement : Then start writing a code once you finalise. Follow recommendation given in above theory point 6. Example of good naming variable can be suppose variable role is keep temporary value then name can tmp_store_key or temp_x or temp_y etc.

7. Test : Follow same actions which was mentioned in above theory point 7. Look for weird looking code like example, x = len - 2 or i = 1 or i++. Placement of this simpler line can cause issue. Test your code against single element array value or empty or null value. This will help to understand smallest test case.

I hope you understand the above steps and example case study. This is a very basic level of understanding. In the future I will come up with a set of examples in my next article. If you have any question related to this information, feel free to reach out to me over my twitter handle, I will be happy answer your questions  @aviboy2006

I would to say special thanks to this 👇🏻 book to help me to solve engineering problems. And also inspire me to share my experience.

 

References :

•  CRACKING THE CODING INTERVIEW
• Brute Force Algorithms Explained
• How to write a Pseudo Code?
• BUD reference

Also, have look at my other experience sharing blogs:

• Experience about applying and attending interviews in last six months
• How and from where to start AWS cloud journey ?