You're probably here because I've linked this to you, or because you're exploring other resources in my McGill repo. This page is meant to house a collection of interview tips, based on my experience as a new(-ish) grad, and as someone who is technically interview trained.
Based on Google
As an intern, you'll get one or more phone interviews, followed by host matching. Host matching is more around seeing if you'll fit with the team, rather than being a technical interview. For full time, you'll have ~5 back to back in person interviews. These interviews can be technical, specialized to your field, or based around the people you'll work with. For conversion, you'll have the same interviews as full time, minus 2 for every internship you've had. If you've had 2 internships, there's a chance you don't need to interview.
An interview typically goes on as follows:
- Interviewer introduces themselves and sets the itinerary
- Interviewer may have some ice breakers to make you feel welcomed and relaxed
- Interviewer will begin asking questions; good questions should hopefully scale depending on your answers
- Interviewer will leave time for questions, and stay with you until your next interview (if in person)
The goal for posing interview questions is to understand the interviewee's level of technical expertise, adaptability, and thoroughness. We are interested in the journey it takes to get there moreso than the final result. For me personally, I am interested in the considerations and evaluations across multiple solutions, rather than having the interviewee get to an optimal solution as fast as possible.
Here are some tips I have:
- When given a question, provide an example flow.
- This not only gives you time to think, but helps makes sure that you've understood the question. Feel free to start with a non-edge case, and provide more edge case examples as you go. It could be that you misunderstood the question, in which the interviewer may correct you. It could also be that the interviewer missed a detail, and will be able to clarify.
- Give a basic solution without considering runtime (or all edge cases).
- A seemingly poor solution is better than none at all. You'll be able to provide something to the interviewer without straining too hard on all considerations, and the first solution may guide you to easier solutions for certain edge cases. It is helpful to speak your thoughts allowed as you go, just so the interviewer isn't seeing you type/write in silence.
- Feel free to create helper methods to assist you, and come back later.
- Naturally, you don't want to make things too abstract, where one method essentially solves the problem; however, ignoring small algorithms that you know are possible and focusing on the overal logic specific to the problem is helpful. The higher level flow is also what's unique to each problem, so it's one of the key things we are looking for during the interview.
- Don't be afraid to correct your mistakes.
- If you see syntactic errors or logical inconsistencies, go back and correct them. As interviewers, we intentionally try not to interrupt you unless we feel you are stuck or are finished. This is precisely to see what problems you can identify independently, regardless of whether it's in the first pass through.
- Voice what doesn't work.
- It may feel difficult to provide your stream of thought as you code. Sometimes, we're spending too much effort finding the right solution, while hiding the solutions we rule out. It helps to let the interviewer know what you've thought of along the way, and why other solutions don't work. This is especially true when picking platform specific APIs to use. As an Android developer, I want to know why you chose a specific layout, why you've chosen a specific method to override, etc.
- Don't cram for an interview like you would an exam.
- Or maybe do, if you really feel like you can retain the information long term. Cramming for exams is already a disaster, but you are afforded the luxury of taking time to think and switch between questions. Interviewing with someone in real time is much harder, and you will likely blank out on things in your short term memory. I would focus more on practicing questions to the point where they are natural, and picking up on certain points that you missed. In a long term sense, this can be achieved by working on projects, where you face real problems and acquire real solutions. In a shorter term sense, it involves grinding leetcode, but with the expectation of using what you know and picking up general patterns, rather than memorizing the solution for a given set of questions.