How to Score a Google Onsite Interview
allenc.com
allenc.com
What I need is a high-traffic scalable document store. The churn of documents is going to be very high and the documents can be very large. I'm going to need to regularly retrieve documents, but mostly only the documents with the closest expire time. How would you go about solving this problem?
Now, there are so many variables in this question that asking for a specific solution is practically useless. Instead, it would focus on an interviewee's ability to parse the computer science problem from the stated problem. I would be looking for answers that include possibly building an index of the documents stored in a distributed priority queue architecture. I'd ask them where they expect pain points to be. Good answers would include things like providing document synchronicity across a distributed architecture, providing good failover in case of machine failure, and working out a sane and minimalist communication API between machines.
Basically, I'm asking candidates what they should Google if they were trying to solve this problem. The answer given when many coding questions are asked is "I'd Google it," but I've learned that recognizing what to Google is an incredibly hard question. When you start dealing with problems harder than "what was that function in the standard library called again?" it becomes even more useful, because the question now isn't "what do I Google?", it's "What papers do I need to read to understand succesful models of this problem?"
I'm just an interviewee still so I've never been able to give this method a try, but I'd be interested to see if results are better or worse than current methods.
Started off with "say your index.html is 500GB..." and a whole bunch of other exaggerations.
I ended up designing a web server all the way down to the TCP/IP layer. Of course, they stopped me and made me explain my design decisions along the way.
I accepted the offer. It was the best job I've had so far.
One guy came in and without introducing himself started to write numbers on the whiteboard. He drew borders around some of them. Then he sat down, introduced himself, and said that what he wrote on the whiteboard was machine code. After explaining some of his nomenclature he asked me what I think that code was doing.
Another guy asked me to solve a problem (don't want to say what specifically it was, because they may still use that question)... Anyway, I could not for the heck of me solve that problem. After 45 frustrating minutes of this he started to write down the solution, then hesitated, then stopped, saying something like "Hmm... It's not quite as easy as I thought".
In the end I ended up declining their offer. I spent some time on their campus, and the vibe just did not feel right. Can't put my finger on it, though.
math problem? systems problem?
I too had an extremely bad vibe about the campus. The ambiance on the whole premises is the same as school : careless playful youth (even coming from the senior engineers), toys everywhere, and the implicit deal that Google will give you everything if you give it everything. I felt a perverse temptation to give in to this, although i knew very well this attitude generates a dependence relation in the employee.
After working in the austere world of avionics for over 10 years, i found it absolutely shocking. But from their point of view, this is a winning combination. It is just not conductive of hiring senior employees, of which they probably have plenty supply anyway.
Seemingly, having a friend who's in a senior exec position at Google seems to be the only surefire way to ensure you get an onsite interview. At least then your friend can hold Recruiting's feet to the fire.
[1] true story. I've elided some minor details which make the whole thing seem even more farcical.
My second onsite was a pretty miserable experience to be honest - I just wasn't doing well, and I knew it, but I couldn't get it together.
But one useful tip that did come out of it. The first interview (of 5) was via video, and it took 30 minutes to get going. It was the first time the interviewer had done one on her own, and she seemed more nervous than me. I didn't do great, but did nothing terrible either.
Anyway, when it came time to finish, she asked me if I had any questions. I was prepared, so asked her something, which she answered quickly - then asked if I had anymore. I said no, and so she goes "well in that case.." and asked me another interview question. And it was the one question I've had that I had no idea of how to approach.
Lesson: make sure you have lots of questions, and keep them talking.
What, no more Fermi Problems anymore? No more reasoning about how many piano tuners there are in Chicago? No more estimating how many hairs you have on your head? Not necessary to calculate the total number of sheets of 8.5 x 11 inch paper used by all the students at the University of Maryland in one semester? How many drops of water are there in Lake Erie? How many notes are played on a given radio station in a given year, has become irrelevant? What a loss ;-)
I'm thinking more about just annoying puzzle problems with one right answer, that if you don't have an "aha!" moment you'd probably never get (and remember, this is in the context of a stressful interview). Stuff like the Two Glass Balls problem:
http://sites.google.com/site/mytechnicalcollection/puzzle/tw...
It is the same reason top companies tend to recruit from top schools. The chance that you pull a top notch programmer from a top school is higher than the chance that you pull one from a mediocre school. In the same way, the chance that the kid who passes your interview with flying colors is a good programmer is better than that of the one that completely tanks.
I've had to write my own sorting algorithm perhaps twice in the last some-odd years. If you're writing sorting algorithms from scratch, you probably should sit back and consult your standard libraries.
So if I ask a candidate some basic coding question and he can't write a for loop, I know it's a no-hire. But past that basic bar, sifting apart the good candidates from the great ones is actually very hard. Do we continue to ask these questions because we can't do better?
(That's why I ask algorithm questions. I realize they suck, but I just don't have any better ideas. I'm an engineer, not an HR flack.)
So what's a better way to test a programmer candidate?
Even just a simple a question as: "We're doing XYZ. To handle this situation what would you do?" is incredibly telling.
To my mind, being able to apply knowledge is the valuable skill, otherwise it is just trivia that a person knows.
We also have a programming test. Everybody is subjected to it. In the beginning (when I had to do it :) ), thought it was stupid, but now I find this a valuable tool to aid with the decision (we frequently hire people who did not finish the test). The problems are relatively simple. You get 2 hours alone in a room, a programming language of your choice, and internet connection (so you can search for stuff).
As for programming tests, I think you're playing into my bias about how everyone thinks the questions are stupid until they pass, at which point the questions become the arbiter of all intelligence and merit. ;) It's that sort of hazing ritual sociology that enshrines questions about moving Mt. Fuji or printing n to the power of 100 in decimal form.
A lot of my interaction between coders is explaining to each other what we've done, I'd prefer someone who might be a worse coder than me but can explain things well (and write good commit messages, etc.) than a guy who writes epic code but can't explain it to me.
the conundrum is this. i spent my time learning the academics and theory of programming, design, and business. jobs want experience.
i am an extremely fast learner, but cannot get a chance at a full time job after being successful at a paid internship for over a year.
everyone is looking for experience, i feel like if you don't know Exactly what you are doing day one, then you can't get your foot in the door.
yes, i have a website up, resume tuned, and a portfolio of what i have done.
thank god for unemployment checks... =/
Or anywhere really, i can relocate.
If you're interested in Denver or anything else, shoot me an e-mail. I can't answer right away (I'm in the hospital at the moment) but I'd be happy to help answer ?'s.
Currently building an online game editor / creator (my startup yCombinator plan)
i would be glad to contribute to an open source project, haven't found one that has really caught my eye, or that i feel i could add meaningful input to.
i should search Github / Google Code a little harder, fire up Mercurial, and give it a shot
I will check this out. Thank you
You can easily write code for, and contribute to, these browsers. Whether it's for the rendering engines (gecko, webkit) or their open-source browser counterparts (firefox, chrome). Get involved!
I can't tell you the number of times I've had an interviewer come into the room and clearly state that they haven't even read my resume yet (so excuse them if they take a minute to look at it first), much less looked up my projects or my website. This has happened everywhere, from tiny startups and Google/Microsoft/Facebook to banks and contract positions. Even when I've worked on projects related to the company (e.g., Twitter and Facebook apps when I interviewed at them), the interviewers had no clue (and I mentioned them quite prominently on my cover letter/resume/site). They don't look them up afterwards, either (using Google Analytics, I can tell whether they've visited).
There have been a couple times when the interviewer has looked up and liked my projects, and we've had fun discussing them, but this has been quite rare.
So unless you're directly using your projects to market yourself (i.e., you're purposely using them to network, rather than just doing them for fun and "passion"), I find this advice rather naive.
But maybe I'm just Doing It Wrong, and YMMV.
We're not psychic, if you aren't upfront with your lack of social skills, your potential to be dunning-krugering yourself, or your unwillingness to write code on your own time for the sake of it, we can't do much for you.
I had a rough start to my career (I have no degree and spent the latter half of my senior year of HS trying to avoid getting slapped with a felony charge), but I still managed to make it because when it came down to it, I enjoy programming.
I enjoy programming so much that regardless of what happens in my career, I will code.
I will code hungry, tired, or homeless.
I will code at night, in the morning, and in the afternoon.
Getting paid to code is a plus, but not the point.
This attitude showed, and I was eventually given a shot.
Where's your code? Why do you want to be in this industry?
Good luck sorting yourself out. The early years are usually rough.
I'm going to go get some night riding in.
2nd edit before I go: You shouldn't give a fuck if anybody, including an interviewer, sees your code. One of the quirkiest but most interesting programmers I've ever known is a 50-something year old that has worked as a line cook his whole life (other than a brief stint in the military). No formal education.
Rough around the edges, maybe 5 people in the whole world have seen his code, and he's probably better at programming than you are...
...because he codes. His latest project? A pseudo-stack machine JIT runtime thingamajobber. The man amazes and amuses me regularly.
Ugh, really? I feel like 90% of the time if you find yourself writing a JIT compiler, you're probably doing it wrong.
And "quirky" is not something I want to hear ascribed to a codebase.
Most recently, he's run into and fixed some bugs in linenoise, which was written by one of the most prolific programmers I'm aware of in recent history.
Don't badmouth people you don't know.
Quirky was an adjective for him, not his code.
He's writing the it for fun, that's all. He has no needs.
I make a point of reading the resume of every person I interview so I can ask relevant questions. To do otherwise would do our time together a disservice.
One hack to get around the experience problem is to charge a lower hourly rate and be more compromising about payment terms. Instead of requesting 50% upfront ask for a smaller amount and remainder at project completion.
Having said that, if you sense the client will have trouble paying you tread carefully.
I'm sure there is a whole philosophy that lowering your hourly rate is precisely what you should not do. There is a time and place when you should follow that. But suffice to day that if you are just looking to get the ball rolling and earn some cash programming, there are enough price sensitive clients.
I would also follow themadvice of working on open source projects. That way within a few months at most you should be able to say you have decen experience developing your average web app.
I'm a recent graduate making a half decent income doing contract work. But I've been freelancing since high school as a dev. On the otherhand, I have no formal degree in CS. You have a better shot at getting a job at google than me.
i have the grand college experience sitting behind a desk taking notes, nodding my head, and cramming for exams. Which in turn stopped me from building more projects.
will PM you my email.
Also, if you're going to send people to your personal site, you shouldn't use one that's under construction. You would be better off using flavors.me to make a temp one, then changing it once you've spruced up your site.
What do you do? What are you looking for? Hows your Joel test?
see http://stackoverflow.com/questions/214031/is-constant-compar...
(“x” = x) //Throws a compile error
(x = “x”) //x is set to "x"
Cheers.
I was more worried that the language in question was C++, so you have to worry about conversion constructors, conversion operators, operator==, etc.