Yes, Googling an answer to a Google interview question from SO is in fact verboten. A seasoned interview can normally pick that up anyway. But a note to potential Google interviewees: if you're caught doing this it will pretty much disqualify your application. We're interested in how you think and how you solve problems, not what you can pass off as knowing.
Interestingly, he mentions the NDA and then goes on to broadly describe the question anyway. If all this is true, I'm not a fan of bit-twiddling questions. It's something you either know or you don't (like reversing bits in O(log n)). This is meant to be an interview not a trivia quiz. I get mad every time I see those kinds of questions asked.
Anyway, another note: if it's on your CV, it's fair game to be asked about. So if you put that you wrote a low of embedded C/C++ in such a way that you'd be expected to do a lot of bit-twiddling then yes, bit-twiddling is absolutely fair game (IMHO).
If however you put that you've only done Python/Django, Clojure and Scala then it's a stupid question to ask (IMHO).
The second phone interview if accurate disappoints me as well. Perhaps this was a product of the position you applied for or what you put on your CV?
As far as intern matching goes, yes there is absolutely room for improvement there.
Note to other commenters: PLEASE PLEASE PLEASE stop spreading this nonsense that Google asks engineering interviewees stupid questions like "a man drove his car to a hotel and lost his fortune, what happened?" This is NOT what we do. The sooner people stop spreading this misinformation the better.
I've interviewed with Google twice, and both times I was so unhappy with the experiences I declined the offers. Many friends work at Google and are happy, so this seems like an instance of getting unlucky with the loops... but don't dismiss off the cuff.
The very first question I got in fall 2010 on a phone interview was "How many ping pong balls fit within a school bus?" The second question was "When would you use a virtual destructor in C++?" without C++ being on resume or confirming if I had any experience with it. I used C++ many years ago and could reason through, but I did walk away thinking how unfair the interviewer was. There were other small instances that led me to say no.
Then in fall 2011 at the Googleplex, my first question was "I'm XYZ and I worked on Google+. That's all you need to know about me. Why am I interviewing you?" It was pretty condescending, and if that was based on my resume then shame on me. If this had been at a bar I would have responded more colorfully, but during an interview all you can do is be polite and answer the question.
While I fully believe most of Google tries to be fair and reasonable during interviews, I've had two experiences where individuals were not. YMMV.
P.S. The bit-wise question sounds like the interviewer asking why UTF-8 is preferred over UTF-16 or something and how you would detect which encoding was used. Regardless of what language you know you should be able to answer this as it affects everyone on the web. At least, that's going to be my new question for interviewing people :)
I find questions like the ping pong ball question rather trying, but I guess there's a long precedent for it. My understanding is that you're supposed to do a back-of-the-envelope calculation that gets you within an order of magnitude or so of the correct answer.
One problem with questions like this is that unless you know that you're supposed to just do a back-of-the-envelope calculation, they can leave you completely flabbergasted, as the questions sound as if they are asking for an accurate answer, which you'd have no reasonable way of determining.
Also, for me, asking me to do any math at all while someone is staring over my shoulder, or what have you, is going to cause me to make mistakes like sqrt(36) == 9, and I have a degree from MIT. Consequently, I hate this style of interview with a passion.
Regarding your experience with the condescending interviewer: I had a similar experience in my last job-interviewing round, and got really pissed, but tried to stay polite and answer the question. This doesn't work though: I spent the whole time distracted, with my mind considering the paradox of a founder having such behavior, and that I'd be using the guy as a mentor. The result: I underperformed on the problem, and got walked out, leaving me feeling like the fool. My new rule (and this goes for general life too): I call people's bad behavior, but not in a judgmental way, but rather to avoid adding a negative dynamic as a kernel to the relationsihp (e.g., in a meeting, I speak up if someone could interpret something poorly, to clarify it, because otherwise some subset of the people will be passive agressive and fume and suffer a downward spiral, rather than speak up themselves). I would have felt so much better about myself if, during that interview, I had said, "You know, this isn't going to work; there is no point spending your time on me anymore." And then walked out.
Then in fall 2011 at the Googleplex, my first question was "I'm XYZ and I worked on Google+. That's all you need to know about me. Why am I interviewing you?"
Out of curiosity, did the interviewer ever explain this odd introduction, or what he/she was trying to get at?
I've been asked bit twiddling in O(log n) questions before and it was in no way supposed to be a test of my knowledge. It was a way for the interviewer to evaluate my ability to not know how to answer a question. It took me almost an hour to solve, but it gave the interviewer a pretty clear insight into my ability to approach something new.
In my experience the best interview questions I've had have been situations where I was asked a question about something I was not familiar with. The interviewer then gave me a 5 minute overview of the things I need to know (like which synchronization methods are available in pthreads, for instance) and then give me the chance to apply the things I just learned. I think most employers care far more about how quickly you can pick up new things than they care about what you already know, and it left me with the feeling that they gave me an offer because of what I can do, rather than what I already know.
Some bit-twiddling questions are a fair game to ask even for folks who haven't done low-level C and C++. Asking esoterica from Hacker's Delight (an excellent book, by the way, but in no way a source of interview questions), is not, but I doubt Google does this.
Bitwise operators are just as available in Java. I've done bit-twiddling in production Java code, it's something you need to do if you ever, e.g., work on a serialization library.
Understand, words, bits, bytes, and bitwise operators (big part of How Computers Work (TM)(R)) is something worth knowing (and not just to pass an interview).
My girlfriend is in the medical profession. She's gotten job offers after 1 hour conversations. The last job interview process I went through had 3 separate phone interviews (each with coding questions) before they were to fly me over for a full day interview. She was pretty surprised at how intensive the process was. I have a CS degree from a top-10 school and have 5+ years of work experience. This is the kind of stuff that makes me sad to be in software.
I've gotten most of my programming jobs with a quick chat. The bigger companies set a higher bar because they don't have any pre-existing knowledge of the candidates like smaller companies do. Google gets tens of thousands of resumes that all look essentially the same. A CS degree and 5 years of experience doesn't narrow things down much, so it's simplest to just ask the candidates a bit about programming and see how they respond.
I think this process, while annoying, is worth it. I don't want to risk having to work with someone whose competence with respect to software engineering has not been verified in a controlled environment. I've done it before and it meant every time I said something like "state machine" or "graph", I had to explain what state machines or graphs were. And at Google, I don't have to do this. The amount of shared knowledge is amazingly high which makes interaction much more productive.
Most companies want to hire the best people, and employees want to work with the same. Why doesn't work experience or education count for anything in our field? Yes ... I've met idiots with CS degrees who can't code FizBuzz to save their life. I've also met idiots who have aced interviews at Microsoft, Google and Amazon by cramming on algorithms books for 2 weeks.
We've really gone off the deep-end with interviews. If you've been a professional developer for 5+ years, do you really remember the details of your algorithms course? Competent devs can figure out the details of this stuff in minutes ... something not conducive to the high-stress environment of interviews. And this is not even considering how much time both parties waste in this process.
Given how smart we are (i.e. software geeks), it boggles my mind how silly our operating procedures are. Just like I've told students that they should never accept unpaid internships on principle, I wish enough of us would tell prospective employers that we won't submit to an unreasonable hiring process.
Work experience and degrees very much do count. You need those, and you need to prove you know what someone with that experience and degree should know. Nothing wrong with that. (Some programs don't cover algorithms in enough detail. Some people forget them after not using them for five years. Experience does not imply growth in all areas.)
I wish enough of us would tell prospective employers that we won't submit to an unreasonable hiring process.
I like this hiring process and I would implement the same thing at my own company. There is so much software that needs to be written, though, that someone who refuses to "submit to an unreasonable hiring process" need not do so. Just grab a job from rent-a-coder and relax!
Back when I was in undergrad, Microsoft was the most desired company to work for, and their interview process was legend. Google raised the bar (in terms of comprehensiveness and IMHO annoyance) but I wonder if that process is truly better vs wasted effort. You can't really say ... oh look how successful Google is. This reminds of the urban legend study that darts pick stocks as well as many of the top investment managers.
You know what I'd like to do at my own company? Hire people based on their unique experience and personality. Pay them fairly and assume employees have lives outside of work. Heh .. engineers can dream, can't they :-)
Google employees are paid well and have lives outside of work.
The hiring strategy may or may not make Google money, but it does make my life there pretty pleasant, and I think the other 30,000 employees would mostly agree.
I think you're missing his point. Work experience should be proof enough in our industry. A high-stress interview process does not really prove anything.
Work experience doesn't prove anything either. People can lie about their credentials. People can have very easy jobs. People can be hated by all of their coworkers. "I worked at X company for Y years" means exactly nothing to me.
Hire people solely based on "work experience" and a ten minute chat and let me know how well you company of 10,000 people does. My prediction is that you will be unhappy with the results.
I do web development, so arbitrary algorithms questions seem to me to be not applicable to what I do 99% of the time. The other 1% I can easily look up the answer, or at least look up the details I need to find the answer.
That's fair, but that's not the sort of position Google is hiring for. We value general computer science more highly than specific Javascript (for example) experience. I can't offer an explanation or analysis of that, but that's how it is. (But if you do have specific experience and know the basic CS, that's ideal.)
Other companies do the opposite, so there's plenty of jobs for either type of person.
Ask your girlfriend about her rotations (where students literally cry after being screamed at while working insane hours), MCATs, and how difficult it is to get into any medical school. Job interviews don't have to be as difficult as credentials are both required (there are folks at Google and Facebook without CS degrees -- and that's a good thing, obviously) and are difficult to get irrespective of where you go to school (CS programs wary widely, as this is still a young discipline unlike biology).
Pharmacy is also similar, with a few caveats: pay is somewhat below what a software engineer can expect mid-career (~$120,000 for retail pharmacy, somewhat less for pharma research), residency is not required, but rotations are still insane, and schools are still selective.
In some ways, I think it would benefit the patients if the medical profession was somewhat more meritocratic and less focused on pushing students to their breaking point during rotations and residency, which continues because "that's the way it has always been done". It still somewhat scares me just _what_ a sleep-deprived student could do to a patient due to the very basics of sleep deprivation.
[Full disclosure: I work at Facebook and have dated a pharm student/pharmacist.]
Of course "in the medical profession" doesn't equal "doctor or pharmacist". Likewise, "software engineer" doesn't equal "software engineer at Google or Facebook": there are plenty of firms that don't use coding interviews. Nobody says that to be a software engineer, you have to work at a licensed firm that has to (as part of licensing) use a certain hiring process, require certain credentials, etc...
(This also isn't an endorsement of all modern interview practices: it's particularly silly for startups to cargo-cult interview questions they've overheard at other companies without measuring their effectiveness and calibrating candidates' response.)
How would a startup measure the effectiveness of an interview practice or calibrate off of candidates' responses if they don't put it into practice based on the experience of other companies/people?
Many of these exotic/novelty interview processes are completely disrespectful of the candidates' time as well. In the past few months I've undertaken a few pretty "rigorous" application processes. A couple of Bay Area startups (I don't live in the Bay Area), and a bunch of other companies both locally and for remote working possibilities.
Startups seem to be the worst when it comes to turning the hiring process into a huge time sink for the candidate. At its worst was one of the Bay Area startups. They outline a 7- or 8-phase interview process. There are independent programming exercises, pair programming over Skype, phone interviews, then at the end they have the candidate in for "cultural fit evaluation" which turned into a six-hour interview gauntlet after flying across the country that morning.
Another bit of inconsideration of my time and my actual job where I work to make money was a company that wanted me to come in in the middle of the afternoon on a workday for 2 hours to "meet the team". I told them I did not feel comfortable leaving the office at 1:30 and go AWOL/take a half day of vacation so I could interview at another place. I wound up backing out of the interview process because of their unwillingness to pick another meeting time, even over lunch.
Then finally tomorrow I am meeting with a company, and they told me yesterday afternoon that they'd like me to prepare a presentation on something I'm passionate about (they liked Jeff Atwood's blog post[1] I guess). This actually I don't mind at all, and think it's a great idea... but I need more than a couple of days' notice. I work 8-10 hours a day, commute a couple more, and by the time I get home I've got 3 hours to spend with my kid, relax, eat dinner, etc. In that 3 hours I also need to prepare a talk on a topic I'm passionate about.
To me that last one is emblematic of these interview processes: good ideas, but not structured with much consideration toward respecting the time of the candidate. I get that hiring the right person is crucial for small teams, no doubt, but I'm getting tired enough of jumping through hoops that I'm not really interested in doing it anymore, even for a great job where I know I can make an awesome contribution.
I was once given this requirement for a scientific computing-type position at an industrial research lab. Most of their applicants were PhD-types, for whom giving an hour-long presentation on their last six years of research was par for the course. For me, it meant I had to scramble to put together a PowerPoint of my undergrad curriculum and research opportunities.
Nah, it didn't suck. One of the strongest "soft" skills I learned in college was giving Powerpoint presentations. Almost as many engineering classes had Powerpoint requirements as papers. In my case, I didn't need to choose a topic - the topic was my educational background and research I had done.
They gave me a few days notice, it was enough time. The only weird thing was that they were surprised when I asked what the presentation should be on - in their minds, of course everyone already a presentation prepared of their PhD thesis. As (perhaps) the only candidate without a PhD (I don't know why they flew me out either...), I was not familiar with their standard rules of the game.
I am really, really interested to hear from senior developers about this. Especially their comments on the growing trend of requiring open source experience. (I for one thing don't have any open source, most of my projects are locked in the university and I currently intern at a company building cool things which, well, I can't open source).
Update: I don't have a problem with this really. I am in fact trying to make some time to code, but I don't like how this can sometimes be required.
I doubt open source is a requirement at any of these companies, but it's a huge asset for any job application if you have some good work to show. It stands to reason that if you're going to be spending most of your day writing to code and interacting with coders, people will be interested to see if you have a good repo and handle issues well. So a good Github repo is a huge asset to any job seeker in this industry. It will also help you to be approached by quality companies if your project's popular/high-profile, as savvy recruiters will look at this kind of thing.
And, you're likely to be asked about open source in your interview. So if you can say intelligent things about it and show you care about it, it might improve your interview performance too.
I wouldn't worry about it. Any company that requires open source contributions hasn't thought very hard about their hiring process. They would be excluding the vast majority of talented (and especially professional) programmers.
It's probably most useful as a bullet point to attract a recruiter's attention. So commit a line of code somewhere and stick it on your resume.
Not to say you shouldn't work on an open source project. But do it because it's something that interests you, not for your resume.
I can't believe the general attitude programmers are putting forward. Here is a person in the medical field that requires at least twice the schooling, huge entry barriers etc getting an hour interview.
We are subjected to full day flights, multiple phone interviews etc.
She deals with life, not code.
This tells me one of two things. Either our hiring practices are severally broken, or its harder to program then be a doctor.
Don't you think that it's possible that becoming a full MD doctor is a qualifications vouching system that programming lacks, and thus it's "every company for themselves" in terms of deciding who is actually qualified/worth hiring?
The amount of sub-par candidates that are nearly constantly looking is absolutely appalling to me, and is probably shocking to most of the non-hiring-managers reading HN.
Why is the interview process so intensive? Same reason gold mining is intensive. There's a lot more dirt than gold in both cases.
The sheer idea that bad doctors don't get through the "qualification" area is insane. They have just as many bad people getting through the qualification period that you speak of. The main difference would be if you didn't have a CS course. Then you start to enter a grey area.
And also I myself have been to more bad doctors then good doctors. There is just as big of gap between the poor doctors and the good doctors as there is in programming.
I think there's a cargo cult mentality around hiring process. Hiring the right person is hard, and hiring the wrong person can be devastating, so everyone's looking for a magic elixir.
I think an interview would be completely useless if there no friction in hiring and firing. But it takes a while to get an employee trained and up to speed. It takes even longer to replace a fired employee, as you either scrap what they were working on or you try to get their replacement to pick up where they left off.
More friction in hiring and firing results in more careful hiring practices. I'm not sure how much friction there is in the medical profession but I'm guessing there's less friction there than in software development (not counting politics).
"Hi, I'm Sean Haufler, rising senior at Yale [...] Position: Software Engineer Intern [...] I didn’t have much experience manipulating individual bits"
Sometimes I want to cry for what the world has become. At least I can be content knowing I have job security. (To be fair: the ability to google the answer quickly and implement it is exactly the skill that kind of test is supposed to screen for. Still, three years at school and no bit math?)
Edit: several of the responses have interpreted this as my sniping at the author. I'm not (he got the question right, after all!). I'm depressed at the status of software engineering and computer science education, such that dealing with the in-memory representation of data is treated as an "obscure" skill that comes up only on job interviews.
I'm a rising junior at Yale, and I know Sean well and we both took systems programming together. We definitely covered bit manipulation and bit tricks, as well as number representation and lots of other stuff.
Sean's an incredibly bright guy but he's more interested in building world-changing apps and web dev. as opposed to low-level systems programming. There are other classes here where you have to code in assembly and do all sorts of bit manipulation (OS's comes to mind). The core CS sequence in our school is also in C, which differs notably from other places that use Python, Java, etc.
He said 'didn’t have much experience manipulating individual bits'. I think it might be worth giving him the benefit of the doubt that he's covered it in class but hasn't extensively worked with them.
Reading stuff like that generally makes me feel much less insecure about my college. It used to be that hearing that someone was from an ivy-league/ivy-league equivalent would make me think they were really, really smart. (narcissism warning) I've come to realize that on average I'm probably about as smart as people from more prestigious universities, if not smarter, despite being an MIT/Columbia/Princeton/Cornell reject and a CMU waitlist.
MIT is vastly different than Yale: it is a vocational school in the best sense of the world. Possibly slightly less so now that 6.001 isn't LISP-based, but I still can't imagine a MIT CS grad not understanding bits.
People coming out of a liberal arts college I tend to expect to know algorithms, state machines, possibly data structures, probably C++ and/or Python and have next-to-zero useful code-writing experience unless they got it elsewhere.
6.001 doesn't exist anymore. The new set of intro courses are completely different. It sounded like you thought 6.001 is now taught in some other language.
There's a lot of spread, as in all things. I did the Ivy League thing many (yikes, many!) years ago, and met plenty of genius types and a handful of dunces. And in programming, the divide between people who can learn the subject well enough to pass the course and those who can Get Things Done is very pronounced even at top schools.
I doubt it's that bad. It might be that he hadn't done any bit hacking in C in a while. If you haven't coded in matlab for a long time and I asked you (during an interview!) to do random bit hacking, you might feel stumped too. You'd probably want to play around with it for a minute and re-figure it out, but you've got an interview waiting for you to produce an answer right away.
The best coders I've ever worked with rarely memorized the nuance little algorithms that they want you to regurgitate during these interviews. The ones that I know that are capable of this are terrible coworkers because they lack other necessary skills to function in an organization or team environment. This is anecdotal but sort of sticks with me.
The interview processes used by these software giants weeds out the kinds of people that have made the biggest differences in the companies I've worked for/with. From my experience they weigh their judgement much more heavily on the actual implementation of code instead of the understanding of code, decisions and overall design.
Knowing how to code a mergesort is not as important to understanding the wider uses of mergesort and when an altered algorithm would suit the problem best or when it would struggle to provide you the right performance at all.
Maybe these companies want code monkeys that can put down exactly as the design is given to them and the process works grand for them, but from an outsider looking in it seems like they miss out on a lot of great talent due to the rigorous screening process.
"Knowing how to code a mergesort" is specifically not what they're looking for, in my experience. The idea is to come up with a problem that requires an interesting algorithm that very few people will know, and see how the candidate reasons their way to an answer.
Many people implement it wrong. The best programmers know how to check their work, and will be asked during the interview to check.
Who doesn't know that (x + y) / 2 can overflow?
But the people who you really want to filter out have no idea or intuition that a problem can be solved by slicing it into two. That's the key idea behind binary search (and indeed, much of computer science).
I've never understood these vague hand-wavey claims about it being more important to know when and how to use X or a modified version of X than to be able to implement X (here X is mergesort, but could just as easily be some bit twiddling or a TCP connection or just about anything). How can someone simultaneously claim that they understand an algorithm well enough to know when best to apply it (and when to modify it!) and also admit that they can't actually implement it.
If you can't muddle through a basic implementation of mergesort 45 minutes, I can't believe that you are actually in a position to know when mergesort is a good or bad option, and certainly not that you are capable of writing a custom version for some domain-specific needs.
If someone wants to claim that it's simply not necessary to know mergesort, that's a reasonable stance (though I disagree). But to claim to truly understand it without being able to implement it seems like a bit of a fib.
Do kids still learn C in college? It's been my experience that new grads are primarily taught in Java...
That said, we do all our interviewing in the langage I expect them to be developing in - namely Ruby, JavaScript, and/or SQL. Is that the norm or do people still interview candidates using, say C or Java, for Ruby/Python/JS positions?
I suppose if we were interviewing someone who didn't know Ruby but knew Java, we could fallback to that. But luckily we have plenty of people that know Ruby/JS that I've never had to do that...
Although you don't have pointer stuff, you can do really interesting things with Ruby and JS.
I'd say Joel Spolsky is somewhat unique in this, although Google has had bias for C++ in the past [1]. Spolsky has long been an advocate for expecting developers to be competent in C [2].
FWIW, Google generally expect engineers to know bit manipulation. Certainly I was asked some, I don't know if everyone necessarily is but I wouldn't be surprised if they were.
> Is that the norm or do people still interview candidates using, say C or Java, for Ruby/Python/JS positions?
When I interviewed at Google, they let me pick the language. I did some C++, some Java, and C#. As long as both you and the interviewer can understand it, they don't care about the language. They want to maximize your comfort.
When I got hired, I ended up doing JS full-time. Google assumes you can pick up a new language.
Learning programming languages is easy. I did all my Google interviews in Perl. Now I write all my code in Java. The skills transfer easily.
I personally would prefer someone who is good at multiple programming languages. People that spend all their time in Java ignore subtle things about how computers work that C programmers are intimately aware of. People that never use scripting languages assume they are "toys" and waste many hours writing "production quality" throwaway applications. So it's good to have experience with everything, but experience can be obtained after hire too :)
I'm not saying being a polyglot is bad - it's certainly very awesome and desirable; but if your interview process is all in C, you're gonna turn away folks that can't do it. That seems suboptimal to me, although if you're FogCreek I guess you get so many people applying you can make C literacy a requirement.
I learned C++ back in, oh, 1996. I haven't coded in it much since about 2001. I'd fail virtually any C++ exam today unless I spent a lot of time relearning my C++.
I can't get to the original article, but I assume that this is documented there. Yes, I think it's silly to require proficiency in a certain language. Google does not have this requirement. You must know a programming language well enough to be an expert, but it doesn't have to be Java/C++/Python/Go.
Also, FWIW, Google intern interviews and full-time interviews are completely different. Interns must interview like everyone else after their internship to be converted to full-time employees.
I think it's very important to mention that C is not C++. Expecting people to know C, even if not used frequently, is not unreasonable imo. Testing people on C++ would be burdensome. Fog Creek has no C++ literacy requirement.
> But luckily we have plenty of people that know Ruby/JS that I've never had to do that...
My take on hiring is that I don't care what languages the person knows. Being versed in what we're using is a plus, but not a strong plus. I'm far more interested in how the person thinks and tackles problems than I am that they are expert in "stack X". If you get the right people, picking up a stack/language isn't rocket science.
In the same vein, googling for answers is fine. I'd rather a person to whom I can say "we need to do X", when they have no prior knowledge of "X", but yet can figure it out (well), and be the new company "expert" on X.
I bring it back to the way my EE school operated. Tests never were about material we covered in class, they were always about applying that knowledge to a new problem that has its root issues in what we discussed in class, you'd have to apply what your learned in class to a completely new situation, often in multiple ways, to come up with a reasonable answer.
The only problem is, that to make this work, you can't give out interview questions that are literally a google query away. You have to come up with open-ended or slightly obscure questions where they have to go google 5 different topics, combine the information, and come up with a reasonable answer.
A handful of candidates I interviewed not long ago from nearby universities (Austin area) had Java backgrounds, although C++ still seems to be pretty common.
We may include generic coding questions that can be answered in any language of the candidate's choosing, but we always try to include a couple in languages that the position targets.
The language depends on the school. At my university, classes use Scheme, Prolog, JavaScript, C, C++, SQL, Java, MIPS, Ruby, Objective-C and way too much Python (it's the new Java :(). Basically, each professor uses whatever language they want--you're (reasonably) expected to pick up a new language in a weekend. I wouldn't be surprised if there were classes using other languages as well that I just haven't heard about.
I really wish we'd have more ML/Haskell but they are only used in a couple of graduate courses as far as I can tell.
Graduated in '03, I did a mix of ASM, C++, Scheme, Fortran, Pascal but depending on the courses you picked, you could have stayed theoretical and only taken C++ and ASM.
I would say always tell the truth. When people revealed they already knew the answer to my question, I'd probe a little deeper to check, but then move on to harder questions. That could only ever improve their chances because there's no penalty for wrong answers in the bonus round. All depends on the interviewer, though.
FWIW, if you're doing hobby projects or working on open-source software: when you get one of those CS related brain teasers start your answer with this if you get the opportunity:
"Oh, I encountered something similar while working on <insert project name>."
Notice the little smile on the interviewer's face and how the interview derails in a chat about projects.
Also applies if you don't know the answer but would like to know to unblock that issue you had.
Wow we had different experiences. I only interviewed at start-ups and none of the companies I talked to asked me any ANSI C questions. I had some interesting Python do-in-whatever questions at one company (which I did all in Python) and on the other I went to them with something I had already made of their unofficial platform and skipped programming challenges.
I've been asked a question in a phone screen the answer to which I had read on the glassdoor page for that company. A lot of people/companies recycle questions on a regular basis.
"Simultaneously, I quickly Googled ‘how to use bitwise operators in C’ and found this wonderful code snippet on StackOverflow that made the problem easy to solve. I wrote a solution with time to spare, and the interviewer seemed content with my answer."
NB to all interviewers: this girl has knows how to solve problems efficiently, effectively, and in a manner appropriate to their role. I would not be pleased if my employee always tried to re-write what has been solved and perfected decades prior by someone smarter than her.
Absolutely. That's why I paid my smart classmates to do all my take-home tests in school; it's an efficient, effective way to get the right answers!
I don't know if you interview people, but I do, and it's hard. I try hard to come up with questions that probe people's knowledge in specific ways and help discriminate between large ranges of ability. It's fucked up to try to ruin the information I'm getting by cheating without telling me.
If you hold the principled position that looking everything up during an interview is a reasonable way to demonstrate your competence, then you should come out and tell me that's what you're doing, so that I can make a decision which isn't based on lies of omission.
Yeah, but I fired the last guy who billed me for that time he needed to re-discover the quadratic equation.
An interview should evaluate the skills one needs for the job, not puzzles that make you feel smart. Were I interviewing someone, I would happily accept an answer something along the lines of "that's been solved already, I would use an existing library so I can move on and solve my real problem" with regard to bitwise operators.
The goal is obviously to figure out how good people will be at solving real problems. But it's not realistic, practical, or fair to come up with an unsolved problem for each interview.
I'm replying to the parent, who seems to think it's principled in the sense that it is the best way to operate in the real world, therefore he will do it in an interview.
I would have to disagree that what I did was "cheating".
Software engineers are given problems to solve, and their job is to solve these problems efficiently. You don't always have the solution to every problem off of the top of your head. That's why programmers use Google, StackOverflow, and documentation as resources. The primary skill employers are looking for is learning how to learn new things quickly. And I believe I demonstrated that skill in my interview.
Also, I declined to mention this in the article, but after I finished that UTF encoding problem in my interview, the interviewer asked where I got the check-bit macro (he saw me paste it in). I told him I got it from StackOverflow. It didn't seem to concern him.
> Also, I declined to mention this in the article, but after I finished that UTF encoding problem in my interview, the interviewer asked where I got the check-bit macro (he saw me paste it in). I told him I got it from StackOverflow. It didn't seem to concern him.
That's a pretty important part of the story, and makes the situation very different. It also makes the interviewer seem a lot more competent. Trivia questions are useless in interviews, and the fact that you were able to quickly google it, recognize it as a relevant solution, and apply it correctly actually is demonstrating that you know how to learn things quickly (and that you have at least some familiarity with binary representations and manipulations). The average charlatan would just start copying and pasting in panic, which is usually pretty easy to pick up on.
Meanwhile, you can't pretend what you described in your post is really a moral position if you had not said anything. It might not have been strictly immoral as you really owe them nothing, but there's no shining principle demonstrated there.
Hello, I am an employer, please don't tell me what skill I am looking for in an interview. If I wanted to know how good you are at learning new things quickly, I would ask questions like "what's on your list of cool things to pick up in the next year or two?" or "what's something interesting you found out working on project X?" or "what do you think about new thing Y, where Y is related to thing Z you know about?" (And I do.)
If I asked you a question about manipulating Unicode, I am so obviously not looking to find out how quickly you learn things, and you know perfectly well I'm not. I'm finding out what you know about character encoding and string manipulation!
(Regarding your addendum, if you're actually honest about it in the interview I don't really take any issue with it. But I hope you would be honest about it before an interviewer has to ask you whether you cheated.)
Interviewing is different from a real job. You need to show you can do more than look up solutions on the web.
I can't blame you for trying to cheat your way into a job and I certainly blame the interviewer for not seeing through your cheat, but make no mistake: you cheated.
It is generally considered cheating by Google phone interview standards, the interviewer probably was satisfied by the other answers, plus the fact that the interviewee immediately and casually owned up to it probably indicated that it hadn't been made clear that it was disallowed.
Employers are risk averse with their hiring and so, in the absence of compelling evidence, they will choose to not hire a candidate. Pasting in an answer from somewhere else turns the question (and possibly the whole interview) into a no-op waste of everybody's time. It just doesn't provide the interviewer with good data to make a decision.
My word of advice to you is this: study harder next time, be honest when they hit a gap in your knowledge (maybe they will offer to fill in that gap!), and don't Google on the phone. Interviews are like tests at school - closed book, unless stated otherwise.
It's amusing to think that someone may be subverting my silly interview questions. If you were being cleverer than the interviewer, I suppose that's a fair way to succeed.
It's absolutely cheating if you don't tell the interviewer. If a candidate doesn't know X, then just tell me, and I'll explain X! That's quicker than Googling and they'll get a better answer. But the whole point is to figure out which Xs they know, for many values of X.
If you're asking a question that is effectively, correctly, and decisively addressed by a single Google query made in real time during the interview, the fault is with the question, not with the candidate.
I basically agree (although it sounds like in this case, the candidate only Googled for help on some part of the question, so who knows.)
But the fault is still with the candidate. It's unethical to get external help in an interview without telling the interviewer what you're doing, full stop, end of story. It doesn't matter if you don't think much of the question. Doing so screws up the interviewer's ability to actually compare you meaningfully to their other candidates.
Further, a technical interview question is rarely designed to have you solve that question but show that you have an understanding of the subset of knowledge to solve that kind of question.
If they want you to solve bit manipulation questions they could come up with something terribly obscure and difficult to explain or they could give you one that can be solved by anyone with the basic knowledge of bitwise operators a bit of problem solving. Having to Google this answer either shows failure on your behalf or the inability to actually sit down and address the problem critically before running off to find help from others (who will often be unable to help you on actual problems)
Ridiculous. The question here isn't "how would you design X" or "estimate the amount of time to do Y" or "explain how you'd debug Z" (all infinitely better interview questions, by the way). It was "how do I perform a particular bit manipulation in C". Google is a fine resource for questions like that.
I also sincerely believe that the more you know about C bit manipulation (particularly the kind of manipulation you need to, e.g., figure out whether a UTF-8 encoding is nonminimal), the less unreasonable that Google search seems.
I've been a C programmer since 1994 and interviewed lord knows how many C programmers and I'd never flunk someone for looking this up, nor would I care if they told me if they had looked it up. Obviously, 'cletus feels differently, but I think he's wrong.
Maybe if interviewing for developer positions wasn't so fucked in the first place, a candidate wouldn't feel like telling the interviewer that he used google as an aide would diminish his chances.
I got the same email from HR telling me that it should take around 3 weeks to hear from a host. She emailed me back 5 minutes later about setting up the interview.
Not saying this makes your 3 months okay, but just pointing out that there seem to be cases at both extremities.
I applied to a bunch of software engineering internships last fall and was amazed by the variation from company to company in terms of how I was dealt with as an intern candidate.
Great overview of the different interview styles being used. I cannot say I am convinced you always get the best people through.
I don't have any aspirations to interview at Google, but did stumble across an 'Google Interview' book at the local bookstore. It makes great reading.
WSJ did an article on Google interviews late last year, including answers. Here are the questions (click the link below if you want answers).
"1. What's the next number in this sequence: 10, 9, 60, 90, 70, 66 … ?
2. You're in a car with a helium balloon on a string that is tied to the floor. The windows are closed. When you step on the gas pedal, what happens to the balloon—does it move forward, move backward, or stay put?
3. Using only a four-minute hourglass and a seven-minute hourglass, measure exactly nine minutes—without the process taking longer than nine minutes.
4. A book has N pages, numbered the usual way, from 1 to N. The total number of digits in the page numbers is 1,095. How many pages does the book have?
5. A man pushed his car to a hotel and lost his fortune. What happened?"
FWIW, these questions have no relation to any questions that are asked in engineering interviews at Google. We mostly focus on software design, implementation, and algorithms. (SREs get some UNIX/networking questions, SETs get refactoring questions, and so on. And some interviewers like math questions.)
As someone who interviews prospective Google engineers, I can confirm what others are saying: The WSJ is full of shit. None of those questions would ever be asked here.
Especially that ridiculous, idiotic Monopoly one that journalists seem to love.
The explanation given in wsj for problem 2 is totally wrong. The balloon will do the same as a person in the car (nod backwards), only less pronounced due to air resistance.
Have you tried it? I have. It's quite startling the first time you put a bunch of helium balloons in your car, accelerate away from a stoplight, and have them all crowd up against the windshield.
In an accelerating car, the air sloshes toward the back, producing a pressure gradient. The helium balloons, being ligher than air, will be crowded out by the sloshing air and will drift toward the area of lowest density, which is in the front.
I can assure you that the wsj is correct! I've been transporting balloons a bit lately* and having fun watching them 'lean in' to turns, 'leaning back' while braking, and 'leaning forward' while accelerating.
*transporting balloons correlates strongly with transporting kids
Every time I've interviewed for a job I have been annoyed by the interview questions. Yet, when I am interviewing others, I do exactly the thing that annoys me. What is the alternative? It's just a way to talk shop.
Yes, Googling an answer to a Google interview question from SO is in fact verboten. A seasoned interview can normally pick that up anyway. But a note to potential Google interviewees: if you're caught doing this it will pretty much disqualify your application. We're interested in how you think and how you solve problems, not what you can pass off as knowing.
Interestingly, he mentions the NDA and then goes on to broadly describe the question anyway. If all this is true, I'm not a fan of bit-twiddling questions. It's something you either know or you don't (like reversing bits in O(log n)). This is meant to be an interview not a trivia quiz. I get mad every time I see those kinds of questions asked.
Anyway, another note: if it's on your CV, it's fair game to be asked about. So if you put that you wrote a low of embedded C/C++ in such a way that you'd be expected to do a lot of bit-twiddling then yes, bit-twiddling is absolutely fair game (IMHO).
If however you put that you've only done Python/Django, Clojure and Scala then it's a stupid question to ask (IMHO).
The second phone interview if accurate disappoints me as well. Perhaps this was a product of the position you applied for or what you put on your CV?
As far as intern matching goes, yes there is absolutely room for improvement there.
Note to other commenters: PLEASE PLEASE PLEASE stop spreading this nonsense that Google asks engineering interviewees stupid questions like "a man drove his car to a hotel and lost his fortune, what happened?" This is NOT what we do. The sooner people stop spreading this misinformation the better.