This blog has moved to Medium

Subscribe via email

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading ... Loading ...

Posts tagged ‘Google’

Leaving so soon?

tl;dr – I’m leaving Google, to join a hot new stealth-mode eCommerce startup founded by Aviv Revach and Eyal Brosh, after five months of being at Google.

To make a long story short – during my short period there, I came to the conclusion that I really prefer working in a startup over being at a large company, at least in this stage of my life and career. The reason I joined Google was to learn how a good big company works – and Google is the best company to do this at. It has really excellent people to learn from, a good culture of moving fast, iterating, dogfooding, and fixing things that are broken. The one thing I was missing there was … they are not a startup, with all that implies. Although Google preserves a lot of startup elements in its culture, and has “startup like” projects started all the time, from above and bottom, including the famous 20% time, what I was missing the thrill and focus of being able to start a new project from absolute scratch, being in charge of major technological decisions, choosing the tooling and technology, and getting the chance to “make it or break it” on my own.

In Google, I knew that even if a project I started would fail, my job would be safe. There are a lot of advantages to this kind of stability, but the advantage of being totally on your own is that it hones the senses, simply because you and your team have so much riding on the success of your project. In a startup, I know that a lot of decisions I make will have major impact on my success, and this is much less apparent in any medium-large company.

I really intended to give it a go and learn all that I could from a large company, but then came Aviv and Eyal, both of which I knew from my army days, and slowly convinced me that their startup was the next best thing on the planet.

It took an agonizing few weeks to decide, and it was a really tough choice (thanks to my wife Aya for her support in these weeks. She heard my endless deliberations and took it really well, and recommended me the wonderful book How We Decide). Eventually, I decided that at this stage of my life, joining a promising startup, especially with such very high caliber people, beats the promise of staying at Google and trying to make things work for me. I can’t be sure this is “the one and only right choice” (there is never “one right choice”), but I know I have to try this, at least for the education I’ll get by doing this.

Fellow Googlers (especially the Trends/Insights team, where I spent the last five months) – I hope to work with you in the future, either in Google or outside. I’ll miss you all, and of course the salad bar in the 26th floor :). You’re welcome to visit me in Hertzelia Pituah, and I’ll still drop by every now and then. So long, and thanks for all the fish.

How I got hired by Google (this time)

(Yada yada, this post doesn’t represents any opinions except my own, and barely even that :))

For the sake of friends, family, and other readers who might be interested, I wanted to document the process I’ve gone through with Google. I find it a bit similar to the process Steve Yegg went through when he got hired by Google, because both of us were turned down by Google the first time we interviewed there. I hope this might help you if you ever decide you want to try to become a Googler yourself (here is why I chose it, but you should find your own reasons).

My history with the job market is rather short – before interviewing at Google for the first time, I have been “employed” by the Israeli Defense Force for six years, in the course of normal army service. I was doing professional and interesting work, but I wasn’t exactly free to choose (Israeli mandates a three years compulsory army service for guys, and I signed for three extra years at the age of eighteen as part of the Atuda program). While in the army, I started my Master degree in CS, and when I finished it (half a year after being released from the army), I finally had to make my first employment choice in the “real world”.

I didn’t know the first thing about what I wanted. Throughout my army service, I had the concept that I really wanted to do “research work” (not that I knew what this means, it just sounded cool). I also remembered that I really enjoyed studying algorithms and data structures back in my B. Sc days, so I considered working as an algorithm developer (I had assumed the job has some correlation to the problems I faced in Algorithms and Data Structures courses – which is not necessarily true). Also, I was really drawn to the startup world, having tried unsuccessfully to create one myself. And, of course, Google was on my list of possible employers, because, well, it’s Google.

I approached interviewing at Google like I would any other company. I ignored the emails they sent me on “how to prepare for the interviews”, and hardly did any any research about the Google interview process. Also, since I thought it’s such a good company, I interviewed there immediately – actually, it was among the very first companies that I interviewed for. Unfortunately (or fortunately), I completely sucked at the interviews (or at least this was my subjective feeling at the time). The interview problem I most distinctly remember is being asked to sort an array of integers. “Trivial”, I said, and blurted either “Quicksort” or “Mergesort”.

“OK”, said my interviewer, “that’s a good answer. Now please implement it on this sheet of paper.”

“What?!”, I staggered. Still, I didn’t completely freeze, and wrote down some implementation or another. I did understand the concepts of both sort algorithms well enough to explain them, but when I tried to put it down on paper, I made some annoying +1/-1 indexing error, which I was unable to track down in the course and pressure of the interview. This, and other errors like this one, was one of the factors that made Google decide I was not ready to work for them yet. “Please interview again in another six months” was the reply I got.

Of course, in another six months I was happily employed at what became my job for the next three years, so the thought of interviewing again didn’t cross my mind until now. Recently, when I decided that it’s time for me to switch jobs, I took a second, more mature look at Google. I thought long and hard about what my motivation for leaving Delver, and found that it’s a desire to learn and grow. I then concluded that Google was the best place for me to do this (not an easy decision, but a decision that had to be made nonetheless). Once these thoughts crystallized in my head, I decided that this time, I’m going to be hired. I knew internally that I’m good enough, and I could make it with the right combination of preparations and luck.

The first thing I did was grill a couple of friends that were hired by Google in the last year. They didn’t reveal anything secret about the interviewing process, of course, but talking to them did send me in the right directions – “go study data structures and algorithms!” was the clear message. I first implement Bubble Sort as a warmup exercises, and managed to include a horrible yet hard to detect bug that made me take things a bit more carefully from then on. I revisited Introduction to CS, Data Structures, and Algorithms course material, and actually solved exams by coding the solutions. I didn’t anticipate how difficult this would be – not the actual problems, but the act of mentally forcing myself to fill in all the gritty details and code algorithms that actually work (and prove it via test cases). “Google is looking for smart engineers who know how to solve algorithmic problems, and code the solutions”, I was told, and so I made sure I am one of these engineers. One of the most difficult things I had to do was mentally push myself to do things throughly and not take shortcuts.

I scurried the web, reading tales of other qualified engineers that went through the interview process. I solved several Google Code Jam problems. I thought about how I would build large, Google scale services such as Search, Gmail and Maps, and wasn’t ashamed to ask questions when I didn’t know the answers. When I was almost ready for a Google interview, I started interviewing at other companies. You can’t believe how bad at interviews we (I) get when we don’t practice it for a few years – interviewing with other companies was a good way to get a feel of the market, validate to myself my choice of Google, and get better at interviewing and solving technical problems. Finally, I submitted my resume via a friend that works at Google (a good recommendation from a Googler tends to help your chances … it certainly can’t hurt). All this time, I kept repeating the basics – I reread the material for Data Structures and Algorithms courses quite a few times until it all sunk in, and I must have implemented Quicksort and Mergesort a few dozens of time until I was sure I could do it flawlessly and under pressure.

A Google interview process is usually composed of a basic “screening” interview, followed by a series of more difficult interviews. I was actually told by my Google recruiter that because my results last time I interviewed, I could skip the screening interview and proceed directly to the more difficult ones. I chose not to, and took the screening interview as a warm-up exercise (I was surprised and encouraged to find that it was really easy for me, and this encouragement helped with the other more difficult interviews). Google usually schedules all your advanced interviews (5-6 of them!) into one long day. One important tip is that you can ask your recruiter to split these interviews into two different days – I found it much easier this way)

Finally, after several challenging interviews and nervous days waiting for Google’s response, I got the “ok, you’re hired”. The process I’ve gone through was, I believe, the right process for me. I might have been slightly over-prepared for some (not all!) of my Google interviews (and I was never actually asked to implement Quicksort or Mergesort), but it’s better to be 400% over prepared and succeed than be 10% under prepared and fail. I understand that not everyone can dedicate as much time for the preparation process as I have – it was relatively easy for me because I announced that I’m quitting before finding another job, and so didn’t have to hide the fact I’m interviewing and studying – this can be very stressful, thinking about your new job while nobody at your current gig knows you’re quitting.

If you want to apply to Google, you should decide what process works for you, and how much you really want it. And study up on your Mergesort/Quicksort – learning to implement them flawlessly is not an exercise in memorization, but rather an exercises in solid algorithm building using pre/post-conditions and an excellent “mental muscle warmer”. I took Steve’s advice of doing “short-term warm-ups” to heart.

I hope this has been a useful post for you, and I encourage you the look up the other available sources. Here are some links to get you started:

Good luck in your interviews!

Noogler training at the Googleplex

Not only did Google agree to pay me money for working on cool products and technologies, they were actually nice enough to send me to two weeks of training in the Mountain View Googleplex – me and every Noogler that joins our forces. Observe the very first photo I took once arriving here.

At the time, I thought only “wow, nice bikes”. I didn’t imagine that there were actually dozens of such bikes available all throughout the Google campus. I was delighted to find that I could use them myself. The principle is really simple – whenever you see a bike, you can pick it up and ride to wherever on campus you want to go, and you just leave the bike there. It’s very addictive.

The first few days were a bit difficult. I was still suffering from jet lag, and for some reason thought Googleplex was much smaller than it actually was. Then, as I tried to meet with some friends, I found out that it’s actually a lot larger. It cost me a missed lunch, but I got the message, and the next day got me a printed map of the campus and simply rode all around on a bike to gain a small sense of direction.

The training courses themselves are a lot of fun, and some of the lecturers were really engaging and funny (not to mention educational – duh!). This week does a good job at showing us Nooglers just how much we don’t know, and how much we’ll never know because the scope of knowledge is always increasing at alarming rates. We get a first hand experience of this here at Google.

What really amazed me is the amount of freedom people seem to have here. From what I’ve seen so far, 20% seems totally real, and people are encourage to take up those projects. One famous Googler named Meng has taken up “World Peace”, at first as a 20% project, and now on full time.

Another great thing about working for Google, and specifically Orientation, is how many interesting people you meet. From other Nooglers, to lecturers, to people whom you share interests with – and not just engineers! I just had beers with a few Nooglers this evening, and they all agreed – we want to feel stupid, we want to improve, and this is the reason we all joined Google.

I haven’t talked a lot about the cool toys. Every company has them, but the variety and quality here is very pleasing. Here is a very small selection that I bothered to photograph … my favorite was a console version of Gauntlet – I believe until now I had only played this on my computer a long long time ago, and it was delighting seeing this game on a real size console.

I managed to get a little bit of work done as well. As it happens, my “work” right now is simply learning about the infrastructure and methodologies of both Google and my team, as well as learning web development in general. I’ll get productive soon enough, don’t worry.

And now, off to Toronto for two days before I finally return home. See y’all soon.

Have feedback on Google? Bring it!

Note – this post obviously only represents my personal opinion, and not of Google. Kittens will be killed if you think otherwise.









Now, that we have that out of the way, let me come to the main point. Feedback is important, and I don’t think we’re doing a good enough job getting and managing user feedback. Yeah, I’m starting to use “we” in this context, even though I’m a super fresh Noogler, I’m practicing!

I just remembered that a few years ago (about five minutes after I discovered User Voice), I found a User Voice feedback forum for Google. Over the years, a few people actually found it and voted up my #1 suggestion. Now that I’m a Googler, I might have some small ability to actually move things in Google, even if right now it’s mostly finding the right people to talk to, and asking them about stuff I care about.

So … if you have a feature suggestion or frustration relating to one of Google’s many products – feel free to post it at the feedback forum – I’ll try to do my best to promote these ideas internally.

Add StackOverflow-specific search to Chrome for fun and profit!

When I saw Chrome’s Custom Search feature a while back, I didn’t think of any particular use for it for me.
However, lately I’ve noticed that a lot of my queries end in “”.

So, I went ahead and setup shortcuts for searching Stack Overflow (and Super User, while I’m at it). From now on, if I want to make the turtle move in Logo, I simply type “SO turtle logo” into my Chrome’s omnibox.

To set this up, see this link.

Basic – a collection of exercises in basic data structures and algorithms

When I started to think seriously about working for Google, I knew I had to get back into shape, fast. Google were going to test me in their (in)famous interview process, which puts a lot of emphasis on basic, “hardcore” computer science – namely, data structures and algorithms.

In the course of the recent months, I have solved quite a few problems in “classic CS” (all of which have classic textbook solutions), and coded the test cases and my solutions. I would like to share this codebase with you on Github.

Basic contains various exercises, algorithms and data structures, implemented in java. Some problems that are included are:

Since the purpose of writing this code was more internal than external, the level of documentation and finish is not perfect. Some tests are failing, and the code has some undiscovered bugs. Still, I think that it’s a worthy reference that can be improved in the future. Naturally, many/all of the above algorithms have better, more professional implementations (some of these are in the JDK itself). However, Basic has the advantage that it does not try to be a complete, production implementation, and thus might be simpler than some of the more complex/complete implementations.

I hope you will find it useful – although I encourage you to use the test harness only at first, and write your own implementations. You learn much more from writing code than from reading it. If you have any questions, or want me to add a specific piece of documentation, feel free to ask.

Why do I want to work at Google?

listed Google as one of the companies I was considering to work for. It was a bit difficult explaining my goals to people, as I wanted either “a cool, small startup” or Google, which are very different in nature.

I don’t really have to explain why I consider working at a cool, small startup … cool. Working for Delver for past three years was an amazing experience. I joined Delver to “change the world”, and knew that I personally will take a large part in the effort of a really small, focused and excellent group of people. The openness, desire to learn and improve, and passion were common to almost everyone on the team.

I still have this passion, and there’s a good chance that one day I will either work in a small startup again, or better yet create one from scratch. However, if there’s one thing that Delver taught me is humility. I know I’m a good software engineer, but I also know how much I don’t know, and that I can improve and learn in so many different areas. This is why I made learning my number one goal in my job search. Beyond “changing the world”, I wanted to find a place where I’ll maximize my improvement, my skillz, and my career path. I wanted to meet a lot of smart people, and get the “I’m the dumbest person in the room” feeling on a daily basis.

I think that Google can be this kind of place for me.

Don’t get me wrong – I know from personal experience that startups offer these kinds of opportunities as well. Some people would say the opportunities for learning are greater at startups that any any big company, Google included. Some say quite the opposite, that Google is so unique that it far outweighs almost any other gig.

What’s your opinion? Do you want to work for Google?

A survey of open APIs

I did some research in the past week on a few “Open APIs”, and wanted to share my findings here. This is just a summary of other, more comprehensive sources. Also, if you have any comments or corrections I’d love to hear them. I chose to present my findings as a list of concepts:

The Open Stack

This is an emerging stack of open protocols that will help build socially-connected websites. I will explore the key elements (I take XRDS-Simple to be rather low level and uninteresting).


  • A single sign-on protocol (help to user not to create yet another set of user/pass)
  • Essential Workflow (here in more details):
    1. You want to logon to StackOverflow, which is an OpenID Consumer
    2. Instead of opening yet another account you are given an alternative (almost no site relies solely on OpenID).
    3. You either enter a URL (way less user friendly) or select from a fixed subset of Providers
    4. You are redirected to that URL, enter your credentials there (only if you are not logged in), and are asked to allow StackOverflow access to your OpenID identity.
    5. Depending on your OpenID provider, you can set for how long this access is granted
    6. Then, you are redirected back to StackOverflow, with a token (encoded in the URL), that is used to grant you access.
  • OpenID is mostly still just a login method today (doesn’t convey extra information beyond a logon grant) – although I did see some evidence to the contrary when I just opened an OpenID account at VeriSign – it seems websites can request more information from an OpenID provider – such as email, nickname and full name.
  • Microsoft, Yahoo, Google are now OpenID providers (in addition to more veteran providers). This is significant because it doesn’t force users to go to yet another place to open an OpenID account – they can just use an existing webmail account.
  • Facebook just joined OpenID foundation board (eBay is there already). Looks like it will become an OpenID provider, maybe also client.
  • Users are still not comfortable with it / unable to figure it out.
  • However, here is an interesting post about using email addresses as OpenID. When this happens, it might help bring in the users.
  • Here is a recipe to enable OpenID on a website (Consumer). Sample Provider implementation for .NET is here.
  • Of course, for your WordPress blog the process is much easier – just install OpenID plugin.
    • Although, I heeded Tomer’s advice and instead used OpenID delegation – this means I use my blog’s URL as my OpenID, but it is just a redirect to a more serious OpenID provider. OpenID is/will be the keys to your world – better guard them safely.
  • Right now, the value of OpenID to a new website is still limited:
    1. Will not eliminate the need for us to implement user logon
    2. Not much value in being an OpenID Provider – it’s a nice to have feature, but in many cases not worth the cost (at least until you get a large user base).
    3. Is not sufficient, on its own, to get access to complete profile information about users (and use this data to help users interact with your website). But … can be complemented with more technologies.
  • Has a nice usage graph.

Google OpenSocial

  • A set of social APIs developed by Google (get list of friends, publish stories).
  • Implemneted y hi5, LinkedIn, MySpace, orkut, Yahoo!, Friendster (full list at the OpenSocial wiki)… but not Facebook (yet). All of these are OpenSocial Containers – data warehouses that answer OpenSocial queries.
  • OpenSocial is Open. The data is not stored on Google – the providers just conform to the OpenSocial API which reflects the data stored at each social network.
  • Had theoretical reach (not usage!) of 700M users Nov 08.
  • To serve OpenSocial:
  • Client implementations are available in javascript, java, .net, php, whatnot…

Google FriendConnect

  • An application that uses OpenSocial to enhance websites with social widgets (Comments, Reviews, …).
  • Is still not wildly spread (this directory is rather sparse at the moment)
  • Doesn’t seem to be targeted at big sites, rather at small sites/blogs (my impression at least).
  • No programming required to add social features to your site – but you have limited control over the effect.
  • Cool flow I tested: Login to FriendConnect on a website, and you already see in your friends list a buddy from Gmail that’s using FriendConnect at this site.


Portable Contacts

Facebook Connect

  • Competitor of the open stack (OpenID+OpenSocial) – gives single sign-on + connects you to Facebook friends & feed
  • Uses a popup instead of redirecting to FB (less intimidating for users).
  • Has already been witnessed to boost new user signup.
  • Main Flow:
    1. User clicks Connect 
    2. Popup (in asks user to confirm
    3. User is shown a Presence Indicator at the target site
    4. Website can pull user’s profile & connections.
    5. Publish stories to Facebook.
    6. Send Facebook hashes of emails, and Facebook replies if they have a user with an identical hash. This can be used to show a user a count of his Facebook buddies that are using the target site (“10 of your friends are using this site, connect to Facebook now”).
  • Example of a FB connect-enabled site – TheRunAround.

RPX / JanRain

  • JanRain – An early OpenID player (in the market since 2005, one of the founders of OpenID).
  • RPXNow – abstracts away Single Sign-on, supports both Facebook Connect and major OpenID players.
  • Here is a blog post about why not to use it (Vendoer lock-in, single point of failure, too little benefit).
    • However, check out the counter arguments in the comments.
  • RPX get social profile data from Google, MySpace, Facebook.
    • This includes interesting profile fields like email/gender/birthday/photo.
  • The API also hints at getting an array of friends from relevant services.

That’s it for now, I hope you enjoyed this review. Remember that most of these APIs are very new or just being adopted, so expect changes to most of these. I expect a large API convergence to happen in the following year or two, which will simplify life for those of us building social applications.