Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Google Interviewing Story

paultyma.blogspot.com

Post reply on HN
Print view View original

41–50 of 122 posts

Re: A Google Interviewing Story

#41

Post by 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.

Re: A Google Interviewing Story

#42

Post by mdwrigh2 »

TARMAP wrote: post #14

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.

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

Re: A Google Interviewing Story

#43

Post by baguasquirrel »

akeefer wrote: post #33

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…

The dinging people for not-clever-enough solutions feels like hazing. It's less about competence than about ego. The most important thing in an interview is to make sure the person's level of skill is at least as big as their conception of their skill.

Re: A Google Interviewing Story

#44

Post by dotBen »

dennisgorelik wrote: post #25
mrshoe wrote: post #13

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…

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".

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.

Re: A Google Interviewing Story

#45

Post by tedunangst »

exit wrote: post #21
nl wrote: post #15

Earlier quoted context omitted.

Your anger is misplaced. Characters can repeat, so a boolean array doesn't work. Plus, the story says I mumbled awhile that given the characters were limited to alphabetic (his original specification) that I could use an array instead of a hashtable for some constant time savings but that was about it.

sorry, i don't get how characters repeating affects things

If there are 3 As in the first string and 4 in the second, it fails. A boolean value can't count to 3.

Re: A Google Interviewing Story

#46

Post by philwelch »

aaronbrethorst wrote: post #12

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…

Your interviewer didn't read your resume?

Re: A Google Interviewing Story

#47

Post by aaronbrethorst »

philwelch wrote: post #46
aaronbrethorst wrote: post #12

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…

Your interviewer didn't read your resume?

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

Re: A Google Interviewing Story

#48

Post by aaronbrethorst »

philwelch wrote: post #46
aaronbrethorst wrote: post #12

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…

Your interviewer didn't read your resume?

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

Re: A Google Interviewing Story

#49

Post by unoti »

akeefer wrote: post #33

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…

Agreed. The prime-number-division thing is a great answer... FOR SPOCK. Who wants to read code that does that kind of stuff... converting strings in to prime numbers? How about: code it in a reasonable, readable way, and come back and optimize it if and when it needs optimizations. People that code things in the cleverest way, even when it's not needed, drive me batty.

I'd far rather see a developer cross 10 items off the to-do list instead of cross 1/2 of an item off a to-do list, and get lots of style points.

It's good to see that a candidate has creativity to come up with solutions like this. But I'd want to temper that by also seeing if they have the good judgement to know when to use such things (almost never).

Re: A Google Interviewing Story

#50

Post by bfung »

nl wrote: post #15
jamesaguilar wrote: post #2

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.

Your anger is misplaced. Characters can repeat, so a boolean array doesn't work. Plus, the story says I mumbled awhile that given the characters were limited to alphabetic (his original specification) that I could use an array instead of a hashtable for some constant time savings but that was about it.

it doesn't matter if characters are repeated. Let's assume ascii characters, so 'A' = 65 in decimal. If you make an array, T[], where T[65] = 1 if 'A' exists and 0 if 'A' didn't exist in the first string, you can run through the 2nd string to check if T[65] was true (1) or false (0), telling you if the character in the 2nd string appeared in the first. Same thing as the hashtable. I think that's what was meant by boolean array.
Post reply on HN