Live data from Hacker News

A Wretched Google Interview Experience

symbo1ics.com

321–330 of 359 posts

Re: A Wretched Google Interview Experience

#321

Earlier quoted context omitted.

Well to be pedantic it will grow, at worst, to (24 * 60 * 60 * 1000000000), if you are calling increment() every individual nanosecond. Though you are right that it is ignoring realistic memory issues. I was approaching it more as a thought exercise to address the moving window.

No, that's just the maximum possible in a single day.

Your bigger problem is with this "trim the array" idea, which is definitely not an obvious solution. The way you've coded it you'd have to tally almost the entire days worth of deltas just to determine the trim point. And you may still exceed that single-day max memory, because you'd accumulate overruns in between trims. I'll leave you to think about that one.

(Hint: google round robin database. You know, the solution that I mentioned.)

Re: A Wretched Google Interview Experience

#322

Earlier quoted context omitted.

No, that's just the maximum possible in a single day.

Your bigger problem is with this "trim the array" idea, which is definitely not an obvious solution. The way you've coded it you'd have to tally almost the entire days worth of deltas just to determine the trim point. And you may still exceed that single-day max memory, because you'd accumulate overruns in between trims. I'll leave you to think about that one. (Hint: google round robin database. You know, the solutio…

My comments, as mentioned, were ignoring real memory constraints. I don't know why you feel the need to come off as frustrated.

Re: A Wretched Google Interview Experience

#323

Earlier quoted context omitted.

Your definition of CRUD is incredibly broad and covers just about any application that reads or writes anything to a datastore, regardless of whether the datastore is ACID or some custom storage system for something like a huge graph of geometric data. Do you consider Quake a CRUD application? How about GwtQuake, a web-based version that consumes big BSP files? What about Minecraft? CRUD to mean has traditionally mea…

To clarify that, the general thrust is to unify everything onto G+, eventually. Should be fairly obvious and I inferred as much even before I joined Google. Good luck with that. I fear the day when my Apps domain is forcefully migrated to Hangouts. Hopefully there will be an alternative to Apps by then that is actually worth using. (One of the people present during my firing needed to summon his boss using internal H…

That's not strictly true. Google Search itself has inherited the ability to run image search, mail search, drive search, and calendar search within the front page.

Sorry to hear about your firing BTW, hope everything works out. I believe in second chances and I don't think people should be blacklisted for all time for something far in their past, with certain exceptions (e.g. sex crimes and working with children, etc)

Re: A Wretched Google Interview Experience

#324

Earlier quoted context omitted.

To clarify that, the general thrust is to unify everything onto G+, eventually. Should be fairly obvious and I inferred as much even before I joined Google. Good luck with that. I fear the day when my Apps domain is forcefully migrated to Hangouts. Hopefully there will be an alternative to Apps by then that is actually worth using. (One of the people present during my firing needed to summon his boss using internal H…

That's not strictly true. Google Search itself has inherited the ability to run image search, mail search, drive search, and calendar search within the front page. Sorry to hear about your firing BTW, hope everything works out. I believe in second chances and I don't think people should be blacklisted for all time for something far in their past, with certain exceptions (e.g. sex crimes and working with children, etc…

Thank you.

Re: A Wretched Google Interview Experience

#325

An acquaintance of mine applied for a product management job, did two interviews in NY that went fine, then was flown out to MTV for a series of interviews. When this person got there, two of the people they were supposed to meet with were traveling on business and hadn't notified the recruiter. A third was out sick. The supposed-to-be fourth, now first interview walked into the room and said, "Look, I don't have any…

I've interviewed at and worked for a number very very large companies before, and none of them have been as disrespectful at interviewing and hiring as Google sounds from these stories. I'm not defending this practice at all, but I think I can understand it. It sounds like the typical problems involved in scheduling 10 people to all perform together at once. Nobody can prevent people from getting sick. Going out of t…

>>As for the calculus interview, that sounds like fair game. PMs are supposed to have some PM interviews and some SWE interviews, and math is a perfectly acceptable area to ask SWE candidates.

Lets leave the managers alone for a while.

When exactly was the last time, you as a programmer used 'calculus' while writing programs.

Your statement shows everything wrong with hiring programmers these days. Which is to demand expertise in totally irrelevant areas, and when the persons fails to the test declare him incapable of doing his actual job.

And then when you hire people experts in irrelevant areas not being able to do the job, start complaining that good programmers are difficult to hire.

How will we find good programmers when we are not even looking out for them?

Re: A Wretched Google Interview Experience

#326
post #104

Earlier quoted context omitted.

> Given the sheer size of Google Microsoft has more employees and the three times I interviewed with them (and got accepted) it was a great experience, with perfect communication from their recruiters and interviewers. The one time I interviewed with Google (and got accepted, but I rejected them for MS) I pretty much went through a similar experience as the blog post, although the interviews themselves weren't bad, j…

Really? Microsoft's HR departments are completely siloed by business unit, and they don't share notes. If the rec you're applying for dries up, they do F-all to guide you into a new one. Each time you engage with a different BU you're completely back to square one.

It might be because each time I interviewed was for a new hire position or internship position...and their university recruiting is pretty solid. Google's on the other hand...

Re: A Wretched Google Interview Experience

#327
post #107

Earlier quoted context omitted.

And they can do all of that just because everybody still wants to work at Google. Let's say the have 100 applicants for a position, out of which 10 are qualified for it. Then they can still screw 9 of them and hire the one person that for one reason or the other had the luck of interviewing with the right people and talking to the right recruiters.

Many people don't want to work at Google. Yes, they can fill their spots, but the reality is that hiring bullshit means that over time their candidate pool progressively filters to "the people who will put up with bullshit", and while it takes years to filter through, in the end you up becoming Microsoft. There was a time when Microsoft was the bee's knees and was the elusive dream employer. Then they started various…

>>"the people who will put up with bullshit"

Isn't that the case already???

Most people joining big web giants I know are generally the kind of people who don't do any great real work but practice hours daily and spend insane amount of time on interview sites, take huge efforts in achieving expertise in one thing and one thing alone 'clearing interviews'.

Re: A Wretched Google Interview Experience

#328

Earlier quoted context omitted.

My experience of those interviews that ask CS or “puzzle” questions is that they are sincerely trying to determine that you are capable of dealing with inherently novel/theoretic problems or problems you've never seen before. Unfortunately this notion is misguided because the problems aren't real problems, and the context in which the problems are solved is entirely different to what it would be in the actual workpla…

You're not alone. Although it's never been as bad as not being able to do arithmetic, I can't seem to get a job doing those kinds of interviews. I was close once at Microsoft, after having done 8 hours of coding and linear algebra and other math (that I wasn't expecting) without a slip up, and what I thought was pretty great performance, but alas that wasn't enough either. Most of the time I freeze up and can't think…

It's great to see comments like this. I thought I was alone. The jobs I have gotten so far is either behavioural only, talk about past projects, or written technical (they give you some questions on paper and then leave you alone for an hour.)

Re: A Wretched Google Interview Experience

#329
post #221

Earlier quoted context omitted.

I'm really surprised that's not how it works at Google, both from their perspective, from the perspective of the candidate. I would be extremely hesitant to interview or accept a job at Google if didn't know what I'd be working on, and it seems like you only find that out when you show up the first day.

You are correct. Your mentor from your new team comes to collect you after orientation, and you find out then. You are also going nowhere for a long, long time.

This is true only if you are hired for a generic role. Most people are, but for sufficient specific jobs (like mine), you will know exactly what team you are joining.

Also, with decent performance you can transfer after a year, occasionally even earlier if another team really wants you.

Re: A Wretched Google Interview Experience

#330

Earlier quoted context omitted.

And that solution is isomorphic to the one the interviewer was looking for, where you put the requests in a priority queue keyed by their finish time and pull out the next one that'll be done. The only difference is that the priority queue in question is hidden in Go's scheduler. The reason interviewers ask these questions is so they get a sense of whether you'd be able to implement Go, starting from first principles…

It's isomorphic and better, because each goroutine performs a synchronous and easily understood acquire-perform-sleep looping operation with no hairy coordination. And even underneath, it's somewhat simpler, because neither Go nor the design I gave cares which of the runnable goroutines (the servers that have finished their work) takes the next request off the channel. Plus the blocking behaviour of channels gives yo…

You probably should care which server gets the request. It's not explicitly said, but if one server can handle twice as many requests per second, then it might be completing each request faster. If that's the case, it's a better service to give more requests to the faster servers. Worth at least discussing to see if there are other aspects to the problem.
Post reply on HN