Hacker News Reader

Comment by jmillikin | Hacker News Reader

As someone who works at Google, this seems like a grossly excessive amount of effort to get past interviews which just aren't that hard. It would have been much easier to browse through the first few chapters of an algorithms textbook, set up a simple network between two linux VMs, and (optionally) brush up on C++/Java/Python syntax if those aren't languages you use often.

The reason Google has a reputation for hard interview problems is that before they came around, the standard technical interview was "So, $NAME, tell me about what you did at your last job". They were one of the first silicon-valley companies to have technical interviews, and so it frightened all the unqualified candidates who couldn't just coast in on good conversation skills.

Before Google, the company with a reputation for impossible interviews was Microsoft. Like Google, I strongly doubt that their questions are anywhere near as difficult as the rumor stream claims.

View on HN

Whether it's an excessive amount or not clearly depends on the person, isn't it? I studied for about 2 months and still didn't get an offer.

http://news.ycombinator.com/item?id=4704039

I don't know if preparing more would've made a difference, but it's possible (though personally I don't regret not having studied more, it simply wasn't worth beyond that point).

Below you mention FizzBuzz. My phone screen question was about implementing a simple, concurrent data structure that could hold a fixed number of items. Not a big deal, but still significantly harder than FizzBuzz, in the sense that pretty much everyone that gets the data structure question right would also be able to solve FizzBuzz, while the converse is not true.

> The reason Google has a reputation for hard interview problems is that before they came around, the standard technical interview was "So, $NAME, tell me about what you did at your last job".

FWIW, This is essentially how Japanese companies still interview. I have never been asked an actual coding or algorithmic question by Japanese companies.

Unlike Microsoft, it seem that Google changed the interviewing process for many companies and I am grateful for it. My interviews pre-Google were primarily trivia contests about the language used for the position I was interviewing for. I was never asked to actually write code or break down a problem. Phone screens were mostly used to verify a candidate had a pulse.

Now I've noticed that almost all phone screens require some type of shared-document coding exercise, and some knowledge of algorithms, followed up by a series of whiteboard coding or problem solving face-to-face interviews. Some companies will ask for a homework problem or code sample as well. It was quite a shift for me as a developer, but a welcome one. The up side is that preparing for interviews now has actually improved my skills as a developer where before I'd learn about aspects of software languages that were often never used (such as details about EJBs when interviewing with companies that never used EJBs) and didn't translate into a hire actually being able to do the job they were hired to do.

Yet Google still has a reputation for very selective hiring ... is that because most of the hiring decision isn't interview-related (degree/GPA/projects/resume)? Or is it that, while the data structures/algorithms questions might not be too hard, it's possible that the interviews are still difficult, due perhaps to a degree of randomness, or to high standards (candidate is IO-bound not compute-bound, never makes a mistake, uses of axiomatic semantics to prove correctness as she writes...)?

It's because, as has been observed by many others, most candidates simply can't code.

If 90% of people who walk in the door can't implement FizzBuzz, and Google wants to hire the top 10% of coders, then it would be expected for the interview process to reject 99% of interview candidates. A more typical hiring goal of "top 1% of coders" means a 99.9% rejection rate.

The phone screen process is supposed to reduce the number of low-quality candidates, but it's a fairly coarse filter, and very easy to game.

Google cares much more about what you've accomplished than about what number is on your transcript, what university's name is on your degree, or even whether you have a degree. If you feel your GPA is too low to be taken seriously, spend a few months coding and put it all online for browsing.

Wow, if Google wants to hire the top 1%, it hardly means rejecting 99% of the interview candidates.

First of all, that logic only works if Google only wants the top 1% of people who apply to Google, and that Google is completely and absolutely incompetent at weeding out the bottom 99% through other screening methods.

Secondly, I doubt that Google has any kind of monopoly that allows them to determine what, exactly, the top 1% or even the top 10% is. A lot of people are fond of throwing these percentages around without even rudimentary data to support their notions of competence - which I think is probably fair to use as a data point for evidence of incompetence.

Thirdly, I could go on, but...

I think you misread my post. Rejecting 99% of interview candidates would provide a result of hiring the top 10% of coders, because 90% of the interview candidates cannot write code. Hiring the top 1% requires rejecting 99.9% of candidates.

You're assuming that other levels of screening (resumes, phone screens) must not be working properly if there are so many bad interview candidates, but really they're working very well. A large company will receive millions of applications for any position, and needs to winnow that down to a few hundred interview candidates. How many nines of rejection do you expect out of a phone screen?

I don't disagree with anything you're saying, but I expect a baseline phone screen session to reject someone who cannot FizzBuzz.

Is that so hard to accomplish without inviting someone in for an interview ? I cannot answer in the affirmative as I do not work in HR.

I think what is meant is that 90% are rejected at the phone screen, and the top 10% or 1% are of those who can code, ie passes the phone screen. That makes them 1% or 0.1% of your initial applicant pool.

You are correct, but the author doesn't seem to be either from the US or a software engineer (his LinkedIn profile indicates a non-technical role).

That said, there's also little harm for a programmer brushing up a bit further than needed on algorithms: skip list, for example, is a great example of a data structure that is less known (perhaps less so after ConcurrentSkipListMap in JDK 6), is commonly used for interviews (as it's easy to explain the general concept in the scope of an interview), and is also practical (used in BigTable/HBase amongst many other places).

It doesn't look like he was interviewing for a software engineering position.

Reply on news.ycombinator.com