Most successful students would not consider taking a final exam without preparation. For students—undergraduate and graduate—about to head into industry, job interviews benefit from the same level of consideration. There are many books and articles on interview skills, and most academic career centers offer additional training. What this article covers is more specific: A highlevel view of Google’s engineering interviews.
The interview process at Google has been designed (and redesigned!) from the ground up to avoid false positives. We want to avoid making offers to candidates who would not be successful at Google. (The cost of this unfortunately includes more false negatives, which are times when we turn down somebody who would have done well.) The recruiters and engineers you will speak with want to see where you shine, whether you can do the job, and make sure you’re someone they want to work with. This article is designed to help both you and Google achieve those goals—and help the interview be an interesting, even pleasant, experience, too.
You will meet at least two types of Googlers (Google employees) in the interview process. The first are our recruiters. Recruiters are nontechnical employees who are experts at both finding candidates and helping them through the interview process. The second are our technical interviewers; they are fulltime engineers who volunteer to help with the hiring process by interviewing candidates like you. All of our Googlers come from academic backgrounds and from industry, and can answer most (if not all) of the questions you might have, including whether Google is likely to be a good fit for you. So please ask away!
There is a standard format for most technical interviews. (Ph.D. students and more experienced candidates may be given one additional interview with a slightly different format, but similar advice applies.) For about 45 minutes you meet with a single technical interviewer, who will present a programming problem and ask you to work out one or more solutions to it. In some interviews, you will be asked to code up one of your solutions on a whiteboard. All of our questions have multiple solutions, and some of our questions do not have a single best answer, so if you have more than one solution, explain the tradeoffs or the benefits of your preferred solution.
Each interview day will have up to five of these 45-minute interviews, depending on your schedule, proximity to the nearest office, and interviewer availability. Candidates living farther away may start with phone interviews before proceeding to an onsite interview. The types of interviewers and which questions they ask are the same in both cases.
“Overall, the interviewers are simply trying to decide one thing: Would you be a good fit for Google?”
Let’s break down a typical interview, piece by piece.
The programming problems are not “trick” questions, but they will always have aspects that require care and attention. First, make sure you understand the problem properly. It helps to clarify assumptions before diving in too deeply, and if you are confused about the question, do ask for examples, or for the question to be reworded. The interviewer will often not offer information until you ask for it. “How big could the input be?” “What happens with bad inputs?” and “How often will we run this?” are three common clarifications. If you’re stuck, one thing to do is recheck your assumptions.
After you have the clarifications that you need, dive into solving the problem. There are usually several paths to a good solution. Much like math homework, it is essential to show your work; the way to do this is to talk to the interviewer, and explain what you are thinking. This is easy for some of us, but really hard for others, so it is important to practice this skill. If narrating your entire thought process will significantly reduce your ability to think on your feet, it is OK to be quiet for a minute or two—but then tell the interviewer what you considered, and why you chose what you chose. The more you can communicate your thought process, the better. If this might be hard for you to do, it is definitely worth practicing with a friend.
Feel free to give answers you know are imperfect; explain briefly why they are not the best answer, and keep going. The first solution is rarely the best, and a sequence of answers very clearly shows your thought process toward solving the problem. It is also fine to start with a brute-force approach, as it gives an initial benchmark for the answers that follow. One trap to avoid is getting stuck thinking about incremental improvements to the worst algorithm; sometimes you will need to leap to another approach.
Ver el articulo completo en http://dl.acm.org/ft_gateway.cfm?id=2539270&ftid=1416475&dwn=1&CFID=390846601&CFTOKEN=61297826
Debes estar registrado para responder a este debate.
matiasmasca empezó el debate #ARG Hiring Tournament for Software Engineering managers PHP and Ruby on Rails en el foro JobPosting & RRHH hace 2 meses
Staff Difusion empezó el debate Oferta Laboral Desarrollador PHP Full-time, part-time o remoto en el foro JobPosting & RRHH hace 2 meses, 1 semana
admin empezó el debate Instructores para diferentes modulos del curso de programación 111mil en el foro JobPosting & RRHH hace 5 meses, 3 semanas
empezó el debate Corrientes / Resistencia – Redes e infraestructura en el foro JobPosting & RRHH hace 1 año