Having interviewed, coached, and sat on hiring committees with many candidates during my three year tenure at Google, I’ve learned a lot about what...
For further actions, you may consider blocking this person and/or reporting abuse
Reminds me of Wargames: The only way to win is not to play.
I have promoted the idea of giving applicants tests, and you can see an example of this here in my articles. So don't get me wrong, I think seeing the output from coding is important.
However, the described approach to interviewing says something about the intellectual insecurities and immaturity of those conducting the interviews. An interviewer is in a position of power over the applicant, but at the same time experienced developers are sitting in judgement of the company and it's representatives.
For me the code portion can be done in private, that is they can be left alone to complete it in their own time. I usually give them a couple of hours to complete it, but in fact the task given is designed to be completed in just over half an hour. Generally I'm unconcerned about the time taken so long as it isn't over time.
Once completed we have a casual chat about their solution and why they decided to code it that way. It should be a relaxed environment where they are at ease. The point of the interview is to evaluate how they will function in the team, how they communicate. How well can they communicate the reasoning behind their implementation? It is most certainly not an opportunity to prove how vastly intellectually superior you are by having them answer brain teasers.
The interview is also an opportunity to show them how you function, to give them a good impression about you and the potential job they are applying for. If you make it a terrifying ordeal you are setting a poor example of how the business operates and how it treats staff.
Black Belt gradings in the martial arts are an ordeal. They are designed that way because we want to ensure they have meaning. Only those with the mental and physical fortitude can make the grade. A job interview is not the professional equivalent of a Black Belt grading.
I understand Google and other companies might behave like it is, but they are not doing themselves or their applicants a service. In fact they might be missing really awesome applicants because of this style of interview.
Thanks for the feedback, Peter. I agree that a job interview should not be a terrifying experience for anyone. It also makes sense that, if you want to see people working at their best, that they should be assessed in an environment where they are psychologically safe.
Speaking for myself, I disagree with the premise that the Google interview is inherently a terrifying experience. Google trains interviewers on how to properly conduct interviews to ensure that the experience is as positive as can be for interviewees, and interviewees are given the chance to provide feedback on the process to help ensure that things are done fairly and equitably. Interviews in generally can be a stressful experience by nature, especially if you are not well prepared. That's why Google provides prep materials and other resources like techdevguide.withgoogle.com to help people hone their skills.
I recognize that Google's hiring methodology may not work well for other companies depending on their needs. Ultimately, I see the Google interview testing the same problem solving and communication skills that I use with other Google engineers nearly every day. It is rigorous and challenging, but so is the job.
PS: Google stopped using brainteasers years ago. I made the mistake of believing they still relied on brainteasers in 2011 and failed to prepare properly as a result. Unfortunately, this myth continues to persist despite the reality.
Good to hear they stopped the brain teasers. A few years ago I had a developer tell me they had actually interviewed with me previously and failed. It seemed my own interview method resulted in a good candidate being excluded.
Developers tend to invest in their own intellect and ego, and so we must guard against an unintentional approach which signals the superiority of the interviewer over applicant.
I sincerely hope Google or others are not quite as intimidating as it appeared to be described.
Here, here. Even after I failed the interview in 2011, I still enjoyed the process and became a better engineer as a result. Of course, Google has some jerks same as any other company, but they are definitely the exception and not the norm.
I love the people I work with at Google, and that's easily the best part about working there. A non-trivial number of us either have struggled or continue to battle with imposter syndrome actually!
I know several very good developers who have rejected offers from Google, Uber and the likes for conducting interviews like the one described at the post and decided to give it a try with less known and smaller companies for conducting the interview like you have said. When I asked one of them "why reject Google?" the answer was:
After talking to people like that I changed my mind about interviews and when I was the one interviewing someone I have always tried to do like you said with extremely good results.
At the end of the day in our industry the law of supply and demand is on the side of us, software engineers, because companies need more of us than they are available and thus an interview is not only for the company to see if the person being interviewed is good for them, it is also for the one being interviewed to see if he likes the company and the people and culture there.
Thanks Anthony for sharing the know-hows.
I've summarized what I've learned below. Would you let me know if I got the gists correctly?
Repeat the question in your own words
Understand the question.
Check assumptions
Think of all edge cases
Use real examples
Walk thru your algorithm with real data manually.
Brainstorm solutions and their time/space complexity
Optimize your algorithm using data structures/algorithms and comparing tradeoffs
Write working code (no pseudo-code please!)
Get your hands dirty with real code writing.
Test your code, always
Iron out bugs and use your examples/edge cases to test your code.
btw, the Medium seems to be 404...
Yup, you got it. And link fixed!
I'll add that in step 5, you want to learn how to express your thoughts in code quickly. Come with a lot of practice or hands-on experience.
I appreciate the confirmation & clarification, Anthony~
And here is ✋5️⃣
Just my name (a-mays-ing). Grateful to serve!