171–180 of 359 posts
Earlier quoted context omitted.
What sort of background thing are you talking about? Criminal? Civil?
Criminal, and that is the extent that I will follow up. I will also reiterate "minor".
Just playing, but "If you have n servers that take requests, and server Sᵢ can take a request every tᵢ seconds, and you need to distribute requests to them as efficiently as possible, how do you do it?" can be done very easily in Go. You have a shared channel which contains the pending requests, and a goroutine per server that simply loops doing: read from the shared channel, perform the request, wait for the sleep p…
That's an easy solution in any language, frankly; have a shared queue of the requests, and the servers simply pull from the queue whenever they aren't processing a request. I'm sure that this is easier to implement in Go than a lot of other languages, but I think this actually defeats the purpose of the question. The hard part of the question is how to assign work to the servers rather than letting the servers pick t…
I actually intended this as a way to "assign work" rather than having the servers pull. Each goroutine "owns" a server and forwards all requests to it, but it's just part of the one load balancer process, and the load balancer does nothing but balance.
IMO, defeating the purpose of a question is how you solve problems in real life.
Now if you wanted a harder question, you could follow that with: OK, that solution will give the servers time to do their thing, but there's no guarantee it won't just end up dumping all the load on a few servers, straining infrastructure and under-using the other machines, because there's no guarantee Go's scheduler is fair. So please develop two competing solutions. First, a fair scheduler that spreads the load evenly. Second, as an alternative, an unfair scheduler that always fills 100% of the time on the first machine before moving on to the second, and so on, and reports how many machines it's using so we can take the others out of the pool and repurpose them.
Earlier quoted context omitted.
Nice catch. I was actually going to bring this up. I have a lot of friends who are interview pros. They say if an interviewer decides earlier on you're not going to get hired, they basically fold up their sheets and ask non-related general questions to pass the rest of the time.
Guilty as charged :-) As an interviewee, I have, more than once, thanked my hosts for their tea and cake and left early when I detected that the interview was turning into a chat. Would a collegiate interviewing model not work better for an intellectually driven organisation like Google? Each team interviewing for their own positions, but with some form of 'tenure track' process for the longer term?
At a broader level, the problem with this is that the delays inherent in doing a lot of hiring and relocating people means that you can't have teams doing their own hiring and then waiting for people to arrive and come on-line - there need to be candidates in the pipeline before the exact seats open up. Otherwise you're talking about a 3-6 month delay from when a seat opens to when there's an engineer sitting in it, which sucks.
Yikes, this story and HN comments sound like disasters. As a sorta balancing out here, my experience interviewing with Google(June 2012) was fantastic IMHO. We agreed right off the beginning what role exactly I'm interviewing for(Test Engineer), different from what I applied for(SDET) and went with it. Note, that I was holding them off for about 2 years. They'd email/call me every 6-8 months, and I'd say "Hold on, gi…
Ha, I didn't tell anyone in my family, including my SO I went to interview with the Big G either. Didn't want them to see how disappointed I would be if they rejected me.
I had a google interview about a year ago. The thing I found strangest is that some interviewers would walk in the room and throw up a coding exercise without any introduction at all. They literally wouldn't give their names and what projects they worked on. You don't care that I've been working for almost 10 years in the real world and would rather judge me on my ability to solve a linked list problem? Really? If an…
I had a very similar experience. I work at an investment bank and was recruited by a large company that does proprietary trading including high frequency trading. I went for the interview which was scheduled to be an all-day thing. In addition to having been in IT for a very long time I am also very knowledgeable on capital markets having successfully taken CFA (Chartered Financial Analyst) tests. The CFO of the comp…
Just playing, but "If you have n servers that take requests, and server Sᵢ can take a request every tᵢ seconds, and you need to distribute requests to them as efficiently as possible, how do you do it?" can be done very easily in Go. You have a shared channel which contains the pending requests, and a goroutine per server that simply loops doing: read from the shared channel, perform the request, wait for the sleep p…
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…
Is there some kind of renegade JavaScript going on here?
Two thoughts: 1) Larger companies get away with inefficient recruiting because they can. If the same company abuses you twice, and you go back a third time, what's that say about you? It certainly goes a long way to explain why they can do it. 2) If you're considering going back on an offer, or interviewing just days after starting a new job, you don't have much room to complain about bad behavior on the company's pa…
>> Larger companies get away with inefficient recruiting because they can. I would disagree. I interviewed with MS, Google & Amazon multiple times. MS & Amazon are definitely much more organized and very prompt in following up with decision.
It would be interesting to see if any of their recent VIP hires had similar headaches, or if this is just junior employees.
As I said elsewhere, this is surprising because everyone I know there is very straightforward.
Google's recruiting seems like it must be at least partially the responsibility of short-tenure contractors. Every time I've dealt with people from their recruiting department, even the very nice ones seemed forgetful, inattentive and poor at communication. The actual Google employees who do the interviewing are on average very bright, good at actively interviewing candidates (instead of just rattling off questions),…
>>> but it also makes it a net negative for candidates who don't meet the unstated criteria Google is after - criteria that could often be screened for before a candidate ever sets foot on campus. The crazy thing is they don't give feedback, then call back in a few months and ask if you want to interview again for the same position like the OP said. Talk about completely confusing people. . .