[PlaceFan]

Is that true? Isn't the generic accusation against AmaGooFaceSoft that your interview performance largely depends on whether you happened to study some interviewer's pet topic (e.g. parallelism, dynamic programming, networking, etc.)?

[rb2k_]

Having done interviews at a few of time, I'd say that's mostly false, at least for the last 2-3 years.

As far as I can tell, there's always a pre-defined pool of questions. Some of them are pretty 'open ended', but still targeted towards getting a good impression of a certain area of knowledge.

That being said, I had an interview with Google at some point in the past where one of the interviewers almost seemed appalled that I didn't know the exact list of items that can be found in a filesystem superblock. But at all other companies it seemed a bit more sane. I guess it's partially a function of the type of personalities a company is willing to hire :)

[tptacek]

Careful. First and most obviously, the "pool of questions" concept is structured only if you have a Google-scale volume of candidates and reliably assigning specific subsets of those questions to candidates.

But even then, for such a process to be rigorously structured, the questions themselves need to be determined a priori and without reference to the candidates background or preferences. Otherwise:

* You're subject to the interviewers and judges (probably subconscious) biases about the merits of different questions.

* You're more exposed to the candidates own innate ability to interview well by navigating themselves to more easily-answered questions.

[anonymoushn]

Recently I failed an interview at Facebook because I chose to serialize a binary tree into a list of N items, rather than a list of N items and O(N) sentinels. Most of the interview was spent convincing the interviewer that this could possibly be correct.

[z3t4]

i recently failed a programming test after acing all tests except one where i needed a text diff and pulled in a library instead of writing my own in less then ten minutes. they said i need to get better at algos. which is fair. but i dont know anyone that can program a decent working text diff in less then ten minutes.

[mquander]

Based on your description, it sounds possible they were just looking for a Levenshtein distance implementation, which is definitely in the Universal Weird Corpus of Interview Questions and for which people who prepare for interviews a ton would have a good shot.

[flukus]

I ported a diff algorithm (a simple one at that) just a few months ago because the language I was working in didn't have one. I couldn't do it off the top of my head today, or probably the day after, it was transient knowledge that I didn't even try to remember.

[mquander]

Why did you conclude that you failed because of that? That sounds like a pass with flying colors. Did you specifically get feedback about that segment?

[anonymoushn]

In the few remaining minutes after we agreed that it was possible to correctly deserialize a tree serialized in this way, I did not produce a linear time deserializer.

[mquander]

:-(

[dastbe]

was it a binary tree or a binary search tree? a BST can be uniquely identified by one of pre/post-order traversal, whereas a binary tree requires an in-order traversal and one other. or placing sentinels that specify a state machine [PUSH_LEFT, PUSH_RIGHT, POP] that specify how to move down and up the tree structure.

[anonymoushn]

It was a BST.

[akhilcacharya]

n sentinels? What do you mean?

Do you mean characters to indicate a null child?

[nostrademons]

This accusation is almost always from people who haven't studied that particular pet topic. In my experience, the pet topics you list - parallelism, dynamic programming, networking, etc. - are needed quite frequently for those jobs at AmaGooFaceSoft. In other words, those candidates would be poor fits for those jobs, which is exactly what an interview is trying to test.

I think the Google hiring process is fucked up in a lot of ways, but I don't think reliance on whiteboarding or the selection of interview questions are two of them.

[PlaceFan]

> This accusation is almost always from people who haven't studied that particular pet topic

Well sure, but you only have so much time to study for these interviews.

So, you make sure you review your basic data structures, algorithms, and complexity analysis. The things that will most likely show up.

Then you have to consider the more advanced topics. Realistically, you're not going to have an expert-level understanding of all of them. None of them are extremely difficult concepts to understand necessarily, but you need the kind of mastery to understand such a problem quickly and under pressure (since it's a short, timed interview).

The most effective way to study, then, is to simply run through a battery of dynamic programming questions and hope you get lucky and the interviewer asks you a variation on one you studied.

I've had more than a few AmaGooFaceSoft interviews ask me slight variations on the change counting question. They're really testing my ability to recall the solution to that problem, not any sort of deep understanding of dynamic programming.

On the flip side, the interviews I've failed almost always involved some pet topic that I wouldn't dream of studying. I once (no joke, and not THAT long ago) had an interviewer at AmaGooFaceSoft ask me do a bunch of calculus questions involving power series (turn a function into a power series, determine the radius of convergence, etc.). Why would I study that for an interview?

[FT_intern]

> Well sure, but you only have so much time to study for these interviews.

Considering the payoff (potentially a $40,000 to $100,000 raise on a 40 hour work week), I think that the amount of time to study for these types of interviews is very trivial. Interviewing skills can be used for interviews at many well paying companies because this type of interview has been standardized, so it's not like you're only studying specific knowledge for one company.

[ZanyProgrammer]

Are those topics really needed for (what you're implying) is the majority of jobs at those companies? I'm not sure if there's any way to really test this.

[nostrademons]

Yes. This is the reality of distributed computing: most of the problems you want to solve do not have off-the-shelf libraries. Rather, you need to know an algorithm, and various algorithmic-design techniques, well enough that you can decompose it into steps and then recompose steps so that they can be partitioned among many different computers, with appropriate failure modes if machines or network connections go down. That requires intimate knowledge of both the algorithm and of the types of problems you run into in a distributed setting.

MapReduce, Pregel, Bigtable, Flume, etc. are building blocks: they solve some of the distribution problems, but you still need to understand how the algorithms that run on top of them work, on a step-by-step level, to implement on top of them.

[mquander]

Is that actually a majority of jobs at Google? I know something about the work that several of my friends working as SREs and SWEs do and it doesn't sound like it involves a lot of distributed systems programming.

Let's say you work on some part of Android. Obviously you need to interact with things like Google's build system which are distributed, but are you really implementing some distributed computation in the course of your every week, or even every month?

I get that Google wants to test during the interview for suitability over a large space of possible specific roles, but I seriously doubt that "distributed systems stuff" would be in the list of top 10 programmer domain knowledges that are useful in those roles. Is it more useful than knowing how to work with version control well? Everyone at Google has to do that, but they don't test it during the interview. Is it more useful than being able to read and write idiomatic and readable Java? They don't really substantially test that during the interview either.

(On the other hand, the things that spawned this conversation were "dynamic programming, parallelism, and networking" and the latter two are much more obviously generally important things.)

[nostrademons]

It was at the time I was there (2009-2014). There's another Googler above who says it's not like that anymore, which is possible, but these were things you needed to know across Search, GMail, YouTube, Plus, Docs, and Infrastructure while I was there.

[joshuamorton]

It entirely depends on what project you work on. When I interned, I had to deal with a lot of custom datastructures, but since I started full time, I haven't (although my next project might?)

[hobls]

People always talk about the whiteboard interview, and assume it has the greatest weight, but the other questions are just as important. There are plenty of things being measured, and technical ability is often not the one that disqualifies a candidate. The other questions do tend to come from a standardized bank of questions too; the whole thing is very structured.

[crispyambulance]

This. I wonder how many people "think" they flubbed an interview strictly because they got some detail wrong on the whiteboard when it was really far more related to a negative impression of grit, communication, motivation, personality, or work-history.

[ryandrake]

And we will never know because the vast majority of companies refuse to give even the vaguest of feedback on the reason they are not moving forward. Not even “it was your technical knowledge” or “it was communication skills”

[hobls]

I think it's a lot! If you had a reasonably decent answer to the whiteboard questions it's often fine if you don't actually get it right.

There are a lot of other ways to screw up an interview.