Surf Roots, Software Thoughts

You may have noticed that my blog has been relatively quiet lately.  I have about eight posts that are on my to-write list, but I’ve been slightly preoccupied lately.  I haven’t had time to fold my laundry, so I sleep next to a huge pile of clean clothes.  I think I’m going to get in the habit of doing this, because it’s so convenient.  I don’t have to open drawers to get clothes.  Instead I just walk over to my bed and grab some articles from the pile.  What have I been preoccupied with you ask?

I announced a few posts ago that I’ve been working for Cloudera, a Hadoop support and training company.  It turns out that startups don’t really mix well with blogging, or life in general really.  I’ve been working like a madman, and I’m loving it.  Hadoop is an awesome, relatively new project, with lots room for improvement and involvement.  Not to mention the Cloudera team is composed of some awesome dudes that I’m totally excited to be spending my time with.  I don’t find it burdening at all to wake up, start working, work all day, work most of the night, sleep super late, and wake up early to repeat the process again.  I’m lovin’ it :).

Here are some posts on deck to give you taste of what I’ve been doing and thinking about: Django; iPhone has changed my life; Remember the Milk and Get Things Done; social constructs and how proximity is not close: a case study on China, Europe, USA and how I’ve changed; super markets and preservatives; San Francisco and how it’s my favorite city in the US.

Stay tuned!

This past Friday was my last day at Redfin.  Sometimes I wonder why I’m leaving such a wonderful company, but I think I’ve made the right decision. I had a really hard time saying goodbye to all my awesome coworkers, and my insane happy-hour-turned-to-long-night-of-drinking made things even more difficult.

It’s going to be hard to find a company that is filled with such wonderful people and work. Goodbye, Redfin. I miss you already :(.

Sushi after a long day’s work.

McGarty Party.

Sign conversations. I’m good at drawing.

Loki, one of the many Redfin doggies.

UW CSE affiliates day.  Also Halloween.

Yay IT Party.

Me and Mose.

Bahn.  Look at the dude on the right!

Scientists.

I’ve been a product manager (PM) at Redfin for almost a year now, and I’ve learned some really valuable things. My bosses, a lead product manager and the director of products, have been incredible mentors, and I wanted to share some of the advice they have given me along with some of the things I have learned along the way. I also wanted to highlight a few points from a book that also helped me learn how to be a good PM, though I’m not sure if I’m a good PM ;).

Research
When you’re designing a product, you need to research. I’ve talked about this a lot in previous posts, so I’ll summarize my previous post very quickly. You need to understand your demographic, and you need to understand the problem that you’re trying to solve. If you don’t fully understand your problem, then you’ll very likely create an unsuccessful product. Talk to your users anyway you can – over coffee, via online surveys, via focus groups, etc. I can’t begin to explain how important this is. Do it! I didn’t research Cellarspot enough, so I designed a website that is barely used.

Documentation
The type of documentation that you’ll have to produce really depends on the situation. Generally speaking, if you’re at a larger company, then you’ll probably have to publish documents about the business requirements of a product, the specifications of a product, and the ways in which a product will look (wireframes). If you have to draft these documents, then think critically about their audience – will programmers be reading this? Will executives be reading this? Etc. Make sure you get these documents reviewed by a peer prior to sending them to your boss.

If you’re at a smaller company, then you probably won’t have to document things as much. I’ve heard of certain startups drawing wireframes on the whiteboard, taking a picture of it and writing a quick description of the features, and then sending these two things off to a developer.

Generally speaking, I think it’s far more agile to draw some whiteboard wireframes, write some quick descriptions, and then send these off to a developer. However, I do believe that documentation is very important. Documentation facilitates review, and I believe that review is usually a good thing. That’s not to say that documentation is necessary for review, though. Documentation also makes it easier for a developer to mimic your vision of the product. I would document things if I were told to, and I would decide on a case-by-case basis whether to document or not if I were to make the decision myself.

I’ve written a lot of documentation at Redfin, and I believe that most of that documentation was necessary. There have been certain times when I thought the time spent on a certain document was wasted, but for the most part I agreed with the decisions my bosses made to document things.

Working with Others – Meetings, Reviews, Etc
As you’re researching, documenting, or just thinking about the product you’re trying to build, you’ll work with other people. Depending on the company, you might be in constant iteration with your boss. Regardless of the company, you’ll have to hand things off to a developer and speak to at least a few people about what should go into the product. Be prepared to be in charge of these interactions. You’re in charge of managing this product, so be prepared to be in charge of meetings, reviews, etc. You should be prepared to do a few things. First, be prepared to explain your current thoughts and ideas. Be prepared to discuss alternatives. Be prepared to ask questions, and make sure that the questions you ask are well-formed. Be prepared to be in charge of organizing meetings, and be prepared to be in charge of making sure those meetings move towards a solution. More to come on what to be prepared for …

Your Idea and the Alternatives
While designing your product, you’re going to run into a few forks in the road, where there are a few different options and only one option can be chosen. Go into meetings with a choice and reasoning for your choice. In my meetings with our CTO, I would present all the options and brainstorm them while in the meeting. I should have brainstormed the options on my own time with peers and presented my decision to our CTO with a detailed explanation and reasoning for not choosing the alternatives. It’s very easy to fall into the trap of putting decision making off, so make sure you’re either making good decisions or asking questions that will help you make a quick and good decision.

One of the products I worked on at Redfin was very, very delayed because of the way I interacted with our CTO. I kept expecting him to make a decision with research that I would present to him, when really he wanted me to make a decision and review my decision.

Take charge; make decisions – just make sure the decisions you are making are well thought and that alternatives have been addressed.

Too Much Data … Can’t … Synthesize
When researching a product, it’s very, very easy to get too much feedback. It’s also common for feedback to contradict other feedback. For example, your CEO might say that he or she wants features A, B, and C and not X, Y, or Z, while a customer might say that he or she wants features X, Y, and Z and not A, B, or C. It’s very easy to get overwhelmed when synthesizing research and feedback. When this happens, take a step back and revisit the problem. Clear your head over the weekend or spend a weekday working on something else. Revisit the problem with a clear head, lay all the options on the table, and make a decision. Again, get others involved by presenting alternatives and reasoning.

I organized a meeting with our CEO, CTO, director of products, director of marketing, and a few other people, and I would say that there were at least five contradicting opinions in this meeting. I didn’t know what to do. I wanted to satisfy everyone’s requirements, but there was no way to do so given their varying opinions. I took some time to work on a different product and later revisited this product. I wrote all the options on the whiteboard, made decisions on contradicting opinions, and prioritized the list of features. I’m still worried that the decisions I made might annoy certain people, but I try to remind myself of the following thought. At one point I had all opinions, feedback, and data in my mind, and the presence of those things naturally affected the way I see this product. Even though I may not have incorporated certain opinions in my list of features, I at least incorporated those opinions in my decisions.

Schedules
Often times PMs are in charge or setting schedules. Make your schedules milestone-oriented. Bucket various work items into milestones and set dates for those milestones. Some example milestones are code complete (all code written), content and design complete (all content and design elements have been included in the product), test ready (your product is ready for testing), zero bugs (all bugs either triaged (priorities changed, assignments made), punted (moved to a later release), or fixed), and release to world (your product is launched). Schedules are much more manageable with fewer deadlines, and bucketing work items into milestones makes it easy to have schedules with fewer deadlines.

When picking deadlines for milestones, make sure your deadlines are based off of feedback from the owners of the work items for each particular milestone. Top-down schedules (schedules defined by a PM and followed by stakeholders) are more prone to inaccuracy and generally create a stressful environment. Talk to each stakeholder and ask them how much time they need to finish their work items. Think critically about dependencies as well – often certain work items will depend on other work items, so these dependencies should be included in your schedule deadlines. Once you have an idea of how long a milestone will take, send an email to all of those involved in that milestone and ask for their confirmation. Bottoms-up schedules are more likely to be accurate and also make the PM seem more like a coordinator/leader than a dictator. Bottoms-up schedules are less likely to be rushed, and therefore the quality of your product is more likely to be higher. A possible criticism to a bottoms-up schedule is that stakeholders such as developers, system engineers, and marketing analysts will be lazy and set dates too far in the future. Hopefully you work with people who are passionate about their work, but if they aren’t, then you’ll have to motivate them. More on motivation later …

Schedules are insanely important. Setting schedules makes your product more likely to move forward at the fastest possible rate, especially when the schedule is defined from the bottom up. Spend time creating a schedule, and make sure that everyone involved in the schedule understands it and agrees with it.

Motivation
It’s easy for large projects to drag on and become uninteresting. It’s also common for coworkers to have different motivations. For example, it’s not uncommon that a PM finds a particular feature very interesting and fun, but a developer finds that same feature to be boring and uninteresting. In cases when a stakeholder is uninterested, it’s your job to motivate them. I haven’t had to do much of this at Redfin, but I can make a few speculations. First, be kind, positive, and pragmatic. I’ve seen first hand how one person’s energy can affect those around them. Create positive energy, not negative energy.

Be generous and thoughtful. Bring your team to a happy hour every now and then. Buy your team a nice lunch. Ask your team how their families are or how their weekends were. Again, create positive energy. Tell your team how awesome their work is – how fast their code runs, how beautiful their design is, or how badass their recommendation system is. Also, always ask if there is anything you can do to help.

Take the blame. If something goes wrong and it isn’t clear who is at fault, then take the blame. You might not necessarily be the person who erred, but take the blame anyway and do what you can to right the wrong. Your team will appreciate this, and at the end of the day, it doesn’t matter who is wrong. Taking the blame makes everyone feel better and allows things to move forward.

Perhaps some people might argue that these techniques are all brown-nose-ers. I simply disagree. Compliments are powerful and make people feel good, and people that feel good are more likely to kick ass, even if they’re burned out or uninterested.

In Summary, Be a Leader
Most of the advice I have just explained really comes down to simply being a leader. Lead your team in a positive, thought-driven way, and do the best you can.

Leave me a comment if I’ve left anything out or if you disagree with some of my opinions.

Update: Amit wrote a really good response post here (also in the trackbacks).

I was looking through Facebook pictures that friends of mine have tagged of me, and I recalled some of the encounters I’ve had with people about tagged pictures. I always hear about people detagging pictures of them on Facebook when they’re in the process of looking for jobs. I’ve thought about this a little bit, and I have an opinion.

I don’t think I’d want to work for a company that judged me based off of my Facebook photos. I should say that I don’t have any particularly bad photos on there, but there are a lot of photos of me being me. By that I mean making a fool of myself by playing air guitar on stage, running around with my shirt off, taking a shot (though I’m not a big drinker), or doing the other things that I tend to do. Anyway, the photos I have on Facebook are probably a decent representation of my personality, and I wouldn’t want to work somewhere that didn’t like my personality, even if they paid a lot of money. I’m not saying that everyone else should share my opinion here; I’m just stating my opinion. I’m happy with who I am, and if a company isn’t OK with my Facebook pictures, then I guess I won’t get hired. I’d want to work somewhere that was looking for personality as well as ability, motivation, etc, or I’d want to work somewhere that was purely looking for ability, motivation, etc.

And now for a collection of embarrassing Facebook pictures:

Rockin’ out to “Don’t Stop Believing” by Journey.

Doin’ my snowboard dance. This typically means better snowboarding. You should try it.

I’ve been working part-time for Redfin and taking a full course load since September ‘07. It’s been hard. Recently I realized that my productivity at work has decreased an insane amount, and I think that I’ve known about this for a while now. I’m not sure why I never acted on it. My big boss, Bryan, called me out on it, and I’m really glad he did. Since his call out, my productivity has gone up a lot - at least I think it has ;). I wanted to shine some light on the difficulties of being a part-time product manager (PM) while taking a full course load.

You need to context switch. While I’m focusing on classes, either in class or while working on assignments, I have lots of things bouncing around in my head. I’m thinking about due dates, action items, exams, and everything else a student worries about. When I’m focusing on work, I need to be consumed with schedules, wireframes, work status, bug counts, and everything else that a PM worries about. For the first few months of my part-time work, I let myself focus on school projects and HST concerns far too often while at work. I always have a lot of things going on, but I would think and act on non-work related things at work far too often. Part of the reason for this was because my schedule didn’t really allow me to have much non-school and non-work time during the day. For example, if I needed to meet with a professor or an adviser, I would have to schedule my appointments right after my classes, forcing me to show up to work late. Sometimes I would even have to schedule phone calls (interviews) during work hours. Again, you need to context switch. What I mean by that is that you have to have times of the day when you do school work, and times of the day when you’ll do work. You can’t try to mix the two. You have to take all the shit going on in your head during school and put it away when you’re at work. You have to take all the shit going on in your head during work and put it away when you’re at school. You can’t mix these things. If you do mix them as I did, you won’t be efficient at either.

Checking your personal email at work periodically can also be deadly. Occasionally I would see important emails in my gmail box and act on them while at work. Bad idea. Checking your email at work makes it easy to mix work with other things, which mixes your thoughts up too much.

In summary, do work when you’re at work, and don’t do work when you’re working on school/projects/etc. If you set barriers between school and work and stick to them, you’ll be much more efficient and productive. Think about these barriers when scheduling interviews, appointments, and when scheduling your classes.

Well it’s officially. I’ve decided to work for Google in Shanghai with a friend of mine, Christophe Bisciglia. I had to choose between Redfin in Seattle and Google in Shanghai, and the decision was not an easy one. Check it out:

Redfin
Pros
Insanely awesome coworkers. Unbeatable coworkers. Incredible company. Radical work. Great learning experience.

Cons
Located in Seattle. Won’t get better at engineering.

Google
Pros
Super challenging engineering work. Managerial experience. Located in Shanghai. Resume booster. Awesome boss.

Cons
Won’t get better at wireframing or specing.

This was a really hard decision. On one hand, I have a company that I truly love in a place that I really don’t like much at all. On the other hand, I have an insane opportunity with a prestigious company and super technical work. I decided on Google mostly because it would be a great segway into the Bay Area. I’d much rather start my life in the Bay, and Google in Shanghai is a great way to start that goal. I’ll get killer experience in Shanghai, which should make job hunting in the Bay much more easy. Shanghai is a crazy town as well, so just being there a few months will be an experience in and of itself. Redfin would also be a powerful experience, but I’m not willing to spend a few more years in Seattle. In fact, I’m scared of working in Seattle for a few more years.

I interned this past summer for Redfin in Seattle, and I found myself having a killer time at work and a boring/depressing time at home for the most part. I was limited a lot by the weather, and many of my college friends were home for the summer. I’m scared that if I were to stay in Seattle, the happiness gap between work and my personal life would grow too large. One could say, “Well why don’t you just leave Seattle if you get depressed?” My response is that I’m worried I might push myself to stay in Seattle until my shares at Redfin vest. Knowing me I’ll want to just stick it out and get my shares, and I don’t think that’s a healthy thing to do.

The Bay Area is still far from the people I love, but it’s much closer than Seattle. The Bay is also pretty close to Mammoth, which is a place where my friends, family, and I congregate all the time. It’s also my favorite place to snowboard. The Bay is also way closer to the ocean, making surfing much more accessible.

I believe I’m making the right decision, and I know that Shanghai will be an adventure to say the least. I just know I’m going to cry when I say goodbye to the rock-solid friends I’ve made at Redfin. I’m gonna miss you guys.

I recently announced that I was heading up to Mammoth Mountain for some snowboarding. Turns out me, my good buddy, and my family are having a killer time, but the vacation is making me think of a former friend of mine, call him Scott, who used to travel to Mammoth with us. And so goes the story of Cellarspot, Scott, and why friends should be careful when going into business together:

Scott and I had been friends since middle school and very close friends since high school. He’s the same age as me, and he’s studying entrepreneurship at USC. I started getting very involved with academia and computer science my sophomore year, so I started working on Cellarspot in the summer of ’06 to apply my newly learned skills. I mentioned the idea to Scott sometime that summer, and he said it sounded like a good idea. A lot of time went by, and I finally started taking Cellarspot seriously in winter ’07. Scott and I had dinner when we were both home for winter break, and he expressed interest in helping out and being involved. I said that’d be cool, but we didn’t move forward from there at all. At about this time, Scott started getting very involved in his entrepreneurial studies, building his interest in Cellarspot a lot. He kept asking me, “What can I do?” I would reply, “nothing,” because my classmates and I were working on the website and there wasn’t anything for a non-technical person to do. He continued to ask me this question through March ’07, and my answer never changed. On a sunny, Sunday morning in April ’07, I got a phone call from Scott that would eventually terminate our friendship (literally).

Scott told me that he was planning on raising capital for Cellarspot so that he could outsource the website to the Philippines. At this time, Cellarspot had already launched but still needed tons of improvements. Scott wanted me to make the improvements, but I didn’t really have much time seeing as how I was insanely busy with senior-level CS classes, TAing, and other things. By outsourcing the website to the Philippines, Scott would be able to get changes made to the site quickly. I didn’t like this idea.

My initial reasoning for not wanting to raise capital and outsource the site was because I loved working on the website. Moreover, the whole reason why I started Cellarspot was to make a cool website and have fun and learn along the way. I thought it would be cool to make money, but that was never my initial intention — I didn’t want to give something I love away. Some of my reasoning was also selfish in that I didn’t want to have pressure from investors, because my main focuses at that time were school and TAing.

When I told him, “no,” Scott started to lecture me about respect, because he learned all about respect in his fraternity. Apparently Scott had been networking with people about Cellarspot for quite some time now, and he was angry that his networking would now be wasted because I wasn’t willing to move forward at the pace he wanted. I would be angry if I were him as well, but he was never upfront with me about what efforts he was making. It’s almost as if he had a plan the entire time that he kept secret from me.

After the phone call, Scott de-friended me on Facebook, and we haven’t spoken since. It’s really sad to see a long friendship end over a business that makes about $5 per month on average, but I suppose that’s just how it is. I wish I could have gone back and handled things better, but I can’t. My only hope is that others learn from my mistakes and maintain their friendships.

Lessons Learned
First, make sure you are always upfront. Instead of telling Scott, “There is nothing for you to do,” I should have said, “You should work on something else and stop thinking about Cellarspot.” This is hard, though, because I didn’t not want Scott to work on Cellarspot. I wanted him to be involved with iterating on the website, but I didn’t want him to take total control of the site and rob me of my technical fun. We both should have been more upfront with one and other about what we wanted and what we could offer.

Second, look for signs that your business is interfering with your friendship. Once Scott and I entered a dialogue about Cellarspot, he would introduce me to his fraternity friends as his “business partner.” Weird, huh? I should have recognized this as an interference and acted on it. Instead I just kept going with the flow and didn’t really think about it outside of being weirded out that we were no longer friends but instead “business partners.”

Third, analyze your friendship prior to becoming business partners. If you have any doubt whatsoever before going into business together, then don’t do it. Scott and I had been great friends for a long time, but Scott is very, very stubborn and opinionated. Even in high school the two of us would angrily argue about silly things because our opinions differed. I’m not very confrontational and argumentative at all. In fact, there have only been six people that I’ve had angry arguments with on a semi-regular basis: my mom, my dad, my sister, my brother, my roommate, and Scott. I should have realized that Scott and I would engage in angry argument and not rationally come to conclusions, making business impossible.

Forth, just remember that freakishly good friendships are infinitely more valuable than business and money. My friendship with Scott prior to Cellarspot was on the decline from freakishly good, but relationships always have bumps in the road, right?

I’ve always been the type of person that asks a lot of questions. I used to be very weary of asking questions in the work place, though, because I was scared of annoying my coworkers/superiors. A lot of times I would hold back if I was worried a certain question would be better unsaid. I was especially careful when I worked in e-marketing at KB Home the summer after my sophomore year, because the office politics there were strange. The Art of Project Management, a book Matt recommended to me, has really given me a new perspective on asking questions and the benefits of doing so.

Another motivation behind this post came from my family’s Hanukkah party last night, where I spoke with lots of family and friends about what to do next year. I’m trying to decide between an engineering internship with Google in Shanghai and a full-time PM position with Redfin. I think there are a few different scenarios where the usefulness of questions really shines:

Your boss tells you to do something
It’s usually the case that your boss is busier than you, especially when you’re interning. It’s also usually the case that when your boss assigns something to you, he (or she) will accidentally leave out details because he is in a rush or he has his mind elsewhere. Naturally, you should ask questions to get that missing detail out of your boss to avoid not fully meeting his requirements. It usually comes down to one choice: either ask questions to clarify the problem or risk misunderstanding some portion of the problem. Depending on the context, you might be able to refine the problem without nagging your boss, but I think asking questions and potentially being annoying is much more important than working towards the wrong goals. I know if I were a boss, I would rather have the people I manage take up a little more of my time to understand the problem in its full than have them spend weeks or even months with the wrong goals in mind. (Hopefully I’ll never be a boss that just tells people what to do — I’d rather work alongside those whom I manage.)

You and your colleagues are brainstorming
Whether it be brainstorming the solution to a technical problem, the solution to a dilemma (such as where to work), or the way in which a certain product should function, it’s often the case that the people around you have opinions. Asking questions in these cases does a number of things:

First, questions get people talking. In my experience, more people are introverted than extroverted, and questions will get the introverts to voice their opinions. With more spoken opinions comes more likeliness that synthesis of those opinions will lead to a positive conclusion.

Second, answers to questions provide a new perspective for everyone listening. It’s often the case that the people you associate yourself with are as smart or smarter than you, and it’s often the case that they see things slightly differently than you do. Answers to questions can solidify your opinions if your colleagues’ perspectives are in line with your thinking. Answers can also make you realize that you’re thinking about things incorrectly if your colleagues’ perspectives don’t line up with your thinking. I believe it’s important to realize that these new perspectives can often times be insanely valuable.

A friend of mine once said that the job of a CEO is to synthesize, decide, and delegate. I wanted to capture this process in a little diagram to show how questions fit in:

Perhaps the most important thing to realize here is that the more synthesized information you have, the more concrete your decision will be. That’s not to say that synthesizing information is easy — I think that the process of synthesizing information deserves a lot of explanation that should perhaps be discussed in a later post. I would also argue that questions are one of the most important aspect of synthesized information, because answers to questions open up the opportunity to have lots of different experiences, readings, and other things coming from different people. Also, synthesizing and deciding are common tasks in challenging jobs, so the above diagram doesn’t necessarily only apply to CEOs.

So, don’t let yourself get intimidated about asking questions in the office. If someone gets annoyed, then tell them that you’re just trying to make sure you have a grasp on the situation. Also tell them that they’re not helping you synthesize. It’ll be awkward and funny at the same time. With all jokes aside, though, questions are super important and should be taken seriously. Try to ask good, concise questions, and the answers will only help. In fact, they’ll probably help a lot.

Update: Bo Bennett agrees.

It seems like we all have a few options: pursue something that makes us happy, pursue something that makes others happy, pursue something that should be pursued by someone of our academic status (finance majors work for financial companies, cs majors work for cs companies, etc), or just don’t pursue anything at all. I’m definitely not going to do the latter, but what about the three former options? Is it selfish to pursue something that makes you happy but doesn’t help others? Is it dangerous to pursue something that doesn’t make you happy but makes others happy? Is it foolish to not pursue something that someone like you should pursue? These are the questions that I’m trying to answer right now.

I would like to put myself in a position where my work directly helps someone else. I would like to put myself in a position where I love my work. I would like to put myself in a position where my technical and leadership skills will be challenged. How does a computer scientist truly help those that need help? I think it’s relatively easy for a computer scientist to find a job after college that they enjoy and that stretches their thinking (e.g. Redfin or Google), but what about helping others? Is it good enough to help your coworkers, family, and friends, or do you have to do more?

I asked my 82-year-old grandpa these questions when I saw him over Thanksgiving break. He started his life as a weapons engineer, where his job was to manufacture weapons to kill the most amount of people for the least amount of manufacturing costs. He later became a sociology lecturer at Chapel Hill and a guardian ad litem once he realized how his weapons work was helping people. I asked him, “Grandpa, how do you really make a difference and help people?” His response was, “I don’t know, but I think asking yourself that question is the first step.”

I don’t know the answers to these questions either, but the hope of this post is to get underclassmen college students thinking. Eventually you’ll be faced with the decision, just like I am now, to start your post-college life, and my only hope is that you decide to do something that solves a true problem, that helps other people in a real way. I also hope that you enjoy what you do and are challenged to become a better/smarter/etc person.

Now max out the volume on your computer, click the “play” button on this YouTube video, and close your eyes. It makes you forget about everything else, huh? What a wonderful song. “Hide And Seek” by iMogen Heap

Speaking of happiness

I have a few friends that work at Google. Prior to talking with Sierra and Jack about Google, I was definitely a startup guy. I’ve had an awesome experience at Redfin, and I even made a long post about why I prefer startups. After speaking with Sierra and Jack, I got the impression that Google was very much a bottoms-up organization, which had a lot of appeal. I want to make sure that the place I work gives me lots of say, lots of creative control, and lots of responsibility, and I think Google definitely would. Sierra and Jack convinced me that I should give Google a shot, so I did. Oh, and I’m looking to be a PM (Google calls them APMs). I sent in my resume through the University of Washington Computer Science and Engineering Affiliates Program and was asked for two phone screens a week or so later.

Phone Screens
My first phone screen was with an APM who mostly asked me about my wine website. He asked me business objective-related questions and told me that the Cellarspot UI wasn’t that bad. I didn’t agree with him.

I thought the first phone screen went well. The next phone screen was with a PM who grinded me with awesome technical challenges.

I thought this interview went OK, but it definitely could have gone better. I heard back about a week later that Google wanted to fly me down for a full-paid weekend. Awesome!

Google Batch Weekend
The weekend started off with a paid flight from Seattle to San Francisco and a paid taxi ride from SFO to my swankster-elite hotel. I felt very much at home. I arrived on a Thursday evening and saw some Berkeley friends that night. The next day was Google day. We were driven in a BALLER Google shuttle from the city to Mountain View to start a big long day of interviews and campus tours.

I had three interviews in the morning, then lunch, then a campus tour, then two more interviews.

I was generally very impressed with the interview process. I got questions asking about my personality, pondering my technical ability, checking my HCI background (of which I have none), and seeing how I would go about spec-ing various products. The most surprising piece of the interview process was that I was never asked about my leadership abilities. PMs need to do three things: 1) understand business requirements, 2) make awesome products with those business requirements in mind, and 3) lead a team. I would argue that being a leader is the most important piece of a PM, but maybe that’s because I have a startup bias. Maybe larger companies like Google have more process and structure so that developers will just follow the PMs spec. I was surprised my leadership wasn’t tested, but maybe that’s not something that you have to have as an entry-level APM at Google.

The campus itself was absolutely stunning. The food was exquisite, the perks were unbelievable (tons of free food, tons of free drinks, and MUCH more), and the wine was flowing (not really). Google would definitely be an unbelievable place to work.

After interviews, we went to the Fog City Diner, which was super awesome. We got to sit down with PMs and APMs and talk about whatever we wanted to talk about. I took this opportunity to ask tons of questions and probably annoyed everyone around me. Marissa Mayer also showed up and talked to each table for a few minutes.  It was nice of her to make a scene and tell some cool stories.

Saturday was scavenger hunt day and karaoke night. It was possibly one of the funnest/best days of my life. We ran around the city for six hours taking embarrassing pictures while doing embarrassing things. Such things include propose to a stranger, get cuffed by a cop, run up hills, roll down streets, get in bed with a couple you don’t know, sing to a couple, get a makeover, etc. I, having very little shame, went to town on this hunt and my team won!

That night was karaoke night, and man was it awesome. I love karaoke, and the my colleagues were absolute rock stars. Eric, Adam, Tom, Jayant, Taj, Josh, and everyone else were just letting loose and having a killer time. Drinks on Google, of course.

I got breakfast with a few more friends Sunday morning and flew home that afternoon. I found out a few days later that I didn’t get the job.

If you’re interviewing with Google, prepare for an awesome time, an awesome company, awesome people (both candidates and Googlers), awesome food, and a super competitive experience. Only three of the 12 candidates moved on in my group, and all of us were ultra qualified. I’m sad that I didn’t get the job, but I had such a wonderful weekend anyway. It’s all good.

Bonus story: Glenn, the Redfin CEO, apparently heard the Google rejection news from my boss Matt. He saw me walking in the halls, snuck up on me, put his arm around me and while walking beside me said, “I heard the good news, dude!” Haha.