Message on Whatsapp 8879355057 for DSA(OA + Interview) + Fullstack Dev Training + 1-1 Personalized Mentoring to get 10+LPA Job
0 like 0 dislike
in Algorithms and Problems by | 1,793 views

3 Answers

1 like 0 dislike
Best answer

Here is my personal Experience (1year starting from scratch) . 
Brief about ratio : 
theory : practice == 1:9
coding : debugging == 4 : 9

After solving, debug other's code, some short ones, recursive(if), debugging is the only way to learn tricks. the theory comes in handy with name algos and direct application, like finding articulation points, spanning tree, Djikstra to name some.

But recursion, backtracking, and Dynamic Programming don't have theories as such. you will get to know about solving DP, once you get strong with recursion and know some past similar problems(past problems, YEP that's the reason why practice is important, no of problems you have solved is going to help in finding out similarities with the new question).

Personally, my weird logic is, I am not gonna think - "ki mere buss ki Nahi hai" until I have solved 2k+ problems. Till now I have solved almost 500+ questions and yes, debugging helps a lot. a hell lot !!.

Platform - start with leetcode(500+ problems to say the minimum) then with Codeforces, as leetcode is gonna make you strong with algos and codeforces is gonna help with tricks

selected by anonymous
0 like 0 dislike
Have a look at :

Solving algorithms is one of the most common and often difficult phase of technical interviews.

Most of the candidates are unable to get past this successfully.

Here are the three steps you need

1- Understand And Repeat The Question

The first thing you need to do is to pay close attention to the question.

Ask the interviewers if something is not clear. Once you are comfortable with your understanding next thing you have to do is to repeat the question loud and clearly.

This will ensure to the interviewer that you have understood their question.

2- Explain Your Approach To Solve The Questions

The No. 1 mistake 95% of candidates make is that they immediately jump to solve the solution on the whiteboard.

This is the wrong approach. The correct way to do is by explaining them in what possible ways the problem can be solved.

Why and by which approach you will solve the problem. If there is something wrong with your approach then interviewer's will provide you feedback about it or clarify the questions again.

3. Design A Pseudo Code

Until now you have the solution in hand, but still you should resist the urge to directly solve the problem. Instead you must design the pseudo code for your solution.

Understand that most of the problems will be algorithmic in nature, and the best way to solve them is by designing an overall outline using pseudo code.

Again by doing this you will get immediate feedback for your solution and if there is some gaps, you can adjust them even before you jump into the full implementation.

4- Write The Full Implementation

You have already explained the solution, Great.

You have shown your pseudo code to the interviewer, Fantastic. And finally now is the time to go with the full implementation on the whiteboard.

Much of the anxiety is already taken away from you, since in your mind you have the solution and a skeleton to follow.

Now your 100% focus should be on the optimal implementation.
0 like 0 dislike
My advice would be to focus on understanding the ideas very deeply. A lot of people focus too heavily on the mechanical details of an algorithm without sufficiently understanding the thought process behind it. Challenge yourself to think deeply and really understand why an algorithm is designed the way it is, whether it can be generalized to solve related problems, and what its limitations, edge cases, and degenerate cases are. In my experience, people usually learn two things when it comes to a particular technique:

1. The mechanical details. For example, how to compute an integral, or the steps needed to insert a value into a max-heap.
2. The way to apply a technique to real-world situations. For example, how to use integrals as a useful tool for performing calculations, or how to use heaps to solve problems where having a priority queue is useful.

Once people have learned those two things, they often think they know everything there is to know about the concept. "I know what a heap is, how to code one, and how to apply one to solve problems. What else could there be to know?"

Try to go beyond that and look for a third level of understanding. Ask "how did someone think of this idea?". Find a plausible sequence of thoughts in your mind that leads to you rediscovering the idea. It doesn't have to be historically accurate; that is, it doesn't have to be the same thought process that led the inventor of the algorithm to originally discover the idea. You have the advantage of hindsight to guide you. Find a sequence of thoughts that makes sense for you, and make the discovery yours.

For example, let's say you're looking to understand self-balancing search trees. Think about the problem at hand: to build a dynamic collection that supports fast insert, remove, and search operations. Suppose you've already invented the concept of a linked list. You might get the idea that, to enable faster operations, you can maintain more than the tail and head pointers into the linked list -- you could maintain K pointers that are spread evenly throughout the linked list.  If you tune K to be sqrt(n) , you can achieve O(sqrt(n)) insert , delete, and find. This is still a pretty flat structure though, and you get the idea to do this hierarchically. You find that when doing inserts or deletes, it's difficult to maintain the exact same number of children for each parent and still get a good runtime, so you allow that number to vary between, say, 2 and 4. Congratulations, you've invented something similar to 2-3-4 trees.

When you "adopt" an idea like that, taking ownership of it into your own mind, you gain the power to modify it at will to suit your needs. The path that led you to an idea can often be continued, or backtracked upon and forked in another direction, to find a related idea for solving a related problem. You see all at once the current idea's strengths and weaknesses, where it can be generalized, where it cannot succeed, why it is done the way it's done and not some other way, what alternative ways it could have been done -- and all that can inform the search.

Perhaps more importantly, as you practice the thought process of invention, you train your mind to be better at inventing.