Leaving Google for Typesafe

So, as some of you may have found out already, I'll be leaving Google effective July 22nd and moving to a new role at Typesafe. Some of you may be wondering why, so I'm offering my reasons in a blog post for the curious:

So, while I see Scala's future as bright and rosy and I can't explain how excited I am to start at typesafe, I'd also like to do a little reflection on Google and some of what makes it a great company.

Google cares about employees

This is not a lie. Google, as best as it can, tries to mean what it says. At my previous companies you'd hear "I'd love to do this, but my hands are tied". At Google, you often hear "I don't know, but let's ask someone who does" which usually turns into "Yes, go ahead". It was rare that something I asked for was denied. My perception of what was acceptible is an entirely different thing. At Google, there are people who think what you think (at over 10k engineers, it's guaranteed one will probably agree with you about something), and that engineer might have also tried to accomplish the same task as you. Go ask about it and find like-minded individuals. You'll be surprised how much

Google tries to do what they say.

The other side to this coin is that the corporate entity and by that I mean the higher ups like to do things for all Google employees. Like bonuses. They really do happen, and they really do try to treat you like a human being.

The other side to this coin is the interview process. I've seen so many negative posting about the interview process. Well, I'm here to dispell a few of those. Google's interviews will challenge your technical abilities. If this annoys you and you don't take the job, then good. You're probably not the type to herd cats deal with politics/relationships involves with a large developer base. If you can't cut the interview, then it gives you a reason to go back and practice. However, more importantly, Google would rather turn away a good candidate than hire a bad one. This mindset is very impressive. It really makes a huge difference on the ability of teams to accomplish things. I knew every employee I worked with at google was reliable to get work done, not something that's always the case externally.

In the future I know my interview style will change. No more will interviewees be allowed to just talk about experiences without showing some code. It's amazing some of the depths you can learn here. It's even great when an interviewee fails to answer the question correctly because you learn their thought process. I know for me, a few candidates who struggled were the ones I wanted sitting beside me coding, more so than the ones who blazed through a question but had a more 'better than thou' aura. So, the point here is care about your employees and care about who you hire. Your company will be in far better shape if you do this.

Culture is faster than process

Google tries to instill a culture of 'doing the right thing' its employees, rather than outlining software process to a T. There are a few 'inconveniences' that exist, but other than mandatory code reviews, a lot of the process is up to the team to do what's best. The other side to this coin is the corporate culture tries to help define and change what's best. It's amazing how one executive making a statement in an all hands meeting can suddenly alter the perceived "best way to code" and get the company to move. It's also surprisingly hard to change culture once it has been really embedded into the engineers, which is the danger. A sense of 'right' in the ways of writing software can be beneficial, but can also turn into anti-patterns if not tempered. I'd love to go into more details here, just feel free to bug me.


blog comments powered by Disqus