Skip to main content

5 Tips before your Google Interviews (or any interview in general)

Hey guys, new grad hiring season is coming up and many of you must be having their Google interviews in queue. While most of you have done some sort of preparation for the interviews, here are few last moment tips to help you perform better - 

Tip number 0 - Be proficient in DSA and Coding 

This is not kind of a last moment tip, but this is tip 0 because it's the most important and obvious one. Before going to an interview you must have a basic understanding of the popular data structures and algorithms and a proficiency in converting the logic to coding language of your choice. You can learn about the basic data structures and algorithms from sites like cpalgorithms or if you want some guided preparation you can join a coding institute like pepcoding. Side by side you can practice what you have learnt on sites like cses, codeforces, leetcode, binarysearch.com. By proficiency it never means you are a code wizard but it implies you can think and rationalize about problems ground up. Having some good practice of wide range of problems is always better as it helps you identify common patterns and apply them in similar scenarios. 

Tip number 1 - Have a context of time 

You must realize that interviews are inherently a time bounded process. Once you’re shortlisted for interviews you’ll be judged only on the traits that you exhibit in those 45 minutes, not on your past record or what you have listed on your resume. It’s important that you have a context of time in the back of your head. So before an interview, split the next 45 minutes you’ll be spending. Ideally you’re expected to solve two questions during 45 minutes, with first usually being a simpler one and second being a bit trickier. Good interviewers ask questions that can be gradually attacked as it gives a good idea about the thinking process of the candidate. So your time division strategy could be, spend 5 minutes understanding and clarifying the first question, 10 minutes in brainstorming the solution and next 5 minutes in coding up the solution. That spares you with 25 minutes for the second question. If the question is easier you can reduce the time to brainstorm to 5 minutes. Similarly for the second part you can divide the time between brainstorming and coding the solution. Say if you have 25 minutes, 5 minutes in understanding and clarifying, 12 minutes in brainstorming, 8 minutes in coding. 

Tip number 2 - Communicate 

The worst interviews are where the candidate just sits in front of the laptop and spends the whole time staring at the screen, or coding haphazardly the solution on the editor. What is even worrisome is that some candidates feel that they are only being judged to solve the problem at hand. Yes, you are going to be judged on the basis of the solution you come up with, but it’s important to realize the difference between a coding contest and an interview. An interview is supposed to select people who can work collaboratively in teams. Real life scenarios are never as well defined as a coding problem and there is always going to be an inherent subjective ambiguity while working on massive projects for which a whole team is required. Hence communication is a big factor in any interview. By communication it doesn't mean to be proficient in English, it means that you are able to ask the right questions and get the required information to solve the issue in hand with your analytical skill. So during the 5 minutes that you’re discussing the question make sure to clarify the question. You can ask the interviewer for a few examples, ask clarifying questions and double check your understanding of the problem in hand. Jotting down things on the doc is always good as it helps the interviewer to understand exactly what you’re conveying. During the brainstorming phase try to vocalize your thoughts. Starting with brute force is better as it helps you have an upper bound on the time complexity of the solution. I have seen some candidates coming up with complex solutions even worse than a brute force. After you come up with any solution, communicate it to the interviewer with time and space complexity. You can then explicitly ask if the solution can be optimized further and if not you can start coding it. 

Tip number 3 - It’s ok to be nervous 

Just before the interview people have that feeling in the belly. It’s ok to be nervous, I would even go as far as saying that if you’re not a bit nervous you lie at either of the two tips of the Dunning Kruger curve. So your situation is the same as most of the candidates. Nervousness is fine, what is not fine is being absolutely unprepared for the things you know are going to happen in those 45 minutes. So before interviews it's important that you do a few mock rounds either with your friends or on some anonymous platforms like pramp. Also it would be even better if you’re regular with some time bound practice on sites like binarysearch.com or codeforces. Time bound practice will help you permute with different strategies that you want to test before the interview and will set your mood for interviewing. If you are completely stuck at any point you can ask for a hint to the interviewer, surely if the interviewer gives a big hint they will mention it in the final assessment but it's better to be unstuck then wasting time. You should realize that the interviewers are spending their energy to potentially hire you and not reject you. You just need to take the lead of the discussion and give hiring signals to the interviewer. 

Tip number 4 - Clean code 

While coding up your solution try to follow style guidelines. You can see the style guidelines for each language on Google's style guide website. Clean code shows a sign of maturity and displays healthy software engineering habits in the candidates. Decompose your code into reusable pieces wherever you can, try to use efficient and best practices for the language, name your variables properly. It's best if you build this as a habit during practice only since it’s more difficult to unlearn such habits during the interviews itself. 

So these were few last moment tips before interviews. I hope these help you perform better. All the best. See you in the interviews.


 

Comments

Popular posts from this blog

Why LLMs are not replacing search

There has been a lot of talks recently about LLMs particularly ChatGPT and now Bard with many people starting to interact with this technology. There are few opinions that it’ll take over how we search, but I don’t feel traditional search is going anywhere, few of my reasons to believe so - 1. LLMs are impressive but not robust - When users first start interacting with these conversational models they are very impressed by the responses it generates, but slowly people can start to see that its not correct always and the results these models spit are not necessarily facts. Also users can make these conversational agents hallucinate things that don’t exist just by conversing with them. And once users start feeling they are getting wrong facts the trust in such models will decrease. 2. No concept of choice - These models spit out a single result, users don’t have any other choices. Many times users want to be able to look through multiple results to gain information about different aspect

Chess Engine Programming