Typical Google waste-of-probably-a-decent-engineer. A javascript coder getting asked sorting algorithm questions and Big-Oh notation. What a waste of time. Google just doesn't get it.
I know all you fanboys out there will say "you need to know this stuff to be a generalist software engineer" but c'mon, hire experts in sorting algorithms if you need that for some obscure bigtable ultra-performant section of code and leave it at that.
Need another example of wasting everyone's time: "She told me they primarily hire strong C++ and Java developers, something which I have very little experience with." Gee, Google, glad you still brought him in when he clearly has no interest or background in that.
I guess I don't understand the 'I failed to do this, let me give you advice now' movement. From his own description the author is woefully under qualified.
Interviewing is one of the purest Bayesian actions people do. We have to take a bunch of limited and incomplete information about a person and try to determine whether they are likely to succeed or not. Most interviewers would love to find people that are smart, able to learn quickly and well, and motivated, excited energetic. The best measure of these things isn't whether the person seems smart, or energetic, everyone is trying to seem smart and energetic and positive in an interview. The best measure is whether they were smart and energetic in the past, and the best guage of that is how deeply they learned in previous experiences. If they are a 'javascript programmer', not knowing javascript syntax by heart is a strong indicator they just kludged through without much deep interest in what they were doing.
Being unable to program on a whiteboard means you don't really know the language you are using. Relying on an IDE to prompt you every time you make an error is a huge crutch, and IDE's can only help you with obvious cases, there are many times where you can get code past the IDE as syntatically correct but logically wrong.
Being unable to program on a whiteboard means you don't really know the language you are using.
This is nonsense. I have a degree from MIT. I've spent the last 15 years programming in C++, Python, Scala, Lisp, Java, SQL, and JavaScript, etc. I've worked on compilers, space telescopes, and brain surgery software, and I know all of these languages fine. There's no way that I would be able to program on a whiteboard without a lot of practice, however. Most likely, I wouldn't be able to remember my own name if you made me stand at a whiteboard to program in an interview situation. Fortunately when I interviewed at Google they let me use pencil and paper.
Btw, I use Emacs much more than an IDE, and much of the knowledge I have for syntax is built into my typing fingers.
Coding with pencil/paper is in the same league as coding on the whiteboard. It's not nonsense and you know it too. You just deliberately missed the point of his post just so you could brag about being from MIT and all the stuff you worked on.
It is nonsense. I feel more strongly than you can apparently imagine about this issue, and I would never knowingly interview for a job that requires coding on a whiteboard or on paper. I made a single exception for Google, and I had to take tranquilizers not to throw up during the interview. I consider this kind of interview to be borderline abuse. It serves no useful purpose that can't be better achieved through different means other than to humiliate those whose brains don't function well under this kind of pressure.
Btw, as far as I'm aware, Google didn't traditionally allow coding on paper--they always required coding at a whiteboard. As I understand it, Google Boston softened this requirement because it's rather counter to MIT culture. In four years of undergrad schooling at MIT and quite a few additional classes as a special grad student, no one ever made me work on a whiteboard, or do any kind of work at all with someone staring over my shoulder.
Yeah, I'm very curious to find out how this whiteboard stuff got to be considered universal. I too am an emacs user who programs in diverse languages (and never uses an "IDE" unless you count emacs), and find it disturbing that corporate gatekeepers really seem to believe things like, "Being unable to program on a whiteboard means you don't really know the language you are using."
I have two whiteboards and a chalkboard at home; I never code on such contraptions. (I like to draw pictures for programmers, but using Balsamiq or something.)
Now, obviously if I were in a situation where showing off whiteboard-coding were useful to me, I'd practice until fluent. But it's so bizarre, this fetishization of whiteboard technology.
Maybe it's good to communicate using pictures, rather than symbols. But if that were the real reason for whiteboard interviews, interviewers would speak of pictures; not whiteboards, nor syntax. Or one can argue that companies like rely on whiteboard tech to communicate; but then why not ask prospective workers to practice it as they would vi or emacs? Or spread the gospel somehow? Is this some weird entrance test, to see if a candidate proactively adapts to this weird obstacle?
As an interviewer, I'd feel I've ironically failed a meta-test, if I didn't accomodate a significant number of people's feelings on this matter. I would therefore not be fit to judge anyone's ability to think effectively.
"I made a single exception for Google, and I had to take tranquilizers not to throw up during the interview. I consider this kind of interview to be borderline abuse. It serves no useful purpose that can't be better achieved through different means other than to humiliate those whose brains don't function well under this kind of pressure."
Is this really because of the whiteboard though? Interviewing is a stressful thing to go through, and no process is going to be perfect for everyone. I agree that in general it can be harsh on candidates who are not glib and extrovertive, but this doesn't have much to do with the whiteboard.
Yes, I have no problem at all with a "traditional" job interview. Even ones where I've been given a paper exam and then left alone for a while have been okay. Though I also find that kind of interview to be rather distasteful, I've never actually had any problem doing well on the exam. Doing well on written exams (with solitude) is a skill that anyone who has graduated from a good school probably has already been forced to acquire.
Because at least that was slightly better than being forced to program on a whiteboard. At least I was able to muddle through and do something half-assed, rather than nothing at all.
Coding on a whiteboard or paper/pencil may require you to use the academic portion of your cs knowledge. I know all my CS exams involve writing code on the test paper...
At MIT I did almost no coding on paper. For programming classes, most of the grade was always determined by very substantial coding projects and problem sets.
There was the occasional exam with some coding, but the coding was typically rather easy (i.e., to demonstrate a CS concept that you would have been recently taught, and practiced on a problem set) and not time pressured. There was also certainly no one staring over my shoulder.
>> I wouldn't be able to remember my own name if you made me stand at a whiteboard to program in an interview situation. Fortunately when I interviewed at Google they let me use pencil and paper.
i don't think the top comment means literally a whiteboard. i think his argument is that if you can't program relatively basic things away from a computer, you don't really know how to program.
Knowing how to program means knowing how to program a computer. Not a whiteboard, not a piece of paper, and certainly not with someone standing behind or over your shoulder. This is not a test of whether you can program; it's a test of whether you can tolerate extremely stressful and potentially humiliating situations without vomiting.
Part of programming is laying out your data structures and algorithms in advance; you can perfectly do that on paper or a whiteboard. A whiteboard is even better at demonstrating pointer manipulations, since you can easily wipe out arrows with your hand and draw new ones.
Someone standing behind you, looking over your shoulder, might be a bit intimidating at first, but if you have your reasoning figured out for yourself, there is no reason why you couldn't speak out your thoughts out loud and let others know the way how you came to a solution.
You are a victim of the apparently common misconception that everyone smart thinks exactly the same way that you do. I don't work the way that you think I should and I don't want to. I often just write a little bit of code to get my brain primed, with no intention to keep even one byte of that code in my final program. It may even be utterly wrong, but that doesn't matter--it helps me get started. Or, I might just stare at the wall for ten minutes until inspiration hits me. Or I may decide to go do something else entirely and let my subconscious mind work on the problem. Then the answer often just comes to me in the middle of something else. Sometimes the answer comes to me, literally, while I am sleeping.
When you would ask me how I came to the answer, I wouldn't be able to tell you: I primed my brain and then eventually a lightbulb turned on.
But doesn't this just show that I'd never come up with a timely answer? Not at all. I took many tests as an MIT student in which I got A's and which I worked in precisely this manner. I didn't know how to solve a certain question, so I moved onto another question and then came back to the unsolved question. Often by the time I did, I just now knew the answer. On other problems, I'd do work and then cross it off and start over.
I could work this way because I didn't have someone staring over my goddamn shoulder asking me what I'm thinking every goddamn step of the way. If I have to explain myself constantly, I just get flustered when I realize that I said something completely stupid, and then I can't continue with my natural thought processes.
I cannot assert strongly enough, that the process that you claim that anyone smart should be good at, does not work for me.
I interviewed with Google at the end of last year. The only thing I took away was that their recruitment people aren't very good at pre-screening and they seemed to like wasting my time.
The first two interviews were OK, basic UNIX admin and software type questions, I could answer most off the top of my head. The third was with someone who certainly had a maths degree and wanted to make sure I knew it.
i hear stories like this a lot. serious question... why does Google ask standard comp sci questions when interviewing for front-end developers?
in over 10 years of front-end development for non-trivial business applications, i have yet to encounter a scenario where ignorance of bubble sort prevented me from doing my job well.
i can tell you what i value when interviewing a front-end developer - in depth knowledge of cross browser quirks and coding techniques to address said quirks (sans jQuery). someone who can tell me what OOCSS is and why it's beneficial. someone who values every pixel, http request, and div like it was their last and uses them wisely.
i don't discount the value of standard comp sci knowledge, but i get rage face if someone judges my skill as a front-end developer based on how well i answer those types of questions
lastly, ever view source of any Google app? that tells me all i need to know about their idea of a front-end development
Similar to how graduating college shows you were able to work hard and learn many different subjects effectively for four years, being able to solve a google problem shows that you A) are smart enough to have understood and retained it from when you were first taught it or B) were driven enough to sit down and learn tough conceptual problems in a few weeks.
So, its less that you know that particular subject, and more what you being able to pick it up is an indicator of.
My point is that most of the very best front-end developers I've met don't have CS degrees. So it seems unfair to penalize them for something they've never been exposed too. There are other ways to assess someones conceptual ability.
The questions asked illustrate what the interviewers know and don't know. Google is reputed to have a mono-culture of CS-heavy people. They know CS-related questions the best and that what they would ask.
When you're as concerned with frontend performance as Google is, computer science knowledge can really come in handy. For example, they wrote their own compiler for Javascript to check for errors and shrink down the code to an absolute minimum, by e.g., shortening variable names and pruning functions that are never called. This means they had to write a their own parser, run various graph-based algorithms to follow references, iterate and transform the abstract syntax tree, etc.
And I'm sure the frontend guys were working on that.
Don't you think it's better to hire compiler experts for that exact problem rather than worrying about whether some frontend dude can write his own JS parser?
Someone who is working on the front-end without basic familiarity with computer science may not recognize such optimization opportunities and may not call a compiler expert in. Also, basic familiarity of computer science is useful for having the chops to validate an idea before wasting the time of an expert.
Using "view source" on an app like Gmail or Maps is a terrible way to judge their front-end developers. The JavaScript might have gone through the Closure compiler, which is a seriously cool piece of software. They might treat the markup with something similar, I don't know. I would base my judgement of their front-end team on the quality of the software as a user, and I think Gmail is the best web-based email app and Maps is the best web-based maps app... so I have a lot of respect for their front end teams, regardless of what the source looks like.
I got a call to interview with Google 10 months ago. Had two phone interviews which went well, could not answer a Javascript prototype object model question, but the interviewer was very kind go explain me where I was wrong.
After a few weeks went for an interview at their MV campus, awesome place. Of the 4 interviews of 45 minutes each and one lunch session that I had, I would say I did good in 2, fine in 1 and goofed up 1.
I did not get an offer, I had guessed that with how my interview went, but my hopes were high :-). All in all I learned new things, met some excellent people and had a great time.
I had read online about the white board process, so I was prepared for that. I really feel for the interviewers that they had to sit for 45 minutes looking at my bad handwriting ;-). The only thing that I could not understand was why when I was not being interviewed for a traditional engineering role, I was being questioned about Big O, algo design etc. The HR lady told me it would be related to the area of my work (Web development, Javascript, Open source contributions etc), but the interview at MV was not at all like that.
Having read other peoples experience with interviews at Google and the scale of their APIs, I think at some point they are looking for people who can do whatever is thrown at them and not just be bound to the technologies they know. All the CS questions they asked me, I feel they were justified to ask them, they wanted to find out if I will be able to work in other areas if need be and not just be "a frontend developer". The interview was easy, I was just not prepared to answer those questions.
Given a chance, I will do it all over again, but this time will go mentally prepared for a CS 101 interview as well.
Sometimes I feel like it's a total crap-shoot with getting interviews at some of these large companies. There were quite a few positions available in the DC Metro area that I was probably more then qualified for or at least qualified enough to get a phone interview. Needless to say, I was never contacted. It's good to know that some people actually get to a phone interview :)
The big companies get so many candidates that they can't possibly do all applications justice. So they rely on referrals. If you know someone at the company, asking them to pass on your CV will hugely increase the chance of getting a phone screen.
"So they rely on referrals. If you know someone at the company, asking them to pass on your CV will hugely increase the chance of getting a phone screen."
This is probably the best piece of advice you can give for starting the job application process. Having an internal person already working in the company recommend you to HR will immediately put you on the top of the queue. At the very least, you'll get an initial phone interview quickly. This is, in fact, the only way that I've able to have successfully get in the door, at both small companies and also larger companies like Google and Microsoft.
The other option is the "career fair", but that tends to only work if you're still a student or near-student status.
Do you really want to be subjected to coding on a whiteboard?
Edit: Instead of down-voting, why don't you explain to me why you would want to code on a whiteboard when it's completely pointless. Might as well throw in some of those pointless questions like why are manholes round?
Whiteboard coding is good because interview questions are not about specific 100% solutions to complex real-world problems like programming usually is. Interview questions are about general problems whose solutions will fit nicely onto a whiteboard. You lose the ability to get realtime syntax highlighting, but you gain the ability to have multiple trains of thought, the ability to draw diagrams and arbitrary symbols, and the ability to point at things as you explain your thoughts to the interviewer. Do you really enjoy it when someone comes over to your laptop to ask you a question about code? Now imagine that for four hours in a row. That's what a laptop interview would be like.
When I was interviewing at Google, someone asked me a question that required me to remember some math. I did not remember it, but I knew how to derive the answer I needed. So I went to another whiteboard, talked my way through the sub-problem while drawing some math symbols, and then transferred the answer back to the original problem, halfway completed on a different whiteboard. Try doing that while hunched over your laptop.
I agree that this process is nothing like the job you're interviewing for. That's because it's an interview, not the job. We try to get a picture of who you are and what you know in a few hours, and that's just not enough time to let you loose with a laptop to see how you approach real-world problems. Not to mention, real world problems don't often involve much "computer science" knowledge. But you still need to know that so you can confidently attack problems that venture into that area.
And largely, the process works. There are very few programmers at Google that can't program. If I have an idea, I can explain it to pretty much anyone, and get good feedback. At other jobs I've had, I've had to explain thing like arrays to coworkers. That means I'm not going to get any feedback on my complex idea, and that sucks. Google is not like that, because we filter those people out at the interview.
Not too long ago I would have agreed with you, but I've recently changed my mind. Coding on a whiteboard is not completely useless:
1. It's a good indicator of how much you know for simple problems.
A few weeks ago I started helping a friend with a particular language and framework. He claimed to know it, having read several books on it. So I said great, go to the board and write a function that adds two numbers together. And he couldn't do it. Who knows, maybe he could have done it on a computer? Maybe he would have Google'd it quickly, or relied on code autocompletion, or the muscle memory from his fingers typing it, etc. But that's not what I wanted to know. Anyone who's written thousands of functions in a particular language could write a simple one like this on a wall, using paint, while hanging upside down. His inability to do so told me: he is not well-versed in this language. PERIOD.
2. You can practice.
"So what", you protest. "Google isn't going to ask simple problems. They'll ask hard ones." And maybe they will. And maybe having to solve it in a foreign way really will fuck you up. But my question to you is: If you know you're interviewing at Google soon, why the hell would you allow whiteboard coding to remain foreign to you? If you suck with whiteboards and you care at all about getting the job, then buy one and practice solving problems on it. Why would Google want someone who doesn't care enough to prepare for their interview? It's not that hard of a skill to pick up. And I daresay it will make you a better, easier-to-communicate-with programmer.
If there was one thing I could tell all applicants at Google, it's to read up on the process, and practice. There is a huge amount of information out there[1]. I feel sad interviewing really smart, capable people who could have breezed through with just a few hours of review and practice.
I imagine it must feel horrible interviewing smart people who would do great at work but whom you are unable to hire due to arbitrary hoops set up by your own company.
> 1. It's a good indicator of how much you know for simple problems.
Google doesn't solve simple problems.
> 2. You can practice.
Maybe if the interviewee was still in college they could "practice" coding on a whiteboard, but considering they may have other obligations like family and work they probably won't have time to practice such a pointless skill.
Personally, I wouldn't need to practice in the first place as I interview extremely well and could easily code on a whiteboard, I just find it antiquated and pointless to do so which was the reason for my comment - not because I am bad at it.
Yes, but that doesn't mean you don't need to know how to solve them. If you can't solve simple stuff, you won't be able to solve hard stuff that depends on knowing the simple stuff cold.
they may have other obligations like family
and work they probably won't have time to
practice such a pointless skill.
Yes, that's a possibility. But once again, if you're Google, you're getting 10s of thousands of applications a week. You can afford to set the bar as high as possible. Every Google employee I know regularly works 10+ hour days there, and sometimes does work at home, too. If you have two applicants of similar skill, but one has more free time to devote to your company, it's obvious who you'll prefer.
I work at Google. We write (diagrams and code) on whiteboards on a regular basis. We don't ask you to do it during an interview because we're sadists, we ask you to do it during an interview because working here, you will be doing it in the course of your ordinary work.
Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.
I worked at google for four months. That wasn't my experience at all. I ended up on a team that despite working in the same office, barely spoke with each other, rarely ate lunch together, lost 1 member for each month I was there, and I didn't even have a 1 on 1 with my manager until 3 months in when I asked him why he was having 1 on 1s with everyone else, but not me. It was the singularly most soul-killing work environment I've ever encountered. What is this strange concept of whiteboard coding and collaboration of which you speak?
The relevant job skill here would have been the willingness to do anything for the great pay and food. I wasn't and I had other employment options I chose after it became clear I would not be allowed to jump to another project anytime soon.
I love working at the whiteboard -- my best ideas come while working at the whiteboard. But writing code on a whiteboard during an interview bears little resemblance to the code/diagrams written on a board during day-to-day work.
Day-to-day work is necessarily collaborative and productive... Whereas when at the board in an interview one person knows the "answer" and is across the table testing the other. It's a completely different set of pressures and requires different skill.
Further, I must have one of those faces people pity because its often that when I end up at the whiteboard the interviewer wants to "help" me if I don't spout off the answer immediately (I've learned to at least start talking so they will give me a second to think). This sometimes entails them trying to lead me down a path which is not the way I would have approached the problem. I'm confused, they think I'm an idiot, now I'm flustered, could this interview go any worse?
I've learned to politely ask for a second to consider and usually that completely solves the problem. I've been successful in technical interviews -- but the idea that it's the same thing as when working out hard problems with team members seems a little silly?
... will typically code better with a keyboard and
editor than someone who relies on the keyboard
and editor to be able to code
The whiteboard sucks for problems for which you either don't know the solution, or for which you know the solution intuitively, but can't reproduce it line by line in successive order. In such cases people go back and forth, adding new functionality or correcting the existing lines to fit a new condition ... and this happens a lot for recursive algorithms. For instance I cannot reproduce the in-place QuickSort line by line, but I can work it out by evolving it from the basic idea, a process that takes a couple of minutes and a lot of corrections.
So you're basically encouraging people that rote-learn solutions and that line above is bullshit.
Leave room between the lines so you can add stuff. Mark it up as you evolve it. If you need to, you can rewrite the clean version on another part of the board. Better yet is if you can figure it out in your head before you start writing, becaus that will definitely make you a better coder.
> Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.
That is very subjective and I'd love to see some evidence of this.
Once upon a time I was working with a psychologist who wanted me to do a take-home exercise. Knowing that I was a software developer and an excellent typist, she insisted that I perform the exercise while writing by hand. She said that it was because I would be using a different part of my brain when handwriting than if I were typing.
Which brings us back to the whiteboard interview. I ask: If I am correctly interpreting what the psychologist said, why force interview candidates to use their brains differently than they normally would while coding?
I can't downvote, but I fail to see what's the problem with "coding" on a whiteboard and why people are stressing out over it. When I interview people I ask them to write code on the piece of paper. All I'm looking for is a presence of a half-decent idea and them not using things like strlen() when iterating through a C-string in their doodles. The rest we will talk over. I never expect polished code on the whiteboard, it's always a starting point for a conversation that follows.
Yeah, it's just to see if a person understands that some basic pointer operations and that regular strings in C are "special" because of their \0 at the end.
do employers really expect candidates to right syntax accurate code on a whiteboard? I just always assumed that pseudo-code was appropriate. There are a lot of key strokes that my fingers know but my brain doesn't. It's very easy to get confused and thrown off your game.
do employers really expect candidates to right syntax accurate code on a whiteboard?
Yes they do. I've still got my Google 'Hire Squad' t-shirt somewhere (when you get trained on how to do interviews at Google you used to get a t-shirt) And they expect the interviewer to transcribe what you write on the white board into your feedback so that the hiring committee can read your notes and know what you're talking about.
You see the part you've missed here is that at Google, the person doing the interviewing has nothing at all with the person deciding if you should be hired. They interview you, using the techniques they were trained to use, they transcribe the whole thing like a court reporter, adding what color they can and a float between 0 and 4 (0 is 'run way', 4 is 'walks on water') And the then that goes into a 'packet' which gets sent to a hiring commitee where a different bunch of people read it (and the notes of everyone else) and they they decide if you are going to move forward in the process.
Writing syntax accurate code on the white board is always a plus. Although one candidate on seeing the dozen different color markers, wrote both syntax accurate and colorized code. That was good for a chuckle (and strangely I think it got them points in the committee).
And the then that goes into a 'packet' which gets sent to a hiring commitee where a different bunch of people read it (and the notes of everyone else) and they they decide if you are going to move forward in the process.
Doesn't most of the personality of the person get lost in this setup? I mean, hiring people purely on technical merits may sound fine, but I'm not sure if that makes for a very pleasant working environment.
Compatibility with Google culture is something that the interviewers are trained to look for. You can't do an interview until you've worked at Google for more than 6 months, for this reason.
I think the whole hiring committee removes a lot of biases that people may have and the end result, in my opinion, is a workplace that's a lot more diverse than any other I've been at.
I don't necessarily expect candidates to have perfect syntax for a given language. (there's a presumption that they would be able to look up correct syntax in practice) At the same time, if you're unable to express your ideas in something close to real code, it is a signal that you're not sufficiently familiar with the language you chose.
Excepting declaring funky things like arrays of pointers to functions in C, what competent developer doesn't know the syntax to his or her own best 2 or 3 languages?
There is a difference between forgetting to put a semicolon at the end of a line (totally harmless on a whiteboard interview), and not knowing that semicolons end statements in C.
Of course, not knowing say, part of the standard library, say the semantics of rand(), without a man page or Google search is much more excusable.
OR you can hand the applicants a laptop and allow them to write code, which is what they are going to be doing on the job presumably. or does Google develop their applications on whiteboards now? I'm thinking a Minority Report-esque digital screen that programmers drag/drop with voice activation to "code".
In all seriousness, I really don't get whiteboarding in interviews.
For whiteboard coding, I've always given interviewees their choice of programming language and have said, "Don't worry about syntax." For me it's more about how you approach the problem than whether you can spell correctly.
I code in a variety of languages and every time I use .indexOf(), I can't remember if it's (needle, haystack) or (haystack, needle). Of course, my IDE shows me the correct way and I go with it in 0.3 seconds.
On a whiteboard, if I were marked down for getting that the "wrong", I don't think I'd like to work for those kind of people anyway. I have no interest in memorizing the exact syntax of every standard library call in every language. When I can look it up almost instantaneously, my mental efforts are best spent elsewhere.
I think there is a difference between if you know the API the language provides and if you know the syntax of the language.
I don't care if they can't remember order of parameters, or really even the name of the methods. But if you can't write syntactically correct code without an IDE, it seems like a problem.
Probably depends on the employer. I've always asked people to write actual code, rather than pseudo-code, because I've found that a lot of pseudo-code I've gotten doesn't make sense or majorly glosses over things. (Think "and then a miracle occurs".)
But I personally wouldn't dock a person if they screwed up the syntax on a whiteboard coding interview - I really use it more as a way to extend the conversation. I do have the bad habit of correcting syntax, though, because I find it too distracting once I see it.
Coding syntactically correct code on a whiteboard is a waste of time. Drawing pictures, diagrams, and pseudocode while trying to solve a problem with others is a great way to get collaborative work done.
DC office is funny. It's so small it doesn't have it's own recruiters. The recruiters in Denver handle recruiting in DC. So if you want to interview, talk to them.
Also, if you do interview, keep in mind you'll have to travel to MV for a full day interview and also a full day interview in DC. Which is actually nice if you have the time; the DC team is so small that they want to be selective with future team members.
The DC projects were cool too, one was google code I believe, and the other was a tool to allow the collection of data sets such as water well tests in developing Africa, etc.
Google only hires 1 in 1000 applicants or so (at least that's what they tell you on day 1). Try not to take it personally that you failed buzzword bingo with their recruiters.
Perhaps someone should take a look at your resume to find out why?
The most likely explanations for a company like Google using whiteboard questions:
- These interviews are easy to give for someone without good interviewing skills, which is basically everyone.
- These interviews are relatively easy to score.
- Google acquires superstars through acquisition. If you need some competent rank-and-file (i.e. a "pool") to support the superstars, whiteboarding is maybe an okay way to weed out people who definitely won't rise to the occasion.
It's a little insulting, but their pay scale probably balances that out.
I had the opportunity to interview with Google. Overall it was a great learning experience, and demonstrated to me the skills and aptitudes required if I wanted to play with the "big boys".
Regarding their interview questions, you either know it or you don't. From my personal experience, Google's rounds of questioning are intentionally designed to weed out the people who fake it or try to cram up beforehand. For software engineering, they are interested in applicants who naturally demonstrate keen skill when it comes to CS fundamentals (algorithms, data structures, discrete mathematics, etc.).
Throughout my phone interviews, Marissa Mayer's quote "A good student excels in all subjects" kept running through my head. After interviewing with them, I believe Google holds all their employees to a similar standard.
>The HR rep sent over an email with some guidelines and things to brush up on which included comp sci 101 things such as sorting algos, hash tables, binary trees and so on.
Does your NDA allow you to post these guidelines? Is so, please do.
It's all about how you think under pressure. You have to know the basics, for sure, but the interview is much more about seeing how you think and work through problems. If you are getting asked to implement merge-sort or something, probably not a great question. But whiteboard algorithm questions let the interviewer see your thought process and how you think on your feet.
Because they're Google. I know that's tautological, but I remember a blog post from some time ago about a guy complaining that all his friends that had been hired by Google had suddenly stopped chit-chatting about technical issues that they encountered at their workplace. They stopped doing that during the usual "at-a-drink-complaining-about-our-daily-job-ordeals" sessions, or on their blog, or anywhere else that might be publicly shared (and, why not? , maybe help other people learn from their (Google's) mistakes). The guy even compared Google with a "vortex", if I remember correctly.
There are some extraordinary situations where it really does make sense: an example I read on HN a long time ago was the first cellular radio engineers that Apple hired before building the iPhone. The simple fact that they interviewed for a job might have been under an NDA. This desire to protect secrets probably gets extrapolated and trickles down to every technical candidate.
I don't know if this is the case for interviews or not, but in general, you do not have to sign the NDA to visit Google. If you choose not to sign it, you get a different looking name sticker, and Googlers have to be careful not to show you anything that could be confidential. You're also restricted to common areas; you can't see your friend's desk. If you sign the NDA, you are allowed to see everything (within reason), and Googlers can be a little less guarded around you. But if you just want to have lunch at Google or attend a LUG meeting, you can do that without signing anything. In theory.
Do your profession a favor and DO NOT sign an NDA in this situation. It's just terrible. Same goes for people that sign non-competes, and thought-police agreements upon being hired.
Don't do it. It's optional, you have the right to refuse. By signing you are putting a huge amount of liability on your shoulders for no reason. You're giving that company the right to sue you for practically any reason they can conjure up.
Them: We're going to tell you secret stuff during the interview. Promise not to blab?
Me: Yeah, sure.
As far as non-competes and IP-assignment, from what I've seen these have gotten much more reasonable over the past 15 years. If you write or invent it on the job, it's a "work for hire" and the company owns it. What's wrong with that?
If you don't want to sign, that's fine. But there are probably 400 to 1000 other people interested in that open position, and 99% of them are going to sign the NDA.
Them: Please sign this NDA.
You: No, I don't sign NDAs.
Them (looking at the next guy in line): NEXT!
This might just be me, but I interviewed with Google on-site about 10 months ago and never signed an NDA.
It wasn't even offered to me - and this was for an engineering job. So I wouldn't say it's 'standard', even at Google. That said, I've also never seen anyone blogging about their Google interviews who hasn't signed one, so maybe they just forgot the paperwork for me!
Are you sure? Do you remember entering your name on a touch screen in order to get your visitor badge? Yeah, there was a legal document in there. Probably should have read that.
I'm glad that you had a pretty good experience overall. I know that lots of folks at Google have worked to try to make interviewing less painful (like limiting the max number of interviews you'll have to do). It's nice to get an independent datapoint where the experience was pretty good, even if it didn't work out this time.
Well, here's what I learned interviewing at google:
Be very good at off-the-cuff 80% solutions to topcoder problems on a whiteboard, which I am. So much so, that when they told me to use whatever sort algorithm I wanted to, I used bubblesort on purpose, to prove a point, and got away with it. Later on, I reduced another interviewer's search problem to a polynomial equation that had integer roots when a solution existed (at which point he asked me what I'd do on an architecture that didn't have a square root or a divide function and I replied "and what modern architecture would that be?"). Which is to say their interview process is a computer science puzzle game IMO. The skills displayed here have at best a loose correlation with one's engineering skills, and that non-correlation shows up like crazy in their codebases (but Steve Yegge already covered that far better than I can).
So if you are a demo coder at heart, and you've been paying attention to whatever technologies are the flavor of the month at google interviews by reading blog entries like this (apparently javascript these days), you'll do just fine.
In my case, it only took one round for me to get the offer which I (unfortunately) accepted (but the tale of my 4 godawful months at google thanks to naively letting myself get blind-allocated into the wrong team is a different story).
Google is a great company, really it is. I know lots of relatively happy people there, but focusing on the interview process is a mistake. The real challenge is to get yourself hired onto a good team by resisting all the pressure they exert to persuade you to jump into the blind pool, which is a recipe for russian roulette. The solution, which in retrospect I smack myself for not doing the due diligence to find out, is to insist on getting allocated to and speaking with your future team as a condition of accepting an offer. Do not compromise on this point.
I'm in the process of negotiating for an engineering job with Google now and it's been extremely difficult to get any information about what positions they're actually hiring for. When I was there for the interview there was very little time for me to ask any questions about what the teams actually do and what I might be doing if I joined. This is very different from every other interview I've had before where I'm talking to the team members I would be working with.
Later, after talking with an engineering manager and getting agreement to be assigned to one team, they tell me I'll be working for some other team as if our conversation never happened. It's almost as if the attitude is that I should be lucky to have been offered a job and I should be happy with whatever I'm given.
Google hires into a general pool by design. It's because in companies where individual managers have hiring authority, every manager has an incentive to drop the hiring bar because it means he'll have more direct reports and more resources to accomplish his own goals. Perfect recipe for empire building.
The time to negotiate teams is after you get an offer. If you have any sort of negotiating leverage at all, you can probably exert some influence there. Basically, multiple managers "bid" on Nooglers, and then the manager from the highest-priority focus area gets him, modulo some input from the prospective employee himself. When I was hired, I was told I'd be working on Google Search, but the recruiter also said that if I didn't like that there were multiple managers in GMail and Apps that also wanted me, and I could go there.
In general, your goal should be to avoid getting marginalized. Typically, the highest-priority projects go to the best managers, who try to surround themselves with the best engineers, so your experience will be noticeably better on a high-priority project than a low one. The disgruntled Xooglers I know typically left because they got assigned to somebody's pet infrastructure project who somehow got headcount for a team of 3 or 4 but then has no idea how to run a software development project successfully, and no support for their ideas outside of their team. The happiest Googlers tend to be people in core Search, Ads, infrastructure (eg. MapReduce/Bigtable teams), research, or Chrome. These departments tend to feature large groups of loosely-knit, largely self-organized teams, and very hands-off management.
It could actually be a good thing that you ended up getting reassigned; it usually means that someone from a higher-priority area noticed your resume and swooped in with a bid. But you should be able to talk to the new prospective manager, or at least someone on his team. Every good manager I know will be happy to talk to a prospective Noogler that they want on their team if it means the difference between having them accept the offer or not.
BTW, I've noticed an interesting pattern where the culture of a focus area depends a lot on the first employer of the founder/SVP for that focus area. Search culture is Stanford culture. Chrome (which started from a bunch of ex-Firefox people) has a very open-source culture. Android culture is Apple culture with some Googliness thrown in (Android founder/SVP Andy Rubin worked at Apple for his first job). Google+ culture bears an unfortunate resemblance to Microsoft (Social SVP Vic Gundotra previously was in charge of .NET for Microsoft). Apps culture is a hodgepodge from various other companies (most apps were acquisitions). Infrastructure culture bears a strong resemblance to Bell Labs culture (former infrastructure SVP Bill Coughran was a VP at Bell Labs). I suppose the resemblance makes a lot of sense, and I wonder if other large companies have a similar effect.
For sure. Big industry names don't assimilate; they mold their environment to what they know (and they usually bring other people with them who come from the same place). Because of their clout, few will dare to disagree with them.
It is amazing how quickly a company's ecosystem can change when you bring in a big name from a different environment.
I'm not entirely sure, I don't work there and don't know all that many people that do. I think that core ads is like search, a heavily data-driven, scientific, Stanford-based culture.
My allocation seemingly had 3 options: one was completely unsuitable, one was desirable, and the third was where I ended up. I obviously chose the desirable allocation.
Unfortunately, two days into working at google, I was informed that my entire team was going to physically relocate in a few months and leave me with an 80-mile commute each way. So I said that was unacceptable and ended up with the third project, which I've already described elsewhere.
Don't worry about first project too much, it's perfectly acceptable to change projects after being noogler for few weeks. There is an understanding that not all projects are a good fit for all people, so I know few people who changed projects in few weeks after they joined.
> Be very good at off-the-cuff 80% solutions to topcoder problems on a whiteboard, which I am. So much so, that when they told me to use whatever sort algorithm I wanted to, I used bubblesort on purpose, to prove a point, and got away with it.
So the point is, "don't ask me to solve extremely common and easy-to-explain problems, because someone else has already written good solutions?" What are the alternatives? Questions about things nobody uses? Questions that are hard or lengthy to explain?
The best alternative I've heard about is something like a trial period, internship, or culinary "stage." That's a big investment for both parties to make without even finding out if someone can write and debug a simple program to solve a well-defined and familiar problem.
It's kind of a big deal that you pick the right algorithm. From what I can gather, the interviewer didn't care what algorithm was used, as long as the candidate could implement it.
This is kind of silly, and the candidate decided to be a smart-ass and rub it in by demonstrating a really bad algorithm.
They should ask "well, what do you think the trade-off should be? Given that, what's the best algorithm you know for this set of trade-offs?".
Interviewing is hard to get right, because it's confrontational. Bad candidates want to fool you. Looking at the total system, the best bang for your buck is getting better candidates to apply. I've met very few managers who do anything other than a piss-weak job at getting good resumes onto their desk. They often throw a rough job description to a some liberal ars major in HR, who puts the ads up then tries to prune down the candidates who's buzzwords don't match the requirements.
Often interviewers don't care about something that seems important because we know that one of the other interviewers has already tested it.
There've been times where I've had a candidate code up a solution and I didn't care whether he got the solution right or not. Because other interviewers had already given him coding & algorithm questions, and I figured their feedback would show whether or not he could do that. I was looking for familiarity with JavaScript language features and DOM APIs, and how he approached a vaguely-specified problem and what design choices he made. That was the part that hadn't been tested in earlier interviews.
Interviewing doesn't have to be confrontational. When we're trained, we're told that our job is to get the candidate to show us their best side. That aligns with the interests of both good and bad candidates. It's just that good candidates will be able to show us a really good side, while bad candidates simply don't have that ability. Then it's up to the hiring committee to set a really high bar and only accept candidates that have demonstrated it.
Mine: I'd implement them myself, explaining how I would proceed (I would be able to implement square root on the white board easily, division I haven't tried yet).
I make development software for companies like Google. Currently their biggest demand is to be able to use their white board instead of the keyboard+IDE for input. We call it an IDW, Integrated Development Whiteboard.
Also, they need tools to help them develop different sorting algorithms and link lists. Plus they are having trouble with binary trees, but link lists and bubble sorts are their number 1 priority!
Instead of more advanced performance modeling, they want to use this non-sciency thing called Big O notation. Once they write a Big O notation on the IDW(Integrated Development Whiteboard) they expect it to go that fast. If it doesn't go that fast... they just chuck more servers at it (we supply their servers too, so Big O makes us happy).
They also want us to provide them with flannel shirts and dr martins for uniforms. They say that 90s clothes help them with their interviewing techniques, because it helps them remember how interviews were done in the day; when they were edgy.
The forty yard dash provides one of the most important signals for football recruiting. Essentially, it's a measurement of the time from when the athlete takes his hands off of the start line to when he crosses the finish line. Most commonly, it is run in cleats on grass with no pads, and certainly no players trying to prevent you from reaching the goal line. In addition to that, the best technique for running a forty, literally falling forward to build momentum before lifting your hand off the ground, is actually illegal for offensive players (and pretty pointless for defensive ones).
So why is this completely unrelated activity so important for measuring football players? Because it takes ten seconds to measure, and a guy who can run a 4.2 forty can almost always play pretty damn well.
Tech interviews today are a low cost way of getting a rough idea of ability to code. Judging from Google's output, it's pretty damn effective for them.
Except that the 40 really isn't a very good measure - if it were, the Oakland Raiders would be winning the Superbowl every year instead of missing the playoffs. Of the 15 fastest players in the last 12 years (http://en.wikipedia.org/wiki/40-yard_dash), only 2 are stars, and most are bench guys or out of the league. The 40 has its uses, but it needs to be taken as one fairly small factor in evaluating a player, and even then it's only really relevant for certain positions.
Similarly, coding algorithms on whiteboards doesn't tell you much other than how good the candidate is at coding algorithms on whiteboards. Given that the vast majority of their revenue comes from either search (which was built over a decade ago) or companies they've acquired, and the numerous well-hyped failures (Buzz, Wave, +, etc.), I don't think it's actually working all that well for Google either.
I'm not saying it's a perfect indicator, I'm saying it's a cheap and easy indicator. Certainly there are outliers in every direction, but a running back who runs a 5.0 forty just isn't going to be very good (unless he's like 400 pounds).
So is it more likely that Google is filled with idiots that can't see the err of their ways, or that, across tens of thousands of individual hires, this is the most cost effective and produces the best results (minimizing false positives) on average.
College-admissions style interviewing just doesn't make sense for a company like Google.
FWIW, there are a couple edge cases (like javascript/frontend engineers) which my company (Facebook) has completely separate hiring tracks for. It works for us, but I'm sure Google has its own reasons for not doing that.
Actually, I'd say that whiteboard interviews are for Google are an arbitrary way of selecting from already qualified candidates, just as 40 times might aid a team in choosing between 2 otherwise similar players.
The players invited to the combine are the ones teams are considering drafting anyway; all the 40 times do is move players up or down the list by generally small amounts. The point isn't that 40 times are useless, it's that they provide very little additional information about a player. Champ Bailey was going to be a high draft pick no matter what he did at the combine, and everyone already knew that Trindon Holliday was fast but probably too small to succeed in the NFL.
Likewise, someone with a 3.9 from MIT or a bunch of good open source work who's coming for an in-person interview is already qualified, and the whiteboard doesn't tell you anything new. I'd guess Google sticks with them for the same reasons teams tout 40 times - it's good marketing both internally (making decisions seem less arbitrary) and externally (look how tough our interviews are is a more socially acceptable way of saying look how smart we are), and it allows people to deflect blame if a hire doesn't work out. Judging by the number of posts about Google interviews I see here and elsewhere, the marketing is certainly successful.
The vast majority of interviews do not result in a hire. (Some of my coworkers have reported giving 20 in a row without a single offer.)
Also, I think your view of the interview pool is somewhat skewed. Most of the candidates I see do not have 3.9s from MIT (BTW, I believe MIT has a 5-point GPA, so it really would be 4.9), and a lot didn't go to Ivy-League universities.
Google has separate tracks for FE SWEs as well. It's just that you also need a basic proficiency with C++/Java and algorithms to be a Google FE SWE, while I'm not sure that Facebook requires that? (Perhaps because Facebook's frontends are written in PHP instead of C++/Java.)
FWIW, Search is continually being rewritten, and the bulk of the current codebase was written in the past 2 years or so.
I'm kinda curious what it'd look like if you took the 2002 version of Google and used it on today's Internet. My guess is it would feel incredibly dated and virtually useless because of spam. We have a couple archived UX studies that were done with the old (pre-2010) UI; I remember that when we launched everybody said "Eww, I hate the new UI. Why change a good thing, Google?" and now when they look at the old UI they're like "Omigod, I can't believe I ever managed to look at that. It's like something straight out of 1998."
Looking at that list... I wouldn't count the three from 2010/2011 because it's too early to tell, so that leaves 12 players. Of those 12, I would say there are 2 superstars (Bailey, Johnson), 2 great players (Rodgers-Cromartie, Routt), a #1 wideout and potential emerging star (Heyward-Bey), and 3 players with promising early careers that were derailed by injury/death (Mathis, Washington, Williams).
That's a pretty fantastic hit rate, especially given how rare it is for any draft pick to work out. Similarly, if Google tries a bunch of projects of which only 10% are expected to work, but 20% of them end up working, then they still did a great job even though 80% of their projects are failures.
This thinking is exactly what Moneyball was all about in Baseball. Football looking at the wrong things.
For instance, 225# reps, vertical leap, reach, etc (all NFL combine measurements). Great, you are measuring and ranking, but are you doing anything meaningful? Are you actually looking at the right things? Probably not.
If they were, Wes Welker, Tom Brady, Victor Cruz (all in the past superbowl) would have been first round picks, probably top 10. Not undrafted, or late round picks. And JeMarcus Russell and Ryan Leaf wouldn't have been drafted #1 and #2 overall (all the physical tools but not the mental - flame outs).
The point is that we as people tend to think we know what to measure and track, but we likely don't. Frankly, we are probably making it up on the fly and we convince ourselves and others that these are good measures, and until someone figures out the next best thing, they actually are. But, as I said, they are probably not the best, or maybe even good, in the infinite wisdom sense.
But, think about it this way. Both football and programming have ways we can actually see if someone can do what they say that can do: literally, look at the film. Look at game day film on a player. Look at github or other places for programmers. And, just like with football players, give them REAL scenarios that test their ability to think through a problem, in real time. Do the same with a programmer. Put these two together and you get rid of the people who can't think (Russell and Leaf) and you get rid of the "physical specimens" that can't play (Most any Oakland WR drafted under Davis).
I personally think this is a much better way that weeds out the most people. Refine your questions and technique and you can spot the people who can and can't perform pretty quickly. If you are unsure, give them a simulated game (programming problem at home) to see what they can do.
Part of the point of the whiteboard is that it's not a real development environment. Google interviews are usually designed to test how you think, not how well you can place a semicolon. The point is, it's okay if you miss a brace or forget the name of a method. It also allows you to mix diagrams and psuedo-code in with 'real' code in an easy way. (also, I can't think of a better environment to give them. You can't provide everyone with their favorite IDE with all the code hints, so in the end it's just going to be a dumb text editor anyway)
Working on a whiteboard is definitely a skill, but one that's worth developing if you plan to work with others on a complex project.
That said, they really shouldn't have been giving this guy standard CS questions. Sure, you want to make sure that he understands why writing his string concatenation loop the wrong way will result in O(n^2) behavior, but he was interviewing for a front-end position.
The front-end interviews are a mix of front-end focused interviewers and gen-eng interviewers (usually 3 & 2, respectively). That's because the frontend-SWE position involves writing JS/HTML/CSS to run in a browser, but it also involves writing the server code that generates that JS/HTML/CSS (same reason that Java or C++ is part of the job req). We care very much about efficiency when your code runs on tens of thousands of servers.
There are also a bunch of algorithmic questions that come up in the browser as well, because unlike a lot of sites, Google actually cares about latency. You often can't use a library function if it involves pulling in a 300K library, nor can you write an O(n^2) algorithm if it involves locking up the browser.
A non-trivial percentage of visitors hit Google Search with an empty cache and no cookies. I know the numbers but aren't sure I can share them, but it's enough that relying on caching to solve latency woes doesn't work.
Strange, These days very little to zero development happens without IDEs. I don't really know why anybody should expect to test somebody's skills without an IDE.
That's because today a term called 'Productivity' has become massively more important than any thing else. Its something like this, Lets say there is an archer. He can shoot the red dot 9/10 of times with his bow and arrow. You take away the bow and arrow and give him stones and ask him to match the same 9/10 hits on the red dot. Guess what, he won't be able to, May be with time he can. But for the time being he can't.
What does this say? Does this mean he is a bad archer? No. Tools and their usage is part of the trade.
I heard they almost have their spam filter down ... They have discovered every third mail sent is some form of cola advertising, and every fifth mail sent is empty words used to drum up hype.. Can no-one think of a way to mark those mails?
I know all you fanboys out there will say "you need to know this stuff to be a generalist software engineer" but c'mon, hire experts in sorting algorithms if you need that for some obscure bigtable ultra-performant section of code and leave it at that.
Need another example of wasting everyone's time: "She told me they primarily hire strong C++ and Java developers, something which I have very little experience with." Gee, Google, glad you still brought him in when he clearly has no interest or background in that.