Understand and analyse the problem

• Read the problem, start thinking about it and if possible write the things that are given and the things that you need to find out on a piece of paper.

• Ask yourself

• are you able to understand the question fully?

• would you be able to explain the question to a layman?

• what and how many inputs are required?

• what would be the output of those inputs?

• can you seperate out some modules or parts of those inputs?

• do you have enough information? if not, try understanding the question again

Go though the sample inputs and examples thoroughly

• take very simple examples and find the output
• take more complex and bigger inputs to see what will be the output, how many use cases do we want then time to handle edge cases
• try out the problem with no input, what should be the output now
• try out the problem with invalid input, what should be the output now

Break down the problem

• try to make a flow chart or a UML for the problem in hand
• divide the problem into different modules or sub-problems
• try to make independent functions for each sub-problem
• connect those sub-problems by calling them in the required order, or as necessary (Probably one function will be calling another)
• try to use classes and objects while handling questions which try to implement some real-world problem (like management systems)

Start coding

• just keep in mind 3 things, and you'll surely figure out the path

• the point where you started

• where are you right now?

• where is your destination?

• When doing the interview, do not waste time figuring out the whole solution and tell your interviewer, keep simplifying the problem and keep telling your interviewer about how you are approaching the problem

• tell the interviewer how you're trying to start

• tell what method is there in your mind right now

• find out the most difficult part you're facing in that problem

• ignore that 'most difficult' part for some time and start solving a simpler sub-part, that'll buy you more time to think about the former part

• once done with the simple sub-parts, try incorporating a similar approach for the difficult part as well

• you might come up with a better solution while doing the problem, tell that to your interviewer

Look back and learn more

• now this is the most important part!

• once you're done, look back whether the code can be improved, is there any other way to solve the given problem?

• don't give up when you feel content with the possible solution(s) and you've explored the problem completely

• here are some questions you should ask yourself once you are done writing the code

• does this code run for every possible input (including the edge cases)?

• is there any other way to solve the problem?

• is the code efficient? can it be more efficient?

• is the code readable?

• if someone else showed you this code, would you be able to understand it?

• can the performance be improved?

• can some other algorithm be used which provides better results?

Questions for interviewer