Life at Google
2 HN recommenders · recommended in 4 months, 2017–2020
24:02 · 7.6M views · Nov 7, 2016
Two Google engineers perform a mock coding interview and then discuss best practices for candidates, including asking clarifying questions and communicating while solving.
Cited as a realistic, well-run example of a technical interview, both for candidates preparing and interviewers calibrating.
5 comments from Hacker News
Whether or not 'everyone' wants to work there is not hugely material. They, and others that do the white-boarding, are 'the best'. They have loads of talent, operational efficiency, ship tons of great products with great innovations. White-boarding done appropriately is an excellent means to develop an understanding of people's aptitudes in a short period of time. Here is an example of a Google white boarding interview, it's excellent in many ways: this video
'Ask clarifying questions' and 'think out loud' are also two of the suggestions in this excellent video from Google showing an example of a great technical interview: this video
"I personally don't recommend those kinds of companies " You wouldn't recommend Google, Microsoft, Facebook and a host of the best companies in the world because they do 'white board interviews'? You're not only working against the data here, you're working against reason: asking people to solve problems that they may encounter on the job is an excellent means of measuring a number of things, even beyond their ability to solve this problem. There are still quite a lot of 'senior engineers' who actually might be valuable in some specific circumstances, who can't walk through problems or write decent code at all. This example [1] from Google is really quite good. If you watch carefully you'll see how many elements and opportunities there are for a 'good developer' to shine both technically, and also in terms of communication. And also for 'ok developer' to just do an ok job. They're not asking bizarre or impossible to solve questions that you'd have to study for either. "That can be, especially for junior engineers." No, it's good to weed out 'senior engineers' who think that their experience and 'good relationships' entitle them to a job. "I don't want to burn myself out doing unpaid work" - an on-site bit of coding is not 'unpaid work' - please don't take this angle that your (or mine, or anyone else's) bit of quick hacky coding is 'work' that could be useful really in any way. This is different from a '2 hour but really 2 day' take home test which is ridiculous. "And yet I'v
Very good points, agree with it. However - I don't think this is about 'ego' or even 'humility' - I think those are not the right words. It's a lack of contextual understanding both in 'self awareness' and also the interviewers plight. I think the premise can be taught. Also, I think interviews can be structured to find qualities independant of background. + Questions that don't measure a person's ability to 'memorize algorithms' are a good start. + Allowing devs to pick their language of expression, i.e. sometimes they are more comfortable in one lang than another. + Don't get syntax/code structure confused with the abstract problem if that's what one is going for. Google has a nice interview example [1] + Open ended questions with many possible turns allow for a 'good' thinker to just go a lot further, and be more impressive while at the same time allowing junior devs to still walk through and complete something. The Google example is again good here. + Time/on the spot - one of the worst issues. Personally I'm about 50/50. Sometimes 'in the flow' sometimes 'not', but surely just given a little bit fo time, I'd be fine on most things. For this reason, giving interviewees an intro to the problems, and giving them as much time as they want to think about them before the interview starts, might be worthwhile as well. 'Let us know when you want to go over a solution'. This could work well for pedantic things such as 'here's some code, find some bugs' or 'how would you structure
I just went through a round of interviews and came away with a better opinion of these "toy" interviews than I started with[1], so I'll play devil's advocate here: these questions have a place. The main reason to use these questions is that they're studyable. Google and Facebook both put out content that walk you through how to solve problems like this. When you get an interview, you can delay it as long as you want, they can tell you the sort of problems to study: go read "Cracking the Coding Interview". Facebook sends you a link to it and a video of the author working a problem. Google sends you stuff like this video . There are thousands of toy questions, and it's not feasible to memorize them all. The correct _and expected_ thing to do is study up for the category. Now that your candidates have in theory studied, you'll get a studied, "best" performance for each candidate, and interview outcomes can be compared in a very low-bias, apples-to-apples way. I can't imagine the success criteria for a pairing being clearer than for toys. I think the potential for toy question interviews to be managed in a low-bias way is the main reason they're used. In comparison, how do you ensure that your exercise in go is exactly as hard as your exercise in Java? Or do they need to know go, or some other language? Or that they didn't spend longer on the take home than you asked? Or 100 other factors of your particular exercise? It's really hard to let every candidate shine on a level playing f