3:44 General attitude - Don't try to defeat the candidate - Don't judge the candidate on unrelated things - Tell the candidate that's what's going to happen, days in advance 13:51 The beginning of the interview - Use the same questions for each candidate - Start open-ended and uncontroversial - Seek evidence - Avoid making the candidate feel like a failure - If you're expecting the candidate to say something negative about themselves, or your company, tell the candidate it's ok 23:40 The coding questions - Avoid "implement this popular algorithms" - Try to find something real world - Try to find something with multiple phase - Allow them to use their laptop - Try not to assess too much at once 35:40 Say goodbye to candidate - Rate candidates on what happens in the interview - Write your assessment straight afterwards - Write your conclusion before discussing the interview with others Thank you guys for sharing these practical and useful advices about interviewing, great topic! This video directly help me build more concrete and structured interview. I also learned a lot of best practices from hiring guides on re:Work website. I really like your empathy and generous attitude towards candidates. You face the inevitable unfairness and bias frankly in the interview process, strive to use good ways and attitudes to ensure fairness, and let candidates have a good and comfortable interview experience regardless of the final result. Looking forward to seeing more HTTP 203 videos discussing other hiring topics.
I was expecting one more subject from this video: for me, the worst part is not getting any feedback, like Google does. You spend hours or even months preparing. Some people buy books and courses on "how to invert binary trees". Then, even if the interviewer does not provide you any sign of failure during the interview, you may receive an automatic message about being rejected. So, without a clue on what to improve, they tell you they hope you apply again in the future.
The best interview is when the candidate can show their best, not even necessarily in that particular field you are looking for. Good people and good skills are scarce, it's best not to overshadow them with our expectations.
Just a nitpick: regarding the topic around 8:55, while correlation != causation is of course correct, in this particular case nobody's claiming there to be causation to begin with. Correlation here is enough for, hypothetically, "bad syntax highlighting" to be a reason not to hire a person (if there really was a strong correlation between that and job performance). This does not depend on the choice of syntax highlighting *causing* the bad performance, or vice versa. Because we're not looking for interventions of any kind here, but just for evidence. That being said, the main argument mentioned, along the lines of "you don't need to rely on such proxies as you can actually *test* the people's performance *directly*", is indeed a good one of course.
I can fully empathise with the story of sweating and then stressing about sweating making it continue, which makes you distracted from the task at hand. Thank you so much for taking that into account with that candidate’s interview
Thank you so much. Like really, thank you. Conducting interviews is one of the least talked about topic when it comes to create a company, and is one of the most people get it wrong. I'm taking notes as I'm close to make my first hire.
I'm here to supply insider reporting about the balloon : Once there was desk move at the office. Jake claimed the balloon as personal belongings by putting move sticker, AND SO, MOVERS MOVED IT TO NEW DESK.
Really mature suggestions from you guys. The sad reality is that interviewing is given short shrift by many companies despite the fact that interviewing is a skill like any other. I've never understood why companies expend such little energy on a process that is possibly more impactful on the company's success than anything else they do. And that's to say nothing of interviews that feel like hazing sessions. Glad you guys posted this, and I hope companies are listening because they often shoot themselves in the feet simply because they aren't giving enough thought to this important process.
I've found that recording interviews is super useful, facilitated by lockdown. * Allows me to double check whether my memory serves me correctly. * Allows a second interviewer to give a second opinion. * Allows me to review their code again. * Allows me to time how long it takes the candidate to do certain things. * The candidate and I are less distracted by note taking. I obviously ask if it's okay first.
About to make an interview at my current company and stumbled upon this video in preparation for it. Thank you a lot for making this! It's really helpful. :)
These ones: ua-cam.com/video/W6lvQvdeF8U/v-deo.html But seriously, my favourite questions are like the "fetch and display data" one I went through in this video. I see a lot of "JS interview questions" lists and they're all about edge cases in the language. I don't find that interesting, because it doesn't tell you anything about how the candidate approaches problem solving. I might ask a question about JS closures, but in that case I'd be focusing on the communication side - can the candidate explain this kind of stuff to people they might be mentoring, or other developers (if it's a dev-rel role).
Coding tasks assigned outside of uniform interview time slots discriminate against those with greater family/life commitments (often older candidates with less free time). A friend of mine recently withdrew from a job application after being assigned a pre-interview coding challenge based on an existing two-year old problem in a real production repo. Because candidates were given a week, they were effectively free to knock themselves out for the entirety of that period in a race-to-the-bottom producing free work.
My interviewees nowadays get to work on assignment they submitted. They explain a little what they did, take small requirements and do it on the fly. Googling is allowed, I too help, and it's like I check how will they perform their job if they are selected and get to know about what they know, how they know
I've actually been collecting frontend interview questions. I was trying to find examples that are simple to implement, but ones that let the candidate add more features and show off if they'd like. Some fantastic advice in this one!
I learned a few practical tips from this-transforming the "implement this algorithm" problem into a real world example without first stating the algorithm is a good one. But there were also some great reminders about how important empathy is during interviews. Thanks!
I've done countless of interviews that included whiteboard and/or code challenges and never found a good question or challenge which actually provided interviewer any useful information about their candidates. I now work for a company which does away with these and instead asks for a case study with questions such as about a feature in an existing product, asking how that feature could be implemented or changed in a technical way, questions about code quality and practices they would apply in different scenarios, as well as questions about work-life balance. These studies should only take 2-3 hours to complete, unless the candidate feels they need more time, but we give them multiple days to prepare. This gives the candidate time to think about their approaches to questions and often provides a better insight into their experience and their thought process and how they communicate that. Problem solving may be important for some positions and companies, it highly depends. But the case studies, which also are transparent and shared with the team allows us to understand our individual mindset on things and where our strengths and weaknesses are; this have made communication much better in less time and without stigma.
Heh, I probably used more notes than usual in this one, because I didn't have slides as prompts. We never script, but the main presenter (me in this episode) will create the slides and notes, whereas the other person (Surma in this episode) is just improvising to the content. We don't show each other the content in advance. Although, we ended up filming the last WebAssembly episode three times due to technical difficulties, so my reactions there were a little fake, as I was trying to remember how I reacted the first time around.
You should show this video to other Google employees who do interviews....I've been to so many interviews where the interviewer is aggressive, that I just refuse approaches from Google.
Ugh, I'm sorry you experienced that. I realise that the advice I'm giving here isn't followed by everyone at Google. I've been trying to push for change on this, but… big company.
I love watching videos from you two, keep up the good work! I also may have done someone dirty on an interview by not following the first tip so... sorry that guy 😅
This was great, thanks. Yoshimi Battles the Pink Robots 🤖 You implicitly touched on a few things multiple times related to visual/cognitive disabilities like Dyslexia. Some candidates may struggle with memory recall or new/unfamiliar visual environments like Google Docs. Allowing them to use their own environment can really help them shine and succeed.
Wow, if only interviews are conducted with such insights. But then again you need to have those insights in the first place. Which means, most interviewers don’t work on their approach thinking they are doing it right , when in fact it’s bad for both parties.
Is inverting binary trees something that regularly happens? I don't know if I've ever used a binary tree straight up, let alone needed to invert it. Now, formating numbers to strings, there's a sucking well of endless potential improvement that I keep running into the edge cases of...
I'm going to have interview with Google as a front-end SWE. I'm asked to have 2 more rounds of interview just focused on JavaScript. But I asked many people - Google seems to have no clear guidance or scope of this kind of interview, comparing to Algorithm & DS interviews.
I'm by no means a great interviewer, it doesn't come to me naturally. But I've found that, after introducing each other, these 4 questions go a long way to determining if the person if a good fit: 1) What do you consider to be your strengths and weaknesses? 2) What do you do outside of work hours, interests, hobbies, etc? 3) Can you send me a sample of code that you have written? 4) Do you have any questions for me? Question 1 helps determine character. Do they spend too long on the strengths and have a hard time listing any weaknesses? They could be proud and difficult to work with. Do they spend too much time on weaknesses and little on strengths? They could unsure of themselves and unable to complete work without significant input. The balance is somewhere in between. Someone who knows what they can do well and what they can't do. Also, i they mention what they are doing to address those weaknesses, that helps determine if they are self motivated. Question 2 helps determine if they are interested in their craft, or if programming is just a job for them. It's great for candidates to be involved in sports, biking, mountain climbing, sailing, snowboarding, etc... but if a candidate doesn't spend some time outside of work to learn new things in the software engineering space, they will fall behind. I tend to look for people who explore things outside of work. They can then bring these learnings to work and help to improve the product. Question 3 is my way of replacing whiteboard tests and homework tests. In my experience, those things just don't work well. Instead, I ask for a sample of what they consider to be the "best" code they have already written. This might be from a public/private github repo, or a zip file of a project they've been working on locally. You can tell a lot about a person by the quality of their personal projects. Someone who writes good code even when no one else will see it will write good code at other times. If they don't have something they can show me, that's usually a sign they don't take time to learn outside of work. But I'll offer them the opportunity to go away and work on something of their choosing to send back. Question 4 is a good indication if they are interested in the position at the company, or just want a job. A good candidate will apply because they like the company and it's product, and feel they can contribute to it. Such candidates usually come prepared with questions about engineering process, team dynamic, future plans, etc. It's not just about finding the right person for the job, but finding the right job for the person. In my experience, someone who comes in unprepared just wanting any work becomes disinterested within 6 months, and leaves within the year. It's not fair on either party. Anyway, I hope my rambling made some sense.
I think question 1 is tricky. "They could be unsure of themselves" - yes, especially in an interview situation, but that might not reflect their approach to a coding problem. I know a lot of people who are not self-confident, but they are confident in their work. Like we discussed in the video, this seems like a proxy metric. Instead, test the thing you're wanting to test. Question 2 doesn't matter. You shouldn't expect your employees to work outside of work hours. Again, you're using a proxy metric. Don't do this. You're wanting to test "will this employee fall behind", and "do they work outside of hours" is a bad way to measure that. If their current knowledge is modern, then that suggests they're not falling behind, right? In fact, when I was interviewing for jobs, I'd ask "if your staff are working out of hours, does this highlight a failure in task planning, or is it just expected?" If the employer said it was expected, I wouldn't work there. If the employer said their staff don't work out of hours, then they're probably lying, or unaware, so it's a red flag. The correct answer is that employees shouldn't have to work outside of contracted hours (else their contract is wrong), but it can happen due to planning errors and unexpected events, and employees are compensated for that in some way (either pay, or time off in lieu). 3 is ok, although it isn't always clear what their involvement was in the project, and which problems _they_ had to solve. Providing examples of work is also tough if the candidate currently works in a closed source / confidential system. And again, you shouldn't expect the candidate to have personal projects. With question 4, again this seems like a proxy metric. If you want to test their interest in the company, then ask what they'd like to change to improve the company. This will show that they have some knowledge about the company's current situation, and that they've thought about ways to improve it.
Please enable nearby share on chrome. It is so useful. I don't wanna connect my phone to laptop via cable every time I want to transfer a picture, video or larger files.
Many people hate on algorithm questions. In my experience, easy to medium (leetcode level) questions can, on occasion, produce false negatives and yes, they aren't particularly representative of the job. However, people who do great on these questions are virtually never bad engineers. Therefore algorithms questions are a great coarse filter.
I strongly disagree on it being a great coarse filter. Even if it was true that people who do well are good engineers (I doub that!), that doesn’t mean that you are not missing out on great talent. I know a whole bunch of talented and respected engineers who say themselves that they do horribly in interviews.
30:12 "How do you generate a random number between A and B?" I would clearly assume that you can't a library function because that would be too easy... so it would be quite difficult
@@snapstromegon Ah yes, I'm a main python developer and the question didn't make senses for me because you can just do "randint(a, b)" or "randrange(a, b)". I would assume the person is asking me to program an RNG.
@@sirk390 Yeah, I am speaking as a web developer here and I am assuming the candidate chose JavaScript. But I also ask the question if the candidate uses C# or Python, and using `randint(a, b)` is absolutely valid.
Nice to have a longer video! 🎈 Do you ask about / look at hobby projects? On the one hand I think it's unfair to /expect/ someone to spend their free time coding, but it is an opportunity to see how they code 'naturally'.
If I find out a company wants me to do a live coding exercise or timed exercise, I turn down the interview and move on. I don't want to work for companies that think like that anyway.
Entirely up to you. However, I've interviewed plenty of people who can talk the talk but simply cannot code. I think it's fair to test candidates on the skills they'll need for the role.
I have heard that there are millions of people applying to Google each year. If that is true, you could make whatever interview you want, as hard questions you want as you would get a person answering all of them correctly sooner or later by pure chance ;)
Thanks guys, for highlighting these points. One question, if a candidate has not switched on his camera, do you continue to interview the person or ask him to first switch on his/her webcam and then proceed with the interview.
I haven't been in this situation. No-camera seems fine for the first round of interviews (as long as the candidate can share their screen). I'm not sure about final rounds. I guess I'd want to know why the webcam was off, especially if the role was customer facing.
Super interesting 🎈 and I like the idea of giving feedback/guidance during the coding question because a single question could be overwhelming and you may not know where to begin. I used to let interviewees complete a 30 min task in their own time and used PRs for feedback, but live coding gives the interviewer more feedback. Do you still hire or recommend someone for hire if they fail the coding questions but excelled in the discussion or vice-versa?
Ratings probably shouldn't be pass/fail. If the candidate is weaker on code vs communication, or vice-versa, the role needs to be taken into account. If it's a communication-heavy role, then maybe there's some wiggle room when it comes to coding skill. At Google, we can also recommend candidates for a different role.
What advice would you give for avoiding gender / sexual orientation / racial biases in tech interviews (e.g. forbidden questions, assessment criteria, screening faux-pas)?
🎈100% agree and hope this becomes more common in companies....in the meantime, is there a specific Google dept. or team that shares this mentality and also is hiring a front end engineer ? :p Also, do you recommend devs go out of their way to make portfolios of their incomplete side projects or is a resume enough these days? Most of my GitHub is private (that nagging thought that your code isn’t clean enough for public scrutiny)
I don't know the interview strategy of all the teams in the company, unfortunately. Candidate selection is done before I get involved, so I don't have much recent insight there, but when I was involved in that, I valued work examples over a statement of expertise. However, I realise not everyone can share work examples openly.
I hate interview bullies. I also hate remote interview cheats. Somone actually copy paste code and pretend it's theirs. I search google all day. But give credit to the source.
Thanks guys for such a great video. One question, I have posted my CV at google multiple times but never heard back, can you please suggest what google looks for in the candidate? I am good at javascript. Is there something i should know along js to be at google?
I heard/read that interviews are practically useless. People looked at how employees were doing that were hired based only on a CV and those that were also interviewed and there was no significant difference. Given how often you can read about just how awful interview practices are, that does not surprise me. So this finding is probably not true in all cases, but might be more applicable than people realize. Interviews do not strike me as being effective at getting the kind of information you really need, a key one simply being the ability to work well in a team.
Awesome video, I would like to share my interview questions with you... would be a big help if you could share your insights to make my process better 😇
The horror stories I read crushed my dreams from when I was a kid of working at Google, things like whiteboards and asking theoretical questions. Total turn-off. If I were to have interviews like you guys describe them, I would consider Google again.
I interviewed for Google 8 years ago, and the theoretical questions were long-gone by then. However, I did have to code on a whiteboard, which is why I won't put anyone else through that 😀
Ohh I kinda do too, but only the rubber ones, and only if they're potentially popping. Like, if someone's squeezing the balloon in their hand… stresssss
@@jakearchibald Ok. Interesting. I was working as recruiter many years ago.......And companies in DACH wants most of the time - not older than 30! That was the rule. (for IT developers!) I am older so i dont agree anymore. 😀
Knowing the names of algos but not knowing how they work is like testing breadth of the knowledge than depth, which can end up where candidate is just a trend follower, i think the proper balance is depth in what they know and breadth in what you ask them..
I seriously do hope more companies watch this video.
3:44 General attitude
- Don't try to defeat the candidate
- Don't judge the candidate on unrelated things
- Tell the candidate that's what's going to happen, days in advance
13:51 The beginning of the interview
- Use the same questions for each candidate
- Start open-ended and uncontroversial
- Seek evidence
- Avoid making the candidate feel like a failure
- If you're expecting the candidate to say something negative about themselves, or your company, tell the candidate it's ok
23:40 The coding questions
- Avoid "implement this popular algorithms"
- Try to find something real world
- Try to find something with multiple phase
- Allow them to use their laptop
- Try not to assess too much at once
35:40 Say goodbye to candidate
- Rate candidates on what happens in the interview
- Write your assessment straight afterwards
- Write your conclusion before discussing the interview with others
Thank you guys for sharing these practical and useful advices about interviewing, great topic! This video directly help me build more concrete and structured interview. I also learned a lot of best practices from hiring guides on re:Work website.
I really like your empathy and generous attitude towards candidates. You face the inevitable unfairness and bias frankly in the interview process, strive to use good ways and attitudes to ensure fairness, and let candidates have a good and comfortable interview experience regardless of the final result.
Looking forward to seeing more HTTP 203 videos discussing other hiring topics.
Thanks for writing up these notes!
👍🏻👍🏻👍🏻
I was expecting one more subject from this video: for me, the worst part is not getting any feedback, like Google does.
You spend hours or even months preparing. Some people buy books and courses on "how to invert binary trees".
Then, even if the interviewer does not provide you any sign of failure during the interview, you may receive an automatic message about being rejected.
So, without a clue on what to improve, they tell you they hope you apply again in the future.
The best interview is when the candidate can show their best, not even necessarily in that particular field you are looking for.
Good people and good skills are scarce, it's best not to overshadow them with our expectations.
Just a nitpick: regarding the topic around 8:55, while correlation != causation is of course correct, in this particular case nobody's claiming there to be causation to begin with. Correlation here is enough for, hypothetically, "bad syntax highlighting" to be a reason not to hire a person (if there really was a strong correlation between that and job performance). This does not depend on the choice of syntax highlighting *causing* the bad performance, or vice versa. Because we're not looking for interventions of any kind here, but just for evidence.
That being said, the main argument mentioned, along the lines of "you don't need to rely on such proxies as you can actually *test* the people's performance *directly*", is indeed a good one of course.
I can fully empathise with the story of sweating and then stressing about sweating making it continue, which makes you distracted from the task at hand. Thank you so much for taking that into account with that candidate’s interview
Thank you so much. Like really, thank you. Conducting interviews is one of the least talked about topic when it comes to create a company, and is one of the most people get it wrong. I'm taking notes as I'm close to make my first hire.
8hi
U8
I'm here to supply insider reporting about the balloon : Once there was desk move at the office. Jake claimed the balloon as personal belongings by putting move sticker, AND SO, MOVERS MOVED IT TO NEW DESK.
This is true.
Hey, the instructions were "do not attempt to move anything to the new desk yourself", and the award balloon is a subset of "anything"
Really mature suggestions from you guys. The sad reality is that interviewing is given short shrift by many companies despite the fact that interviewing is a skill like any other. I've never understood why companies expend such little energy on a process that is possibly more impactful on the company's success than anything else they do. And that's to say nothing of interviews that feel like hazing sessions.
Glad you guys posted this, and I hope companies are listening because they often shoot themselves in the feet simply because they aren't giving enough thought to this important process.
I've found that recording interviews is super useful, facilitated by lockdown.
* Allows me to double check whether my memory serves me correctly.
* Allows a second interviewer to give a second opinion.
* Allows me to review their code again.
* Allows me to time how long it takes the candidate to do certain things.
* The candidate and I are less distracted by note taking.
I obviously ask if it's okay first.
@Koopa never
Can you do a video on code reviews, please?
About to make an interview at my current company and stumbled upon this video in preparation for it.
Thank you a lot for making this!
It's really helpful. :)
Jake share your list of fav JS questions 🎈
These ones: ua-cam.com/video/W6lvQvdeF8U/v-deo.html
But seriously, my favourite questions are like the "fetch and display data" one I went through in this video. I see a lot of "JS interview questions" lists and they're all about edge cases in the language. I don't find that interesting, because it doesn't tell you anything about how the candidate approaches problem solving. I might ask a question about JS closures, but in that case I'd be focusing on the communication side - can the candidate explain this kind of stuff to people they might be mentoring, or other developers (if it's a dev-rel role).
Coding tasks assigned outside of uniform interview time slots discriminate against those with greater family/life commitments (often older candidates with less free time). A friend of mine recently withdrew from a job application after being assigned a pre-interview coding challenge based on an existing two-year old problem in a real production repo. Because candidates were given a week, they were effectively free to knock themselves out for the entirety of that period in a race-to-the-bottom producing free work.
My interviewees nowadays get to work on assignment they submitted. They explain a little what they did, take small requirements and do it on the fly. Googling is allowed, I too help, and it's like I check how will they perform their job if they are selected and get to know about what they know, how they know
2:50 The balloon: "Why are we still here? Just to suffer?"
0:28 and I am still here... Good going Me!
I've actually been collecting frontend interview questions. I was trying to find examples that are simple to implement, but ones that let the candidate add more features and show off if they'd like.
Some fantastic advice in this one!
Thanks to both of you for a great video .. trying to not lose complete hope in myself to one day get a developer job 🎈
Cheers! And hey, I've failed many interviews. Sometimes the interview was bad, sometimes I messed up. It happens.
I learned a few practical tips from this-transforming the "implement this algorithm" problem into a real world example without first stating the algorithm is a good one. But there were also some great reminders about how important empathy is during interviews. Thanks!
I've done countless of interviews that included whiteboard and/or code challenges and never found a good question or challenge which actually provided interviewer any useful information about their candidates.
I now work for a company which does away with these and instead asks for a case study with questions such as about a feature in an existing product, asking how that feature could be implemented or changed in a technical way, questions about code quality and practices they would apply in different scenarios, as well as questions about work-life balance. These studies should only take 2-3 hours to complete, unless the candidate feels they need more time, but we give them multiple days to prepare.
This gives the candidate time to think about their approaches to questions and often provides a better insight into their experience and their thought process and how they communicate that.
Problem solving may be important for some positions and companies, it highly depends. But the case studies, which also are transparent and shared with the team allows us to understand our individual mindset on things and where our strengths and weaknesses are; this have made communication much better in less time and without stigma.
🎈 I don't know how much typical episodes are scripted but this episode felt a lot more freeform and I definitely liked the casual feel a lot more.
Heh, I probably used more notes than usual in this one, because I didn't have slides as prompts. We never script, but the main presenter (me in this episode) will create the slides and notes, whereas the other person (Surma in this episode) is just improvising to the content. We don't show each other the content in advance. Although, we ended up filming the last WebAssembly episode three times due to technical difficulties, so my reactions there were a little fake, as I was trying to remember how I reacted the first time around.
You should show this video to other Google employees who do interviews....I've been to so many interviews where the interviewer is aggressive, that I just refuse approaches from Google.
Ugh, I'm sorry you experienced that. I realise that the advice I'm giving here isn't followed by everyone at Google. I've been trying to push for change on this, but… big company.
I love watching videos from you two, keep up the good work! I also may have done someone dirty on an interview by not following the first tip so... sorry that guy 😅
I've done most of the bad things I mentioned too. Don't beat yourself up about it, just do it better next time 😀
This was great, thanks. Yoshimi Battles the Pink Robots 🤖
You implicitly touched on a few things multiple times related to visual/cognitive disabilities like Dyslexia. Some candidates may struggle with memory recall or new/unfamiliar visual environments like Google Docs. Allowing them to use their own environment can really help them shine and succeed.
I watch it before I start a round of interview.
The binary tree example at 25:45 is a really good point.
Very interesting topic!
Wow, if only interviews are conducted with such insights. But then again you need to have those insights in the first place. Which means, most interviewers don’t work on their approach thinking they are doing it right , when in fact it’s bad for both parties.
Worked at Nike and had a prospective candidate show up in Adidas clothing XD. That one was harder to overlook
Nice! We use a shared code instance to run the code, which makes things much easier than docs / whiteboarding
Although not code specific, this video is 100% google.
went into this thinking it would be advice from the other perspective, but still watched it all anyway haha
I feel I became a lot better at being interviewed once I started conducting interviews myself.
Would love to get in a mock interview with these two or either of them. 😃
hmm nah - what would i do if they actually offer me a job ?
@@jonathan-._.- Oh yeah have not thought of it. But even if they offer, I am in Asia. So chances of me working with them is very less. 😃
Is inverting binary trees something that regularly happens? I don't know if I've ever used a binary tree straight up, let alone needed to invert it.
Now, formating numbers to strings, there's a sucking well of endless potential improvement that I keep running into the edge cases of...
man i wish i could get someone like them as an interviewer
I'm going to have interview with Google as a front-end SWE. I'm asked to have 2 more rounds of interview just focused on JavaScript. But I asked many people - Google seems to have no clear guidance or scope of this kind of interview, comparing to Algorithm & DS interviews.
I may not have a balloon, but I have conducted hundreds of interviews and I can say that this is great advise!
I'm by no means a great interviewer, it doesn't come to me naturally. But I've found that, after introducing each other, these 4 questions go a long way to determining if the person if a good fit:
1) What do you consider to be your strengths and weaknesses?
2) What do you do outside of work hours, interests, hobbies, etc?
3) Can you send me a sample of code that you have written?
4) Do you have any questions for me?
Question 1 helps determine character. Do they spend too long on the strengths and have a hard time listing any weaknesses? They could be proud and difficult to work with. Do they spend too much time on weaknesses and little on strengths? They could unsure of themselves and unable to complete work without significant input. The balance is somewhere in between. Someone who knows what they can do well and what they can't do. Also, i they mention what they are doing to address those weaknesses, that helps determine if they are self motivated.
Question 2 helps determine if they are interested in their craft, or if programming is just a job for them. It's great for candidates to be involved in sports, biking, mountain climbing, sailing, snowboarding, etc... but if a candidate doesn't spend some time outside of work to learn new things in the software engineering space, they will fall behind. I tend to look for people who explore things outside of work. They can then bring these learnings to work and help to improve the product.
Question 3 is my way of replacing whiteboard tests and homework tests. In my experience, those things just don't work well. Instead, I ask for a sample of what they consider to be the "best" code they have already written. This might be from a public/private github repo, or a zip file of a project they've been working on locally. You can tell a lot about a person by the quality of their personal projects. Someone who writes good code even when no one else will see it will write good code at other times. If they don't have something they can show me, that's usually a sign they don't take time to learn outside of work. But I'll offer them the opportunity to go away and work on something of their choosing to send back.
Question 4 is a good indication if they are interested in the position at the company, or just want a job. A good candidate will apply because they like the company and it's product, and feel they can contribute to it. Such candidates usually come prepared with questions about engineering process, team dynamic, future plans, etc. It's not just about finding the right person for the job, but finding the right job for the person. In my experience, someone who comes in unprepared just wanting any work becomes disinterested within 6 months, and leaves within the year. It's not fair on either party.
Anyway, I hope my rambling made some sense.
I think question 1 is tricky. "They could be unsure of themselves" - yes, especially in an interview situation, but that might not reflect their approach to a coding problem. I know a lot of people who are not self-confident, but they are confident in their work. Like we discussed in the video, this seems like a proxy metric. Instead, test the thing you're wanting to test.
Question 2 doesn't matter. You shouldn't expect your employees to work outside of work hours. Again, you're using a proxy metric. Don't do this. You're wanting to test "will this employee fall behind", and "do they work outside of hours" is a bad way to measure that. If their current knowledge is modern, then that suggests they're not falling behind, right?
In fact, when I was interviewing for jobs, I'd ask "if your staff are working out of hours, does this highlight a failure in task planning, or is it just expected?" If the employer said it was expected, I wouldn't work there. If the employer said their staff don't work out of hours, then they're probably lying, or unaware, so it's a red flag. The correct answer is that employees shouldn't have to work outside of contracted hours (else their contract is wrong), but it can happen due to planning errors and unexpected events, and employees are compensated for that in some way (either pay, or time off in lieu).
3 is ok, although it isn't always clear what their involvement was in the project, and which problems _they_ had to solve. Providing examples of work is also tough if the candidate currently works in a closed source / confidential system. And again, you shouldn't expect the candidate to have personal projects.
With question 4, again this seems like a proxy metric. If you want to test their interest in the company, then ask what they'd like to change to improve the company. This will show that they have some knowledge about the company's current situation, and that they've thought about ways to improve it.
Yeah you're right it doesn't matter how they set up syntax highlighting in their editor as long as their editor is vim
Yes, my abilities are in problem solving, not memorisation. Give me a hard problem that I can solve using Google and Intelisense.
Please enable nearby share on chrome. It is so useful. I don't wanna connect my phone to laptop via cable every time I want to transfer a picture, video or larger files.
Many people hate on algorithm questions. In my experience, easy to medium (leetcode level) questions can, on occasion, produce false negatives and yes, they aren't particularly representative of the job. However, people who do great on these questions are virtually never bad engineers. Therefore algorithms questions are a great coarse filter.
I strongly disagree on it being a great coarse filter. Even if it was true that people who do well are good engineers (I doub that!), that doesn’t mean that you are not missing out on great talent. I know a whole bunch of talented and respected engineers who say themselves that they do horribly in interviews.
30:12 "How do you generate a random number between A and B?" I would clearly assume that you can't a library function because that would be too easy... so it would be quite difficult
Wouldn't it just be A + Math.random() * (B-A)?
Assuming JS I think calling Math.random is considered a language feature and not a library.
@@snapstromegon Ah yes, I'm a main python developer and the question didn't make senses for me because you can just do "randint(a, b)" or "randrange(a, b)".
I would assume the person is asking me to program an RNG.
@@sirk390 Yeah, I am speaking as a web developer here and I am assuming the candidate chose JavaScript. But I also ask the question if the candidate uses C# or Python, and using `randint(a, b)` is absolutely valid.
Nice to have a longer video! 🎈
Do you ask about / look at hobby projects? On the one hand I think it's unfair to /expect/ someone to spend their free time coding, but it is an opportunity to see how they code 'naturally'.
I might ask about hobbies just for small talk, but I don't take it into consideration. If they do zero coding outside of work, that's fine by me.
Excellent points. But as interviewee, I am going to hate myself afterwards anyway :)
If I find out a company wants me to do a live coding exercise or timed exercise, I turn down the interview and move on. I don't want to work for companies that think like that anyway.
Entirely up to you. However, I've interviewed plenty of people who can talk the talk but simply cannot code. I think it's fair to test candidates on the skills they'll need for the role.
I have heard that there are millions of people applying to Google each year.
If that is true, you could make whatever interview you want, as hard questions you want as you would get a person answering all of them correctly sooner or later by pure chance ;)
Good one i think all interviewers should watch this
Best. Interview-related. Video. Ever.
Smart advices, thank you.
Awesome topic ❤️
Very good stuff.
Great ideas 💡
Great videos as usually guys!
Could someone please explain me how can I get the"Assets" folder to improve the performance of the site?
Thanks guys, for highlighting these points.
One question, if a candidate has not switched on his camera, do you continue to interview the person or ask him to first switch on his/her webcam and then proceed with the interview.
I haven't been in this situation. No-camera seems fine for the first round of interviews (as long as the candidate can share their screen). I'm not sure about final rounds. I guess I'd want to know why the webcam was off, especially if the role was customer facing.
What's the deal with that inverted binary tree?
Never heard of it, is it in any way useful ?
Hi Jake Can you please give us some Tips to get selected in Resume Round for google
I'm not involved in that part of the process so I don't have any insight to offer
Super interesting 🎈 and I like the idea of giving feedback/guidance during the coding question because a single question could be overwhelming and you may not know where to begin. I used to let interviewees complete a 30 min task in their own time and used PRs for feedback, but live coding gives the interviewer more feedback.
Do you still hire or recommend someone for hire if they fail the coding questions but excelled in the discussion or vice-versa?
Ratings probably shouldn't be pass/fail. If the candidate is weaker on code vs communication, or vice-versa, the role needs to be taken into account. If it's a communication-heavy role, then maybe there's some wiggle room when it comes to coding skill. At Google, we can also recommend candidates for a different role.
Very nice one, thanks guys
What advice would you give for avoiding gender / sexual orientation / racial biases in tech interviews (e.g. forbidden questions, assessment criteria, screening faux-pas)?
Sticking to the same core questions for each candidate is a good step
🎈100% agree and hope this becomes more common in companies....in the meantime, is there a specific Google dept. or team that shares this mentality and also is hiring a front end engineer ? :p
Also, do you recommend devs go out of their way to make portfolios of their incomplete side projects or is a resume enough these days?
Most of my GitHub is private (that nagging thought that your code isn’t clean enough for public scrutiny)
I don't know the interview strategy of all the teams in the company, unfortunately. Candidate selection is done before I get involved, so I don't have much recent insight there, but when I was involved in that, I valued work examples over a statement of expertise. However, I realise not everyone can share work examples openly.
0:01 Hear, hear!
I hate interview bullies. I also hate remote interview cheats. Somone actually copy paste code and pretend it's theirs. I search google all day. But give credit to the source.
Wait wait wait did I just mishear 20:25 or did they really forget to censor that?
Gotta hit those robots where it hurts
@@jakearchibald that caught me so off guard because the worst I expected was a classic "hit em in their bums" but wow I admire that
Thanks guys for such a great video. One question, I have posted my CV at google multiple times but never heard back, can you please suggest what google looks for in the candidate? I am good at javascript. Is there something i should know along js to be at google?
Neither of us are involved in that part of the process, so we don't have any useful feedback, sorry
I heard/read that interviews are practically useless. People looked at how employees were doing that were hired based only on a CV and those that were also interviewed and there was no significant difference. Given how often you can read about just how awful interview practices are, that does not surprise me. So this finding is probably not true in all cases, but might be more applicable than people realize.
Interviews do not strike me as being effective at getting the kind of information you really need, a key one simply being the ability to work well in a team.
Hmm, I've seen some great CVs, but the candidate turned out to be all talk, or just lying on their CV. I feel that interviews are useful.
@@jakearchibald That it definitely a valid concern.
Awesome video, I would like to share my interview questions with you... would be a big help if you could share your insights to make my process better 😇
After morning
The horror stories I read crushed my dreams from when I was a kid of working at Google, things like whiteboards and asking theoretical questions. Total turn-off. If I were to have interviews like you guys describe them, I would consider Google again.
I interviewed for Google 8 years ago, and the theoretical questions were long-gone by then. However, I did have to code on a whiteboard, which is why I won't put anyone else through that 😀
@@jakearchibald Happy to hear that it's changing for the better. I guess crazy stories really do last long.
Thank god I don't work at your office Jake because I have phobia of balloons
Ohh I kinda do too, but only the rubber ones, and only if they're potentially popping. Like, if someone's squeezing the balloon in their hand… stresssss
Jake's mug.
me on a white board coding :
fun ctrlspaceenter toString (param1:num ctrlspaceenter
ret ctrlspaceenter pa ctrlspaceenter toS ctrlspaceenter
Since I'm left-handed, it just ends up being an inky smear
Can we get a video on how to get our resumes selected in Google?
Not from us unfortunately. Neither of us are part of that process, and we try to only do videos about things we know about 😀
@@jakearchibald can you get the people to do the video who do resume selection
🎈
📌
Wearing suits and programmers! Does it still exist? 😂
I have some dev friends who work in finance and they wear suits to work. It seems like they're on a different planet to me.
I think the title is a bit off - it should be "Interviewing developers" right? Great video on an interesting topic anyways!
Hmm yeah. It's difficult to come up with a short title that isn't ambiguous. I'll take another swing at it…
There are shows where they meet for minutes and marry directly :D
Don't get me wrong but how old are your candidates? I guess between 24 and max. 30 years old. Am I right?
I definitely interview people within that range, but it isn't exclusive. 30+ is pretty common.
@@jakearchibald Ok. Interesting. I was working as recruiter many years ago.......And companies in DACH wants most of the time - not older than 30! That was the rule. (for IT developers!) I am older so i dont agree anymore. 😀
are there people that care about io-assignement optimization ?
สวัสดีครับ
🤔 giant robot army - have you heard of emps :3
if you don't use Nvim your are not ready for a coding job yet :P
im jsut judging peopel by wether they use tabs or spaces ...
cause ive never heard of an autoindenter :D
Gooole
Keren 👌👌👌👌👌👌👌👍👍👍🤝🤝🤝
Knowing the names of algos but not knowing how they work is like testing breadth of the knowledge than depth, which can end up where candidate is just a trend follower, i think the proper balance is depth in what they know and breadth in what you ask them..
I think one of Jake’s key insights here was about the candidate recognising that a particular algorithm was appropriate for the problem at hand.
@@qzbnyv yes Application of knowledge, misinterpreted that one
First lol