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".)
A Google Interviewing Story
111–120 of 122 posts
Re: A Google Interviewing Story
#112How many stories like this are out there now? Hundreds?
Re: A Google Interviewing Story
#113Re: A Google Interviewing Story
#114Earlier 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.)
Re: A Google Interviewing Story
#115Earlier 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.
Re: A Google Interviewing Story
#116Earlier 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.
Re: A Google Interviewing Story
#117I 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…
Re: A Google Interviewing Story
#118If 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…
Re: A Google Interviewing Story
#119Earlier 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.
Re: A Google Interviewing Story
#120I 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.
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.)