Is this a serious article?

Iterating over a hash slightly wrong when writing code in a google doc during an interview is such a stupid, trivial thing to be judged on, whether it's you or someone else doing the judging. It's clear from the "My lame attempt" example that the basic concepts are understood, and if he's written a series of articles about the Enumerable module then he probably knows it better than the majority of professional developers working with the language.

If this is a serious article, then it really highlights everything that's wrong with tech interviewing.

Don't sweat it. I find those Google interviews to be very discouraging and I felt dumb after not doing great on one when I was in school. Looking back, the whole interview was a mess. I got the call from the engineer 45 minutes late, I couldn't access the Google Doc because he was trying to send it to my university email address, and the coding portion started off with him writing "!(x & (x - 1)) && x" at the top of the empty document and asking "What does this do?".

Looking back, it was pretty silly but man did it really kill the confidence of 19 year-old me when it took me 10 minutes to work out that it detected numbers that were powers of 2. It really gave me a negative impression of Google's interview process (that and the complete radio silence afterwards), which I still think about when they send me their bi-annual recruiter emails. Funnily enough, the last email I got specifically mentioned that I had "done really well in the recruiting process in the past".

> When your bread and butter is crunching through large amounts of data with MapReduce, it only makes sense that you tend to take a more functional approach and think in terms of single-operation mapping, filtering, folding, and sorting.

Umm, sorry, no. You wouldn't believe what kind of 5-level-nested-if C++ statements you could find in Google's codebase. Google might be known for its technical abilities, but "affinity to functional programming ideas" is generally not one of them.

I don't think anyone could succeed in a coding test without rehearsing before taking it, just like any kind of live performance.

Programming languages are powerful things with which you can do a lot of very different things and tackle very different issues. Sometimes it's database querying, sometimes complex data structures, sometimes parallelism, genericity, business data modeling, etc. etc.

There should be a list of "warm up" exercises somewhere to help people prepare for general tests and make sure they've touched at least every subject once before going live.

I doubt that you were rejected (even if you were, which it seems like you don't know) based on needing to be prompted about select, and getting syntax wrong, especially for a non-dev position and in a phone screen. If I were doing a phone screen, I'd honestly be probing more for whether you know how code works in general, and if you knew what select was (i.e. when I prompted you, your response wasn't "uh...what's select?")

Also, did you not sign an agreement with Google that you wouldn't share interview questions before you started interviewing? I think sharing questions is generally considered somewhat uncool.

True story: I sort-of-interviewed at Google. The interview ended because the interviewer, after having been told that I had already completed the project they were trying to recruit for, became agitated and told me that I was just a hobbyist and my product did not exist -- this while he was being shown it in motion. I put a spare PCB for my product in his hand and asked him if it didn't exist, why was it making him bleed. Then I closed his hand hard around the PCB and told him to keep it, it's under GPL, and go ahead and crib from the design.

People who reject physical reality should receive a bit of negative conditioning about doing so...

I am terribly out of Ruby practice. Choosing Ruby as his language, presumably because it is the language he is best at, and then whiffing on the basics is probably what did him in. The brevity of phone interviews and the need to whittle down a massive pool of applicants to a manageable stream means that the interviewer is going to infer a lot from a little.

He should have chosen a language he is better at. If Ruby is indeed his top language, and he's rusty at that, then perhaps OP just isn't fit for a coding job at this point in time?

I didn't get as far as a full interview, but an internal recruiter reached out to me and we chatted for about 20 minutes or so for a specific position she was trying to fill. It was no better than a standard recruiter, really - I was expecting more.

"So, I found your resume... blah blah blah, you say you've done XYZ, blah blah blah, send me a copy of your resume."

WTF?

I said "um... you're google - don't you already have all my information?" a bit jokingly, and she laughed a bit. I then told her I wasn't at my computer, but if she Binged my name, my site would come up, and she could grab a resume from there. A few mumbles later, I got "OK, got it! I'll get back with you in a couple days with the answers to those questions!" I'd asked a couple questions about the job. That was early August - no followup. As unprofessional as any other hack recruiter imo. I guess I shouldn't have expected more, but I did.

tldr: I told Google to Bing me.

If im ever being interviewed by Google, i'm going to say "hold up let me google the solution to that real quick."

A good engineer spends about 95% of their time discovering new things to learn about their craft. An even better engineer uses what other engineers have already discovered and shared with the world to further their understanding.

If the world only consisted of the "even better" engineers things like this wouldnt ever exist. http://swtch.com/~rsc/regexp/regexp1.html

When I hear, "I want you to develop a mini google.", I feel that the only right answer to the question is, "No thats not a problem that needs to be fixed anymore. Lets actually fix a real world problem that affects real world people."

There are very few new generation software engineers that are truly hackers at heart. Its really sad when a company like Google doesnt even know how to look for them anymore.

How is that a good answer at all? If I was asking a candidate that question, I'd expect them to make an inverted index

On a related note, given that Google has been using their hiring and employee performance data to try to improve their interview process (http://www.linkedin.com/today/post/article/20130620142512-35...), I wonder whether they have also managed to identify good and bad interviewers.

not a bad read but please less "failcatz" pics on the body next time. maybe they can be tiled on the side or something?

+1 for "get up and deal with it".

Well since he was asked to make a "mini google" speed and parallelism are non-concerns.

So your plan for your mini Google was to iterate through every entry in the index? (Setting aside the ludicrous idea of iterating through a hash when you can just ask it for a value by key... or am I missing something? Please enlighten me if I am.)

> If im ever being interviewed by Google, i'm going to say "hold up let me google the solution to that real quick."

If Google just wanted people to take existing publicly known parts and hook them together, they would be recruiting people fresh out of community college instead of fresh out of masters and PhD programs, and they'd be offering around $50k/year salary.

Google is trying to find people who can create the parts that ordinary programmers hook together.

I really can't get behind this kind of thinking. If you can't do what came before, how you plan on advancing the state of the art? Knowledge is hierarchical, one cannot get by forever by just googling the answer to everything if you're expected to be pushing new boundaries. Testing if you know the fundamentals is legitimate, even if there's already a million implementations of them on the web.

While you're not expected to be an encyclopedia of knowledge about any particular language, framework, or API; having the frequent need to look things up is a red flag because if you're always looking things up you may not move fast enough.

Also, having the "this is not a problem" attitude is a red flag; what else would this person not consider a problem when I hire them?

Then you've turned the interview into a waste of time. There is no actionable information that is produced from that answer.

If you honestly are looking for a job and aren't looking to make some kind of F-U 2 The Man statement, do yourself a favor and don't give an answer like that.

This just seems silly to say.

If you were asked to write a regex engine as an exercise you'd say "No thats not a problem that needs to be fixed anymore."?

How would you expect to be able to improve performance of regex engines without understanding how a basic regex engine works?