How Google will interview: what to be, what not to pass
In recent weeks, a wave of articles on Habré on how interviews are conducted has increased.
Google is looking for engineers constantly. Like SRE, I can say for sure that you are needed in our ranks . Cookies in mini kitchens and coffee in coffee machines are waiting for you. Just need to pass an interview. It is difficult, but real - I once described my history as an applicant, and now, among other things, I am also engaged in conducting interviews. So now I will tell you how we conduct interviews with engineers.
No, I did not become a recruiter. The interview process involves a conversation with a recruiter first. This is a general conversation “what-where-why” (that is, a description of the process for your particular case) and the very favorite screeningfrom the multiple choice questionnaire. Screening at one time seemed to me very basic, I suspect that you have already answered such questions a hundred times. Then the interviews will be conducted already by engineers - by your future colleagues (close or distant, this is how it will turn out, our planet is very small).
(Important: I describe the process as I know for engineering positions (Software Engineer (SWE) and Site Reliability Engineer (SRE)). For interns, the process changes; as well as the process can be different in principle, as the HR department adapts the process to achieve the best effect. Use the information given here only to give an idea of what to expect - but not a public offer! Accurate information about how the process will run for you personally, will only be information from your recruiter. The information may also become outdated - review Read the section How We Hire for current information at the time of reading the article).
First there will be several interviews through hangouts / meet. This is a full-fledged interview, as I said above - the engineers will be interviewed, and it is assumed that the candidate will “think out loud” + will write a dozen or two lines in any programming language (yes, unfortunately, in Google).
My interview is designed for ~ 45 plus or minus ten minutes, but usually I try to fit in exactly 45 minutes. From this time, five minutes for a brief acquaintance and general information, 30-35 minutes for questions and discussion, then five minutes for the candidate's questions (if any).
In general, the purpose of the interviewer is to collect information on several skill axes.candidate (such as the ability to code, knowledge of algorithms and data structures, etc.). But the most important thing in the interview is to find out how a person thinks. That is, it is always important to find the boundary when a person does not know the solution. Each interviewer has his own technique (especially for telephone interviews): someone keeps a dozen questions in store, from warm-ups (literally, writing a three-line cycle) to difficult questions to explain. Someone has 2-3 “favorite” questions, any of which can be turned in a dozen sides and both simplified and complicated - depending on what the interlocutor demonstrates. I am sure there are more options, but I do not know about them.
I tried both techniques, and I prefer the latter: depending on the candidate’s resume and self-assessment, I use a more appropriate form of the question. The question is always open (after all, when did you last see the exact problem statement in our industry?) And depending on what and how the candidate asks questions, I simplify or complicate the question so that by the end of the first about 10 minutes the candidate already wrote a trivial solution. It is rarely difficult, after all, a solution is trivial.
Questions are also trivially asked “why are you sure that it works?” (If the candidate did not immediately describe the limits of applicability or tests), and what is the complexity of the solution obtained. It simply gives information that the candidate knows how to code and understands what he wrote. But it’s not enough to code — you need to be able to think, so questions follow: how to get rid of restrictions? How to do better? Either (what happens when the candidate is very good or just knows the solution by experience) how to make the code work with these or other additional restrictions.
This gives a bunch of signals right away - how much does the candidate know how to adapt to changes in the task? And how ready is it to think about strongly alternative solutions? The discussion itself is also of interest - the question is always asked as openly as possible, therefore there are dozens of ways to understand it. Is the business environment being clarified, or only technical limitations? Are technical limitations taken into account? For example, several times it was that I said “expected 1e12 objects”, and the candidate does not estimate how much it is. And this is almost a terabyte, if byte per object. Or ~ 116.5 gigabytes per bit. Or 4.3 terabytes if int32. Well, you understand. No, it is not necessary to remember this - not on the exam, no one has selected the calculator. The phone is, yes, even in the search. And by the way, you can ask.
And this is how I will raise the complexity or simply modify the task for all available interview time. Yes, it is possible that for the interviewee this is the main working bread, and he eats such tasks for breakfast, lunch and dinner. Well, in this case, my travel card has a completely different question. For example, instead of graphs, for dynamic programming. Or on lists. Or even the question where the optimal solution will require a bunch. The main thing is another entourage, another task.
The most important thing here is to give at the same time a very simple task, so that the candidate can decide and show the basic skills, and raise the complexity to a level where the candidate does not know the answer, so that he can show how he thinks. If at the same time you can find a solution to a more complex task, this is excellent, but if the candidate could solve everything at all, then this is a person’s person’s puncture that he didn’t prepare a question of even greater complexity.
Want specifics? Here is one of the questions that you will NOT be asked simply because it is considered already “leaked” - that is, it is likely that the candidate will not think about him, but remember. As I wrote above, it is important how the candidate thinks, and not how he recalls ... So, the question is: implement LRU cache .
In general, the task is beautiful, as it allows many forms of tasks and many forms of interpretation. For example, you can ask a question straight in the forehead “implement LRU cache”. It can be formulated as “imagine that our service for processing a request checks the existence of an external object. How can we speed up the processing? ”- expecting a very obvious sentence“ let's just cache the result ”. What can you ask “how?”. And “what if we want to control the maximum memory consumed by this cache?”. The question leaves open - and which API should this cache provide. For simplicity, you can always reduce to set (key, value) + get (key); but you can add TTL. It is possible with get (key, fetch_func). In general, the evaluation of the proposed API can also give an additional signal about the experience and way of thinking of the candidate.
A trivial hashmap solution will give O (1) on get () + O (N) on set () (this is the same, right?). If all the elements are additionally linked (by creating a double link), it will be possible to obtain O (1) for both operations. If you need to add a TTL ... I think the idea is clear. If you wish, let's discuss in the comments: imagine what you asked this question, how will you think? what solution do you propose? ..
And in what programming language? Yes, what like, in which the most. C ++? Wonderful. Go? Wonderful. Python? You're welcome. Perl? Today is rare, but also yes. And Java, yes. And javascript (even though it’s harder considering the memory of the solution).
So, after about 40 minutes from the start of the interview, the thought flight of the candidate will be interrupted, but this does not mean that everything is bad. It just means time is up.
After the interview itself, the interviewer writes a report, often with a detailed transcript of what happened to the interview. This report will be used to make a decision. I personally reserve about an hour immediately after the interview, in order to record the full minutes of the conversation in fresh memory, some simply write on paper almost a complete transcript in the interview process.
After a telephone interview, on the basis of the reports of all the interviewees, a decision is made about inviting to a confrontation. It will be a full day of interviews in one of the offices: several interviews in the morning, then lunch (and getting to know the dining room in the office :) and then a couple more. When interviewing SRE, these will be different interviews, a list of which the recruiter will tell you, including coding and necessarily NALSD: Non-Abstract Large-Scale System Design. The key is non-abstract (that is, not the general words “we need a database”) and “large scale” (that is, if the base is needed, then for petabytes, for example). You can read more here and many more where to find materials in the search. I recruited a few links for training. This is a very important point of the interview - simply because working in a Google-sized company, you have to think and consider systems from such sides.
In general, an in-person interview is not much different from a telephone one — similar questions and a similar process. In doing so, we try to distribute the questions so as not to ask the same question twice.
What else can I add about the interview process? Have fun! No, seriously, relax and have fun! Telephone interview? Just a conversation with an interesting conversation partner. Guaranteed new information and new experience. Full-time interviews? More fun! You are on a business trip at the expense of the future employer :) Take a walk around the city, meet with friends. Also guaranteed a full day of entertainment and interesting conversations.
And after this day of fun, all those who interviewed you also write a report, with the full protocol of the conversation. All interview data is aggregated and reviewed by an independent committee.. This is important: none of those who know you personally, is not involved in the decision. None of those who interviewed - also does not participate directly. This is all aimed at eliminating bias in the decision. Evaluation is only for compliance with the required standard of the standard for hiring. If suddenly there is no luck, and you do not pass - you can always try again in a year. For this year, you can systematize your knowledge and fill in the gaps discovered.
Have any questions? Ask in the comments.
Any interest in trying out an interview before the interview? There are services for mock interview (for example, one and two , but they are not from the company itself, so there are no guarantees); Google sometimes runs similar campaigns.
And yes, do not be shyapply yourself. If you believe in the magic of “filing through an employee” - write to me, I will submit your application. Welcome!
Google is looking for engineers constantly. Like SRE, I can say for sure that you are needed in our ranks . Cookies in mini kitchens and coffee in coffee machines are waiting for you. Just need to pass an interview. It is difficult, but real - I once described my history as an applicant, and now, among other things, I am also engaged in conducting interviews. So now I will tell you how we conduct interviews with engineers. No, I did not become a recruiter. The interview process involves a conversation with a recruiter first. This is a general conversation “what-where-why” (that is, a description of the process for your particular case) and the very favorite screeningfrom the multiple choice questionnaire. Screening at one time seemed to me very basic, I suspect that you have already answered such questions a hundred times. Then the interviews will be conducted already by engineers - by your future colleagues (close or distant, this is how it will turn out, our planet is very small).
(Important: I describe the process as I know for engineering positions (Software Engineer (SWE) and Site Reliability Engineer (SRE)). For interns, the process changes; as well as the process can be different in principle, as the HR department adapts the process to achieve the best effect. Use the information given here only to give an idea of what to expect - but not a public offer! Accurate information about how the process will run for you personally, will only be information from your recruiter. The information may also become outdated - review Read the section How We Hire for current information at the time of reading the article).
First there will be several interviews through hangouts / meet. This is a full-fledged interview, as I said above - the engineers will be interviewed, and it is assumed that the candidate will “think out loud” + will write a dozen or two lines in any programming language (yes, unfortunately, in Google).
My interview is designed for ~ 45 plus or minus ten minutes, but usually I try to fit in exactly 45 minutes. From this time, five minutes for a brief acquaintance and general information, 30-35 minutes for questions and discussion, then five minutes for the candidate's questions (if any).
In general, the purpose of the interviewer is to collect information on several skill axes.candidate (such as the ability to code, knowledge of algorithms and data structures, etc.). But the most important thing in the interview is to find out how a person thinks. That is, it is always important to find the boundary when a person does not know the solution. Each interviewer has his own technique (especially for telephone interviews): someone keeps a dozen questions in store, from warm-ups (literally, writing a three-line cycle) to difficult questions to explain. Someone has 2-3 “favorite” questions, any of which can be turned in a dozen sides and both simplified and complicated - depending on what the interlocutor demonstrates. I am sure there are more options, but I do not know about them.
I tried both techniques, and I prefer the latter: depending on the candidate’s resume and self-assessment, I use a more appropriate form of the question. The question is always open (after all, when did you last see the exact problem statement in our industry?) And depending on what and how the candidate asks questions, I simplify or complicate the question so that by the end of the first about 10 minutes the candidate already wrote a trivial solution. It is rarely difficult, after all, a solution is trivial.
Questions are also trivially asked “why are you sure that it works?” (If the candidate did not immediately describe the limits of applicability or tests), and what is the complexity of the solution obtained. It simply gives information that the candidate knows how to code and understands what he wrote. But it’s not enough to code — you need to be able to think, so questions follow: how to get rid of restrictions? How to do better? Either (what happens when the candidate is very good or just knows the solution by experience) how to make the code work with these or other additional restrictions.
This gives a bunch of signals right away - how much does the candidate know how to adapt to changes in the task? And how ready is it to think about strongly alternative solutions? The discussion itself is also of interest - the question is always asked as openly as possible, therefore there are dozens of ways to understand it. Is the business environment being clarified, or only technical limitations? Are technical limitations taken into account? For example, several times it was that I said “expected 1e12 objects”, and the candidate does not estimate how much it is. And this is almost a terabyte, if byte per object. Or ~ 116.5 gigabytes per bit. Or 4.3 terabytes if int32. Well, you understand. No, it is not necessary to remember this - not on the exam, no one has selected the calculator. The phone is, yes, even in the search. And by the way, you can ask.
And this is how I will raise the complexity or simply modify the task for all available interview time. Yes, it is possible that for the interviewee this is the main working bread, and he eats such tasks for breakfast, lunch and dinner. Well, in this case
The most important thing here is to give at the same time a very simple task, so that the candidate can decide and show the basic skills, and raise the complexity to a level where the candidate does not know the answer, so that he can show how he thinks. If at the same time you can find a solution to a more complex task, this is excellent, but if the candidate could solve everything at all, then this is a person’s person’s puncture that he didn’t prepare a question of even greater complexity.
Want specifics? Here is one of the questions that you will NOT be asked simply because it is considered already “leaked” - that is, it is likely that the candidate will not think about him, but remember. As I wrote above, it is important how the candidate thinks, and not how he recalls ... So, the question is: implement LRU cache .
In general, the task is beautiful, as it allows many forms of tasks and many forms of interpretation. For example, you can ask a question straight in the forehead “implement LRU cache”. It can be formulated as “imagine that our service for processing a request checks the existence of an external object. How can we speed up the processing? ”- expecting a very obvious sentence“ let's just cache the result ”. What can you ask “how?”. And “what if we want to control the maximum memory consumed by this cache?”. The question leaves open - and which API should this cache provide. For simplicity, you can always reduce to set (key, value) + get (key); but you can add TTL. It is possible with get (key, fetch_func). In general, the evaluation of the proposed API can also give an additional signal about the experience and way of thinking of the candidate.
A trivial hashmap solution will give O (1) on get () + O (N) on set () (this is the same, right?). If all the elements are additionally linked (by creating a double link), it will be possible to obtain O (1) for both operations. If you need to add a TTL ... I think the idea is clear. If you wish, let's discuss in the comments: imagine what you asked this question, how will you think? what solution do you propose? ..
And in what programming language? Yes, what like, in which the most. C ++? Wonderful. Go? Wonderful. Python? You're welcome. Perl? Today is rare, but also yes. And Java, yes. And javascript (even though it’s harder considering the memory of the solution).
So, after about 40 minutes from the start of the interview, the thought flight of the candidate will be interrupted, but this does not mean that everything is bad. It just means time is up.
After the interview itself, the interviewer writes a report, often with a detailed transcript of what happened to the interview. This report will be used to make a decision. I personally reserve about an hour immediately after the interview, in order to record the full minutes of the conversation in fresh memory, some simply write on paper almost a complete transcript in the interview process.
After a telephone interview, on the basis of the reports of all the interviewees, a decision is made about inviting to a confrontation. It will be a full day of interviews in one of the offices: several interviews in the morning, then lunch (and getting to know the dining room in the office :) and then a couple more. When interviewing SRE, these will be different interviews, a list of which the recruiter will tell you, including coding and necessarily NALSD: Non-Abstract Large-Scale System Design. The key is non-abstract (that is, not the general words “we need a database”) and “large scale” (that is, if the base is needed, then for petabytes, for example). You can read more here and many more where to find materials in the search. I recruited a few links for training. This is a very important point of the interview - simply because working in a Google-sized company, you have to think and consider systems from such sides.
In general, an in-person interview is not much different from a telephone one — similar questions and a similar process. In doing so, we try to distribute the questions so as not to ask the same question twice.
What else can I add about the interview process? Have fun! No, seriously, relax and have fun! Telephone interview? Just a conversation with an interesting conversation partner. Guaranteed new information and new experience. Full-time interviews? More fun! You are on a business trip at the expense of the future employer :) Take a walk around the city, meet with friends. Also guaranteed a full day of entertainment and interesting conversations.
And after this day of fun, all those who interviewed you also write a report, with the full protocol of the conversation. All interview data is aggregated and reviewed by an independent committee.. This is important: none of those who know you personally, is not involved in the decision. None of those who interviewed - also does not participate directly. This is all aimed at eliminating bias in the decision. Evaluation is only for compliance with the required standard of the standard for hiring. If suddenly there is no luck, and you do not pass - you can always try again in a year. For this year, you can systematize your knowledge and fill in the gaps discovered.
Have any questions? Ask in the comments.
Any interest in trying out an interview before the interview? There are services for mock interview (for example, one and two , but they are not from the company itself, so there are no guarantees); Google sometimes runs similar campaigns.
And yes, do not be shyapply yourself. If you believe in the magic of “filing through an employee” - write to me, I will submit your application. Welcome!