DEV Community: Harjeet

Marissa Mayer on Career Growth and How a Revenue Guarantee Almost Killed Google

Harjeet — Tue, 09 Apr 2019 21:10:41 +0000

I remember when we made a huge revenue guarantee to AOL to get the account. We did a best-case scenario projection, a middle of the road projection, and a worst-case scenario projection. Worst-case scenario and middle of the road had us going out of business with the contract. The best-case scenario had us breaking even.

Marissa Mayer was one of the earliest employees at Google and helped to shape both Gmail and Google Maps. Mayer became the CEO of Yahoo in 2012, a position she held until 2017 when Yahoo was acquired by Verizon for $4.48 billion. In 2018, she co-founded Lumi Labs, a startup incubator in Palo Alto focusing on consumer media and AI. Marissa Mayer recently sat down with Triplebyte's CEO, Harj Taggar, to discuss her career in tech and the advice she gives to new engineers.

This interview has been edited for clarity and style. Marissa Mayer is a Triplebyte investor.

Getting Started in Technology

Why did you pursue a career in technology?

Originally I thought I was going to go into medicine, and I was very committed to majoring in Biology and Chemistry at Stanford. But shortly after I arrived, I bought a computer with my babysitting money, and I took an Introduction to Computer Science class for non-majors in order to fulfill a requirement. It's funny—on the first day of class, the lecturer said, Studies have shown that of the 400 of you sitting in this introductory class, exactly two of you will go on to take any further Computer Science classes, so I'm gonna make this easy on everyone.

Clearly I was one of those two people who went on.

I took the rest of the Computer Science core over the course of my B.A. and M.A., because I loved that introductory course. It was the very early days of what would later blossom into the internet. Netscape had just gotten started. Yahoo was getting started—although it was still “David and Jerry's Guide to the World Wide Web,” and it was hosted in Jerry Yang's student directory at Stanford. I was introduced to a lot of things at that time—the Mosaic browser, things like that—all through CS105 at Stanford.

Why did you decide to stay at Stanford to pursue a master's degree?

I already knew that I wanted to do more school. My undergraduate degree was in Symbolic Systems, which I studied because I wanted more breadth as an undergrad, but for my master's I decided I wanted more depth. There were only 13 classes in artificial intelligence offered at Stanford at that time, and I'd taken seven of them for my undergraduate. I realized that, while I had a very deep understanding of artificial intelligence, I did not yet have some of the basics down. I knew how a database worked. I knew how an operating system worked. I knew how a compiler worked. But I hadn't taken classes on those topics, so I went back for my master's and took the rest of the AI offerings as well as a lot of programming basics. That way, I could actually go and market myself as a software engineer and say, “I've written a compiler. I've written an operating system. I've written a database. I know how they work.”

Choosing Google

When did you get serious about your career?

I got serious about my career when I was graduating from my master's, sometime around January of 1999. It was the height of the World Wide Web. Between January of 1999 and the end of April, I had amassed about 14 offers in all kinds of different sectors: software engineering jobs at big companies, software engineering jobs at small companies, technology consulting, and teaching.

What was it like to interview at Google?

Ironically, Google used to be located in the building we are in now, on this floor. There was a conference room much like this one. It had a ping-pong table for entertainment, which was also used for the all-hands meeting. There were seven people the day I started, but an eighth person joined that same day. He came in to interview me and said, I know I'm here to interview you, but I just started this morning, so I'm not really sure what to ask.

Google's interview format has changed a lot since then, but at the time I had to talk to everyone. I interviewed over two days, and, ironically, between those two days, another person had joined, and another person had also started moonlighting in the evenings—so I had two more people to talk to the next day! They were really growing quickly. They asked me some coding questions, some theoretical questions, and some systems design questions, but the vast majority of the questions focused on coding.

Did you leave with any impressions of Larry, Sergey, and Craig?

Yes. I thought that Larry Page was very quiet. I thought that Sergey was deeply mathematical (which he is) because he quizzed me a lot on k-means clustering and different patterns that you might see if you actually mapped the values of what they meant.

I felt that Craig Silverstein—who is now one of my best friends—was one of the most brilliant people I'd ever met. A lot of my desire to go to Google was that I wanted to sit down and work alongside Craig and learn as much as I could. Obviously, when you join a startup, your ideals need to align with those of the founders. All three of them factored heavily into my decision to choose Google.

What made Craig such a brilliant engineer?

Craig is just a genius. He can speak in-depth on so many different subjects. And he's also the first to admit when he doesn't know a lot about something. He's just really, really sharp. I think he was pursuing a systems or theory-based Ph.D. at Stanford when he dropped out to help start Google with Larry and Sergey. People who work on systems and theory are generally just really terrific engineers. So I knew there was a lot that I could learn from him.

How did you decide to join Google? What was your decision making process like?

I had a long analytical evening with a friend of mine where we looked at all the job offers I had received. We created a giant matrix with one row per job offer and one column per value. We compared everything from the basics like cash and stock to where I'd be living, happiness factor, and trajectory factor—all of these different elements. And so we went to work analyzing this problem.

At midnight my friend, Andre, who is brilliant—he had better than a 4.0 in Economics at Stanford—said, You know Marissa, this has been totally fascinating, analyzing such a rich and interesting problem. Thank you so much for helping me work through this with you. And I sat back and just got really overwhelmed and was like, I'm glad this was fun for you, but I still don't have an answer, and I don't know what I'm thinking. I told myself I'd make a decision by tomorrow. What am I going to do?

At which point he gave me the best piece of advice I've ever gotten. He said to me, You know, I've looked at this problem for six hours with you. I understand it at least as well as you do. We've talked about every facet of each of these companies. But I have to tell you, I think you've approached the problem all wrong.

And then he said, You're looking at this as if there is one right answer among these fourteen, and thirteen wrong answers, but now that I've analyzed this with you, I can see that there are actually a bunch of good options here. There's just going to be one that you pick, and you commit to, and you won't look back at the others, and you'll make it great.

I think this is a common thing that very analytical people trip themselves up with. They look at things as if there's a right answer and a wrong answer when, the truth is, there's often just good choices, and maybe a great choice in there.

Of course, if there is a standout choice, you hope it stands out to you and you pick it. That's why you want to make sure that you really understand the space well and all the different elements of the different choices. But it's a trap to think that there's only one right or wrong answer.

How did you value stock when you were thinking about Google?

I didn't actually think about the stock, I'll be honest. I knew that Larry and Sergey were fair, but for me, I valued the learning. I came to Google because some of the smartest people I'd ever met were working there including, Larry and Sergey and Craig. I also came to Google because I felt entirely unprepared to do what we were trying to do. They were talking about building a Fortune 500 company.

On the matrix we made, I had a “chance of success metric,” and I gave Google a 2% chance. However, I gave every other startup I was interviewing with a .02% chance. So, Google's chance of success was a hundred times better than any other startup I applied to—but still a one in fifty shot. Which is pretty good for a startup, but it's still far from assurance of success. And remember, at the time, it was a seven person company.

Did your estimation of Google's chance of success change at some point?

It never felt assured. A lot of people feel that Google's success came overnight, but that's not the way it felt for me on the inside. It was very hard work, just back-breakingly hard work. Incredibly long hours. Incredibly stressful because we had this site we were keeping up. You would just chip away, and our traffic was constantly going up, and we were winning new users. But it didn't feel overnight.

We definitely had milestones. It was a rich field for competition for accounts and contracts. We landed Yahoo, powering Yahoo search, and then powering AOL search as well. We would ask ourselves, Oh gosh. What've we done? Now we actually have to build this and meet these timelines and these standards and these SLAs.

Were the contracts with Yahoo and AOL a turning point?

Those two contracts were also moments when we bit off a lot more than we could chew, and we really had to catch up. I remember when we made a huge revenue guarantee to AOL to get the account. We did a best-case scenario projection, a middle of the road projection, and a worst-case scenario projection. Worst-case scenario and middle of the road had us going out of business with the contract. The best-case scenario had us breaking even.

It turned out all of our models were wrong, but there was literally a moment when we signed a contract and realized, “in most likelihood, this contract breaks the company.” Ultimately, that was actually a great moment because we realized how much money we could make for AOL, that we could meet those guarantees, and that we could make even more money off our own site where we could keep 100%. We got a lot of insights from that contract.

Of course, you could say, Wasn't it great that you signed that contract and landed it? And it did turn out to be this major achievement, but the day we signed that contract was one of the scariest in the history of Google. When you're working at a startup, often the moments of major achievement are actually really scary ones. Those days aren't necessarily the ones you celebrate in the moment.

Moving to Yahoo

What differences did you notice between the engineering cultures at Yahoo and Google?

Both companies had really strong engineering cultures. I would say that Google does some tech for technology's sake, and engineering is really the driving force there. When I arrived at Yahoo, I found that what we were building was driven more by marketing and sales and less by, say, product or engineering. At Yahoo, we worked hard to bring what we were building, and why we were building it, and how we were building it, back into the realm of tech and products. We actually changed the engineering culture quite a bit over those five years.

Did having an engineering background help you as CEO?

Overall, people knew that I had coded, and that gave me a lot of credibility when I got involved in critical technical discussions about how we were building things, or what particular products we needed to build. It helped with credibility and also helped me know what I was asking for.

I think I was a good engineer. I was an even better product manager. And one of the reasons I was a good product manager was because I had been an engineer. So when I went to my engineers and said, I need you to build this feature, or, I think we should prioritize this, I actually knew what I was asking for. I knew if I was asking for something really hard that was going take a lot of re-architecting, and I knew if I was asking for something easy.

Advice on Choosing a Company to Work For

What's your advice for choosing between a big tech company and startup?

I would tell you to focus on what you're going to learn and the impact you can make. There are different scenarios at every company, but if you feel like you'll be part of a team with a lot of people who are smarter than you and better than you at a craft that you really care about, that's a great team to join. Also, if you're at a tiny company—you're one in five people, let's say—your impact is going to be pretty big. You have to make sure their mission is big, though. If the mission's big and the company is small, that's a great combination.

For example, I had looked at McKinsey for consulting—which is a great company—but I had a lot of friends who were in analyst roles there, and I knew that as an analyst you would do all the work, and all the analysis, and prepare the presentation, but when it's time to actually make the decision, you're often asked to leave while the executives debate it. I felt that if I could be in the room when those decisions were being made—even if it was for some of the decisions and not all of them—I would learn a lot more. I felt that I would learn more trying to help the team at Google build a Fortune 500 company than I would giving advice to Fortune 500 companies.

At the same time, if you're at a big company and there's a team that has a big mandate, but the team is small, that is also a great opportunity to progress your career.

Is the argument in favor of joining a startup less true today, now that big tech companies are increasing their compensation—especially for engineers?

Overall, yes, the value that engineers bring to companies is more recognized and rewarded now. At the same time, I still think that choosing a company is a lot more about your own learning and your own advancement and your own contribution than it is about compensation.

I feel that many people overweight compensation. The truth is, if you focus on what you can learn and what you can contribute and the impact you can make, you also usually get disproportionately rewarded in compensation, whether in the short term or in the long term.

Did you set career goals for yourself while you were at Google?

For the first two years, Google was a very flat organization. I guess they did actually have a career ladder, and I was moving up it, but we didn't get insight into that until later. When they actually digitized all the records, I was like, Oh, it turns out I was getting all these promotions at the time, but I had no idea. Once they actually put the hierarchy in place, then it became really clear what the next step was, when it was time to make a move to director or a VP.

I'm a big advocate for having frank conversations once a year, outside of annual performance reviews. You don't want to exhaust your manager, but you want to know where you are and participate in planning with them. So, if you get your performance review in March, then have a straightforward conversation in, say, August or September: Here's what I'm hoping to do. Here's what I think I can contribute. What are some of the steps you think I need to take, and things I need to fix, in order to make that step.

How should someone decide whether to continue in engineering, or go into management?

It's important for you to either pursue a management track or not based on your own proclivity. If you're deeply an introvert, if you don't enjoy leading, these are reasons why you should just try and become a very senior engineer without direct management of people. More and more companies are starting to open up avenues where you can become senior without managing people, and I think that's really freeing for people who really want to perfect their craft, who want to lead teams, but who don't necessarily want to be bogged down with managing and developing people. I think that it's important to have these two tracks. A lot of it is intrinsic personality traits that will draw you to one or the other and you need to listen to those.

That said, leadership on a large scale, by its definition, requires managing and developing people.

Our final question: Why isn't everyone happy all the time?

I don't know. Overall, I'm a pretty happy person, and one of my theories in life is that people fundamentally want to be happy. So, if you ever find a moment when you aren't happy, you should just wait. Something is likely to change in the scenario. Someone else will change what they're doing, or you'll get motivated to change what you're doing, so the situation will change overall for the better.

Marissa Mayer, thank you so much for your time!

Gmail Creator and YC Partner Paul Buchheit on Joining Google, How to Become a Great Engineer, and Happiness

Harjeet — Thu, 24 Jan 2019 22:42:04 +0000

Paul Buchheit is an engineer and partner at Y Combinator. He was the 23rd employee at Google, where he built Gmail and the first prototype for Adsense. After leaving Google he co-founded Friendfeed, which was acquired by Facebook.

Triplebyte co-founder and CEO, Harj Taggar, sat down with Paul to talk about how he got started with programming, joining Google, and becoming a great engineer.

This interview has been edited for length and clarity.

On Becoming a Programmer

How did you start programming?

One moment I remember really getting into programming came while playing a fantasy RPG video game. I got stuck and couldn't find the magic handcuffs—or whatever it was—that I needed. Then I thought, “maybe instead of searching in the game, I can just hack the data file where it saves the inventory!” I started writing programs to figure out how the game was storing things. Then I figured out how to insert anything into my inventory, including things that didn't even exist in the game.

That's when I realized wow, this is way more fun than the actual game. With games you're just trapped inside someone else's world. But with programming, you can do anything you want to the world, right? It's an open environment, and there's no limit to what you can do. From then on, video games just seemed like a pointless waste of time compared to programming.

I had actually first started programming maybe a year earlier. I'd bought a 386 with one megabyte of memory and started playing with it. I found a text file on how to program on a BBS, along with a C compiler which halfway worked. I learned a little bit by playing with those. Later at a hamfest I found a used Turbo C 2.0 compiler for $11 which came with a manual. So now I had a working compiler and a manual, and I started bashing my head against a wall for a couple of years figuring out how it all worked. At first I didn't actually enjoy it very much, but I was stubborn and determined to figure it out.

Did you feel like you were a good programmer when you got to college?

I felt like I was relatively good. I knew I wasn't good at building large scale things—but my code did the job. When I got to college, there was an ACM programming competition which I thought would be fun to take part in. I ended up coming in second place, so then I thought, “yeah I'm probably OK.”

Why did you join Intel after you graduated?

I was always interested in startups and businesses. When I was maybe 10 years old, I actually did door-to-door sales in my neighborhood. I'd take this catalog and go bug people to buy things. I made $1 every time I sold a package of greeting cards!

After college I wanted to work at a startup, but didn't really know how to find one -- there wasn't much information about startups on the Internet back then. However I know that they would probably be in Silicon Valley. That's where Netscape, SGI and a bunch of these cool sounding companies all were. I took a job at Intel because they were located in Silicon Valley, and I thought it would be the best way to meet people and find a cool startup. My naive assumption was that I would bump into them on the street or something. I thought the streets of Silicon Valley would be paved in startups, or that I would meet startup people everywhere. But that never really happened.

On Joining Google and Creating Gmail

Why did you decide to leave Intel?

Overall, the job wasn't exciting to me. I didn't have to work that hard, and one day I had this realization while sitting in my gray cubicle (I was in a sea of gray cubicles surrounded by gray walls, listening to white noise and all alone): I'm like, “Man I am so tired. I need to go home and take a nap.” I went home, but as soon as I got there I realized, “I'm not tired anymore.” Working at Intel was a draining environment, and I knew I wanted to leave.

How did you find Google? What was the hiring process like back then?

So, I was really into Linux. I actually got into Linux even before college, in '93 or around then. I'd installed the Yggdrasil Linux distribution on a partially broken hard drive I found, on which I could partition off 60MB that worked. That was enough to fit a small Linux install, but it wasn't enough room for Emacs which is why I'm a vi person.

I would spend a lot of time reading Slashdot for all the latest Linux news. That was where I read about Google, which was this little startup building clusters of Linux machines! To me, what could possibly be more exciting than clusters of Linux machines? And they had a special Linux search so they would show up on Slashdot relatively often. And they had more than just the color gray—they had four colors, so I applied for a job!

Amusingly, my resume email actually bounced because their mail server was misconfigured! But I sent it again the next day, and by then they had fixed the MX record or whatever was wrong, and someone got back to me to setup a phone call. I did a phone screen, and then they invited me in for a day of interviews.

Why did you decide to take the Google offer?

Well it was the only one I got, so that made it easy!

Also, it was exciting, and I thought they were doing cool stuff. I didn't believe in the business or think the company would be a huge success, though. I thought they were going to be roadkill and would get squashed by one of the big internet companies. By then, Yahoo was already a behemoth, and Alta Vista had so much money. I didn't understand how this little startup would be able to compete. But I decided I didn't care. I wanted to go work on Linux stuff and figured I'd at least meet some smart people there, and maybe they'd later start a company that would actually be successful.

In hindsight, I realize the early team at Google was actually quite remarkable. I think they made a real point of hiring smart people. In part, that was because they were working on really interesting problems and smart people want to work on interesting problems. I remember Jeff Dean had gone to work at another startup before Google and immediately fixed all of their problems. When he asked, “Now what do I do?,” it turned out that they had nothing else interesting to work on, so he left. He was drawn into Google because of the interesting systems problems there.

It became a cycle. These smart people would bring more smart people with them and so on. I think we got the whole systems department at UCSB because Urs was a professor there. It was like pulling on a string of talent and getting all the talent attached to it.

So, you thought Google would fail and be “roadkill.” When did you change your mind?

After I had been there for about a week, I was like, “Oh this company is going to be big.” I actually went back and asked for more stock options, but they said you could only negotiate for that before accepting the offer!

I didn't realize that Google was really taking off, though, until we did the Yahoo deal, which was after I'd been there a year or so. We took the Yahoo deal away from Inktomi, which at the time was a huge high flying company. I think they were worth many billions of dollars at the time, and it was exciting to beat them. I remember they tried to downplay the loss and announced something publicly like, “This 'search thing' isn't really great. The real money is in internet caching.”

After that I thought, “wow, these people are idiots, and we're going to roll over them.” From then on, we just kept winning deals and squashing other companies. That was exciting.

How did they decide what you got to work on at Google?

Marissa and I were actually given two projects to work on when we started. One was to build product search, and the other one was to build an ad system. I ended up focusing more on product search because that seemed more interesting than building an ad system. I was later part of a group called Onebox, which was basically the idea that you should be able to type in anything and get an answer, even if it isn't a regular web search.

I generally had product tendencies and was always hacking things on the side and adding features to things. I actually built the first version of the “did you mean?” feature after looking through our search query logs and discovering that I'm not the only person who can't spell. The quality team was working on these obscure things to improve search quality by .1% and I'm thinking, “at least 20% of our queries are misspelled. If we fix the spelling, I can improve 20% of the queries!” So I hacked that together. I would hack a lot of things together like that.

As Google grew, did you keep the freedom to hack on things you found interesting? Was creating Gmail part of that?

Around 2001, Larry got frustrated that each group was setting their own priorities and not working on what he thought were the most strategically important things for the company. His fix was to eliminate management and organize engineering around specific projects. He and Wayne Rosing, who was the VP of Engineering at the time, would sit down with engineers and give them projects. When they sat down with me they said, “we want you to build an email something.” That was all the specification I got! So I went off to build something with email, which became Gmail.

How did you manage your personal career progression at Google?

I've never really been into the whole “career” thing. It just feels horribly big-company. I was always very allergic to things that I perceived as big company. I just didn't want to be tucked away in a corner working on something irrelevant. I interned at Microsoft after my freshman year of college. On my last day, one of the smartest engineers in my group gave me this piece of advice, “Make sure they don't stick you off in a corner working on something unimportant.” I've always remembered it as good advice. My ambition at Google was just to launch a cool product or create something important.

On Leaving Google

Why did you decide to leave Google?

My daughter, our first child, was born unexpectedly—100 days early. There was a lot of medical trauma surrounding her birth, and we were in the hospital for months. When it was all over, I was really excited to get back to work because I loved working at Google. I liked it so much that I couldn't sleep the night before—I was just thinking over and over, “Oh man, I can't wait to get back—I'm going to do all this stuff!”

But when I went in the next day, the energy drained out of me. I suddenly felt like I used to feel working at Intel. Partially I think Google had grown so much in my absence, but it was also partly a “boiling the frog” effect: before I spent time away, I hadn't noticed things slowly changing, but when I got back I realized, “Oh wow, here I am in a meeting with a bunch of people I don't know who are telling me to do stuff that I don't care about.” I knew immediately that if I stayed at Google, and wanted to be successful and influential, I would have to become more of a big company person. I knew that I had the capacity to do that, but I didn't want to. I wanted to do something else, so I left.

On What it Takes to Become a Great Engineer

What skills and knowledge does it take to be a good engineer?

Computer science is almost unlike any other engineering discipline because we routinely work at many different layers of abstraction. Someone who is only able to operate at one level is not going to be effective because often any given problem will be at a different level of abstraction from the last. Great engineers understand computers all the way from the silicon up through the different layers and protocols and systems.

How do you become a better engineer?

Doing it. Showing up seems to be the secret to getting good at most things. I programmed when I was in high school, and it was all I did because I didn't have anything else going on—fortunately. Programming was my hobby, and I always had some project I was trying to implement. I think there's no substitute for doing a lot of programming because you just can't get really good in a short amount of time. It certainly took me years before I would say I was any good.

Who are some of the best engineers you've worked with? What made them great?

One of the most impressive engineers I ever worked with is Bret Taylor who was also my co-founder at FriendFeed. I've never encountered anyone else who combines being an incredible engineer, and being an incredible product person, and an incredible manager, and an incredible designer. He is good at everything—it's unfair!

The story about Bret I most vividly remember is from our days at Google. He wasn't even an engineer there, instead he was a product manager for some reason. As the PM on Google Maps, he was frustrated that the JavaScript was really slow. It would take forever to load. So, one weekend he said, “I'm going to rewrite it”. And he rewrote the entire thing, making it 10 times as fast and a third of the size. He completely threw away the code that a team of engineers had been working on for months. Someone who can do that is ridiculous. Talk about 10x engineers. That's more like 1000x. And it's good, clean code too. Literally no number of median engineers can do that. You can give me a million median engineers and they would never be able to do that. They would just make a huge mess.

Craig Silverstein was another, he was the very first Google employee. He is someone who types and programs faster than I can perceive what he's doing. Sometimes I like to watch other engineers work so I can learn how they do things. But with Craig he moved too fast for that. The screen would flicker and code would just appear. He'd constantly be flipping buffers in Emacs or whatever. He types so fast. I've never seen anyone else that fast.

On When to Quit Your Job and Join a Startup

Do you think every good engineer currently working at Google, Facebook, or Apple should quit to join a startup?

No.

Alright. Who should and who shouldn't?

If you're happy working where you are, and you don't have any ambition to do anything else, you're probably going to get paid less and work more if you leave. If getting paid less and working more is unappealing to you, then I would recommend staying where you are!

I feel the need to preface that any generalization about joining startups is basically wrong because startups have tremendously high variance. Most startups are s**t. There's a few of them that are really exceptional, and if you land at an exceptional one, you can do really well. If you randomly pick something, you'll probably have a bad time.

If the hours and the pay are worse, what are the benefits of working at a startup?

A big company, like Google is today, has all these really smart people who are already experienced and know what they're doing. So, if you join Google, you're going to be working at your “correct” level. At a startup, though, they probably don't have the resources they need, so you can be operating way beyond your level. That's what I think is really great about startups.

Gmail is an example of this. I was 24 years old at the time, and I'd never completed a project of that scale or built anything like that before. Google today would never give that project to a relatively inexperienced 24 year old. But at a startup you can end up getting a project that a more mature company would give to a more experienced engineer.

Today, the big technology companies are paying engineers a lot more money than Intel was when you left for Google. How should that fact affect an engineer's decision to join a startup?

Yeah, that's hard. I think you have to view it as an investment. You're essentially investing in yourself. You have to believe that at the startup, you're going to learn and develop faster. If you don't think it will provide that, maybe you shouldn't take the job. If you go someplace with a lot of really smart people who are moving really fast, you can grow and develop as an engineer, or whatever you want to be, much faster than you would at a big company.

I would suggest thinking about joining a startup as more like going to grad school to learn. Optimize around learning when choosing a job. That's the best thing. Then if a startup fails, you can always go back to Google and probably get paid a lot more, because now you're actually a much better engineer than you would have been if you had stayed there like everyone else.

If you're thinking about joining a startup, how do you tell if the founders are like Larry and Sergey or if they're an Elizabeth Holmes?

Right, that's the worst combination: smart and full of s**t. I think you have to interview them a little bit. Ask hard questions and see if they give direct, insightful answers, or if they're evasive and dismissive. It also helps if there is a product you can try. I would avoid startups that have a ton of hype and no product.

Generally, when you are interviewing with a startup, how should you decide if it is the right company for you?

Looking back, one of the things that really impressed me about Google, which is probably good advice for anyone choosing a startup to work at, was that the interviewers all asked really smart questions. They asked things that only people who really knew their stuff could have answered well. Urs asked me, “Let's say you have a server, and it's running really slowly for some reason, how do you diagnose the cause?” To answer that question, you actually have to understand systems really well.

Their questions required being able to think at all these different levels: “Is there something going on in the kernel? Do you understand that hard drives are not these magical things which spit out information? Do you know why random access takes time?”

I only interviewed at one other company and they asked stupid questions like, “name the seven layers of the OSI Networking Stack,” or something that you'd pull out of a textbook, not things that were actually interesting.

Also, when I first went to work at Google, I had the opposite feeling I described having at Intel. I was excited. I woke up in the morning and was excited to go to work. There was this buzz of productivity in the office all the time. I think that's one way to know if a startup is doing well: When you go into their office, you can just tell. Are people busy working, or are they sitting around on Twitter wasting time? Are people showing up because they have to, or are they eagerly working because they're excited? Google was a really energizing place to be back then.

On Investing, Crypto, College, and Happiness

Do you think being an engineer made you a better investor?

Probably. I mean I think working as an engineer makes you believe you're better at everything!

I do think that the ability to break problems down into smaller pieces helps in a lot of areas. Certainly, as an investor, you need to be able to evaluate people and call them on their shit. Especially with technical things, someone who doesn't have a technical background can't really evaluate well. If someone says that something is easy to do or hard to do, a person without tech skills will just have to take their word for it.

You joined Google because you were deeply interested in Linux. Is there a technology you're equally excited about today?

This is a question which I would be curious for someone else to tell me the answer to! The closest thing I can think of is Bitcoin and crypto. I'm pretty sure they would have captured the attention of 21 year old me. What's different about crypto, though, is that it's full of all these get rich quick scammers, which Linux didn't have.

Is college useful?

I think so. If nothing else, it's a period of growing up and becoming independent. I wouldn't have wanted to go directly from high-school to working at Intel. That would have been nightmarish. There's a lot of human development that goes on in college.

By the time I got to college, I'd already had my first job programming. I was working with a friend of my father who did machine repair, programming an industrial robot that would pick metal rods out of a hopper and put them into a grinder. I learned a lot doing that, but I didn't really know anyone who could program. It was exciting to meet people who could program well in college because I could learn from them.

Why isn't everyone happy all the time?

Oh God. I'm not sure. I think maybe we've strayed too far from our evolutionary roots. We've created a world where it's hard for people to be happy. Plus, there's a whole industry evolved to make us unhappy—it's profitable for us to be unhappy because then we'll go buy “solutions” for our unhappiness.

Ok that's everything, thanks Paul!

How to Choose a Startup to Work For by Thinking Like An Investor

Harjeet — Wed, 16 Jan 2019 00:08:42 +0000

I believe that most advice on choosing a startup to work for is wrong. Early employees at wildly successful startups suggest you assume the value of your equity is zero and instead optimize for how much you can learn. In this post I'll argue that evaluating how likely a startup is to succeed should actually be the most important factor in your decision to join one. As a former partner at Y Combinator, I know a lot about how investors do this. Now, as a founder and CEO of Triplebyte, I see how much less rigor the average job seeker applies to their decision and what they miss that investors would notice.

First you should be sure you really want to work at a startup. This is not the right choice for everyone. Paul Buchheit, an early engineer at Google, says,

“If you're happy working where you are, and you don't have any ambition to do anything else, you're probably going to get paid less and work more if you leave [for a startup]. If getting paid less and working more is unappealing to you, then I would recommend staying where you are!”

Joining a startup means giving up greater liquid compensation today for the chance of gaining other things that accumulate value over time. Things like personal networks, learning opportunities and equity.

You can learn new things and meet people working at any startup. However you will learn significantly more, build a stronger network, and accelerate your career trajectory much faster by joining a successful startup than an average one.

Successful startups attract the best resources in every category as they grow. They'll get the best investors, press coverage, and hire the best talent. The latter is especially important for your career. Initially, founders can only recruit talent from the limited pool of people who have the risk tolerance to join something early. As the startup succeeds, this pool grows and it becomes a magnet for the best talent. By joining early, you get to work alongside the smartest people and solve problems together without several layers of management between you.

It's also only by joining a successful startup early that you can get remarkably steep career trajectories, like Jeff Dean, Marissa Mayer or Chris Cox. Successful startups grow faster than they can hire experienced and qualified people to keep up with growth. This creates vacuums of responsibility, vacuums that existing employees who might be “under qualified” on paper can step in and fill. If you fill the vacuum well, you can keep repeating until you rise up into the highest levels of leadership of what will eventually become a public company. Even if you leave before reaching those levels, there's a halo effect around you now. Companies will roll out the red carpet to hire you, and investors will be keen to fund your startup ideas.

How To Choose a Startup

Once you've decided to join a startup, the first obvious thing to look for is any evidence that it is already succeeding. This is what investors do. Unfortunately, at the early stages there's usually not much data like this. When there is, one thing we learned at YC was not to be fooled by large absolute numbers. What matters most is the growth rate. A startup with $1 million in monthly revenue which has been flat for the past year is less exciting than one with $100,000 in monthly revenue that was at $0 six months ago. You care about the trajectory a startup is on, not just where it is at this moment in time. Joining Facebook in 2006 would have been a better choice than Myspace even though the latter had more users at the time.

Next, you need to evaluate the strength of the team and market. At the earliest stage, the team is just the founders. It's difficult to evaluate startup founders using traditional signals like college or work history. In fact, the kind of experience that looks good on a resume can be a negative signal for being suited to founding a company. Rising up the ranks at Google might mean you can only thrive in a well-structured environment working on a product with millions of users. Neither of those conditions apply to startups. However, it may also signal an outlying level of competence and competitiveness. Those are both good traits for a startup founder. That's what makes this so hard. There's not a single clearly defined shape of person you're trying to identify.

My advice would be to focus on how impressive the accomplishments of the founders are relative to their peer group and environment. Starting a company and convincing investors to invest is an accomplishment that contains signal. It contains more signal if achieved by a 19 year old college dropout from Milwaukee than a Stanford computer science graduate.

You also need to evaluate how well a founder understands the problem they're working on. Being an expert in the domain yourself makes this easy. You know exactly which questions to ask someone to call bullshit. If you're not, then take the approach of asking the founders to teach you about the problem they're working on. Be intellectually curious and see how well they can explain product choices they've made, how the market works, and who their competitors are. I particularly like asking what has surprised them since starting the company and which early assumptions turned out to be wrong. I would be suspicious if they claim every assumption turned out to be completely right.

Evaluating the relationship between founders is as important as evaluating the founders themselves. The top cause of startup death during a Y Combinator batch was cofounder disputes. We evaluated this very closely during interviews. We were looking for red flags such as talking over each other and disagreeing on important issues. It was a particularly bad sign if it wasn't clear who the CEO was. Likewise it was a bad sign if, when asked, one person meekly answered they were the CEO while the other glared at them. I'd recommend you request to meet the cofounders together to answer your questions so you can feel out this dynamic.

You can also get valuable data about the startup from the team that has been hired. They may know about any red flags or major issues the company is facing which the founders haven't told you about. This data is especially valuable because it is the hardest to get. Once you receive an offer, ask anyone you met during the interview to meet you for coffee. Then ask them hard questions such as, what are the biggest weaknesses of the founders? How have conflicts been handled? What major problems has the company faced thus far?

If you are an engineer, I'd also ask specific questions around how product ideas are generated and work is assigned. Do not look for a perfectly smooth and egalitarian process here. I believe early stage startups work better as benevolent dictatorships. You want at least one of the founders to have strong product opinions and be the final product decision maker. Early on, speed of action matters most to a startup, and decisiveness is a good trait in startup founders because it creates motion. Don't miss out on joining a great early stage startup because the founder seemed too opinionated and involved in product decisions early on.

You should also judge the quality of the product but don't always look for a perfect product. An imperfect product with bugs is fine if the team can explain why it still delivers a better experience than competitors. Moving quickly to launch software and sacrificing some amount of quality to gain users in a new or emerging market is a good strategy for a startup. This same tradeoff does not apply if the startup is in a crowded space with large incumbents who already have pretty decent products. Airtable is a good recent example of a product that has seen success launching in a crowded market by taking time to build and iterate on the product.

Next you need to evaluate how promising the market is. I won't cover how to do deep analysis of market size here. Estimating the true market size is an exercise composed of some parts rigorous analysis, guesswork, and persuasion. What is important is identifying the type of market the startup is in. There are two types of market for a startup. The first is a new market that is growing quickly e.g. blockchain. The second is an already known and large market with existing large incumbents e.g. real estate.

The type of market a startup is in should also impact how you evaluate the strength of the team and product. Being the first mover in a new and growing market has huge advantages which can cover up a lot of deficiencies in both the team and the product. If it is early enough, investors won't have funded many competitors yet. If you believe strongly in the growth potential of a market and find a startup that is currently in the lead you can afford to be more forgiving on the quality of the team and product. If the startup grows, both will be upgraded anyhow.

Operating in a market which is already known to be large and valuable will be less forgiving. There will be many well-funded competitors, and you'll need an exceptional team with access to capital and a correct vision for differentiation. Opendoor, for example, was not an average founding team. Co-founder Keith Rabois was an early team member at several startups that went public, such as LinkedIn, Paypal and Square. CEO Eric Wu had deep domain expertise after founding and selling a real estate startup.

Conclusion

Simply joining any startup won’t provide you with great learning opportunities or a strong personal network by default. A startup on a flat growth trajectory with a weak team offers neither. A consequence of this is being willing to move startups if the one you are currently at stops growing. I think startup employees should re-evaluate the growth trajectory of their startup every year. I’m conflicted in offering this advice. As the founder of a hiring marketplace, more people looking for jobs each year increases our market size. As the founder and CEO of a startup, I want my employees to stay with us for a long time and have faith during the inevitable rough patches.

There's a balance here. Every startup faces challenges, and if you're quick to jump ship you might give up a lot of upside. As a personal anecdote, my first startup was given an acquisition offer by Facebook in 2007. We declined in favor of taking another deal because Facebook seemed like a chaotic organization at the time with a lot of executive turnover and the conventional wisdom said it was overvalued. In hindsight, it may not have been a bad decision to join and stick through a temporarily turbulent time.

Predicting startup success is hard, and even professional investors fail at it most of the time. My advice here is intended to make you think more like them, in the hope that you'll build a portfolio of experiences over time that will maximize both your learning and your earnings. Good luck!

Thanks to Elad Gil, Ammon Bartram and Charlie Treichler for reading early drafts of this essay.