Invisible wrote:
>>> (E.g., I suspect if you applied to work for Google,
>> Not if their interview process is anything to go on.
> O RLY?
> You know something about this then?

Yeah. They saw my resume and wanted to interview me. So they asked me 
stupid questions over the phone like you get in phone interview just to 
see if you're a poseur or something.

But then, when I got there, there wasn't a single question about 
anything I knew or anything I'd done. Not one word mentioned about 
what's on my resume.

Plus, all the questions were these abstract programming questions, most 
of which had nothing to do with the sort of things Google does.

"How do you efficiently tell if an integer is a power of two?"  (It's 
trivia - if you know the trick, you answer the question, and if you 
don't, it's unlikely you'll come up with it in the middle of a job 
interview.)

"You have a bunch of data you want to be able to insert, find, and 
remove, and you want to be able to retrieve a random subset of size N of 
that data."   Well, use a hashtable, and take the first N entries. 
"What if your hash function doesn't balance out well?"  Can I assume I 
know how to generate good random numbers, or is that what you're asking? 
"You can assume you have random numbers."   So I can write a good random 
number generator, but I can't write a good hash function?

"You have 10,000 machines with 5,000 entries in a file on each. You want 
to find the 100 most common entries in the file. Estimate how many 
machines it'll take."   Well, how fast do you want it?  "Um, well, pick 
a speed, and estimate how many machines it'll take."  OK, run the 
program on 100 machines going to 5 machines, then 100 machines going to 
10 machines. Assuming that's roughly twice as fast, multiply that number 
by 100, divide it by how fast you want it, and that's your number of 
machines.  "OK, do that."  So, you want me to estimate how many machines 
it takes to run an unknown program on unknown data at an unknown speed 
and finish within an unspecified deadline, and you want me to estimate 
that standing in front of the whiteboard at the job interview?  "Yes."

"Find the smallest N numbers that fit the equation 2^i * 5^j for any 
positive i and j."   Struggles for a bit, realizes there's no obvious 
pattern to it.  Where do these numbers come from? "What?" What sort of 
process generates or consumes numbers like this that I'd have to find 
them? That'll give me a handle on what order they're in.  "Just solve it."

"How would you estimate the cache size of a processor?"  I'd look in the 
source of memtest x86 and see what processor instructions it uses to 
look that up in the CPU.  "Say it's a different CPU."   I'd ask the 
manufacturer.  "How would you do it with a program?"  Why would I guess, 
if I can actually determine it accurately at runtime? OK,here's some 
code to do it.  "What would make it's results invalid?"   See?

Virtually none of the questions were connected with any sort of 
scientific or business processes that I could figure out, except maybe 
the "estimate merging files", for which "do it on a small sample and 
multiply" wasn't acceptable for some reason.

Their system administration group did a better job on the questions. 
Stuff like "if you try to log in and get told 'too many processes', 
what's goign on and how do you fix it?"   Or "name the bits in the TCP 
headers."  At least that was testing actual knowledge you might need if 
you're administering machines.

-- 
Darren New / San Diego, CA, USA (PST)

Post a reply to this message