Live data from Hacker News

A Wretched Google Interview Experience

symbo1ics.com

211–220 of 359 posts

Re: A Wretched Google Interview Experience

#211
post #166

Earlier quoted context omitted.

you say flaky, I say assholes who don't respect others' time. And way to move the goalposts re: your friend would be happy comment. I think what would have made his friend happy is to be treated with respect. Similarly with your bitterness comment; it's not bitter, it's letting the world know you and your colleagues believe it's right to treat people this way (because if you all didn't think this was ok, then you wou…

I'm not defending the hiring practices at all; on some level, we lose out on a lot of qualified candidates who would do great work and would be great to work with. I'm not a recruiter, but I try to help out however I can; people on HN regularly email me asking for advice, or to ping their recruiter, and so on, and I'm happy to do this. I want to work with you, and I don't want the intrinsic flakiness of people to adv…

You described it as a "free trip to MTV" as if it were some kind of a perk. It's wasting two days of somebody's time, and apparently showing no remorse. At that point the ball should have been clearly in Google's court, surely they could have figured out a less painful way of gathering any extra data they needed. I mean, the guy was in NYC! It should have been trivial.

It's well known both inside Google and outside it that many parts of the hiring process are badly broken. Suggesting that people should just grin and bear such abuse just means the process will never get fixed. While if people just stopped the process if it got silly enough, somebody's bonus would be in sufficient jeopardy to cause some action.

(When I worked at Google I never referred any friends unless they asked me to -- the chance of them having a bad experience was just too high. And recruiters were always pretending to be shocked that anyone could think the process wasn't working properly.)

Re: A Wretched Google Interview Experience

#212

I think this is very unfortunate. I've seen a lot of good candidates get rejected for no obvious reasons. The lack of communication seems driven I think by the sheer deluge of the number of resumes/interviews going on at Google, and what appears to be, a reliance on temps and contractors as part of the process. I had a friend who interviewed at Google, who is an excellent software engineer I've worked with for years,…

> consider myself a relatively poor interviewer and I usually decline to do them unless they intersect my subject area (compilers, GWT, etc)

First, given you understand your limitations as an interview, you're probably a better interviewer than most -- including myself :-)

An employer I worked for made it very difficult (but certainly not impossible, implausible, or even socially unaccepted) to stop interviewing altogether. Instead, they'd take a different approach: in addition to trying to match interviewers with candidates, they would also perform analysis on interviewer's previous feedback (e.g., are they constantly voting down candidates that go on to receive an offer after additional review, or vice-versa?) and weigh the feedback accordingly.

I'd be highly surprised if Google doesn't do this.

I do agree that usual "watch an experienced candidate do the interviews" approach to training is insufficient: this is much like expecting one to become a better candidate by watching a strong quickly "get" an algorithmic question with an a-ha insight, it looks easy when you already know the answer. I love the anagrams example from Programming Pearls -- it appears as "aha" problem, seems obvious to those who already know the answer -- but the book describes in detail on how it represents an entire class of problems and how to achieve that seeming insight using a more structured approach.

As an aside I actually finding interviewing others to be much harder than being interviewed myself -- if I screw up as a candidate worst thing that can happen is I don't get an offer, if I screw up as an interviewer people other than myself (the candidate, the company) will be affected. There's plenty of sites that talk about how to prepare for being interviewed, candidates spend dozens of hours before going for an interview, but there's less material out there for individual engineers who want to become better interviewers. Joel and Yegge are prominent exceptions, but most other pundits say only the obvious, e.g., "ask questions that can tell you if the candidate can do the job?"

Re: A Wretched Google Interview Experience

#213
post #107

Earlier quoted context omitted.

And they can do all of that just because everybody still wants to work at Google. Let's say the have 100 applicants for a position, out of which 10 are qualified for it. Then they can still screw 9 of them and hire the one person that for one reason or the other had the luck of interviewing with the right people and talking to the right recruiters.

Many people don't want to work at Google. Yes, they can fill their spots, but the reality is that hiring bullshit means that over time their candidate pool progressively filters to "the people who will put up with bullshit", and while it takes years to filter through, in the end you up becoming Microsoft. There was a time when Microsoft was the bee's knees and was the elusive dream employer. Then they started various…

"Person is willing to put up with nonsensical HR bullshit" and "person is a creative hacker" are damned near mutually exclusive.

Get your HR droids on a leash, folks, before they kill your company.

Re: A Wretched Google Interview Experience

#214

Earlier quoted context omitted.

Why don't more people walk out of interviews? Especially if someone set you up to fail, quite literally: interviewing for the wrong job. It's a waste of my time, it's a waste of your time as a company. On top of that, if you're going to throw out dickish comments like the article states (paraphrase: "ask your friend, he'll know the answer"), I wouldn't stick around. Is that the atmosphere at the company? Agree or dis…

Because then your interviewer does a hatchet-job on you in a feedback form and you get shitlisted from interviewing at Google forever. That's the problem with large companies. There are companies where I would just walk out of an abusive interview, because the brokenness represents their whole company. Then you have massive, mega, ultra-sized companies like Google where even though this particular team is beating you…

Funny that there seems to be a consensus that Google can effectively black-list people, and yet it seems they can't even keep track of who they are supposed to actually interview or who they have previously contacted about interviewing.

Re: A Wretched Google Interview Experience

#215

Earlier quoted context omitted.

I think this is being relatively unfair in assessment. Google hasn't had a hit product in a while? Search and Ads are dominant. Android is the #1 mobile smartphone OS with 80% of the market. Chrome is now the #1 browser. Google Maps is the #1 mapping application. Gmail is now #1 in active users. G+ now has 190 million active posters now monthly now (Twitter only has 110 million active posters) YouTube is the top vide…

> most of the changes go unnoticed like a frog slowly being boiled in water. Believe me, I notice. GMail and GMaps get slower and slower every day. I can't actually use GMail anymore; clicking anything takes several seconds. Wasn't this way in 2005, and I had a crappier computer then.

[deleted]

Re: A Wretched Google Interview Experience

#216

Earlier quoted context omitted.

It's interesting to see that the Google employees commenting in this thread are OK with people being treated this way. It reveals a lot about the culture. No wonder you fail so badly at customer service. Maybe you have been at Google so long that you don't realise it, but this is not a normal or decent way to treat somebody. I can't think of anybody I know who would want to work there after going through that intervi…

Please read my reply below. I'm personally not OK with screwing over candidates, but I can understand why fuckups happen from time to time. If you're having problems with the process, never hesitate to send me an email. jrockway AT google.com.

This is not just a few fuckups though is it?

Interviewers not being on site I can see yes, that can happen and I agree we can attribute that to 'flakiness' if it's a one off. (Although I have to say I can't imagine it ever happening at anywhere I have ever worked, and I've worked in local government, a bumbling bureaucracy if ever there was one).

But failing to return calls just about every single time? Waiting months before getting back to tell somebody they progressed to the next stage or didn't make it? Having to call a friend at Google to find out if you passed the interview or not because they didn't bother to call back? Making snide remarks to the candidate? Just about every account in this thread reveals a similar story of waiting for months to get any reply, not getting replies, not being told how the interview went, not being told why they were turned down. That is systematic and reveals a hiring process that treats people like shit because you can get away with it.

Re: A Wretched Google Interview Experience

#217

Earlier quoted context omitted.

I've interviewed at and worked for a number very very large companies before, and none of them have been as disrespectful at interviewing and hiring as Google sounds from these stories. I'm not defending this practice at all, but I think I can understand it. It sounds like the typical problems involved in scheduling 10 people to all perform together at once. Nobody can prevent people from getting sick. Going out of t…

You're focusing on the details. The huge, blaring point is that some person was flown across the country, probably took time off work, etc. for an interview that was utterly hopeless from the outset and thus pointless. It's Kafkaesque in its absurdity. Make no mistake, this sort of conduct is a black mark on Google. Funny how the only people in this thread defending it are people currently employed by Google. The wor…

> Going out of town and missing an interview is pretty flaky, but it happens.

Sorry, "it happens", is such a callous sentiment regarding someone's future. "We booked and agreed on a time and couldn't be bothered doing it and couldn't be bothered telling you, either" is outrageous.

Re: A Wretched Google Interview Experience

#218

Earlier quoted context omitted.

The skills being evaluated in Google interviews (and on topcoder) are of minimal use in most real problem-solving environments. They're a proxy for skill - something many skilled candidates happen to have alongside the skills you actually want. Linked list questions are a favored choice of this class of interviewer despite the fact that 90%+ of programmers will never have a good reason to write a linked list - or eve…

> Linked list questions are a favored choice of this class of interviewer despite the fact that 90%+ of programmers will never have a good reason to write a linked list - or even use one, for that matter. If you can't write basic algorithms to manipulate linked lists (traversal, reversal, etc) on demand, you almost certainly aren't a good coder. These kinds of questions are a good weed-out pass. They don't correlate…

I get the impression you didn't read the part of my post where I said these algorithms are useful.

The problem is expecting a candidate to have them memorized and be able to rattle off a particular algorithm from memory in a 15-30 minute interview window, when in the REAL WORLD if you don't remember the exact details of an algorithm, you look it up or grab it from a library instead of writing a busted implementation yourself.

That's why these questions are unrealistic: They're evaluating a candidate's ability to do something you almost never want them to actually do.

Yes, a candidate who can't understand linked lists is probably a bad choice. I never said otherwise. It's lazy to make the leap from that to 'thus, asking a candidate to write a complex data structure utilizing linked lists on the board in 30 minutes is a good idea'. Only if it's something they should actually be able to rattle off like it's no problem...

There are lots of ways to evaluate critical thinking and problem solving skills that don't rely on a candidate having memorized the contents of a CS textbook.

A better interview question is one that focuses on solving a real problem for a hypothetical customer, because that's what most engineers actually get paid to do. If the problem happens to be optimally solved with a linked list, you can see if the candidate arrives at that conclusion naturally, or guide them towards it if they don't.

Re: A Wretched Google Interview Experience

#219
post #52

Earlier quoted context omitted.

- have a counter for every bigger interval asnd the last timestamp If the timestamp is same second as last increment everything, if not increment where appropriate and rotate everything else to 0. What am i missing?

My reading of the API is that getCountInLastSecond returns the count from the last billion nanoseconds, not the count from the previous second bucket (as the clock ticks). So when he mentions he can't bound memory, it's because he can't easily discretize the counters.

Then you also need to carry a second-worth of timestamps in a queue.

Re: A Wretched Google Interview Experience

#220
post #50

Earlier quoted context omitted.

Wow, I've really got to look into Go. Sounds so easy.

What he's described is pretty trivially done in most modern languages/frameworks. I can write the same in C#, Scala or C++11--swapping greenlets for standard threads, which honestly is unlikely to be a perf concern--pretty trivially. The hardest of the above would be C++, because boost::threadpool isn't officially part of Boost--though it works fine--and otherwise you'd have to get a little creative with boost::threa…

You don’t need a thread pool or threads at all. Just schedule a timer for each server. You could do it in JavaScript.

I’d even guess that a JavaScript implementation would be more efficient than Go. A goroutine has an overhead measured in kilobytes; a JavaScript timer is presumably smaller.

Post reply on HN