Live data from Hacker News

A Google Interviewing Story

paultyma.blogspot.com

111–120 of 122 posts

Re: A Google Interviewing Story

#111
post #95

Earlier quoted context omitted.

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.

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

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.

Re: A Google Interviewing Story

#112
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?

Re: A Google Interviewing Story

#114
post #73

Earlier quoted context omitted.

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

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

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.

Re: A Google Interviewing Story

#115
post #73

Earlier quoted context omitted.

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

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.

http://en.wikipedia.org/wiki/Chinese_room

Re: A Google Interviewing Story

#116

Earlier quoted context omitted.

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. T…

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.

I don't think you read the post being discussed here.

Re: A Google Interviewing Story

#117
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…

There are two kinds of cleverness: cleverness that makes things simpler and easier to understand, and cleverness that makes things more complicated and harder to understand. Often the former is the more difficult of the two, and also the mark of a better programmer. Moreover, experienced-but-average programmers will often decry cleverness in general, having observed too many cases of the latter and not enough of the former kind, and then when the former kind comes along, they have the same reaction, and this is bad.

Re: A Google Interviewing Story

#118
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…

In two interviews with G, separated by 5 years, the same 'hard' programming problem came up both times. I answered it badly the first time, then did a bit if research after that interview, and was fully ready to expound on it in the later one. It would be really embarrassing to get tripped up on the same question twice.

Re: A Google Interviewing Story

#119
post #86

Earlier quoted context omitted.

> 15 seen &= mask( haystack); Shouldn't it be seen ^= mask( haystack); And a personal change would be to define all as: int all = ~(~0 EDIT: For some reasons, asterisk doesn't appear before haystack.

Right you are, fixed now.

Yup, and you corrected my mistake as well. For some weird reasons, I typed ^ (xor) when I was actually thinking of | (or).

Re: A Google Interviewing Story

#120
post #18

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…

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.

Seconds? No.

Minutes? Well, yes.

In interviews, my tentative conclusion after two minutes is _usually_ the same as after 60 minutes. (I spend the following 58 minutes trying to disprove my hypothesis, of course.)

Post reply on HN