These are my personal tips that you should consider to have a great interview. Nothing professional nor official. Anyway, I wish you the best of luck.
Engineers inside of the big tech companies have the option to become interviewers, but it is not mandatory. If they want to interview, they need to take a course and pass it. So, they are interviewing because they want to do it, it is like a distraction to them in a busy coding day.
The interviewer knows you a very few with just your CV and the 45 minutes of interview, but he wants you to success in the interview, without gift it to you, obviously. They will try to guide you, give you hints and even explain things if you are missing some knowledge to do the problem, but they won't solve the problem for you.
During the interview, your interviewer might be making some notes of what he sees in real time. Every time he types “enter”, the system will write his paragraphs with the time, and he could make some notes of (--, -, /, +, ++) to score if the comment. Something like:
After the interview ends, the interviewer must write a report of what they saw during the interview, and they must answer some questions about your performance. I have read in some posts, and the questions should be something like:
Also, the previous questions are measured between:
| DEFINITELY NOT HIRE | NOT HIRE | HIRE | DEFINITELY HIRE |
And to support his decision, the interviewer must write a brief paragraph and he might quote a section from the coding pad to justify himself better. So, remember to not erase anything but typos, and write most of the things that you are saying. It would be nice if you practice your writing in pages like www.keybr.com
Even though this is not something measurable, if you keep a friendly, humble and listener profile, the interviewer will subjectively feel that you two can be friends, and there is a high probability that he will write the report in a slightly better way that emphasize your achievements and reduce your mistakes. (There are studies about it)
There is a hiring committee who take the final decision, so the interviewers need to write all the things they saw in the interviews. But the hiring committee has access also to all your previous applications and interviews you have had in the past for the company.
They will base their final decision based on your recent interviews, of course. But keep in mind that they have access to your previous interviews, because I know about some cases where the interviewers repeated a question that you got asked before. That could be seen as a chance to finish your interview really quickly and with the most optimal solution, but if you don't say anything that you have solve that problem before, the hiring committee will see it and that is highly frowned upon. (50 points to Slytherin)
It is better to say something like “Hey Peter, I think I got asked/solved this problem before, the solution is like … and the “, then the interviewer will see that you have good coding knowledge, but also that you are trustworthy and honest. (100 points to Gryffindor)
In that case, he might change the problem, ask you to do it with a different approach, increase the difficulty, or just pass through your solution.
Most of the interviews are expected to end for the first 45 minutes, but if the interviewer wants it and have time for it, he could take extra time to finish the interview. That could happen if he considers that there were troubles in the connection, the problem was a hard one, or if with extra time you can solve the problem.
I would say that an interview should follow the next pattern, but don't take my word for it.
| Introduction |
0 – 5 minutes: Connection and interviewer's presentation. Verify the audio and video connections and the interviewer should present himself very briefly. Put attention, you can come up with a good question to him. This could be something like “Hi Jimmy, my name is Peter and I have been in Google for 5 years, I have worked in YouTube search engine… I joined when… “ |
|
5 – 8 minutes (Optional): It depends on your interviewer, but he might ask you to make a short presentation of yourself. You should have a small paragraph well practiced, to show your interest in coding and that you are a good candidate to Google. |
|
| Coding |
1st part: Problem presentation. After verifying you are familiar with the coding concepts (array, tree, string …), they will copy the problem in the code pad and explain what they want you to solve. (Optional) – Some questions are related to a board game or a real-life problem, so they might take some minutes to explain you a bit better what they meant. |
|
2nd part: Clarify your doubts. Make meaningful questions! They are evaluated! And there could be edge cases that you are missing, and the worst thing you could do is to solve a problem that they did not ask you. |
|
|
3rd part: Write fast in pseudo-code your ideas while you are explaining why you are doing the things and write the complexities. Listen to your interviewer, ask for time to think if you need it, ask him if your pseudo-solution is efficient enough to cod it, and even ask for a small hint if you are stuck in the problem. |
|
|
4th part: Write your solution, you should keep explaining while writing. Take care with the small typos, and edge/empty common cases. Write comments in your code, that will make it easier for your interviewer to understand your code. Example: “// this for-loop creates a priority queue with the first 10 elements”. It is not necessary to code everything, you can assume there is a function to do small things, as long as you can resume what the function does and know its complexities. Example: “Could I assume there is a function that orders the vector by it first element?”. |
|
|
5th part: Debug your code with the given examples or edges cases and verify that your solutions behaves as it should. While you are explaining the debugging of your code, you can use comments to pass through your code. This is very important to find indexes typos and missing edge cases. Example “If A='XYZ', the first letter is 'X' (//a='X') and happens that …, after that, 'a' changes to 'Y' (//a='Y') and …” |
|
|
6th part (Optional): Discuss a better solution. Sometimes there is even a more efficient solution, and you are not really expected to always come up with the weirdest-best solution, but it gives you extra point if you can discuss the idea. Something like “Do you think that there is a way that you can improve your solution using a priority-queue?” or “Do you think that there is a way to improve your solution?”. Remember that it is okay to ask for time to think a bit. |
|
| Questions |
3 – 10 minutes: Ask significant questions. Depending on your speed to solve the problem or the time of your interviewer, you can have time for 1 or more questions to him. This is also an important part of the interview, because it is when you can empathize with the interviewer and relax the things a bit. You must do questions that show you have interesting into joining them:
– Extra points if you make your interviewer laugh :P |
I would say that to be successful in the interviews you need coding knowledge, but you also need to know how to do a great interview. And for that, the best thing you can do is to practice with your friends the interviews. Take a medium problem from leetcode.com and practice the role of the interviewee and interviewer with your friend.