paint-brush
An Opinionated Guide to Preparing for Coding Interviewsby@saurabhmaurya06
5,082 reads
5,082 reads

An Opinionated Guide to Preparing for Coding Interviews

by SaurabhMay 13th, 2016
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

The same recycled algorithm questions, some puzzles peppered in and a disproportionate amount of emphasis on your performance in the interview.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - An Opinionated Guide to Preparing for Coding Interviews
Saurabh HackerNoon profile picture

Musings of a former SDE at Amazon

The same recycled algorithm questions, some puzzles peppered in and a disproportionate amount of emphasis on your performance in the interview.

Many argue that tech hiring is broken

But that’s not really what you're worried about right now, is it? With about 2 months before campus placements, a standardized, stale hiring process is the EASIEST TO GAME. Your questionable CGPA, your lack of internships, meagre projects — all have very little bearing on your selection. Let's get down it.

Competitive coding.

This is going to play a very large factor in most product company interviews. Amazon, Microsoft, Directi, Flipkart et al are guilty of asking the same questions over and over again. Two months is just enough time to cover the important topics.

InterviewBit is your bible here. It’s split into categories and guides you on what topics to do when. The average time per question feature is a good indicator of how good you currently are. You will find more specific guidance on the InterviewBit platform directly. It’s the only coding platform I used for my entire preparation.

  • Solve one question per topic box and move on initially. If you have more time, do some more trees, graphs and linked list based questions.
  • Unless you have prior experience in C++, prefer Java. Most companies are Java shops and you will get a few brownie points here.
  • Code every question yourself. Don't just look at the answers and move on. This will take A LOT OF TIME. Being panicky and tense is going to make you worse. Initially, don't set yourself mental deadlines to finish a question.
  • It’s normal for some questions to take 2 hours or more.
  • Don’t use multiple competitive coding platforms. Stick to one so that you are more likely to cover all kinds of questions.

Assuming you are a rank novice to competitive coding, expect at least 45 of your 60 days to be fully devoted to this. Get most of these days in early as it’s harder to spend quality time on coding when you are nervous.

Theory

Data structures, Algorithms, Operating Systems, Databases, Networking. Very little math related theory. Find college lecture slides and revise from there; that will be enough. You can skim through these topics at your own pace. Do not spend more than a few hours on each topic. Take about 3–4 full days in total for this.



Step 1: Skim lecture slides.Step 2: Google ‘indiabix *topic* questions’ and quickly solve some MCQs.Step 3: Don't worry about memory-based questions. Focus on concepts.

Projects

When recruiters ask you this, they are trying to see if you really enjoy programming. Make sure your face lights up when you talk about that app you built and what you were trying to solve using it. Expect to field some questions on why you chose a particular technology stack and why you designed it in a particular way.

If you have a CS degree you would have done college assignments (PPL, Compilers, Computer Graphics) you can pass them off as projects. PS-1 projects can be added here too.

If you don't have a CS degree and have minimal projects, emphasize that you are self-driven and can learn new things on your own. That you have cleared the preliminary rounds without a teacher. A friend of mine said exactly this at a PayPal personal interview (and it worked!).

Resume

That’s a whole article in itself. For now, just keep it as something to do in the last few days. You will probably be too jumpy to spend hours on coding questions that late anyway.

Last few days

Practice mock interviews with friends or in front of a mirror. Rehearse out loud your introduction, two pet projects and common questions. And always do a quick (~10 minute) review of a company before you sit for its personal interviews!

Word of advice

Drop absolutely everything and work your hardest for placements. There is a lot of variance in the quality of companies. A job offer in the domain of your choice is well worth the effort put into it. You should be able to put in at least 6 hours each day.

I made the mistake of not taking placements seriously enough. When you miss being a part of a data engineering team because of a standard DP question, you're going to get pretty mad at yourself. Try not to let that happen.

Most people say they got lucky on their interview day. No matter how good you are, cracking 4–5 interviews straight is pretty damn hard. Just hang in there and don't let your confidence drop just because you messed up a few interviews.

Some FAQs





  1. **What language should I use?**Java and C++ are both solid choices. Most companies use a lot of Java so they might be a little happier with someone proficient in it. Also, you are quite likely to be using Java at work so you might as well get good at it now. Competitive coders prefer C++ so you will find most algorithm solutions in C++. It is a little less verbose too. Pick either C++ or Java depending on what you are already comfortable with.C does not have an STL, making it a pretty bad choice.Some companies do not allow Ruby or Python.


  2. **What is STL?**The Standard Template Library (STL) in C++ has pre-built implementations of stacks, queues, hash maps and iterators etc. You will need these to code quickly during the process. Collections is the rough equivalent in Java. You'll learn these quickly enough once you start coding.








  3. What’s the usual interview process?First round(a) Aptitude and Theory MCQs or(b) Online coding round (on Hackerrank or equivalent) Usually, 3 questions to solve in two hours. You don't necessarily need to solve all three to go to the next round. Two is usually enough. One if it’s really hard. Questions tend to be standard.Second round3 Personal Interviews. Puzzles and coding questions on paper here. Some trivia theory may be also asked. Your PI may ask you variations of the question once you solve it.Very few companies hold a formal HR round. Your technical interviewers may ask you to introduce yourself, your projects, extracurriculars etc.


  4. **How tough are the questions?**The questions are of the same level as on InterviewBit. Rarely would there be a question with a truly novel approach to it. DP questions are rare (Directi does ask these) and when asked, they tend to the simpler ones.


  5. **Should I practice aptitude questions?**If you haven't done a lot of competitive coding before, it’s a better idea to work on that first. Keep aptitude questions very low on your priority. Maybe spend a few hours on one day just to get into the groove.













  6. **What do I work on first?**Order the things you are working on in decreasing order of priority. It’s quite likely that you won’t finish everything, so get everything important done first.1. Competitive coding — Every company is going to test you on this. Its also the most time consuming of everything you need to do. Finish all the topics on InterviewBit once before doing anything else.[Day 1 to Day 45]2. Theory — Inability to answer conceptual CS questions won't look too good. If you are from a non-CS branch, they tend to go a little easier on the theory for you. [Day 45 to Day 50]3. Resume — Companies usually shortlist based on MCQs or the preliminary coding rounds. Your resume plays less of a factor there. It’s more important in personal interviews where they will use it as a conversation starter. If you've listed a project and can't explain it well, that’s a red flag. List fewer projects and know them well. Leave resume writing for the end and get plenty of feedback. [Day 50 to Day 55]4. Interview preparation — Do this after writing a basic resume. Your answers should reflect what you say in the resume. Say you have a low GPA but you have added a lot of projects in your resume. You should then introduce yourself as someone who loves building things. What if you are someone from a non-CS background with few projects? Emphasize that you are self-driven and can teach yourself. That you have reached this far on your own. Practice your ‘pitch’ with other people and get feedback. [Day 50 to Day 55]5. Cover your gaps — If there are coding topics you aren't too happy with, go over them again. The same with theory. Fill whatever gaps you think you may have.[Day 55 to Day 60]





  7. **How does the interview start?**You sit at a table across your interviewer with a pen and paper. It will branch out into either(a) your interviewer asking you a question (puzzles or code) without much introduction. You clarify all aspects of the question. Talk him through the approach, and then start writing code on paper. Make sure the code is perfect before giving it to him for final review. He may ask another question with a similar process before sending you for the next interview.(b) your interviewer asking you to introduce yourself. This is to gauge your communication skills, your interests and anything you might not have put on your resume. You can try a “Hi, I’m X and I study Y here. I really like [building tools people use]/networking/automation/[niche the company is in]. I've worked on a few projects in *above area* and I really like X about it. I’m hoping to learn more about Y at my job.” Always give the interviewer space to interrupt you with a question. Take a pause and judge whether he wants you to continue. This is where you have the opportunity to weave a story around your strengths and explain away your weaknesses. Use it well. It will proceed largely like (a) from here.

There are other tools/platforms you can use to learn. I've deliberately mentioned just one for each purpose. Most people spend too much time worrying what the “best” way is. I believe there’s no one better than someone who has cracked the process before to guide you for it.

This is an opinionated piece for people who have received too little or too much advice. So that you spend time preparing instead of overthinking these things.

About the Author