Why Google Engineers Got It Wrong

A couple days ago the new information had been revealed by Snowden and we learned that NSA was able to intercept un-encrypted traffic between Google, Yahoo, … data centers. Several Google engineers responded with “F..k NSA” comments. Guys, you’ve got it wrong!

First, let’s settle one important thing: I believe that NSA (or any other government agency) should be controlled, monitored and audited by us (the public) through our elected representatives. The recent disclosures by Snowden and others show that Congress failed to do their job either by approving NSA’s wide spread data collection programs or by demonstrating the in-ability to control NSA. We simply should vote them out in the next election.

The important thing to understand about this story is that the NSA “hack” became possible because of bad assumptions made by Google engineering and security teams about the safety of the link between Google’s data centers. It’s actually quite common for software engineers and computer security guys to downplay the risks associated with physical security. However, the bad guys will try every option including physical break in or coming into a Pilates class with a malware on a flash drive. Your security is only as strong as your weakest link and attackers will not be breaking a locked door if there is an open window on the side.

However, even bigger security issue with the Google’s decision to do not encrypt internal traffic is the total ignorance for the other attack vectors. If NSA was able to get to the traffic, then would Google employees be able to read this un-encrypted traffic as well? I bet it was possible. Given the Google’s size and the sensitivity of the information we share with Google (email, chat, …), it is hard to explain the ignorance shown by Google’s security guys. This is not a question of technology and the Google’s move to encrypt the traffic now shows that it is possible to do. It was a security failure at Google and NSA is only half-guilty here.

Now we can go back to the “F..k NSA” comments from Google engineers. Guys, you’ve got it wrong! Don’t blame the messenger. You’ve failed and you should admit that there is a problem that needs to be fixed. It could have been NSA who got your internal traffic, or a rogue employee, or just a criminal. Just shut up: you’ve failed and the best you can do is to learn from it.

Google itself is actually doing the right thing by implementing appropriate security measures to protect users’ data. The other great thing Google can do is to release to the public the security incident report that I am sure they prepared internally. This would allow everyone to better understand what went wrong and learn from it.

This post started as a discussion on HN.

How To Fail My Interview

It is very easy to fail my technical interview. Yet, if you need some tips on how to do it fast and easy, please read on.

1) “I was responsible for …”

This is the phrase I often see in technical resumes. And it has a big meaning for me because I value ownership and responsibility in the team. However, if you put this phrase in your resume, then please be prepared to answer not only “what?” questions about the project but also “why?”. And please don’t answer that “I don’t know why we did it this way, I was not making this decision, the architect/team lead/some other random guy did”. It is perfectly normal to have someone else make some decisions on your project. Either because the decision was made before your time, or because the level or scope of the decision is above or below your pay grade, or because the way things are setup inside your company. However, I strongly believe that a true owner of a project/product/system/subsystem should very clearly understand and agree with every decision made in his/her area of responsibility. If you don’t understand why things are done the way they are done and just follow the directions, then you are not probably qualified to make other decisions in this area at all. And you are definitely not responsible for your project. The other guy who makes and understands the decisions is. Worse, it also shows me that the candidate doesn’t know his/her limits or doesn’t understand the limits at all. Thanks, I’ll pass.

2) “I rate my experience in X 10 out of 10”

During the interview, I try to ask questions that match the candidates overall experience as well as his/her experience in a particular technology. I want to ask you a question that will challenge you. Thus, a candidate with 10/10 knowledge of PHP will get a question I would ask Rasmus and a candidate with 10/10 rating for MySQL will get a question I saved for Monty. The bar will be set high and a very few candidates are able to meet it. The more important part is that I actually do not expect every web developer I hire to be 10/10 in PHP, MySQL, and every other technology we use. There are always things to learn. And there is always Google to find details and more information when needed. The 10/10 candidate who failed the question is just a sign of an “inflated” the resume. Thanks, I’ll pass.

3) “I have experience with A, B, C, D, E, F, …, X, Y, Z. And many other related things.”

For any technology I define a “minimum equipment list” that anyone with even a basic exposure to this technology should know and understand. This is indeed a “minimum” list: for Java you need to know about garbage collection; for SQL databases – about joins and transactions; – you got the idea. If you have a technology listed on your resume, then I feel it is a fair game to ask questions about these basic things. And if a candidate has no clue what I am asking about then the only logical conclusion for me is that the resume have been “inflated”. Thanks, I’ll pass.

4) “I know you use technology X but I think you should actually use technology Y”

As an engineer you should understand that there is no silver bullet technology that works everywhere and all the times. Each technology choice is a tradeoff. One solution gives you one set of pluses and minuses. And another solution gives you another set. To make a decision, you have to compare the pluses and minuses of each solution against your priorities and objectives. And then find the one that works best for you. It is great to be passionate about technology, but I don’t believe that after minutes or even hours of the interview, a candidate knows and understands the tradeoffs behind the technology choices made by myself, my team and my company over the years. Thus, a candidate just shows his or her lack of ability to make rational technology decisions based on facts. Thanks, I’ll pass.

BTW, I am hiring 🙂


Patents vs. copyright vs. ???

We all heard many times that software patents are bad. The last week’s ruling on Apple vs. Samsung case was quickly show-cased as yet another example of complete lack of any reasons behind software patents. Yet many (including myself) agree that Samsung indeed copied Apple’s design. What options does Apple have to stop it beyond software patents?

The first and only option that comes to mind is the copyright law. As any art work, Apple’s designs are protected by the copyright law. And it seems natural that Apple should go after Samsung using the copyright law. However, the copyright law includes two key provisions that make it impossible: idea/expression differentiation and fair-use doctrine. Thus, Samsung doesn’t violate the copyright law unless it copies Apple’s icons pixel by pixel, or builds its phone with the exact iPhone dimensions and buttons.

The patents and the copyright law in the current form are outdated and don’t match the reality of the fast moving and fast copying 21st century. However, if as a society we want to reward inventors and original artists, then we need to find a way to fix patent and copyright laws. The other proposed options (e.g. government grants/prizes) are even worse solutions to the problem. And it is not too hard to fix them. First, we should drastically reduce the protection period to 1 year or may be even less. The long protection period provided by both the patents and the copyright law actually shifts the risk/reward tradeoff in the wrong direction and makes it easier for companies or pirates to decide to infringe on patents or copy the digital content. Nobody in 21st century is going to wait years until patent expires or the art work goes into public domain. Second, we should build into the patent law an automatic way to license the patent and pay reasonable licensing fees w/o the need to negotiate with the patent holder. Third, we should include “fair use”-type clause into the patent law to ensure that university and other research organizations can freely use patents. And the last but not the least, we should drastically speed up the approval of patents. Patents should be granted automatically and review on patents should be performed only if someone wants to challenge them. The patents database will be the place to go to find out how to solve a problem to avoid duplication of efforts, not a sacred place you (as engineer) should never look at because of the fear to be sued for knowingly infringing on a patent.