I'll be starting at Google in a week and a half. I can't go into specifics, but I can say this:

I had two phone interviews - the first had quite a few questions about my prior experience (over a decade) and how to approach real-world problems from a high-level, including some that I had worked on at my current position. The second was primarily purely technical, but did have some more theoretical/project-management-y type of questions. In neither one was I required to write any code.

On-site: one interview was entirely whiteboard-coding (in a collaborative style), on a set of related generic problems. Next was one with a set of problems related to my experience. Third was almost entirely telling war stories. Last two were some generic graph-theory-type problems and some simple problems involving data structures relevant to the my area of experience.

As I hadn't interviewed for anything in 11 years, I did spend some time brushing up on my basic algorithmic theory, and essentially followed Steve Yegge's suggestions. I honestly think I probably could have done the vast majority of it without any studying, but spending time practicing solving problems on paper (with a countdown-timer as an artificial pressure-inducing device) certainly did help me, I think, in the on-site. No amount of memorization could have helped with most of it, aside from basic knowledge that anyone who's taken Data Structures should know.

I didn't find the process to be insulting at all; it was an enjoyable challenge. Everyone I talked with on the engineering side of things I can only say the best about, and so far as I can tell the team I'll be with has some really great people. I am a more senior developer, so perhaps I got a different experience than some.

This sounds like a huge improvement from when I talked with them a few years ago.

When I interviewed with them, it seemed the interviewers had quite a large effect on how each session went. I had four great interviews, and two that were unpleasant. This had very little to do with how challenging the questions were and a lot more to do with the style of the interviewer.

My experience wasn't a real life type one more academic instead. My interviewer was really late and refused to let me finish my data structure implementation to optimize a single method instead. When we finished it was time for him to go. He wouldn't let me go back to finish my data structure as he didn't have the time.

I was later declined. Had a couple of friends at google ask the interviewer. He said I was declined for not finishing my data structure.

Their interviewing process was quite frustrating. I'm fine with getting declined but not under those circumstances.

Your story can't be true because interviewers do not make hiring decisions at Google.

I can assure you my story is accurate. The interviewers do not make decisions regarding the entire hiring event but they do give feedback regarding how you did in each interview. I was given poor feedback due to, according to him, a zero tolerance like policy where the data model for that particular question had to be complete and I was unable to complete it.

That was my first technical interview over the phone so it was pretty obvious it was related to that single interview. One of the Googlers I knew that checked the system said the same.

Really?

I had the impression that they all had to agree for a hire. Hence one no means no hire.

The important part of the "realistic" process is the part where you go from "the crawler's indexing is too slow" to "it might be because it allocates a lot of little bits of memory; it needs to first generate a BST of outbound link weights, and then functionally invert that into a second graph with a bunch of inbound link weights, and then inject all that into the PageRank matrix. You could probably save some time (though at the cost of memory-safety) by inverting the first BST in-place."

Once you get to that point, though, if they asked me "and how would you invert the tree in-place?" I'd answer "well, first I'd make sure we aren't just using a tree structure that already knows how to invert itself, or could easily be extended to know how. Then, assuming that didn't pan out, I'd google 'in-place invert binary tree' and read three or four solutions that already exist to burn the semantic structure of what I'm about to write into my head so that I don't subtly screw it up and have to fiddle with it for the next hour when I could be coding something else. Then I code it."

And that should be enough.

One of my interviewers at Google asked me to implement a balanced tree insert on the whiteboard in C. After doing so he immediately told me it wouldn't work. I searched futilely for a minute or two to find the problem before he condescendingly pointed out I had left out a semicolon on one of my statements...

Another in the same interview got in my face (this should be easy) when he thought it was taking me too long too multiply two numbers like 637 and 41 during an estimating problem. I understand the point of most of these questions is quick and dirty estimation (600 x 40), but seriously...

RE your second paragraph, it's easier than it sounds.

637 is an awkward number, we'll start by rounding up to 640: 640 * 2 = 1280, anyone in tech knows 2x that is 2560.

Make up the missing 3: 3 * 4 = 12, 2560 - 12 = 2548.

2548 * 10 = 25,480.

25,480 + 7 = 25,487

25,487 + 30 = 25,517

25,517 + 600 = 26,117.

That said, I did make a screw up when calculating it, and added the 637 before multiplying by 10 (which may have been the differentiating part of that question, combined with the intentional stress, to see how you cope with pressure? Although I didn't sleep last night, which might be the cause :D). I dunno if they wanted you to do it as quickly as 600/640 x 40 though, which obviously makes it much more difficult.

Afterthought, due to sleep deprived state, quicker way to solve:

600 x 40 = 24,000 40^2 = 1600 25,600 quick and dirty, for accuracy: 3 * 40 = 120 25,600 - 120 = 25,480 25,480 + 600 = 26,080 26,080 + 37 = 26,117.

Sorry, this comment turned into a bit of a ramble.

Of course multiplying two numbers is easy: primary school children learn how to do it. Doing it in your head under pressure in an interview is entirely different.

What primary school did you go to, where you had to multiply those kinds of numbers in your head?

Perhaps it is an ego trip for the interviewers?

> It's not like they get you in a room and ask you to draw a linked list or a binary tree.

And yet the OP was turned down for not being able to invert a binary tree (based on limited information, etc etc.)? What do you feel that is, if not a "whiteboard this algorithm" question?

As for many of the other companies who try and emulate Google - this is exactly what they do.

> And yet the OP was turned down for not being able to invert a binary tree

Your source is a series of salty tweets.

Well, for what it's worth, it's all we have to go on at the moment.

And in either case, my original comment was directed at the idea that "algorithmic interviews provide false negatives, but not false positives".

It's something that trips me up constantly, but we don't have to say anything. If there's not enough to go on, we can just be quiet.

There are tens of thousands of employees at Google. Most of them interview. People are different.

> There are tens of thousands of employees at Google. Most of them interview.

You say that as if it's a good thing. Do you expect that most people could be e.g. effective teachers, effective marketers, or effective taste-testers, with no previous experience?

That said, I recently heard about a Google interview where the interviewer asked the question and left the room for 30 minutes while the candidate white boarded.

Obviously he didn't give 1 shit about "how you approach the real world issues".

They literally had me do a deterministic finite automaton problem.

Ok, on the one hand, you should be able to answer the question with, "Get a standard-issue POSIX-conformant regex library. Next question!"

On the other hand, knowing that DFAs are equivalent to regexes are equivalent to NFAs is already a step of theoretical knowledge that any "Just let me write code" so-called "dev" is likely to complain about being asked for.

I was asked that question about 7 years after reading Mastering Regular Expressions and about 10 years after taking Automata in college. It so happens that I am an expert in regex, have a patent in the field, regularly answer stackoverflow regex questions for fun, etc. Unfortunately, the question involved me actually drawing a DFA, trying to remember the notation, etc. At this point I don't even remember the particular question, only that I couldn't remember how to draw or read the diagrams.

Circles for states and arrows for transitions between states? Is there anything more to it than that?

I think you use "sausages" for initial and final states...

I too don't remember much.

Perhaps that's the point. A self-proclaimed expert in the field should know how to draw or at least read a DFA.

The interviewer told me this was a favorite question of his. Also I don't think I presented myself as a regex expert to them. Anyhow, I'm an expert in regex like a DBA would be an expert in SQL or particular databases. The interview was for an ordinary software engineer role.

Regardless, I only meant to make the point that I disagree with the comment "They're more interested in how you approach real world issues" and that this statement is false: "It's not like they get you in a room and ask you to draw a linked list or a binary tree"

edit: by "expert" I just mean something I'm particularly skilled in, not something I'm an authority in from theory to practice.