Triplebyte Blog

We help engineers join great companies
Try our coding quiz

Share this article

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

By Harj Taggar on Jan 17, 2019

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

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!

Get offers from top tech companies

Take our coding quiz

Liked what you read? Here are some of our other popular posts…

How to Interview Engineers

By Ammon Bartram on Jun 26, 2017

We do a lot of interviewing at Triplebyte. Indeed, over the last 2 years, I've interviewed just over 900 engineers. Whether this was a good use of my time can be debated! (I sometimes wake up in a cold sweat and doubt it.) But regardless, our goal is to improve how engineers are hired. To that end, we run background-blind interviews, looking at coding skills, not credentials or resumes. After an engineer passes our process, they go straight to the final interview at companies we work with (including Apple, Facebook, Dropbox and Stripe). We interview engineers without knowing their backgrounds, and then get to see how they do across multiple top tech companies. This gives us, I think, some of the best available data on interviewing.

Read More

Bootcamps vs. College

By Ammon Bartram on May 19, 2016

Programming bootcamps seem to make an impossible claim. Instead of spending four years in university, they say, you can learn how to be a software engineer in a three month program. On the face of it, this sounds more like an ad for Trump University than a plausible educational model.

But this is not what we’ve found at Triplebyte. We do interviews with engineers, and match them with startups where they’ll be a good fit. Companies vary widely in what skills they look for, and by mapping these differences, we’re able to help engineers pass more interviews and find jobs they would not have found on their own. Over the last year, we’ve worked with about 100 bootcamp grads, and many have gone on to get jobs at great companies. We do our interviews blind, without knowing a candidate's background, and we regularly get through an interview and give a candidate very positive scores, only to be surprised at the end when we learn that the candidate has only been programming for 6 months.

Read More

How to pass a programming interview

By Ammon Bartram on Mar 8, 2016

Being a good programmer has a surprisingly small role in passing programming interviews. To be a productive programmer, you need to be able to solve large, sprawling problems over weeks and months. Each question in an interview, in contrast, lasts less than one hour. To do well in an interview, then, you need to be able to solve small problems quickly, under duress, while explaining your thoughts clearly. This is a different skill. On top of this, interviewers are often poorly trained and inattentive (they would rather be programming), and ask questions far removed from actual work. They bring bias, pattern matching, and a lack of standardization.

Read More