Producer’s note: Someone on Quora asked: How do you compare working at an established company like Facebook/Google and a promising startup like Dropbox/Quora, especially for a fresh graduate? Here is one of the best answers that’s been pulled from the thread.
Whether joining an established company or a rapidly growing startup will help you learn faster depends on your own preferences and comfort level. There are a number of different facets to consider.
1. Training and Mentoring
Google’s invested a significant amount of resources to create codelabs that explain how core abstractions are used and why they exist, guides that compile the best practices for different programming languages, and design docs that explain the rationale and details behind major pieces of infrastructure. I joined Google’s search quality team right after graduating with my Master’s, and I learned a great deal in my first six months from soaking up all these materials. If you’re curious and motivated to learn, there’s a huge library of knowledge available to you and many ways to use those resources to improve your programming skills.
A startup won’t have the same volume of resources, but any fast-growing startup that wants to help new hires ramp up as quickly as possible will also invest in creating similar training resources. For example, at Quora, we write our own codelabs to help new hires learn key abstractions, document most of our processes, infrastructure, and best practices on our internal instance of Quora, and assign a mentor to each new hire who’s tasked with making sure he or she is ramping up effectively and getting integrated into the team during the first eight weeks. In contrast, my initial mentor at Google did not do much more than show me to my desk on my first day.
There’s a saying among Googlers that it takes 6 months to ramp up at Google and become productive. An established company like Google might be able to afford that time, but startups don’t have that luxury. We need our new hires to be productive after their first few weeks, and we’re working hard to make sure we hire the right people and havein place to make that happen.
Needless to say, startups work at a much faster pace than established companies. Pre-commit code reviews, weekly, biweekly, or even monthly release cycles, launch checklists, and formalized product approval meetings are all mechanisms and processes aimed at creating structure and minimizing breakages at larger companies, but often at the cost of development speed. Continuous deployment (where every commit can go to production), post-commit code reviews, and lighter-weight approval processes at startups aim to allow for quick iteration while providing for basic quality control.
Working at a startup doesn’t have to mean that you’re making it the focus of your life, but do expect to work longer hours than Google’s 40-hour work week and do expect to have it be an important focus area. A high-energy startup atmosphere may be more stressful at times (like when the site breaks) but also more exciting, with more features launching more often, and this type of variance and environment only appeals to certain people.
I imagine this is still true, but back when I applied for Google in 2005, the norm was not to assign new hires to teams until they’ve already accepted their offers. With a company of 30K employees, the variance of technical ability among engineers and leadership ability among managers is actually quite high, and the hiring bar necessarily needs to drop to support hiring at that scale. You might get assigned to a strong team or a subpar one; unless you negotiate for particular teams, this really depends on the focus area and the luck of the draw. In contrast, at a smaller startup, you’ve actually already met a significant fraction of the team through interviews and have a good sense of the technical abilities of people you might work with.
Adding to this team aspect is the significant amount of friction that exists at established places like Google for switching teams; the typical expectation is that you’d stay on a team for at least six months to a year. Your initial team, project, and manager assignment therefore end up significantly impacting your career growth and work happiness despite being relatively out of your control (again unless you proactively try to get yourself onto a good team before you join the company).
While project choice may or may not be outside of your control at a startup, the faster startup pace means that even if your initial project doesn’t turn out to be interesting to you, you’ll likely be working on something else in a few weeks anyway.
4. Project Structure
At Google, you’re likely to focus on specific areas for longer periods of time with the same team of people. For example, I worked on query refinements my first year and UI experiments around search sessions and search history during my second. This can be great if you have a specific area of interest and get hired specifically for that area or if you’re someone who wants to focus in-depth on particular areas. Projects at established companies tend to be more structured, where you have more guidance on what to do day-to-day from your tech lead, product manager, or manager.
Whether this is true at a startup depends on the team structure of the specific startup. At Ooyala, which grew from 30 to 70 employees while I was there, I spent a year as the tech lead of analytics and focused almost exclusively on analytics for that year. One aspect of Quora I found that I really enjoy is that teams revolve around projects, and most projects tend to last on the order of weeks. In my year and half at Quora, I’ve had opportunities to work on signup conversion, machine learning for answer quality, moderation tools, topic groups, recommendations and relatedness metrics, spam detection, and various user growth initiatives. The variety of projects I work on and the larger number of team members I get to work with add to my work fulfillment and happiness.
At a startup, you’ll likely be taking a pay cut compared to Google in return for more equity, but at post-series A companies, there’s really no risk that you’ll be living out of an office apartment or needing to resort to eating ramen. There’s certainly a risk that the startup might fail, but at an established company, there’s a similar risk that the project you’re working on might go nowhere or get canned as well.
Google shuts down a number of projects every year, particularly after Larry’s become CEO, and many projects never launch after months or years of work. If you’re in Silicon Valley and you’re a strong engineer, demand for engineering hires is so high that it’s really not too hard to find another job if you really needed to.
6. Impact and Influence
Given that there’s a much smaller team working on a much higher surface area of product features at a startup, you’ll end up wielding significantly more influence at a small company than a larger one. When I worked on UI experiments at Google, any visible change (even experimental ones) had to go through a weekly UI review with Marissa. At a startup, you’ll likely be making many decisions by yourself or with your immediate team.
This influence applies both at the product level (what to build or not to build and how to build it) and at the team level (how to do recruiting and interviews, what programming practices we want to encourage, how to organize team priorities, etc.). It’s much harder to exert nearly as much influence at a place like Google since many practices have already been firmly established.
A startup can’t really compete with having 20 on-campus cafes, a tennis court, a bowling alley, or some of the other perks. Depending on your team at Google, you might be able to travel to different offices across the globe for work.
But that doesn’t mean that at a startup like Quora we won’t try to make work more fun with concerts, karaoke, movie nights, board game nights, Giants games, annual ski trips, running races, or ultimate frisbee.
The high density of startups in Palo Alto, Mountain View, and San Francisco means that there are frequent startup events (parties, barbeques, networking events) as well as popular cafes where you can often bump into other people working at startups. If you’re considering founding your own startup in the future, working at one gives a good opportunity to join in the startup scene. It’s a little harder to find similar networking opportunities at Google.
An ability to dive into foreign code bases, understand them, and modify them, and the foresight to build tools to help yourself iterate more quickly will get you really far in a startup. At a place like Google, you can count on there being specialist teams to configure databases to run faster, fix compiler bugs, create build tools, and monitor production services. At a startup like Quora, you might be tasked with figuring out how to do it. Of course, we’ll still consult with the right third-party experts when necessary for help, but the responsibility still ultimately falls on you.
Established companies like Google obviously operate at a significantly larger scale, serving billions of queries and crunching petabytes of data per day. You’ll get to write MapReduces that run computations over thousands of machines, and there are few opportunities to do that at other places.
Most startups nowadays use Amazon Web Services, and there’ll probably be opportunities to use Elastic Map Reduce or spin up many machines, but it’ll be at orders of magnitude smaller scale. That said, you don’t need to operating on a scale of billions to feel that you’re making a big difference.
What choice makes more sense depends on you. I will say that personally, having worked at both a big company like Google and smaller startups like Ooyala and Quora, I find it hard to ever go back to a bigger company that doesn’t move as fast as Quora.