How to move from Service based companies to Product based companies

Migrating from service based companies to product based companies is tough. Companies like TCS, CTS, IBM, Infosys have a very mediocre (if at all any) quality bar (which explains their number of employees), as a result of which employees find it very easy to be mediocre in terms of fundamentals and skills and can carry on for years. Grunt work is the norm in these companies, and gradual exposure to such work pushes the brain towards a state of non-intellect, and it becomes even tougher to migrate the longer you stay in these companies. No hope is lost though. You can still make it (I did!).

Necessary disclaimers - Everything I am saying is based on my personal experience. I have worked in IBM India, following which I cleared Adobe and Amazon. I worked at Amazon for 3.5 years, following which I am a SDE 2 in Microsoft IDC, Hyderabad. My background is Electrical Engineering, and until 4th year I did not know programming at all, and scored a zero in my semester programming course. So if I can do it, no reason you cannot!

1. Learn coding. When I say learn coding, I place very little (if at all any) emphasis of the language. One of the most common questions in Indian software sphere is - “Bro, what languages do you know? I know Java and C++”. This question is ridiculous due to a number of reasons. Firstly, language is very easy to pick up. When I joined Amazon, I did not know Java at all. From day one, I had to code in Java. I learnt it on the fly. You may learn Java, but end up working in Microsoft, where majority of the codebase is C++ and C#. What will you do then? You will always have to be prepared to know new technologies (be it languages like Erlang, or frameworks like Swift, or Cloud platforms like AWS/Azure) ad-hoc. If you are not quick to adapt to new requirements, you will never prosper in product based companies. Most of the people who claim that they know C++ will fail badly if they face 10 questions from a Scott Meyers book. Just knowing how to write a for loop in a language doesn’t mean you “know” the language. Secondly, language is the last thing interviewers look at. When I cleared Adobe, the role was for a C/C++ developer. And I knew neither, I wrote all interview answers in Perl and Python! So language is not important, pick up any one, code lots and lots of stuff in that language and become comfortable in coding.
   
   Which language to pick up? Any one of them, really. However, if you are looking for a job in Microsoft, you might as well be proficient in C++ or C#. If anything, your ramp up time after joining will be reduced. If you are looking for a Java developer position say in Amazon, may be Java. If you are looking for a web developer position, you have to be well versed in HTML/CSS/Javascript (although critiques go bonkers when HTML is called a language. Brace yourself!)

2. Grasp computer fundamentals. This is where the cream is separated from the crop. You may ask yourself, I am working in Amazon, I will never need to write an OS from scratch. Why do I need to learn what virtual memory is, or in which scenarios an AVL Tree is a better balancing data structure compared to a Red Black Tree? Because while you will not need to use them directly, you will need to use higher level stuff that eventually use these internally, and your knowledge in these low level stuff will not only help you debug that nasty vtable error your precious C++ code is throwing, or determine whether clustered index is better suited in your scenario than a non-clustered one, it will also help you be a subject matter expert, which is of paramount importance if you are looking for a promotion. Sure, Google and Stackoverflow can always come your rescue, but if you, just like others, fire up Google to search for a solution when your junior comes to you with a problem, it doesn’t show that you are an expert at the subject, it just shows you are an expert at Googling, and the peer respect necessary for rising up doesn’t build up. So computer science is a massive field, what fundamentals you should be expert at? For starters:

a. Operating Systems. You don’t have to know how to fork kernel code, debug device drivers and all that, but at least know the basics of how the memory system works, what paging and segmentation are, how caching is done, how processes are spawned, transferred, scheduled and called, how files are represented and stored, etc. Don’t just read the theory, go to Youtube and go through working examples to hit the lesson home. You don’t have to know the detailed intricacies of how a printer works, but if you answer “Well sir, on clicking the print button, the paper gets printed” to a question “How do printers work”, you are being no different than your mother whose solution to every computer problem is to restart it. When the interviewer asks you this question - he is just verifying whether your fundamentals are in order, you are expected to at least say something about I/O devices, file streams, how the printable files are supposed to follow a generic protocol that can copy a stream to an output device so that the device can print anything that obeys that protocol regardless of what that file actually is, etc.

b. Database - Just like language, this is another dicey area. People just learn how to form one or two simple queries, and they start saying that they know Oracle or MySQL. Don’t. You will get roasted in interview. My last interview round in Amazon was an excruciatingly tough one, requiring details of database index caching and optimization and internal data structures. I had to use every bit of my knowledge to clear that round. Was that necessary? Nope. The person who interviewed worked in the same team which I joined, and there never had been or in future were any requirement for database knowledge. He simply tried to roast me just to verify if what I had stated in my resume was true. Remember - this is not TCS, they won’t ask you to write a program to print your name to test your language skills. So you need to have a holistic knowledge of databases - how index works and what are the various types of index, where to use which one, how they are represented internally, how to optimize a given query, which join is better suited to a given query, how can stored procedure be used to make things easy, the caveats of a stored procedure, etc. An excellent book would be the biblical one on SQL Server by Kalen Delaney.

If the role is geared towards a specific technology, that the fundamentals of that will also be required. For example, if you are applying for a SDE role in Microsoft Edge team, where majority if the work is in C++, you will be expected to be fairly expert in C++. So if you with great confidence answer, “Well, in the order in which they are initialized” to the question “In what order are member variables initialized in a constructor initializer list”, you have already messed up!

3. Learn Software Design - This is most important if you are looking for senior roles based on experience, like SDE 2 or SDE 3. You may be the star performer in TCS, but you won’t clear even the first round in Microsoft if you are clueless about Object Oriented Design. Read, internalize the biblical book on designs by the Gang of Four. You will be specifically asked to design stuff - like design a bank ATM system, or a system of 10 elevators, you will be expected to use all your design knowledge to come up with a design which is clean, reusable and extensible. You will be asked why in a particular case, Factory Pattern is overkill, why in a given situation, Singleton Pattern makes sense, etc. These knowledge will be in requirement during practically every day of your work, so be sure that interviewers will grill you on this topic. It might be okay if you could not explain how exactly segmentation works in OS, but it won’t be okay if you could not write clean and reusable object oriented code.

4. Learn about Data Structures and Algorithms. This is perhaps most important, although its importance gradually reduces as you apply for higher positions. Again, like everything else, it is a gigantic field. The interviews can also range from the tricky one to the unimaginably tough. I have seen Google interview questions which require knowledge of centroid decomposition. Will you face these questions, the likes of which generally appear in Topcoder or Olympiads? Probably not. If you do, you are applying for the wrong position. Coming back, the kind of questions which generally do come are abundant over internet. Grab some books like the one by Gayle Lackman, or browse through the examples at GeeksForGeeks and Leetcode. You will have a very good idea of what kind of questions do arise in interviews in Google, Amazon, Facebook, Microsoft, etc. However, do not mug them up. You can be the best mugger of your generation, you will still fail in interview if you don’t get the concepts right. For example, in my Amazon interview 3rd round, I was asked a stock question - there are N players numbered 1 to N, and a function which takes two player ids as input and returns the winner in O(1) time. Use the function to sort the N players in the array in least time so that every player has won against the player on his left. I also gave the stock answer - quicksort, replacing the typical comparison operation by this function. I was feeling reasonably pleased until the interviewer (he was to become my manager) asked me its worst case scenario. That for a Quicksort is O(N^2). There are ways to optimize quicksort, but none could apply here because of the nature of the problem. He said it is possible to do it. If I had mugged up the solution, I would have had to give up. But I gave it some thought, finally came up with a solution based on AVL tree that reduced the worst time to O(N Log N). No amount of mugging up GeeksForGeeks and Leetcode could have prepared me for this. So how do you learn and practice?

a. Grab hold of a good book on the topic. Preferably CLRS, or the one by Steven Skienna. Learn the fundamentals. How binary trees work. How binary search trees work. Where to use heap sort. What amortized time analysis is. What is meant by NP hard problems. How to find the shortest path between two nodes in a mesh. Etc.

b. Go through the websites I mentioned. Many people frown upon them, do not listen to them. Go through the problems solved there, practice. Learn. Practice again. You may have written an immensely popular software for OS X like Homebrew, however Google will still reject you if you do not know how invert a binary tree (this is a real life example. Google it!).

Many people ask whether this is necessary. For example, in my three year work in Amazon, the most complex algorithm I had to use was a binary search. I never had to take resort to binary trees, or even linked lists, forget Red Black Tree! So why do interviewers ask you that tough binary tree algorithm even though your work will not require it? It is because these test your problem solving skills. One who can solve tough problems in an interview in such short duration is capable of solving big real world problems the company will be facing in short time as well - that is the idea.