What I learnt from my interviews?

Alrite, well, it had been quite sometime (actually long time ;P 3 years) since I wrote something in my blog, so after a break, here it is. With a total of 13 phone interviews and 30 onsite interviews :P, I think now I gained enough experience, that I can blog about it ;P

So, What did I learn from my interviews?

First thing you need before attending an interview is CONFIDENCE. "You are what you think you are". You have to tell to yourself, that you are really capable of doing the job (whatever it may be -Software Design/Development Engineer / Technology Analyst/Associate) and interview is just a place where you show your capabilities. There is no point in being nervous in an interview which would mean that you yourself is not convinced that you would get this job. Being confident means you think or say to yourself that you know answers to ALL the questions that the interviewer might ask you. Of course, there are sometimes you might not know the answer for a given technical question (say, some feature in Java or C++), in that case, ADMIT that you don't know the answer in a nice way saying that you are always ready to learn, instead of giving some crappy answer.

As I said, first thing we need to crack an interview is confidence, but how do we get it?

Of course, Confidence comes with PREPARATION. Prepare for not only technical questions, but also for behavioral ones. Organize yourself. There is a saying "For every minute spent organizing, one hour is gained". This is the truth. Create a list of topics that you would want to prepare - say, Linked Lists, Binary Trees, Dynamic Programming, Graphs, String manipulation, Data Structures especially HashTables, Java language features, C++ language features, OOPs concepts, Threads, Mutexes, Synchronization, OS concepts and whatever there is in your resume - academic and professional projects. Once the list is created, allocate time for each topic - say Dynamic Programming - 3 hrs, Java Threads - 2 hrs, etc. Create a timetable for next few weeks and target to complete these topics. I would definitely recommend topcoder.com for anyone preparing for coding interviews. Also, visit interview questions websites like careercup.com and glassdoor.com, they really give you an insight on what to expect in a particular company's interview. Allocate time for these websites too in your timetable. Also, practice writing code in white paper or notepad without eclipse or any fancy IDEs. This will help you in Whiteboard problem solving interviews.

Also, learn about algorithm complexities - the notations - O(n), omega(n), etc. Understand what each really means and how to compute them for a given algorithm. Almost in every coding interview they would ask you about the time and space complexity for your solution. When given a problem, never jump in solution and never start writing code! - This is really really important! If you start writing code for a given problem immediately, that would leave a really bad impression on you. Ask as many questions as possible before giving your solution. For e.g., lets say the interviewer asks a question, "given an int array and sum, find 2 elements in array that would add up to the sum" - We can ask questions like, Is the array already sorted? Can it contain -ve elements? Can I use extra space? Generally, we would start with O(n^2) algorithm and end up in O(n) or O(logn) algorithm. The interviewers might ask the pros and cons of each approach too. Important thing I learnt is before answering any question, take a moment to repeat the question to the interviewer, and in that way you would actually get some extra time to think solution for the question while repeating it.

In addition to above optimization questions, there might even be questions like how would you solve a question in most inefficient way possible! :P For e.g., for the well know cycle in a linked list problem, how would you solve it if you don't know the slow-fast-pointer approach?

I understood that interviewers expect us to know both inefficient and efficient solutions for the same problem.

To be continued.....