Comment by Siddarthan Sarumathi Pandian on "What should I do if I am struggling at answering simple Java questions?"

It's really really easy to lose touch with the concepts you mentioned when you are busy with work. If you ask me to write a DFS algorithm right now, I might struggle to get it right in the first go.

There are two things you can do, the first one is a solution to the question asked. The second thing is mostly my rant of how screwed up hiring is in our industry.

Get yourself a copy of a basic programming book which can teach you the core principles - OOP, Multithreading - take a week and get your theory covered. Week 2, start solving the simplest of questions - Reversing a string, bubble sort, merge sort etc. Week 3, move to tougher concepts like multithreading and dynamic programming. Keep doing it for another week and I believe you will have your mojo back. I can suggest a very good C++ book (it does not cover multi threading).
This is my rant part. I do not understand why companies try to find out how you write bubble sort or a DFS algorithm. There are so many smart people out there who have done this and have put the functions in a library for us to use. You can just use them and build whatever you want to build. So, do not sell your 7 years of experience short. Apply to companies that appreciate that and ask you design questions. You'll need to put all your experience to use and build a solution to the problem.

Thanks Spsiddarthan,

I will definitely accept your suggestions. I will pick my favorite java programming book for that purpose.

I do not understand why companies try to find out how you write bubble sort or a DFS algorithm

Sorry, but I don't agree with this sentiment. Knowing an algorithm is not a necessity, but it still is nuts-and-bolts of the system you are running in. If you do not know/understand basics of bubble sort or a simple DFS problem you there is a problem. Note, that I am not saying, you should know the algorithm by heart or anything, just so much as to create a basic understanding of the concept.

The problem is, if you don't, the day a complex issue comes which might be due to inherent implementation of certain algorithm, it will be really hard to figure out a solution. For instance, if a guy uses Solr and doesn't understand basics of IR or a guy using Hadoop doesn't understand all the phases of Map-Reduce or some complex tasks running a wide variety of pattern matching using some library, IMO is not an engineer who I can trust with a critical system.

Ujjwal, I agree with knowing the basics - an absolute necessity, I should have perhaps used a better example in my rant - like that of balancing an AVL tree. Sure, it proves that you're really really good with recursion and very very sound in Graph Theory. However, it does not say anything about how you building a clean architecture. I have seen so many good programmers who have a fantastic understanding of concepts like separations of concerns, but struggle with algorithmic questions posed in white board interviews. I have also seen candidates do extremely well in algorithmic rounds, but struggle in design rounds. It's just that I would any day pick the ones that do well in the design rounds over the ones in algorithmic rounds. Of course, if one can't write the simplest of algorithms, they are obviously not a good-fit. Just my opinion :)

That better example explains the sentiment better! :) If you have an understanding of basics and are good at designing, it is all that is needed. Balancing an AVL tree is something that you don't need everyday, and if needed you can go refer to some document for that.

However, you will also note that *awesome*companies don't in-fact ask balancing AVL tree. They will focus more on problem statement that requires you to think, and often the solution would be one of the simpler ones. Of course, there are exceptions, and it highly depends on the interviewer. A good one will make an interviewee think rather than present a rote answer.

Search Hashnode