51–60 of 225 posts
Fact is, it just isn't true. As a Googler, I am surrounded by enormously talented engineers, the likes of which I rarely encountered on the outside. They love what they do, and it shows. I have no doubt that there are false negatives/positives, but I am convinced that Google is doing something right.
A slightly...biased perspective?
The interview process took about two weeks and on the whole was pretty reasonable for both sides.
There was a short phone screen (~30 minutes)
Then I had two technical exercises to do. For each, I was given a reasonable time period (4 hours) that started when I visited a special link to the get the problem description, and then used whatever tools I wanted to get it done, then email in the completed exercise.
The two exercises were not completely trivial, but were relatively straightforward and actually involved skills relevant to the position and not arcane puzzles or comp-sci theory. (Basically, the first was to write a Postgres schema from scratch (total 5 or 6 tables and maybe 30 columns across all the tables). The second task was to write a CSV parser (including reasonable error checking/recovery) to load data into the schema from the first problem.
Finally, there was the main interview (conducted via Facetime, this is a remote position). That ran for close to 3 hours.
This worked well, since it gave me a feel for what the work would actually be like, and I was given, as the candidate, every oppurtunity to put my best foot forward - no whiteboard exercises, no surprises.
Fact is, it just isn't true. As a Googler, I am surrounded by enormously talented engineers, the likes of which I rarely encountered on the outside. They love what they do, and it shows. I have no doubt that there are false negatives/positives, but I am convinced that Google is doing something right.
Have you encountered anyone outside? Sure there are talented engineers there but so are engineers in startups and other companies. I'm afraid that's a very myopic statement.
I'll be the contrarian and claim that inverting a binary tree is a perfectly reasonable interview question. (Although not anymore now that it's famous). It combines basic background knowledge (what is a binary tree and how is it structured?), ability to reason logically (binary tree algorithms are often recursive, "inverting" a tree with no children is a no-op, otherwise you want to swap the children, and the childre…
Why not ask questions about, say, working with a general tree data structure, like XML or an HTML DOM? That's something that comes up all the time in many fields. Why the obsession with low-level pointer juggling?
Earlier quoted context omitted.
How about sitting the candidate down in front of an actual computer, or ask the candidate to bring in their own laptop? Then if you want to see how they do, pick out some open source projects that need a feature or two added, or a bug fixed, and have the candidate walk through some solution? This way, you are getting to see what their style is, and the random open source projects gets a potential improvement. And you…
So instead of giving them an algorithm problem that they might have seen in the past (or seen something similar) you give them a random open source project -- along with all the idiosycracies it certainly contains -- that they are 100% unfamiliar with and ask them within a few minutes to make sense of the entire codebase and produce a meaningful contribution? Sorry, but that sounds even more cruel and unusual than as…
That's at minimum a day's work for most tasks, and sometimes two if setup or debugging turns out to be more difficult than expected. It definitely doesn't scale as an in-person interview, but by doing it asynchronously you lose a lot of the live communication and thought-process data that current interviews provide…
…then again, you could take this opportunity to measure their ability to give asynchronous status updates instead: can they clearly document their progress, the challenges they faced, and how they overcame them?
I enjoy the challenge of programming interviews. When I interviewed in Mountain View, I thought it was just super cool to have been invited. It was like the mother ship had summoned me home! I was mega-underwhelmed when I botched the last session, though. And after doing so poorly, no one escorted me out or summed things up. Efficient, I suppose -- I'd met with the recruiter at the beginning of the day and there was…
I don't mean to personalize this to you, but your story kinda illustrates one of the problems. There's so much ego and self-worth tied up in both sides of this style of "interview". Both sides have this overwhelming need to show how smart they are. It's understandable in some ways. It's part of what attracts people to the field, showing off intelligence. I'm guilty of it myself. But it makes the "interview" process h…
^This guy gets it.
I've never understood why interviews are set up to put the interviewee on edge and make him or her feel out of place, while simultaneously putting the interviewer in a temporary position of ultimate power. Said position does one of two things based on their personality: Makes the interviewer feel superior and aggressive, or makes them uncomfortable and ready to get it over with. Neither situation is good for the people involved nor the process itself. You're basically testing an employee on non-work-related problems under artificial pressure, which is pointless.
And I say all of that as both an interviewee and interviewer in the past.
I enjoy the challenge of programming interviews. When I interviewed in Mountain View, I thought it was just super cool to have been invited. It was like the mother ship had summoned me home! I was mega-underwhelmed when I botched the last session, though. And after doing so poorly, no one escorted me out or summed things up. Efficient, I suppose -- I'd met with the recruiter at the beginning of the day and there was…
Interviewing is hard (from both sides). Sometimes it just isn't your day. Sometimes it just isn't your job. I was quite depressed when I screwed up that interview because it was the first one I had done after taking 5 years away from programming professionally. I was definitely rusty and I was secretly worried that I wasn't going to recover.
But, in retrospect, I'm glad I didn't get that job. It's a bit like the situation of being asked to TDD building Pascal's Triangle. I am an avid TDDer and I would have a hard time doing justice to that problem. Of course it is easy to get started, but then at some point there is going to be a "and then there is magic" bit because you are trying to test a function that is outputting an infinite sequence. It could make a fascinating conversation, but I think it says alot more about the interviewer than the interviewee.
Unfortunately, just like there a people who look like they would be amazing an amazing hire, but turn out to be so-so (at best), employers are the same. The the 10x employer is probably more mythical than the 10x employee.
Not sure what OP is being proud of exactly. I was subjected to this style when I interviewed at Twitter. Sorry my op sounded like I was accusing the author of something but this whiteboard approach is what I did at Twitter.
My experience with Twitter was really odd. I knew someone internal and had them directly submit my resume with a recommendation. The resume was tailored for exactly the position they wanted showing me besting all of their requirements. I got an email 4 months later telling me my resume was not good enough for even a phone screening. I've never had that happen before and it's still perplexing.
I'll be the contrarian and claim that inverting a binary tree is a perfectly reasonable interview question. (Although not anymore now that it's famous). It combines basic background knowledge (what is a binary tree and how is it structured?), ability to reason logically (binary tree algorithms are often recursive, "inverting" a tree with no children is a no-op, otherwise you want to swap the children, and the childre…