Google: Difference between revisions
→Re-Evaluate the design
m (Protected "Google" ([Edit=Allow only logged in users] (indefinite) [Move=Allow only logged in users] (indefinite) [Delete=Allow only logged in users] (indefinite))) |
|||
Line 407:
== Re-Evaluate the design ==
Room for improvement?
= Dublin =
== Interview 1 (45 mins) ==
;Technical RRK - Foundational technical knowledge where the interviewer will ask you at least one question from 2-3 areas based on your expertise. This would include areas like (but not all)
* Connectivity (Layer-2 switching)
* Connectivity (Layer-3 IP routing)
* Network hardware devices
* Network hardware performance
* Webtech/troubleshooting/SQL
;Troubleshooting - Focus on process of troubleshooting rather than technical details
* Networking troubleshooting questions to demonstrate you can apply knowledge of Networking specific technologies to troubleshoot specific problems
;System Design -
* Designing technical solutions
== Interview 2 (45 mins) ==
;HrM Interview - This interview is based around the below criteria. This is some but not all they will cover.
* Handling customer issues
* Long term customer success
* Escalating handling
;A few additional tips which may help in your preparations:
* Talk through your thought process about the questions you are asked. In all of Google's interviews, our engineers are evaluating not only your technical abilities but also how you approach problems and how you try to solve them.
* Ask clarifying questions if you do not understand the problem or need more information. Many of the questions asked in Google interviews are deliberately underspecified because our engineers are looking to see how you engage the problem. In particular, they are looking to see which areas leap to your mind as the most important piece of the technological puzzle you've been presented.
* Think about ways to improve the solution you'll present. In many cases, the first answer that springs to mind isn't the most elegant solution and may need some refining. It's definitely worthwhile to talk about your initial thoughts to a question, but jumping immediately into presenting a brute force solution will be received less well than taking time to compose a more efficient solution.
* When asked a question by the interviewer '''your answer should''' be:
SPECIFIC: inline with the question, no digressions.
SYNTHETIC: be factual, simple, short sentences, no long explanations. Inform the interviewer that you have additional info if he would like to know more.
TECHNICAL: your interviewer is an expert and they love to hear deep technical details in your answers (relevant to the question of course)... They are eager to learn something new.
OPEN: if you don't know the answer to the question it is not a problem but please please please tell the interviewer, don't pretend that you know by just guessing the answer. Tell them that you will attempt a solution by using the following X Y Z elements. ALWAYS explain the reasoning that you are following.
FLUID: keep the conversation going, no long blank moments, if you need additional information about the problem you are asked to solve, ask the interviewer. The interview is a conversation not a monologue, not an exam.
| |||