[TGImemegen]

Googler here. At some stage of the interview process, we have to check whether you're able to code, there's no way around it if you're applying for a coding position. So yes, we'll have you code the solution to a problem. Of course in the real world we'd use a library or look up the algorithm on stack overflow like everyone else. Good for you if you came up with a workable algorithm for the problem quickly. But that's not the only point of the interview. An important goal there is to check if you can really code. We don't usually care if you don't know find the perfect algorithm (unless it's for a senior position), and in fact it's a desirable property if you don't, because that allows us to see your thinking process. Some of the best interviewees I've had, they didn't have the right solution, but impressed me with how they thought about the problem and dealt with the situation of having a problem in front of them that they didn't know how to solve. How they considered possible boundary conditions and restrictions and extensions. Someone saying "yeah, this is just depth-first-search" and then spits up a memorized solution gives me zero insights on whether the candidate is good (and will likely not allow me to write great feedback on the candidate, unless they're able to sell me that they understand what they are doing and why and how). It's usually expected that most of the interview will be taken up by you implementing some algorithm, and it's expected that you won't get every detail right.

We do NOT require you to produce token-by-token perfect code, and nowhere in the process will I ever have to give feedback on whether the code produced was actually valid. So maybe you misunderstood your interviewer's intention, or something else went wrong, or maybe they were just joking. But it's not the interviewers task to copy code into GCC and try it out, that'd be a huge waste of time. So let me be very clear and explicit: no-one gets classified as "no hire" because they've forgotten a semicolon somewhere. You messed up somewhere else.

With that said, if a candidate says they can write in a language, we expect them to know the language, its idioms and at least parts of the standard library. Not every nook and cranny (e.g. I'd often instruct candidates "just pretend you have some library that implements a heap, and invent an API for it, I don't care about that part"), but if you call "strlen" in the termination-condition of your for-loop instead of before, or do other stuff that shows you don't know the language well, that's a red flag. After all, we expect you to be able to write production-level code that servers billions of users.

[cheschire]

There’s enough counter anecdotes here on HN when this topic comes up that the wording of your post comes off as tone deaf. You actually seem to believe every interviewer at Google behaves like you, for the same reasons, to the same standards.

“We do NOT”

“You messed up”

“let me be very clear”

“whether you’re able to code”

These types of statements come off as patronizing. If your whole process sounded like this, and if you somehow actually do represent a majority of Google interviewers, then it’s no wonder so many folks have a distaste for the experience.

[TGImemegen]

I tried conveying what I was told when I was trained for conducting interviews, what I've explicitly seen demanded on the interview forms I have to fill out and what I get as feedback from hiring committees. Thus I indeed assume that my opinion represents the majority of interviewers. Whether that assumption is warranted or not, I wouldn't know.

[bborud]

Well, in real life this varies. I've seen interviewers from among the first 200 Google employees, nitpick their way through someone's whiteboard code, obsessing over every comma and semicolon. It was embarrassing. And I have to say that while shadowing these interviews I couldn't help but think "I've seen your code - you have bigger problems than getting the syntax perfect, mate" (about the interviewer).

It depends on who you get as your interviewers, so generalizing isn't really useful. Some interviewers can't relate the interview to what it is supposed to tell you. I've seen that in inexperienced interviewers and I've seen that in very experienced interviewers who had enough GOOG stock to buy a small country.

If the interviewer can't think of a better way to test candidates, that's on the interviewer. Not the candidate.

[tchalla]

> So let me be very clear and explicit: no-one gets classified as "no hire" because they've forgotten a semicolon somewhere. You messed up somewhere else.

How much money can you bet that this never or does not happen? If you can't put your money, I find it difficult to take this seriously.

> We don't usually care if you don't know find the perfect algorithm (unless it's for a senior position)

The unless clearly means that you "do care".

[gregkerzhner]

This statement "we don't usually care if you don't know find the perfect algorithm (unless it's for a senior position)" made me chuckle.

I can see this interviewer writing feedback like "Well, this candidate didn't come up with a perfect implementation of Dijkstra's shortest path algorithm, but its OK, they were pretty close. Oh wait, they are a senior engineer? Nevermind... they should have really mastered these algorithms while building CRUD APIs all these years."

[hownottowrite]

“servers billions of users”

And therein lies the problem.

[notJim]

This is all ridiculous. Of course you have to test that people can code, but it doesn't follow that people must be able to code without any references available, or without using standard libraries. I can code just fine, but I still have to look up the arguments to functions I don't use very often, etc.

As far as algorithms/data structures, most of what we do on a day-to-day basis is more about selecting the appropriate data structures and algorithms that fit the problem, and assembling them together correctly. I've never needed to code a hashtable, but I need to think about their characteristics and whether they're appropriate all the time. I've never written a btree, but I do understand database indices pretty well. So in my view, asking candidates to code up these things on the fly in an interview with no reference materials is a total waste of time. What matters more is if they can correctly apply them. If you're really sure someone needs to write these things, then a more realistic move would be to sit them down with a standard textbook or paper and see if they can get the code working.

> After all, we expect you to be able to write production-level code that servers billions of users.

And you do all this through sheer clairvoyance, rather than using tools like unit tests, code review, design specs, etc, right? No? Then why are you expecting people in interviews to do it without those things.

[luffapi]

How does Google interview for product development skill? That’s seriously lacking in that organization, definitely the worst of the FANGs.

The arrogance displayed in your comment isn’t backed up by the ultra-low quality of product being produced by Google. Something is clearly wrong with the culture and hiring process there. Maybe instead of fretting over people using strlen as an exit condition, you should look for people who can actually produce software people enjoy using. You don’t even need to do a coding interview! Just browse GitHub for people you want to hire and get to work convincing them to join you.