Thursday, November 29, 2007

Your business model called; its leaving (and its not coming back)

Let's say you found yourself a cash cow. Something that made you tons of money; day after day. And let's say that you get better and better at making your cash cow efficient. Pretty soon, you're rolling in dough. At some point you can nearly rest on your laurels while your money machine keeps churning. Eventually, you probably don't need anymore money, but that doesn't stop most people it seems. You just keep on wanting more (and why not, if the cash cow keeps delivering).

Its probably pretty safe to say that at this point in time, the advent of some technology enabled your cash cow. Maybe it was recorded media or a new video format or some computers in need of an operating system. Whatever it was, its likely that some recent technology gave you the building blocks to create your new cash cow business.

And, as you realized that technology enabled your cash cow, you also know that it's just a matter of time before it's going to disable it too. Usually by the advent of yet newer technology obsoleting yours. What do you do then? The best option is to see if you can morph your cash cow to be in synergy with the new technology. Kodak is a good example, they moved from pure film to a strong embrace of digital photography. AT&T is another - land phones are dying - they made sure they were in the mobile business.

Other models however aren't so easy to move with. Music CDs are sort of silly now and the new technology doesn't leave a lot of room for a new business model. What do you do then? You might think that you're the kind of person that if you spent a few years making millions (or billions) producing music CDs that you might eventually have enough of it all. If you truly can't save it then - you can take your millions, smile back upon the fun ride of building something great, and move on to something new.

You might be. But it doesn't seem like this is the way it works. Instead (statistically speaking) if you had an un-save-able dying cash cow, you'd defend it anyway. You'd start to use the millions your cash cow makes to try to change laws, start lawsuits, or stifle technology to artificially keep your cash cow alive. Quite literally, you'd use its own resources to hinder future technology that will hurt it (regardless if thats good, bad, or indifferent for humanity).

Technology enables business, art, and science. And it kills them too, usually by advancing to a point that makes the existing ideas obsolete. A few people miss LP records these days, and surely some still play and collect them. But that number will continue to diminish. I'm sure plenty of folks stuck with a horse-and-buggy because they thought automobiles were a stupid idea. Those people are mostly dead now, just like LP records will be some day.

Now, it might seem like I'm picking on the record industry. I'm not really, they're just a poignant example. Whatever you think, the people in that industry are not idiots. They *know* their business model is dead. Dead, dead, deaddity, dead, dead, dead. Music is really a service, the idea of putting in on a CD was always an artificial means of trying to turn a service into a product.

Instead of teenagers idolizing manufactured rock stars, the internet gives every indie band in the world an open forum. It wasn't that long ago that rock bands begged and prayed to get signed with a big label. Now they can start their own label and reach thousands of listeners, all for the cost of a website. Add a marketing and sales manager and you have a music-making company.

You don't need to be a futurist to predict some corporate business models that will be dead (remnants always remain for awhile) in the near future. Shrink-wrapped software, music CDs, desktop computers, and purely-gasoline automobiles to name a few.

What about if we go just a little longer term - say 30 to 50 years. Now I'd venture to say things keyboards, mice, paper books, bullets, telephones, and batteries.

You might disagree, but I think you're not thinking far enough ahead. I don't think people disagree because they think this idea is wrong. I think just like (or depend) on some of those things and don't want them to go away. If you sell batteries, you'll probably vigilantly tell me that we'll ALWAYS need batteries. In fact, although "30 to 50 years" might not be accurate, my predictions above are pretty guaranteed in some time frame.

A friend of mine disagreed with me when I said libraries were destined to disappear. He argued they won't because people will always like to read from books. "Will always" is a very long time. Most people like books because they're used to them, kids today are pretty used to reading off screens a fair bit of the time. Tomorrow's kids will be even moreso. And would you really be willing to bet we won't invent something better (in all ways) than a paper book in a 100 years? 200? Heck, I'd bet reading itself will be gone by then.

Coming back to the nearer future, the title of this article talks about dying business models. Finding ones in the global corporate marketplace is easy. What I'm more thinking about is *your* business model.

Whether you're a assembly-line worker in a Ford plant in Michigan, a C++ programmer (sorry, I mean "software engineer") in silicon valley, or a McDonald's fry cook. Its pretty damn likely that technology is going to kill your job or career (i.e., your "business model") in your lifetime.

I've read around the net that its a "bad time to be a photographer". Simply put, thousand dollar digital SLR cameras and photoshop have destroyed the historical profession of a photographer. Surely, a skilled photographer can take better photos on average than an amateur. But the rules are now changed. With multi-gigabyte memory cards, I can snap photos all damn day long. And the camera has gotten far better at helping me take great photos. And Photoshop can come in the backside and fix any minor problems I might have. Maybe its a bad time to *be* a photographer - but its a great time to *become* a photographer - anyone can be one in just a few hours! (Of course, thats exactly why existing photographers might think its a bad time to already be one).

Seriously, if I snap a quick thousand photos, its getting more and more likely that I'll snap a really good shot. Then I can sell it on the internet in many instant-gratifying ways for a fraction of historical stock photography. The profession as we knew it is likely soon gone.

I've seen this even in computer programming. Coding used to be much harder than it is today. It takes much less devotion and study to make programs these days and its getting easier all the time. You might argue that good programmers write the best code, but you rarely need the best code to get a website up and running. And programming is perpetually going to get easier. (It used to take HTML expertise to make a website, now it just takes a MySpace account).

Scary enough I can boot up Adobe Illustrator (or more precisely, Gimp in my case since I use linux) and I can do things that a professional graphic designer of 20 years ago could only dream of. This is really a frightening thought - I have a really exceptional lack of artistic ability, but Gimp gives me a baseline. I might not be able to reproduce Van Gogh, but I can make all the graphics I need for websites or Christmas cards or whatever.

In a grand view, this is probably a great thing for our world. More people can do more things faster. It all sounds great unless you're personally be obsoleted in the process. Complaining photographers have somewhat of a point. They spent years perfecting their craft. They learned tricks of lighting and developing and who knows what else just to have it taken away by some fancy new camera. Technology obsoleted their craft overnite (like the song says, "Video killed the radio star").

If you're not a photographer and you're sort of not feeling sorry for them, thats ok as long as you're careful to shine that mirror on yourself too. Like I said, if you spent years learning the intricacies of C++, tax law, medicine, or anything else - you surely have job security likely for awhile. But definitely not forever.

Whatever your business model - it is indeed, at some given rate, dying. And its always possible that a technology will come to be tomorrow that will destroy it instantly. And every year we shall see more fights ensue with people looking to save their business model.

Create a cure for cancer? Watch the chemotherapy companies go into action. Build an electric car thats cleaner, faster, and more economical than any gasoline one? Watch the oil and car companies head to Washington. Invent teleportation? Airline industry sponsored laws will quickly be up for debate.

If you're complaining that your business model is dying, you might as well complain that the sun is going to come up tomorrow. Its going to happen and you have two options - keep moving or retire. Be ready to throw out what you learned if you see it becoming obsolete.

If you're lucky you'll be on the forefront of that technology and you can start a company giving you your own technology-induced cash cow. Once that happens, you can sit back counting money. Until the next wave comes and your once new cash cow starts to crumble. Then, of course, you can adapt again or you can become the technology stifler yourself. Somehow I have a feeling that thats one job that will never go out of style.

Tuesday, July 17, 2007

Don't Chase your Dream Too Fast

I thought of a funny quote today (which is oh-so-true):

Don't chase your dream too fast - chase someone else's first, and after you screw that up and learn a little; then go after yours.

(this applies to dream jobs, dream dates, pretty much "dream anything")

Sunday, July 08, 2007

This blog made the Top 50 Google Blog list

SEO-Space has ranked my blog #47 on the Top 50 Google Blogs list. That's pretty cool given how many blogs by googlers are out there.

They mentioned my earlier article on Why I work at Google.

Thanks SEO-Space!

(Of course, I work for, but do not speak for Google. All words are my own.)

Monday, June 25, 2007

Using Tricky Assertions

I'm not sure why, but I never got much in the habit of using the java assert keyword. Its a nice idea, but I somehow just checked what I wanted the old fashioned way.

And, although I'm a big fan of IDEs and I love debuggers, I still find having some print statements here and there sometimes is really helpful.

Of course, print statements suck when you're done and you no longer want them. That is, you need to go delete (or comment them out) all over the place.

I've sort of combined these ideas into a pretty obvious trick (which I seem to get asked about a fair bit, hence this post). Its basically a comment-out-less, performance-free debugging (or stats, or logging, or whatever) facility.


assert(Debug.out("test code val="+val));

The only trick is that the method (like "Debug.out") must always return true. Now run the app with assertions turned on "java -ea Main" and you get the messages. For production, simply don't run with -ea and the VM will ignore those statements (I hope) altogether.

This basically gives you an application-wide, command-line way to turn on or off (with no performance hit if the VM is smart) some code. If you think about, there's many possible uses for such a thing.

Edit: Code for Debug.out would look something like:

class Debug {
 public static boolean out(String x) {
  return true;

Sunday, June 24, 2007

Been Reading Crappy (Half)Books

I don't read a lot of books. At least under the definition of, you open it, flip pages over several days or weeks, get to the last one, read the last sentence, say "huh", and put it down. I mean, I don't finish a lot of books, at least nowhere near the number I start.

I *do* read a lot of half books - that is I only get half-way through. I have a feeling I'm rather hard on books - I expect a lot.

The problem I see is that there is simply an absolute deluge of books that should be articles. Simply said, books are about ideas. However (fixing the english of that last sentence), every book should be about multiple ideas.

So so so so many (half)books I read are only about one idea. They have a wispy chapter 1 introduction, chapter 2 introduces the idea (which sometimes is so simple it takes a paragraph), and then the rest of the book cites contrived/researched/induced examples about how that idea is so great.

That's fine and all. Some of those ideas are pretty luminary (i.e. Freakonomics comes to mind) but one single idea has to be pretty damn big to make a book. (Meta-note: the idea that books should be about multiple ideas and not just one idea is probably not a big enough idea to be a book, just an article, or maybe even a stinky little blog post).

I read a lot of technical books (not halves usually) and technical books are pretty hard to be stuck on one idea. Brian Goetz' Java Concurrency in Practice is a great example. If you're a Java techie, this is an incredible page turner. (Another amazingly great techie book is Warren's Hacker's Delight .)

I also read a lot of (half)books about business. I just read a (half)book called Selling Blue Elephants. The basic idea was to do market research using actual customer testing. Cool. Good idea. They even gave a spiffy acronym to try to add it to the world's business vocabulary (much like "tipping point" and "long tail" have done in the past few years).

But that was about it. The rest was case studies on how customer testing helped a bunch of products. Yip.

I also have been listening to Good to Great lately, a pretty heavily lauded book. I don't usually do books on CD but it was a gift. There was a lot of solid empirical research in it which was helpful but it seemed (much like Built to Last) to be fraught by survivorship bias. And I don't discount the strong research, but the results were somewhat expected (that's no ones fault, its just that everyone loves a plot twist).

The entire section devoted to how people in "great" companies tend to be stay friends is what really ended up ejecting the CD however. It almost seemd to imply was almost that if you were only in a "good" company, you'll never make any friends.

My expectations are probably too high. Business vs. technology is largely analogous to art vs. science - and its damn hard to write about art (as compared to science). Its just too subjective.

Becoming a great businessperson is analogous to becoming a great techie. It simply takes some level of innate talent that can't be replaced by hard work (and after you have that, then you still need a lot of hard work). After that however, the tech stuff is arguably easier to document.

Now I definitely might be too hard on books but how I figure it, I only get so many days on this planet (and this planet is the only one I know with books). I really can't afford to waste time on any book I find anything less than insanely great (Influence by Cialdini).
Ah well, onto the next - maybe I'll read some Call of Cthulhu. Or even better, "How to run a business like Cthulu would" - I bet there'd be more than one idea in there.

Sunday, April 08, 2007

A Few Book Reviews

The very last book I completed was the California Driver's handbook. Man, what a snorer. I have to get my CA driver's license this week, so I figured I better know what the speed limit is in a 2-lane alley with a bike-lane on thursdays is. In any case, avoid this book like the plague - its only to be read as an aching reminder that driving is a privilege and the DMV is a perfect example of a system without competition (i.e., its inefficient, broken, and is barely preferable to getting hot pokers stuck in your eyes).

Apart from that, tonite I also finished Perfectly Legal: The Covert Campaign to Rig Our Tax System to Benefit the Super Rich--and CheatEverybody Else which does not disappoint.

On one hand its a basic consideration of what we all know. Want to avoid taxes? Get rich. It does however examine in detail some pretty amazing tax loopholes (and downright scams). From a surprising number of people that simply don't pay because they don't think they should (and the IRS having scant resources to catch them) to companies like Stanley Works and Ingersoll-Rand that try (or succeed) in moving their theoretical corporate headquarters to Bermuda to avoid US taxes.

In the end it's a pretty grotesque look at our tax system. If you're easily made mad, then by the end of this, you'll definitely be mad (if you're not in the top 1% of our country's wage earners, you'll be mad because of how much you pay and they don't. If you are in the top 1%, you'll be mad because you're bound to find some tax loopholes you're not taking advantage of).

In any case, I found myself looking forward to getting back to reading this book every time I had
to put it down.

A few weeks back I got done with a long read of
The Birth of Plenty : How the Prosperity of the Modern World was Created. Its an interesting book in that it basically qualifies as "economic history". A methodical study of why somewhere a hundred or 2 years ago, human civilization went from basic subsistence to spurt of radical productivity. The examination is done on a country-by-country basis and is a pretty great read.

Interestingly, the same author wrote The Four Pillars of Investing : Lessons for Building a Winning Portfolio (which I haven't read.. yet). He seems like he'd be an interesting guy to meet.

Its quite long but wonderfully researched. If economics or history interests you, its worth the time.

At the end of last year I got through about half of A Theory of Everything: An Integral Vision for Business, Politics, Science and Spirituality. It was recommended to me by a member of the board of my Ohio company Preemptive Solutions. Simply said, he's the kind of guy that if he recommends a book, you might just want to check it out.

Anyway, this is not a leisurely saturday afternoon read. Its dense and it makes you think with every section. I plan on getting back to it soon, but Chapter 2 alone was worth the price of admission (after I reread it a time or two).

It lays out a theory for levels of thinking. From the most basic levels concerned with food, water, sex, etc. to the highest levels that only (an estimated) 1-2% of our population functions at. Its really a fascinating way to consider simply how we think.

Oh.. and finally.. I read about half of Now, Discover Your Strengths before I fell into a reading induced coma.

This book purports to be an analysis of how to analyze people and play to their strengths. The one worthwhile message was that we tend to look to improve people's weaknesses (for example, if you are a manager, you might do this to an employee). However, this is misguided - you're better off to play to their strengths. If they're a great coder, let them be that. Encourage it - help it. Don't force them into management (for example).

Thats a fine idea but I found most of the rest of the book arbitrarily contrived. I really hate it when I see a bulleted list presented as fact thats clearly just someone's opinion. Such lists can be added to or deleted from and be just as correct.

In any case, I'm pretty done with that book. If you're interested, you can have my copy.

Tuesday, March 27, 2007

Notes from my Java Generics talk at SDwest

Sorry - meant to put these up earlier.

They are Here.

Thursday, March 22, 2007

Howto Pass a Silicon Valley Software Engineering Interview

I do a fair bit of interviewing. This probably averages about 2 to 3 interviews per week - mostly for Java developers. I'm also giving a birds-of-a-feather at the Software Developer's conference tonite in the Santa Clara Hyatt bar on just this topic (7:30pm if you're interested).

Now mind you, being an experienced interviewER does not necessarily give you relevant information on being an experienced interviewEE. However, the latter is hard to gain a lot of experience at. Because of course, if you're good at it, you tend to not do it for very long (i.e., you get hired).

Before Google, I interviewed at several startups in the valley. And combining that experience plus what I know about how I interview at Google and how I interviewed at Preemptive I do have a few guidelines.

1) Don't interview at your dream job first.

If you haven't interviewed in awhile, your first interview is likely not going to be great. It's not because you're not a crackshot developer or a math whiz. It's just because you aren't familiar with the whole process. From getting used to jumping from topic to topic all the way to saying why you want the job. Its always a good idea to interview at your 3rd or 4th choice first.

2) Be positive - no swearing.

You will get asked about your last job. Saying your manager sucked and the dev team was a mess wins you nothing. I've seen candidates attempt to put down some technical faction or previous employers seeking my solidarity with them. Nuh uh. Doesn't happen.

Why are you leaving your current job? Simple - because this new job is a better opportunity. Your last job was a fine career builder but this one's business model or development principles or philosophy or job description or reputation suits you way better. Not to mention your skillset can bring significantly more value in this new position.

Don't tell your new employee what's wrong with their products - mention you hope you can (non-specifically) improve such products. Even if asked what you'd improve, phrase it such that it is indeed an improvement and not a fix for something you think is terrible.

Also - forget technical religion. If you love Agile say so - but don't pretend its the only solution. Millions of people get work done on windows, linux, agile, waterfall, C++, java, .NET everyday. All are solutions - sure, some are better than others and defensible positions are great - but unfounded zealousness is not.

And, I am amazed I need to write this - don't swear. Its a respect issue. You don't know your interviewer. Some people don't mind swearing - some do. There's really no need.

3) Check your attitude at the door.

As I've said in previous articles, if you are the smartest person at where you work - QUIT. Similarly, its a silly idea to join a company where you will be the smartest person the day you start. Therefore, if you ARE smart, you will be looking to join a company where you AREN'T the smartest person. Therefore - you should leave your arrogance about how great you are outside.

I ask most every candidate to rate their Java and C++ skills on a scale of 1-10. Then I write that down for the next interviewer. At Google, you never know who your interviewers are going to be. If you say you're a Java or C++ expert that rates a 10 - you darn well better be - because you never know - your next interviewer could be Josh Bloch, Matt Austern,
Guido van Rossum,
or Ken Thompson. Or worse, someone else you've never heard of that's a super crackshot - and there are plenty of those.

Again, I'm amazed at people that give their interviewer attitude. It's such an obviously stupid act that I have to question the person's intelligence in addition to being annoyed by their arrogance.

4) Be passionate about development.

I have a dirty secret - if Google stopped paying me tomorrow, I'd still come to work (unless they like took my badge too and got Hector the security guard to watch out for me - that dude could smoke me). God forbid that while sleeping I have a dream that solves a coding problem I've had the day before. When this has happened in the past, I found myself sitting awake in bed with my mind racing. I was too excited to sleep and figured I might as well drive into work and start implementing the solution (despite the fact that it happened to be 4am).

The number one thing I look at on resumes (and I don't look at resumes all that much) is extra-cirricular coding activities. I want to hire engineers that I want work with. And those engineers are passionate about cool algorithms, slick code, and new ideas. They do that stuff in their spare time - its not just a job, its what they do because they love it.

5) APIs really don't impress.

People seem so proud they know a lot of APIs. As far as I know, APIs were designed to be easy to learn. I'd really rather hire a smart person that I know can learn most any API than one that brags about the few they already know.

I'm not saying knowing APIs is bad - it's not. It's just not the most interesting thing on your resume.

6) Know algorithms and data structures.

One theme in Silicon Valley is massive amounts of data. And its not always of the classic relational database type of data. Its massively huge datasets that require plenty of processing (imagine the graphs made for page rank).

One of my favorite/fun interview questions (actually, probably one of my ex-favorites given that posting it here means its too well-known) is simply how to sort some objects. The absolute beauty of this question is that very many software engineer interviewees have given me a suboptimal answer for this - whereas my mom (who, despite making crazy good pirogis, has zero computer training) got it right.

Here it is, as I ask it of engineers, and as I asked it of my mom:

Engineer's version: Say you had a million objects in memory (assume we have no memory constraints) all of type UniversityStudent. These objects have two fields:

String name;
int numberOfYearsOld;

What is the fastest way to sort these objects by "numberOfYearsOld"?

... So.. whats the answer? quicksort? mergesort? whats the running time?
The most common answer I get is something like quicksort with an average running time of O(nlogn). For a million objects, that's something like 20million operations (comparisons) to do the sort.

Mom's version: Say you came into a very large room with a million papers in a stack. On each paper is written the name and number-of-years-old of a given student. Whats the fastest way to sort these papers by hand by number-of-years-old?

Mom made stacks. A stack of 18yr olds. A stack of 19yr olds, etc. She needed a possible of about 100 stacks maybe (ages 10-110). How many times do you need to look at each paper? Once. Right. That's 1 million operations or O(n). Go mom.

Of course, Mom got it right because she had no preconceived notions about the problem or sorting in general. A candidate that memorized sorting algorithms before coming to the interview probably robotically responded with O(nlogn) without really thinking about the problem.

If you've written plenty of code, you should be familiar with when to use what data structures and to know their runtime characteristics. You should know that a hashtable's worst case search time is linear - and you should have an idea how to avoid it. And why you might use a binary tree instead of a hashtable even though it's an O(logn) lookup. And that O(1) is effectively the same as O(100). Surely the subtleties are situation dependent - but that's why you understand it - to apply it in the right situation.

This is all datastruct and algorithms 101. I perpetually hear developers tell me that they learned that stuff in school but now forgot it. Personally, I wonder what the hell they have been coding? If you've just been gluing APIs together then thats nice, but its not very interesting. Even if you don't interact with them directly, knowing data structures and algorithms is key to understanding performance. This is not premature optimization - this is choosing the right tool for the job. And that choice is often wonderfully subtle.

And if you decide to do 20million operations when you could very easily instead do 1million, eventually we're going to have some problems.

7) Be an engineer that your interviewer would want to work with.

I don't know exactly what that means because it will vary with every interview and interviewer. Obviously be genuine but be passionate.

8) Know the language you say you do.

I try to phrase all language questions as things that I think any developer that has worked in a language for a year couldn't possibly not know. Tell me about wait, notify, and notifyAll (3 methods every Java class ever created has).

I'm not worried if you don't know Java generics, but if you say you do, I'll ask for some code.

Good interviewing coding questions in my opinion should be meaty, do something, and take no more than a whiteboard.


There really is a spectrum of good to poor engineers. And the one theme that runs through it all is passion. Not for a given language or system - but for problem solving. And building things. Certainly a good degree doesn't hurt but I promise you its not the whole story. I have flunked MIT Ph.Ds. and recommended-for-hire people with very modest formal educations.

As I've said before - the interview is very very honest. Its about you, the whiteboard, and what you can do.

Bottom line is I want smart, passionate, crackshot developers. They're out there and I want them here - partially because they'll help to make my company better. But also because they're very likely going to be smarter than me - and working with them is going to make me better.

Notes from my BOF can be found HERE


Tuesday, January 30, 2007

Why I work at Google

I seem to get asked this a lot. But only by people that have known me for awhile. Noting that, I have a warning/disclaimer: If you don't know me or you only have known me since working at Google, this is probably not what you are expecting and might be excruciatingly boring or irrelevant. (you've been warned!).

The reason I get asked this is that I left a perfectly good start up called Preemptive Solutions to come here. When I say "perfectly good" its one that I am a co-founder, is now 10 years old, and was President (which I later became VP as I decided I wanted to live away from the HQ). In addition, the company has been by all measurements, a great success since inception - profitable every year, great product lines (and more coming down the pike!), and has over 20 employees (and aggressively hiring!).

The other original founder Gabriel and I have been friends since the 5th grade. I'm happy to say the company gave our friendship a foundation in lives that otherwise were diverging. I'm still a part-owner of the company and we talk almost daily.

In early 2005, I basically became ready to leave Preemptive. Not for any nefarious reason. I had been working remotely for a few years and I was ready for a change. No matter how you slice it, being remote leaves you out of the action - and I missed the action. Myself and 2 other guys (Bill joined us 6 months after we incorporated) built the company from scratch and it was a blast - but not being there, I was unavoidably an afterthought.

This was nobody's fault except my own. I really had 2 options - move back to Cleveland (where HQ is) or look to advance my life in another direction.

As luck would have it - life brought me to Silicon Valley. I had lived here before, but here I was again. And this time - I was looking for a job. At the time (April 2005) I was hearing plenty of buzz about Google, but honestly, after doing some comprehensive research on slashdot (*snicker*) it seemed like the luster might be have been off. I read (again, from the reliable people in-the-know that post comments on slashdot) that the hard problems had been solved. The big money had already been made. The cool people had come and gone. It seemed like the "party was over".

Just before my move, I attended the Software Development conference in the valley where I chair the Java track. Its a fun conference and the timing was perfect to give me a chance to look for a place to live. The thing about that conference is that it does a great job of attracting big names in the industry to speak. Consequently, the speaker party is always a ton of fun.

During that party I had a conversation with two very well known Java authors (who were appropriately snooty) where we got into a discussion about Google. It turns out that both of these "industry pundits" interviewed and were rejected (obviously, I'm carefully leaving their names out). I had heard about Google's "legendary" interviews - but I figured with a few books on your resume, how could you not get in?

Now mind you, after writing a computer book of my own and meeting many computer book authors, books don't impress me much. Writing a computer book is like getting a Ph.D. - its 10% talent, 10% luck, and 80% persistence (Ph.Ds "usually" take longer, but not always). And that's that. I'm not saying its easy, but a book definitely doesn't make computer book authors necessarily luminary or anything. This is probably especially true for books that don't invent anything (i.e., just cover an existing language or API).

Anyway, both of these snooty guys then proceeded to snoot on me how I probably shouldn't even bother as I don't have a chance (Again, I only wrote one book). Well, as you can imagine, it was now a moral imperative that I at least give it a try. If I didn't get in, I wouldn't be stupid enough to brag about it at parties. If I did get in, I could snoot back next time we met.

I'll admit that stories of Google's interviewing process scared me a bit. There was also a nagging question as to whether I'd apply as a manager or engineer. For the past 8 years I had been in management running my own start up. I hired, I fired, I made marketing plans, I built products, I built teams, I schmoozed clients, I did strategy. Granted, after 5pm I often found myself still coding - but that wasn't at all my main job.

I needed to decide whether to apply at Google as a (probably technical) manager or as an engineer. I preferred a managerial role but two things worried me. 1) I had no formal business education (which turned out to be way less important than I thought, read below). And, 2), business interviews (anywhere) are what we call non-deterministic. Basically, you can give great answers, but if the interviewer doesn't like you, you can get a bad review. With engineering, the questions have a "right" and a "wrong" answer - or reasonable facsimiles thereof. The interviewer can dislike you, but they can't say you're wrong if you're right.

Personally, I think I'm a better manager than I am an engineer. But I had no metric to know what they'd think.

Now keep in mind, those two assumptions above are BEFORE I ever set foot on Google's campus. I had no idea what to expect, I was just making calculated risks. But based on these unknowns, I chose to apply as an engineer.

I interviewed at several companies in the valley ( gave me an offer on the spot. It was surprisingly low and the CTO informed me it was a mandatory 54hour work week - wtf?). I also started interviewing at Google. At that point, I was still pretty skeptical about the idea of working there. I expected a lot of "attitude". I was pretty surprised when I got none.

The engineers I met in my interviews were passionate about development. That was it. They wanted to know if I was passionate about it too. They were excited about Google. They were excited about making cool stuff. There was no attitude, no snoot - just dev talk.

It also became immediately clear to me why the snooty authors didn't get whisked in based on their resumes alone. It was, in my estimation, the most honest interview I had ever been given. It was me, the interviewer, and the whiteboard.

The logic is pretty clear. Your resume tells what you did, which is great. And they did look at it. But they were far more interested in what I could do.
Right now.
On the whiteboard.

Understanding that no system is perfect and assuming they were allotting for interviewing nervousness, like I said, I felt this was pretty darn fair. The interviews were challenging, but also damn fun. When one was over, I found myself looking forward to the next.

The interview process took a long time. The longer it went on, the more I liked the idea of working at Google.

There is a very important old saying about jobs: "If you're the smartest person where you work, quit". Basically - if you work with people smarter than you, you'll learn a lot. If you don't, you won't.

I wasn't really working anywhere at the time, but it was evident just from my interviews that there were plenty of people smarter than me at Google. I liked that idea a lot. The atmosphere was college-like. Engineers seemed excited and unencumbered.

It dawned on me that every decade there seems to be a "place" to work as an engineer. In the 80's it was Xerox Parc, in the 90's it was Microsoft. The 2000s, to me, felt like it was Google.

Needless to say, I took the job.

In a week or two I'm changing to a Java team working with Josh Bloch, Frank Yellin, and Pablo Bellver. How frickin cool is that? I can't think of a better place to be as an engineer (unless you're in Cleveland! then go work for Preemptive! :).

And as far as the snooty authors go, I still see them. Of course, they've written off my working at Google as "lucky" or a fluke. That's all not very relevant now as I pretty much blotted them out of my mind the instant I started interviewing. In fact, I completely forgot about them until the next year when I saw them again and they re-applied their snootage.

I'll admit my entrepreneurial side itches every now and then, and, as usual, I have a half-dozen projects/websites I work on in my free time. But as far as a day job goes, I'm good. Now when I'm asked why I work at Google, I pretty much ask back "where else would I want to?". And I assure you, there are still plenty of hard problems, plenty of passion, and the party - is - most definitely, not over.