Chapter Six The Interview: Fill & Download for Free

Some answers here are already really good, but I think it could be valuable to have the perspective from someone who trained for these interviews very recently and got a job offer as a direct result. So I'm gonna one-up your question and tell you how you can get a job at Google and Facebook in 1 month (1 month's prep, that is.) By the way, brevity isn't my strong suit, so this post might take you a while to get through, but I promise it's worth it, and I'll do my best to answer questions you post in the comments about specifics, because I'm almost definitely going to forget to mention some important things (I prepped for the interviews some 5 months ago so this is based on my memory only.)I'm going to detail how I prepared for technical interviews in ~1 month, after which I got a job at Facebook. The process of getting an interview all the way up to getting an offer will probably take 1-2 months extra after that. For my own experience during the actual interview process, see Jimmy Saade's answer to What is the software engineering interview process like at Facebook London? Note that this is for the general Software Engineering position (in my case, new grad), and nothing specific like Android/iOS developer, or Infrastructure Engineer, or so on.The cool and not-so-convenient thing about tech interviews is that you really never know what you're going to get, so you have to be prepared for a huge range of possible topics, some of which are more likely to occur than others. I'll touch on these below and then outline some very important question-types that may arise and that you should be prepared to deal with.So let's say your interview is in one month. Here's how I would plan said month (assuming a full-time schedule). Note that this is what I would do (and did, actually), so it might not be the optimum approach for you, but I suggest working similarly and switching it up a bit based on how you feel you'd grasp concepts better (e.g. solve and code in parallel, as opposed to what I did which is solve everything then code everything...)Days -∞ to 0 - PrerequisitesI assume that you have taken an algorithms course and know your way around major data structures including but not limited to: binary trees, binary search trees, hash tables, heaps, stacks, queues, graphs, lists, tries... as well as all algorithms related to them (insert, delete, search, find, find max, find min...) and the time complexity for each of these, at least at a high level. For graphs you need to know searches (BFS and its properties, DFS and its properties including cycle detection and the like) and shortest path algorithms (Dijkstra, Bellman-Ford, and A*) at a bare minimum. If you don't know all these, along with Dynamic Programming, you're going to need longer than a month. Pick up Introduction to Algorithms (CLRS) and start studying them first. (Update: I posted an answer here: Jimmy Saade's answer to What should I know from CLRS 3rd edition book if my aim is to get into Google? in regards to which parts of CLRS are relevant for technical interviews.) This is the easy part, as it's all academic and it's just expected that you know all of it. The part that follows below (Day 1 onwards) is the actually valuable part that I can offer you.I also assume that you know a programming language like C++ (or Java) and the built-in functions which actually make it useful (i.e. STL or its Java equivalents). (Update 2: I posted info relevant to this here: Jimmy Saade's answer to What are the most important concepts in C and C++ that should be learnt and understood before a programming interview?). If you don't know STL, spend time learning vectors, maps, sets, unordered maps, unordered sets, queues, stacks, and the entire "algorithm" library (seriously, all of it). These are essentially implementations of what you just learned in CLRS, so that if you need to use a heap you won't actually start to code one during an interview (just use a map or priority queue). You also need to know how to implement a linked list, BST, and a trie in 5 minutes flat, which is a lot easier than it sounds (just build a Node class and an insert function and for interview purposes, you're good.)I do not assume that you know anything about the following topics: parallel programming, computer networks (HTTP/TCP/IP/Ethernet), operating systems/scheduling, threads/processes/parallelism/concurrency, assembly, hardware and hardware-descriptive languages, or whatever else. While these are all valuable concepts to know as a computer scientist (as are machine learning and AI and others), the chances that they come up are close to none unless you state them as skills on your resume, so your time is better spent elsewhere (i.e. working on the topics below). You do need to have some awareness of distributed computing, though, so scroll down to the System Design section for that and make sure you read the MapReduce paper at the very least.Day 1 - The BookBuy this book: Elements of Programming Interviews. Phew. That was hard.In all seriousness, this is the best book on the subject in my opinion, and I'm actually really surprised so little people know about it or use it. (I have no affiliation with this book.) The collection of questions is excellent and to-the-point, it is large (300+ problems, which is the most I've seen in one book), they focus on the right concepts (e.g. several problems are on binary search, which is extremely likely to come up in an interview - more so than any other algorithm), and their answers (and the code provided) are almost all correct and excellent. I say "almost" because there are 1 or 2 problems which have much simpler solutions than the book details, but it's not an issue, especially when you compare it with other programming interview books, which have several answers which are downright incorrect. Plus the online support community is pretty good, with Java code available for all problems (the book has them in C++ only) and an online forum for discussions over at Home - Elements of Programming Interviews. They also forgo all the 'teaching' stuff that other books have where they try to teach you big-O notation and data structures, and focus almost completely on the problems part, which is much, much, much, much more important. The big-O notation and data structures you should learn from CLRS, which is the best resource for them, period. No other book, especially not programming interview books, come close to its quality in teaching that stuff.I also know (through various sources) that several of these problems are actually asked as-is (or in a disguised form) during interviews, which shows how on-point it is. (I imagine a reason for that may actually be its low popularity compared to other interview books, as companies ban questions that are 'out there' from being asked in interviews, which is why you probably won't see questions from Cracking the Coding Interview.) If this happens to you, however, I suggest you tell your interviewer, as it's very easy for them to tell if you know the problem before or not, and if you just recite the answer it defeats the purpose of the interview. Luckily for me, I wasn't asked any of the problems I'd done from the book.Days 2-14 - Algorithms StageGo through the book chapter by chapter, one chapter per day[1], starting at Chapter 5, ending at Chapter 19. Do every single problem. All of them. (To be completely honest, I might've skipped a few, but this was more by accident than anything else, and I definitely did like 98%+ of them.) Don't code, solve the problems only (i.e. find the algorithm). Give yourself a deadline per problem, depending on how hard the problem is (for example, 10 minutes for non-ninja[2] problems, 20 minutes for gray-ninja problems, 30-40 minutes for black-ninja problems) - if you haven't found the solution by then, look at the answer and understand it. If you don't you won't improve. It's important to think of the problems on your own, because it's the way of thinking that matters, as you can't go and recite the book on interview day. If you found a solution, make sure it's correct, and that you have thought of all corner cases.Note 1: The new version of the book (which I linked to) has all the ninja problems in a separate chapter (Ch. 22). This, in my opinion, is a terrible idea. The book I had had the problems which are currently in Ch. 22 spread across the book, each in its relevant chapter. I suggest you go through the relevant ninja problems of each chapter while doing said chapter. For example, on Day 2, do Chapter 5, and the Chapter 5-related problems in Chapter 22. On Day 3, do Chapter 6, and the Chapter 6-related problems in Chapter 22, and so on. I believe the problems in Ch. 22 are ordered accordingly (the ninja problems of Ch. 5 come first, then those of Ch. 6, and so on), so this shouldn't be too hard, but I'm not 100% sure as I have the older copy of the book.Note 2: I sometimes spent hours on a single problem, just because I thought the problem was really interesting and I insisted on cracking it myself. I find these random endeavors useful in the long run, as it develops your critical thinking a lot more than the easier problems, but it also takes time, so you likely can't do this for every problem, if you even want to do it at all.Days 14-24 - Coding StageRepeat the book, this time with coding. You already know the answers, so you should be able to remember the algorithm for each problem pretty quickly (if you don't, look it up. It happens, and it can happen sometimes even if you'd previously figured the problem out by yourself.) This is the coding stage, so don't waste time re-deriving algorithms.I do not suggest you code all problems, especially if you're experienced with ACM-ICPC, TopCoder, or Codeforces and the like (and really, if you're familiar enough with STL, you probably have a decent skill set). Only write the code for problems you feel have complex algorithms, a new data structure you haven't used before (e.g. unordered map for hashing maybe), problems with tricky corner cases (binary search is at the top of this list as its variants are asked often and can be much trickier than you think) or a programming concept you're not comfortable with (these include, but are not limited to, operator overloading, custom comparators, custom hash functions, custom == functions, and much more...) If a problem proves tricky for you, or you implemented it in a way which you feel isn't optimal, look at the solutions the book provides, which are excellent and clean, and will teach you all of the above-mentioned concepts. I suggest you mimic their style of writing code a bit. Some important-if-obvious notes are: use descriptive variable names (none of that 1-letter-variable-name crap) and indent properly, and don't forget to close parentheses and brackets.I also suggest you code all problems from the Greedy Algorithms chapter and almost all ninja-marked problems. The Dynamic Programming chapter is also important if you're not familiar with DP, and can be tough to grasp, so make sure you give it its time.Day 25 - Onto more questionsSo now that you've exhausted the best question reserve and are comfortable enough to step into an interview, you... need to prep even more. Go to Google Interview Questions (Career Cup). This is a dangerous place. Some very good problems exist, but there's also a class of problems that my ACM trainer likes to call "Chuck Norris problems": Problems written where the OP has no idea what's going on and suggests the interviewer required linear time for problems that clearly cannot be done in linear time (like this, which is clearly not linear time: http://www.careercup.com/question?id=14951746), or similar.Now that you've finished Elements of Programming Interviews, you should be easily be able to differentiate between good problems and terrible problems. On Day 25, go through "all" (the last 20 pages or so) the Google Questions (even if you're preparing for Facebook) and make a list of the ones you deem 'good', and by 'good' I mean problems you feel might have actually been asked in a Google interview. You know the question style from the book, so you should be able to tell which are legit and which are questionable. I assume you should have a list of something like 80-120 questions in the end, some simple, some not so much.Also note that very few problems actually have correct answers posted on the site, so mainly you'll have to rely on your know-how to figure them out and make sure they're correct, but given your previous prep you won't find it too difficult to know when you should be sure of your answer and when you shouldn't. This is actually valuable prep for the actual interview, which is a similar experience.Days 26-30 - Solving Career Cup QuestionsSolve all the problems you jotted down on Day 25. Find the algorithm. If you feel it's too difficult, seek help. If you feel it's impossible or the best solution is exponential time, it really might be that the OP was mistaken. Shake it off, move on to another problem. If you still feel like it, code some of the more challenging problems.Several of the Career Cup questions are similar to ones in the book, so you shouldn't have too much trouble with most problems.Day 30.5 - Skip Lists (Google-only)I've heard that Google has recently gotten into the habit of asking about Skip Lists (not sure why). Watch this video:and understand it and know the analysis of the expected run times. After that, implement and test your very own Skip List. I did this just to practice and because Skip Lists are interesting anyway.To be honest, Google can be pretty unpredictable with their questions sometimes, in my experience. They might ask general questions about object-oriented programming or computer networking, Linux commands like grep, theoretical things like the proof of the sorting lower bound, coding questions that rely on some math concept you may have forgotten to be solved, or in-depth programming language questions (e.g. functors/operator overloading in C++). I guess it depends on your resume and what you claim to be proficient in, so my advice is not to put anything on there that you’re not at least somewhat proficient in. It helps to have a degree in Computer Science or Electrical and Computer Engineering, really, just based on the huge variety in the possible questions. I suggest a read-through of Get that job at Google (Steve Yegge) and Five Essential Phone Screen Questions (Steve Yegge). You should probably know most of the topics covered here (I wouldn’t put my money on things like threads/processes/parallelism coming up unless you explicitly state it on your resume, though.) Most of the coding questions in the second link are too easy to come up in an interview, I think, so don’t get too excited by them, and I’d skip the “Special Fast Track Version” section. It’s humorous but I thought it’s way too cynical and off-point. Your choice of text editor, knowledge of OS, or knowledge of one vs. multiple languages will not, in and of themselves, make you fail an interview.On a small note, though I believe Google may ask a lot of non-algorithmic questions as above, the bulk of the interview will still be data structures/algorithms/coding, so all the other things mentioned in Yegge’s blog you should know, but they’re not the main focus.Day 31 - The Non-Technical StuffOkay, so I'm cheating a bit by adding Day 31, but you should also take a day or so to prepare for the non-technical part of the interviews, especially if you're interviewing at Facebook, where there's a non-technical interview. First, prepare questions you want to ask your interviewers about Facebook and about their job and what they do all day. See my Facebook London post for more examples on this. Second, think over your experiences in college/work/whatever - projects you've worked on, teams you've worked with or managed, conflicts you've addressed, hard bugs you've had to deal with, etc. Google-search "behavioral questions" and you'll find thousands of possible questions.Prepare a non-generic answer for "Why Facebook" (hint: the fast pace and culture, the great talent in the company, the mission to connect the world...) and "Why Google" (hint: the diversity of the endeavors, the awesomeness of search and Android, the mission to do awesome things, the company culture...). I wasn't asked these questions in either company (to my disappointment since I was really passionate about both and couldn't wait to show it), but I squeezed in my interest while asking my questions to the interviewer, so use that opportunity if you really want to impart something that you didn't get the chance to.Tips for the InterviewsNumbers 3,4,7,8,9 are the most important points.You might be nervous before an interview, but it'll pass. I was nervous before every single interview. Once the interviewer stepped in and we started talking, I generally had a blast because I really loved talking with them and solving these kinds of problems. Try your best not to be too nervous: do mock interviews and the like. I also recommend scheduling interviews in an increasing-priority order, so that you get used to it and find out your shortcomings by the time you reach your most-wanted company.Practice coding without a compiler/on a whiteboard/paper. I did neither, but I have the C++ syntax memorized and I'm used to coding on a paper in ACM competitions, so you might not need to do this if you're already comfortable enough with your favorite language (you only need to know one language well, by the way, as long as it's reasonably well-known, like C++/Java/Python. They let you use whatever language you like during the interview.)Corner cases can kill you. You really have to practice on finding and dealing with corner cases, and/or recognizing what I call "corner-case-prone problems". Some problems are dead simple algorithmically but can be very tricky to code, and I got 2 of these problems, once in my Google phone interviews, and once in my Facebook phone interviews.After finding the algorithm, stop, pause, and think about how to code it, before you actually do. This is especially true for the harder problems, and I would've failed one of my interviews had I not done this, and as a result, would never have gotten a job at FB. I also might've passed an interview at Google which I failed, if I'd taken my advice in this step at the time.Think out loud about algorithms/ideas as you come up with them. It's fine to pause and think quietly for a bit, but don't stand there for 3 minutes without a word. Always at least give the simple solution, which very well might not have a great run-time, but it won't hurt. I did it in all my interviews no matter how simple the answer was, but I said them directly and noted that there's probably a better solution, then proceeded to think of that. (e.g: Okay, to search a sorted array, we can scan it linearly, but this is an O(n) solution and there's likely something faster). Also, don't be cocky about it (question yourself out loud until you're sure of your method and have a rough proof that your method works). Don't argue with your interviewer. 99.99% of the time, they're right, and you're wrong. One possible exception to this is if they’re challenging your code: they’re either really pointing out a bug to you, or trying to make it seem that way to see how confident you are in your code and if you’ll agree blindly or protest that your code is actually correct (if this happens, don’t panic, just think well about your answer before you give it.)Don't talk through your code line by line as you write it. Interviewers know how to read your code and what if-statements and for-loops are. Only speak about the general structure of the code (which you should've mentioned before anyway, as per Tip #4) while coding. Do, however, mention what you're doing in intricate lines of code (for example, if you want to test if 'x' is a power of 2 via "if(x & (x-1))==0", you might want to mention that.)Questions are so often underspecified, and this is a huge weakness of Elements of Programming Interviews: all problems are specified completely, so you have next to no training on this. Always think of questions you might ask or conditions that might make your algorithm fail if not true. Some examples are: Are all numbers positive? Are they distinct? What is the type of the input (integer/double...)? Can you revisit a grid cell? The book has questions where these properties are specified explicitly in the question: think about what would happen if these conditions weren't there: the solution often breaks down.Don't give up if you don't think of the answer directly. In my last Facebook interview, I got the most challenging problem yet, and it took me about 5 minutes to get to the answer, and I ended up hired. That was actually possibly *the* interview that got me hired, and it was also the one I most enjoyed.Two really important concepts to know well are binary search (and its variants) and searching the state-space using Breadth-First-Search to find some shortest sequence of 'moves' (like this problem: ACM-ICPC Live Archive - Kermit the Frog). Both come up very often.Luck matters. The interview process isn't perfect, and you might not pass it even if you're really good, as it depends on your interviewers and what questions you get (and what type of questions you're strong in, etc.) You can mitigate this factor a lot by prepping a huge amount, but it's always there, and it's important to know. I suggest you read Get that job at Google (Steve Yegge's blog) if you want some more detail about this factor.Ignore Ch. 20 and 21 in the book. They're not great. (Maybe read through Ch. 21 a bit to get an idea but that's it.) Scroll down to the System Design section if you also have to prepare for a system design interview.Undersell yourself on your CV (or at least, don't oversell yourself), especially if applying through a referral. If you write 'expert in C++', they're going to call up their senior-most C++ engineer to get you to crash and burn. I've never met anyone who got anything related to multithreading and parallelism in an interview for SWE, except one person who listed it as a skill. And lo and behold, he was asked about it, and it didn’t go so well.Oftentimes, you'll get a problem which is a variant of a problem you've seen before in the book or on Career Cup, or is the same problem but in a "disguised form" (i.e. it's worded differently but it has the same or a mostly similar solution.) Be careful about these subtle differences; you might figure out (or think that you've figured out) the solution for the problem because you found it very similar to one you've seen before, but a small difference in the problem statement actually means its solution is really really different. As an example, check out question 17.5 - Search for a sequence in a 2D array - in Elements of Programming Interviews. It includes the statement "It is acceptable to visit an entry in A more than once." With it, the solution is DP. If that statement is not included (i.e. it's not acceptable to visit an entry more than once), the solution is branch-and-bound, and there's no DP involved at all. If you wrongly answer DP instead of branch-and-bound or vice versa, the interviewer will know you've seen the other problem before and think you've just memorized the solution, so that's probably enough by itself to give you a "no-hire" recommendation from that interviewer. (I'd also venture a guess that that statement wouldn't be stated by the interviewer at all first, exactly for this reason, and you'd have to ask whether or not you can visit an entry more than once, as per tip #7. The goal is to see whether or not you'll figure out that there's a huge difference in solutions depending on the interviewer's answer to this question.)Again, I probably forgot a whole lot of stuff, so if there's anything specific you want to know, leave a comment. I'll also do my best to keep this post updated with whatever other important things I remember later.System DesignEven though I didn't have one myself, I did prepare for the System Design interviews. I prepared by visiting this site: Hired In Tech, which is decent (not great) and by reading several papers on this site, straight from Google: Distributed Systems and Parallel Computing, mainly the first MapReduce paper (near the very end of the page) and the Chubby paper. MapReduce is very important and I really suggest you read it and understand how it works. After those steps, look up databases, specifically SQL and NoSQL, get acquainted with the CAP theorem, scalability topics, and maybe read up on Hadoop and some problems you can solve with it (Hadoop In Practice is a decent book for these purposes). Try some questions like the "Design a URL shortener" question on Hired In Tech, or something larger scale like "Design a web search engine" or "Design Google Maps", all questions which may be asked (also check Ch. 21 of the book for possible questions and a small idea of how to answer them - though the book's answers aren't great.) But in general, for the system design interview, practicing on questions is less meaningful than fundamentally understanding the above concepts and knowing how to discuss them, as the entire interview is something like a quick conversation between you and the interviewer, where he/she will change the question specifications on the fly to see how you deal with different scenarios.Final AdviceSo, if you really want that job, it’s going to take some time and dedication, but hopefully it’s the enjoyable kind. I personally really enjoyed preparing these kinds of questions and found that, job aside, I really learned a lot and got a good deal of knowledge out of the preparation, and you probably will too.My final piece of advice is to just go into the interview and not be stressed out (this is obviously easier said than done). The engineers want you to be good and they want to hire you – hiring is a pretty expensive process. Some may be easygoing, and some may be less forgiving, but in all cases, the interview is very similar to a conversation between two engineers, and that’s exactly what these companies strive for the interview to be, so just treat it that way, and if you’ve prepared well, it’ll show.[1] - One chapter per day is actually a bit slow since you're not coding, so for shorter chapters such as Chapters 5, 7, 8, 9, I suggest you do 2 per day, which is feasible.[2] - In Elements of Programming Interviews, non-ninja problems are standard problems, gray-ninja problems are somewhat difficult, and black-ninja problems are difficult.Disclaimer: This is my own opinion/advice, and is not endorsed by anyone else in any way.

Rarely do we come across candidates who have been selected in the country’s best PGP course after eight years of work experience. Which is what makes Amit Singh’s story fascinating!Back in 2002, Singh cracked MBA at FMS Delhi and a few IITs. But due to personal tragedies, he decided not to join any programme. He went on to work with two major Public Sector Undertaking (PSU) companies of the country for the next eight years. Meanwhile, he also got married and had a daughter.Here is Singh narrating his entire story – why he opted for PGP and not PGPX, how the MBA interview panels grilled him for higher work-ex and problems faced during placements (due to his high work-experience); and the ultimate lesson he learned during this entire journey.Chapter 1: Family, work & first MBA attemptAmit SinghI was born and bought up in a middle-class North Indian household. My family has always valued the importance of formal education and supported all my educational endeavours. After completing school education from CMS Gomti Nagar, Lucknow, and I pursued BTech in Electronics and Communication Engineering from IIT Roorkee (batch 1998-2002). In final year, I was placed with Sapient, which offered the highest package in our college back then. I was happy with where my life was heading.And then the financial crisis of 2002 struck. Sapient delayed my joining and changed the terms of my package.I was disappointed, so was my family. I went ahead and joined Sapient. After a few months, I got call from the Defence Research and Development Organisation (DRDO). Due to uncertainty in the economic scenario, I joined the DRDO. It was a safe government job.In retrospective, I feel it was the first among many mistakes of my career. After working in DRDO for two years, I realised R&D was not my cup of tea.So I started preparing for MBA exams. I cleared CAT, FMS (it was a separate exam) and JMET in 2007. I got calls from IIM Bangalore, FMS Delhi and all the IITs and finally converted FMS and all the IITs.I was about to join FMS Delhi in July when an unforeseen tragedy struck us. My mother fell sick due to food poisoning (in April 2008) and within 15 days she passed away. My family was devastated. I was in no position to join a B-School. During this period, I also broke-up with my girlfriend.The next six months were like hell. I started suffering from depression and quit my job. I wanted to be near my family and support them (I was posted in DRDO Bangalore).Chapter 2: Marriage & PowergridIn 2008, I appeared for Powergrid exam and got through. I was posted in Kolkata and stayed there till 2013.Meanwhile, I also got married. Marriage was essential to bring some sanity in our lives. My issues related to depression got better post marriage but the aftereffects (joint and muscular pain, loss of energy) still lingered on. I went on medication and took up Yoga, Swimming and Reiki.In 2010, I was blessed with a baby girl. Life changed once again and this time for better. By 2012, I completely recovered from depression.But the stagnant work culture at Powergrid made me think about MBA once again.Chapter 3: CAT 2013 & IIM AhmedabadI started preparing for CAT in 2012.Though I was not in preparation mode from 2008 to 2012, I kept reading books on different subjects. This helped me get get started easily.At this point, I was confused between a one-year MBA executive course or a two-year full-time MBA. Since I had eight-years of work-experience, I started exploring the one-year course.I got in touch with my friends from IIT-R who were now IIM alumni. After much diligence, discussion and deliberation, I concluded that PGP or two-year MBA course is better than a one-year executive programme.The reasons for this are:PGP is flagship program of IIMs, valued much higher than PGPX by the industry.Indian industry is not yet mature for one year program. One-year program is normally through GMAT which is perceived easier than CAT.PGP is equivalent to MBA. But PGPX is not equal to MBA. So if anyone plans to do PhD or want to join government leadership positions in future, PGPX or one-year programmes may prove to be a hindrance.The whole experience of a two-year programme is totally different from one-year programme. Three months into the PGPX programme, placement process begins which can ruin the whole MBA experience.Students from one-year programme find it difficult to change career track as recruiters value their previous work-experience.One-year programme is costlier by around Rs 10 lacs.Though the opportunity cost of one-year MBA may seems lower, in the long run two-year PGP/MBA pays off better in the Indian industry.Amit Singh with his wife and daughter at IIM-A graduation ceremonyChapter 4: IIM InterviewsAt IIM Lucknow, the interview panel was unhappy with my profile. They said I am ruining my life by trying to get into PGP. They went to the extent of saying that candidates like me make the PGP placement process difficult.IIM Kozhikode was no better. They grilled me and kept repeating the same thing. “You are trying to pursue PGP because you have nothing else to do. You are fed of the PSU life,” said one panellist.Both the interviews left me sour.Then came the IIM Ahmedabad interview. It was such a refreshing change. The panellists enquired about my decision to pursue MBA just once. They were professional and conducted the interview properly.And guess what. I managed to convert my IIM Ahmedabad call for PGP.Chapter 5: B-School Experience & InternshipAt one end there was a 20-year old girl, fresh out of college, and on the other end was I, 106 months of experience, married with a child – that was the bandwidth of IIM Ahmedabad’s PGP batch.After coming into IIM Ahmedabad, the tuchchas (second year MBA students Bschool Lingo) were unhappy with my decision to pursue MBA after eight-years of work-experience. There’s not a single company (that visits during campus placement process who can provide a satisfactory job or do some justice to my profile, they said.I asked them not to worry. “I am not here for job. I will find something or the other,” I remember telling them.During internship season, candidates fight and prepare as if they are on war! On Day 2, I got INTEL. No one expected it. INTEL had come after a gap of three years. They had no stereotypical profile (in terms of background, age and profile) in mind like regular recruiters.First year of PGP was mostly about studies, fighting for survival. I did not bring my family in campus during the first year since it is quite difficult to study when you have four-year daughter!In second year, the exploration phase of my life started. I did everything possible – inside and outside the campus. I explored whole startup ecosystem of India, entrepreneurship options, job options, meeting different kind of people etc.I volunteered in almost every kind of activity at IIM-A. I was the finance coordinator of Insight (marketing fest of IIM A), member of Eloquence (Public-speaking club), and member of mentorship club and Public Policy club. I networked extensively with people around and alumni.Chapter 6: Final PlacementI got placed even before final placements formally began! (Guess what? I was searching for those tuchchas who said I’ll face problems during placements.)I got good offers from two firms on the second day of Laterals – Assistant Vice President at YES Bank and Deputy General Manager at Adani Group.I chose Yes Bank.In the last two months of PGP, I joined a local group in Ahmedabad on a part-time basis. I was the head of the only data centre in Gujrat and a 24x7 Hindi news channel. It was an awesome experience.Meanwhile, I also started some online startups and experienced entrepreneurship.Chapter 6: Final lessonHere are some thoughts:It is never too late to start afresh.Believe in yourself and God.Believe in the chance factor of life.Open up to explore new things.Don’t judge the institute and course just by placement packages.Use the institute in every way possible, not just for getting a job. Do not be transactional in your relationship with institute.Network with everyone – professors, students, alumni, staffs, chaiwala, fruitwala, everyone. A friend and I started an initiative to meet all the professors before graduating. We took appointments, spoke to them about their lives and so on. The whole concept was very enriching. Prof Samir Barua, former director of IIM A said, “I have never seen this kind of initiative in last 30 years of my professional life”.Keep learning and exploring.Mr. Amit singh's LinkedIn profile:Page on linkedin.comSOURCE :http://www.shiksha.com/why-i-opted-for-pgp-at-iim-ahmedabad-not-pgpx-after-8-years-of-work-ex-article-11314-1To avoid any misconceptions on PGPX developed by aspirants after reading this answer i'm sharing blog on life during PGPX at IIMA by Mr.Vinay Solanki .PGPX@IIMA an Invigorating JourneyInside IIMA PGPXParticipant BlogsYou can also read http://www.oneyearmba.co.in/why-i-left-goldman-sachs-for-a-one-year-mba-at-iim-a-pgpx/

With over ten years of programming experience and a CS degree, it took me about a month and a half of daily practice to get ready for the interview. “Ready,” for me, is ambitiously defined as the ability to tackle almost any technical interview question in 30 minutes or less and reach an optimal solution. The following is based upon what I did to prepare—your mileage may vary.Ingredients:About two years of solid coding experiencePencil and paperCracking the Coding Interview (CTCI)Your favorite algorithms bookIntroduction to Algorithms, The Algorithm Design Manual, and Programming Pearls are a few good choices. Might I suggest you go low tech and buy physical copies?Two or three hours a dayHighly recommended: WhiteboardHighly recommended: CS degreeOptional: MIT OpenCourseware or another learning siteDirections:1) Learn as much as you can about the Google interview process (days 1–2)Just like an incomplete understanding of a technical question will ruin you in the actual interview, misinformation will derail your preparation leading up to it. I learned this the hard way when I failed at my first attempt after emphasizing brain teasers over studying algorithms and data structures.Start with the source—check out google.com/careers for info on how Google hires. Then watch this video from Google about what interviewers look for in the interview, and finally check out an example interview featuring real Google engineers.Once you have a solid foundation, I’d recommend following up by reading CTCI. Particularly focus on chapters 5 and 6 entitled Behavioral Questions and Technical Questions.By the time you finally read my short article about the six things you absolutely need to do during the actual interview, you should have a good grasp of what a well prepared candidate looks like.2) Benchmark yourself (days 3–5)Now that you know how prepared you need to be, figure out where you are right now. Use CTCI for this. Take a couple of questions from each section and solve them using the six steps I mentioned earlier. Keep track of how long it takes you to reach an optimal solution for each problem you solve.If and only if you’ve solved the problem yourself, take a look at the accompanying solution to assess how you did. Did you reach the optimal solution or at least progress beyond the naive/brute force answer? How long did it take you? Was your code written in the fewest lines possible?Do this for every section. When done, you can prioritize the sections that you didn’t do so well on up front in your practice regimen and leave the other sections for later. You should repeat this exercise just before your interview so that you know your weak spots going into the day of the interview.3) Make a study list (days 3–5)Using the data you acquired from the previous step, make a prioritized list of things you need to study. This list should include:Memorizing two good sorting algorithms and their Big-OMemorizing binary searchMemorizing how to implement basic data structures such as hashmap, linked list, stack, queue, and trees (n-ary, trie, heap) and their Big-O complexitiesMemorizing graph traversal algorithms (BFS, DFS, and a shortest path algorithm like Dijkstra's)Memorizing powers of 2Practice bit manipulation exercises (working with bit maps, bit shifting)Object-Oriented Programming terminology (abstraction, inheritance, cohesion, coupling)Know the collections and math APIs for your given programming languageRecursion, backtracking, and memoizationReview principles of basic discrete mathematics and statisticsThis is all covered in CTCI and your favorite algorithms book. Note: the point of the memorization is understanding! You will probably never be asked to write out an algorithm verbatim. Rather, you’ll be expected to know each well enough that you can use them creatively to solve a problem you’ve never seen.4) Practice algorithms and data structures daily (days 6–30)Pick a two or three items from your list and commit about two or three hours each day working on these things (e.g. 1 hr before work, lunch break, 1 hr after work). As you memorize things, test yourself by writing out an algorithm or data structure on paper or on a whiteboard. Write down the worst case Big-O time and space complexities for the algorithm when you’re done. Always check your work, always!Now copy what you’ve written to your favorite IDE and compile. Take note of any compilation errors so that you can avoid them when you repeat the exercise again. You can and should also create unit tests to verify the correctness of your code.Keep doing this until you can transcribe and compile your code without logical or syntactical errors.5) Tackle as many programming questions as you can (days 16–30)By now, you should have a pretty good handle on the skills you need to succeed on interview question. Starting with CTCI, tackle every single programming problem you can, again using the six steps. Devote about half your study time to this while you spend the other half reviewing items from your study list.If you’re doing well, you’ll probably start to run out of questions in the book. You can find tons more of real samples online from sites like CareerCup or Interview Cake. Or, just use your favorite search engine. I know a pretty good one you can use ;).Practice a few times with another person, both with someone technical and someone non-technical. Ask them if:You looked and sounded relaxedYou looked like a disciplined problem solverYou kept thinking out loud throughout the entire exercise6) Relax and get some good sleep (day 30)Congratulations! You’ve worked really hard. There’s nothing else you can do. Relax and get into your good place. You’ve made it this far. That means you either really enjoy coding or that you will stop at nothing to get that job at Google. I think you will genuinely enjoy your interview experience. Make sure to have fun! I look forward to seeing you in the meeting room.Find this and other articles at https://anthonydmays.com.