Strange, I have yet to meet a single Google interviewer who was looking for perfect syntax during the interview. Last year I forgot the syntax for a data structure, told my interviewer "something like this," and he just said "that's fine." Got the internship later on. I even had one interviewer who was ok with me writing out matrix algebra mathematically instead of using np.matmul and all that.
I interviewed with Google NYC for Senior Dev position once, prepared well and thought it went well.<p>Received the green light and moved to the next phase, where I spoke with potential teams over the phone, then settled with Google Maps. Met with one of their Tech Leads, cool. I was really happy and though that all my effort to prepare for the “Google interview” had payed off.<p>Then no word back from the recruiter with a final offer. It turns out the VP of eng saw some red flags in my interview and decided to bail.<p>I felt really frustrated and while I spoke I spoke with the recruiter he apologized and even said the hiring manager was on my side and people overall liked me but there were two engs that were on the fence. Gosh, I think I met with 7-8 engs, all the seniors seemed to like me. I remember not having the best conversation with 2 engs who were new to the company and could not relax nor communicate well.<p>Bottom line, prepare but also be prepared for some degree of luck and arbitrary judgements.<p>Yes, there are great interviewers in google. Engs that are engs in their minds and hearts, who can see the process is not perfect but work to get it better. But unfortunately, there are insecure folks who should be better trained for before interviewing candidates.<p>That was 5 years ago, not sure I would subject myself to this sort of loop even again. And strange enough they contact me few months after to reinterview but this time I could skip the big loop and meet with just 3 engs... I said no since I was already in a new job.
A friend said recently, "people want to be employed without becoming employable". These guides really exemplify this obsession. Sure, Google has a nice salary and good perks and whatever. But after you get the job, you have to do the job. I wonder if the people who read these guides and try to study just the right topics to get a job, whether they actually <i>like</i> programming.<p>These guides act as optimizations, shortening the path you need to take to get the job, shortening the stuff you need to learn, etc. But in the end, the path is all you get. If you don't like programming and if you don't like learning, then are you really gonna like Google?<p>I suppose there's people who genuinely like programming who just need a manual to teach them how to play the game. Lord knows I've practiced my fair share of whiteboard problems when I'd rather be reading about compilers. But there's something wrong about having to play a game to get the job.
The amount of time required to 'learn' the Google interview would be time that could be spent learning more universally applicable skills.<p>Is it true that an experienced developer would not be able to pass the interview without studying using a similar guide? If so, then the interview process is... fubar.
This is getting ridiculous. These guides to interviewing at specific companies are starting to sound like the video game cheat code books of old.<p>If the process is so nuanced that there's an entire industry around these types of guides (and Google even highly recommends you buy them!), then the process is fundamentally flawed.<p>But we already knew that, and as long as others are still playing the game, we are forced to play or miss out.
It's also a good marketing milking cow to create paid courses and trainings for Google interviews — the dream of so many novice devs and other "Intensive Coding Bootcamp" participants.<p>Keyword research and trends... <a href="https://trends.google.com/trends/explore?date=all&geo=US&q=Google%20job%20interview" rel="nofollow">https://trends.google.com/trends/explore?date=all&geo=US&q=G...</a>
I hate these style of interviews. I give them to prospective engineers every week for one of these FAANGM companies.<p>They don't test for good engineers -- they test for people who practice these style interviews, and for good new graduates.<p>It makes sense to ask these questions to new grads, but afterwards there is so much more experience that I feel like is much more important than acing data structures questions.<p>I am amazing at whiteboard questions, but that doesn't make me a good engineer. It's because I found the trick to solving these, and have practiced them. A lot of it it is practice 'ooo this looks like a graph problem, let me use a graph', etc.
These guides are just people trying to make a quick buck. There's no shortcut to getting good and perhaps that's why these type of interviews are here to stay.
> For the phone interview, it will be on a Google document, and for the onsite interview, it will be writing code on a whiteboard.<p>That part is not completely correct. At onsite can choose to write code in a Chromebook which will have a lightweight editor with syntax highlighting.
Should be titled "How to Ace the Technical Interview in the Bay Area". Even absolute shithole bottom tier companies or unknown startups are asking these questions. Write perfect code on the whiteboard or get rejected. You have to put in A LOT of time into preparation even if you don't want to work at Google, which is ridiculous.
They lost me when they got into showing how to make the 'dups' function faster. The author definitely either doesn't understand big-O notation or doesn't understand the complexity. Their O(1) implementation is anything but. Likely O(n×log(n)) at best. Also, their brute force implementation is unnecessarily verbose. Want dups?<p><pre><code> from collections import defaultdict
def dups(seq):
d = defaultdict(int)
for x in seq:
d[x] += 1
return [k for k, v in d.items() if v > 1]
</code></pre>
Assuming Python's defaultdict has O(1) lookup/insertion (which I think it does), this algorithm is a proper O(n) complexity.
It would be nice if an article on how to ace a coding interview did not have incorrect code in it. AFAICT the set-based algorithm for finding duplicates is wrong; the resulting set will contain items in the list that are not duplicated.
I wouldn't get an interview from Google even if I wanted to. I'm 29 and live in Africa.
That said this guide was still helpful. A reminder of some of the skills I should hone for my next interview.
I loved reading the comments here because they give so much perspective from all sorts of people. HN is extremely critical of everything and it can be sobering.
I cannot obviously speak about the intentions or damage such guides have or can do but honestly, even if you know how to code, it doesn't hurt to prepare for an interview in a way a prospective company would want you to.
Question for hiring managers and employers:<p>In Silicon Valley, tech interviewing has become an arms race between applicants cramming to pass tech screens and interviews, and employers coming up with new routines. Sites like Glassdoor and CareerCup are loaded with interview questions that have appeared in those routines, giving savvy interviewees the opportunity to see the questions on the exam and prepare accordingly.<p>How do you feel about the existence of these sites, and do they affect how interviews are conducted?
There's an unconscious bias in this post. Google as a company is not only interviewing engineering roles. Even for engineering roles, there are too many sub categories and many doesn't follow the typical SWE interview process.<p>If you just want to know what the interview for your roles would be, the recruiter from Google will happy to give you an overview.
I've never seen an interview process that HN (and Reddit and Slashdot and ...) didn't trash as "deeply flawed", "biased", "unfair", "unreasonable", etc. At some point, though, a company has to have some sort of process, and by and large what they use works for them.
You can bypass the whole charade by knowing 2-3 people within Google that can provide "assurance" you are good enough. Whiteboard testing is for grunts/unknowns without network. Another way is to be a significant contributor to some popular open source project.