
A Google Interviewing Story - ramanujam
http://paultyma.blogspot.com/2010/11/google-interviewing-story.html
======
akeefer
I enjoy clever ways of approaching problems as much as the next guy, but I
would never ding someone in an interview for not coming up with a clever-
enough solution. Good software engineering is maybe 99.7% failure-avoidance
and 0.3% cleverness. On very rare occasions you need a clever solution, but
most of the time you need to solve the problem in a way that you're 100% sure
will work, has no nasty failure conditions, and that other competent engineers
will understand. If there's no other good solution, or if every bit/cycle
matters, then you get to try to be clever, but that happens pretty rarely.
I've seen way, way too many problems caused by people using clever solutions
for problems that had straightforward-but-less-fun solutions. (And as has been
pointed out plenty of times already here, the clever solution in this case is
less optimal than a more straightforward one would be). If an interviewer
seemed intent on proving they were more clever than me, or on trying to get me
to throw out unnecessarily-clever solutions to straightforward problems, it
would be a pretty big turnoff.

~~~
jdoliner
I doubt that the interviewer mentioned the prime number solution due to
insufficient cleverness in the original solution. The answered O(n+m) solution
actually contains flaws beyond its lack of cleverness. 1) there's no good
reason to use a hash map, hashing is useful in maps for mapping an unevenly
distributed set from a large an arbitrarily large space to an evenly
distributed set from an arbitrarily small space. The space is only 26
characters so why hash? You can simply use a map (no hash needed), and in this
case there's even a very natural way to get indices into an array (index(c) =
c - 'a').

Now it's true, that these are both linear time solutions simply with different
factors and we might simply say who cares. The thing about the prime solution
is that it's actually really dumb itself and I think that's what Guy really
wanted you to tell him. He was pointing out that you could leverage the
smallness of your data and hoping the interviewee would come up with an even
better way to leverage this fact.

The first thing we should notice is that asymptotic bounds are misplaced here
if you consider how such a function might actually be used. The strings are
basically being used as sets that is AA might as well be A as far as our
answer is concerned. So assuming people aren't giving us stupid data (and in
an interview you could mention a way to make this assumption true). The
strings shouldn't ever have duplicates and thus shouldn't ever be bigger than
26 characters (otherwise they contain all of the characters and the answer is
independent). So if a solution has runtime n + m + c, that c actually starts
to matter.

The thing about the primes solution is that multiplication and modulo
operations are actually very expensive and all you want to keep track of is
whether you've seen a character (1 bit of information) so you should really
use a bitmap for this. And since it so happens that 26 < 32 these will fit
very nicely in a single int. It's even a pretty nice implementation:
<https://gist.github.com/707639>

[edit: link to code]

~~~
tomerico
With your solution, I might have not accepted you to do job because it is
obvious you don't have experience with Unicode and localization.

~~~
user24
that's outside the scope of the problem. (which is why I really dislike these
kinds of tests, because you can't win - if you don't consider unicode the
interviewer says "ahh, but what about unicode" and if you do the interviewer
says "ahh, but that's outside the scope of the problem".)

~~~
scottyallen
The right way to approach this is to clarify the requirements. "Should I
consider unicode?" will get you points with the interviewer, and will allow
you to quickly clarify the scope of the question.

------
antirez
In my life I never got interviewed, even if it is 15 years I work as a
programmer. Now I work at VMware thanks to Redis, and VMware did not requested
an interview, and my only previous not-self-employed position 10 years ago was
likewise triggered by my work on hping.

But, I'm sure, I would suck so much at this kind of interviews. If you are
anything like me you'll understand what I mean, in topics where I work day by
day I've pretty much the control of what the good solution can be in a few
minutes, but for many things to find the best solution requires, at least for
me, days of thinking, sleeping, possibly waking up with the solution in mind,
to find it's wrong and you need to reiterate the process.

My design abilities are all there, in this days. I'm sure that in the five
minutes race I would say many times something of super stupid. Now my question
is, are the five-minutes performances really linked to the three days thinking
about your problem solution?

Isn't it possible that at least a subset of guys that will get the few-days
answer well, will instead provide a poor answer in little time, and sometimes
the other way around?

If this can be somewhat true, there is a huge industry selecting runners for
100 meters, in order to run, most of the times, a maraton.

------
lacker
The prime multiplication is a pretty bad solution. It's actually O(n log n)
rather than O(n), since you have to use some form of big integer, and
multiplying a size-n number by a constant is O(log n). It is also needlessly
complicated.

~~~
Oxryly
Yeah, I don't get the interest in this answer. It's neat-but-useless.

~~~
firebones
It's just one anecdote, but it also seems like the kind of thing that happens
in companies that grow fast and have trouble maintaining quality in their
hiring process. Instead of hiring true cleverness, they hire for someone who
feigns the trappings of cleverness (smart enough to regurgitate a "clever"
solution that turns out not to be practical in the real world.)

------
aaronbrethorst
My last internship in college involved working on thermostat systems for
Honeywell with a bunch of people who had been there their entire professional
careers. I didn't have much interest in becoming a lifer and ended up
interviewing with a couple other companies, including Microsoft.

I interviewed for a Program Management position in the Visual Studio group. My
first interview was with the Design Manager for the VS product line. Her final
question for me was about building an effective temperature control system for
a new house. I launched into a 5 minute analysis of the advantages and
disadvantages of a wide range of HVAC systems, obvious ramifications from open
floor plans, and so on.

A month later, we sat down for lunch as co-employees for the first time, and I
told her the whole story. She got a big laugh out of it. I guess she didn't
realize that's what I'd spent the last few months working on.

~~~
philwelch
Your interviewer didn't read your resume?

~~~
aaronbrethorst
She did, but I hadn't been super-specific about what I'd been working on.

------
jamesaguilar
Angry because neither the hash table or the prime multiplication would be as
fast as a boolean array indexed by the char value. As an added bonus, the
boolean array actually makes the most intuitive sense.

~~~
user24
the boolean array indexed by char effectively _is_ a hashtable isn't it? where
the hashing algorithm is index = ord(theChar).

~~~
mrud
Yes, that's correct.

~~~
user24
thanks :)

------
rapind
Stories like this and the comments that follow just reinforces my belief that
I am no where near smart enough to work with most of you guys.

Plus I'll never wear leather pants. That can't be comfortable.

~~~
hardik988
Well, look at the bright side. You're now smarter 'by this question' - You can
be rest assured that if you're ever asked this question, you'll be able to
answer it.

------
mrshoe
If you are ever asked an interview question which you've already answered in a
previous interview, you should tell the interviewer immediately.

I know some coworkers who will intentionally ask a question they know you were
asked in a previous interview to test your integrity. (Edit: Not that I would
condone this practice either.)

These types of interview questions are about evaluating _how you think_ far
more than _what you know_. So, more importantly than the risk of getting
caught, if you recite an answer from memory and pretend that you're deriving
the solution on the fly, you're lying to your future coworker.

~~~
dennisgorelik
There is a limit to how open employee should be. Google actually wants
employees to keep things to themselves and not to talk about internal stuff to
outside world. 100% honesty would make prospective candidate leak internal
Google stuff to the outside world. So it's unlikely that interviewers would
set up "integrity traps".

~~~
dotBen
_100% honesty would make prospective candidate leak internal Google stuff to
the outside world._

That doesn't make any sense.

open != honest. Two different things. It's not dishonest to obey a Non
Disclosure Agreement, and so you can be perfectly honest person and still not
be "open" about matters which you are not authorized to reveal.

~~~
dennisgorelik
You forgot about context of my comment. I used "100% honesty" in the sense of
"never lie and AND be open". Please re-read original context: "If you are ever
asked an interview question which you've already answered in a previous
interview, you should tell the interviewer immediately."

"Not talking about your past interview experience" has about the level of
openness as "not talking about your corporate experience".

------
nhashem
I feel like most engineers rarely have to try too hard to get a decent job,
but I wonder if it's because of stories like this. I've been on the interview
circuit a handful of times so far in my life, and aside from the first time
when I was mostly clueless ("So where do you want to be in 5 years?"; "Man, I
never think that far ahead."), I feel like interviews have become a very
routine process of answering a similar subset of questions over and over
again. Am I being hired because they've made a true evaluation of my technical
skills, or was I just serendipitously lucky to have heard the answer to how
those 5 pirates are going to split those 100 gold pieces?

~~~
zeraholladay
Probably none of the above. I've heard the interviewer makes up their mind to
hire you in the first few seconds of meeting you. Psychology is a strange,
strange thing ... but reality is better than fiction.

~~~
firebones
Never underestimate the influence of narcissism in hiring, manifested as the
kind of blink decision you describe. Teams in a large company develop a
personality and culture that more often than not extends to attributes that
have less to do with skill and competence and more to do with similarity of
physical characteristics and outside interests. (The degenerate case is flat
out nepotism, but the more typical case is a team of people fitting a core
profile--5'10" 30-something males from second tier colleges, or taller-than-
average mustachioed conservatives.)

Most large company hiring practices are not so much a selection of specific
traits as they are a filter for ensuring a lack of negative traits. When you
factor in the bias of narcissism in interviewers, you'll get competent people
who are skillful at reflecting the interviewers' traits back at them (such as
the author, who didn't demonstrate incompetency with his first answer, but
aced the interview by reflecting the cleverness the interviewer must have
self-identified with as "Google material".) After a certain point, four or
seven or nine layers of interview will certainly guarantee the incompetent
ones don't get through, but at the same time it will also select for the kind
of highly adaptable social personality that is often found in political
operators.

~~~
enjo
My go to story to describe this involves a guy who was a EMT. He spent his
interviews describing his life as an EMT, and rarely dealing with any
meaningful technical discussions. He was offered a ton of jobs....

I saw something similar with a badly underqualified sys-admin who had been in
marine recon before embarking on a technical career. He had zero issues
finding a high paying job.

------
ajays
I have been in a similar situation, where one interview's curveball ended up
being asked in a subsequent interview. I went through the same emotions as the
author (including resisting the urge to grin from ear to ear). But like an
idiot, I answered with the trick answer right away (though I was calm about
it). I then told the interviewer that I had learnt it in a previous interview.
It turned out he was looking for the clever answer too; and he was
disappointed that I knew it. Maybe he felt I wasn't sufficiently "excited"
about the clever answer, but I never got the job. Which is not too bad, since
that outfit wasn't my first choice anyways.

------
ronnier
I was asked that exact same question over a phone interview.

One of the most interesting questions given to me was, write an algorithm such
that given four colors and a rectangle, fill the rectangle with a gradient
using a color in each corner. After the fact it wasn't very hard, but having
never thought about such a problem, it was pretty difficult white boarding it
out. It was a pretty good question because I think that most people aren't
thinking or preparing for such a problem, instead opting to study arrays,
linked lists, trees, sorting algorithms and running time. You really get to
see how a person thinks with it.

------
kabdib
Multiplication and division are o(log n) operations.

------
ibagrak
I've had something similar happen to me at a Microsoft interview. The
interviewer asked me a question I explicitly knew the answer to, and it too
wasn't "my" answer to the problem but the one I've heard in another interview.
So I just told him: "I know this one. Can you ask me something else?" He told
me he appreciated my honesty, and didn't have any other questions.

I got the job.

------
zeraholladay
Personally, I would be more inclined to hire a person picking the "throw it in
a hash and look it up" solution over any more complex solution. My reasoning
is that bad programmers tend to get lost in nuance, or don't understand a
problem. Good programmers tend to reason through the proportionate value of a
problem. I'm not saying nuance is always a bad thing, but it's probably not
what your company is developing unless you work for a math department.

------
TARMAP
I hate such stupid tricks, frankly a hash table or an array for a restricted
domain is way faster, since the whole data structure gets cached on the L1.

I can solve the same problem by using statistical thermodynamics, and show its
only o(1), since each string is a configuration of the system and finding
common alphabets is like finding degenerate states.

~~~
mdwrigh2
How could you do this in O(1)? Or are you saying you can get a probably right
answer in O(1)?

~~~
swolchok
It's impossible to do in O(1) in the worst case, because you have to at least
examine all the input (e.g., if the input matches the regex AA*B.)

~~~
mdwrigh2
That was my thought process, but the parent of my post claimed he could do it
in O(1) (actually, he claimed it in o(1), but I'm assuming he just typo'd).
Hence my question.

~~~
TARMAP
<http://en.wikipedia.org/wiki/Chinese_room>

------
random42
The point of the story is not the actual problem that author had to solve,
which we have been discussing (but again, its _hacker_ news, after all :-)),
but basically to tell how interviewing experience, even at which you fail,
prepare you for better.

------
wazoox
Hum, Guy's solution is really terrible, division, multiplication and modulo
are very expensive operations, and completely unnecessary here. This is
basically a case of "I'm clever and you must think like me to be in my team".
Uh no thanks.

------
Aleran
It is strange how every time someone interviews at Google they feel compelled
to write "their" story and share it with the internet.

How many stories like this are out there now? Hundreds?

------
lwhi
I paused a bit before reading about the possible solutions, and actually
thought of the (prime number) solution the interviewer came up with.

I realise that this is a bit of redundant post .. but, as a person who isn't a
brilliant coder I surprised myself. But then again, after reading the comments
here - I think maybe I just have an obtuse way of thinking about things.

------
skybrian
I'm guessing that the guy in the leather pants probably got the idea from
reading about Godel numbering. If you're interested in this, you might like
this book: [http://www.amazon.com/Godels-Proof-Ernest-
Nagel/dp/081475816...](http://www.amazon.com/Godels-Proof-Ernest-
Nagel/dp/0814758169)

------
exit
> _"Given that our range of characters is limited."_

i think what matters is that characters are enumerable, not finite?

~~~
endtime
Yes, if your code is going to run on an Turing Machine that actually has
infinite tape.

------
wingo
Leather pants turn a good story into a great story.

------
lwhi
Leather pants in an academic setting always makes me think of Jeff Goldblum in
Jurassic Park.

------
Charuru
I kind of wish that he didn't emphasize the 'women engineer', would've kinda
gotten the picture when he starts using she.

Maybe we'll get there someday...

