Not every good engineer makes a good startup engineer. Some of the most promising candidates that I’ve interviewed in the past six years across three startups (Ooyala, Quora, and now Quip) would bring 5+ years of experience from a top engineering company like Google, only to do poorly during our interview processes. Usually, the candidate wasn’t a bad engineer; in fact, he might have even excelled at his current job. We just thought he wouldn’t make a particularly good startup engineer.

Having spent many years interviewing candidates and training and mentoring other engineers, I’ve found that certain qualities do make engineers more likely to succeed within startup environments. Ultimately, these qualities stem from a few key aspects of how working at a startup differs from working at a more established company. At a startup,

1. You have a higher surface area of the product, software systems, the team, and the culture that you’re responsible for.

2. Your success depends much more on the team’s performance than your own. At a larger and more established company, you might get promoted up the career ladder purely based on the strength of your own individual contributions. At a small startup, there probably isn’t even a career ladder.

3. Time is more critical, both because startups often have yet to reach profitability and because agility is their main advantage against entrenched competitors. The limited time means that you have to ramp up quickly and don’t have the luxury to dilly-dally or work on the wrong priorities for too long.

The most effective startup engineers that I’ve worked with have the skills and decision-making abilities to effectively navigate this landscape. In particular, they exhibit some combination of these 7 qualities:

1. Systematic debugging skills. A large fraction of engineering time is actually spent debugging and understanding what’s going on within a complex system. A customer reports an urgent issue, and you have to fix it ASAP. The server’s CPU load spikes, and you have to figure out why. Data gets corrupted, and you have to identify the culprit. Good debugging skills enable you to get things done faster.

   Effective debugging requires adopting a rigorous, scientific mindset toward problems: formulating a hypothesis about what went wrong, and then figuring out the most efficient way or a minimal reproducible case to test that hypothesis. The other part involves being fluent with a wide range of tools: a profiler to help identify bottlenecks, a debugger to step through code execution, git bisect to narrow down the cause of a regression, UNIX command-line fu to slice and dice what’s happening. ¹

   The theme of debugging applies more broadly than just the technical realm, however. Growth and usage for a product have plateaued—how do you formulate and test hypotheses about user behavior and debug those trends? The team’s not hitting their project targets—how do you debug whether the root cause is poor project estimation skills, insufficient team communication, too much context switching, or something else? Recruiting isn’t leading to as many engineering hires as you’d like—how do you debug whether the problems are in your sourcing pipeline, your interviews, your closing pitches, your offers, etc.? (Hint: Start with the data).

2. Fearlessness to dive into what you don’t know. As a startup engineer, you often need to dive into large and unfamiliar codebases. You might need to dig through the code of an open-source tool you’re using because the tool isn’t behaving as desired. Or you might need to understand another teammate’s code because he doesn’t have the time to modify it. The ability to quickly navigate large codebases and to hone in on the relevant portions becomes critical. Much of that ability comes from the experience of reading a lot of code. The other part comes from being familiar with tools to search the codebase, jump to relevant portions, and look up relevant commit history in version control—all of these shortcuts can reduce the time it takes to understand unfamiliar code. This fearlessness can help at more established companies as well, but you can often succeed by just specializing in one part of the codebase and knowing it really well.

   The unknown pool that you’re diving into need not be code-related, however. It’s not uncommon for a startup engineer to handle customer support, work with salespeople to scope the feasibility of a customer request, train new engineers, and many other tasks that you might not be familiar with. Adopting a growth mindset during those experiences is important to doing a good job.

3. A pragmatic attitude toward decision-making. Being a stickler about ostensibly good software engineering practices like code reviews and unit tests might be important at larger companies to help the organization scale. ² But at a startup, it pays to be more pragmatic in your tradeoffs and to do what enables the team to get things done faster. Pragmatism means knowing when to fight important battles, and when it’s better to accept a decision even when you don’t agree with it so that the team as a whole can make progress. I’ve seen wars get waged over coding styles—over whether lines of source code should have 80, 100, or 120 characters and whether curly braces should start on a new line. But there are ultimately many harder and more important decisions to spend your time and energy on.

   The guiding heuristic for evaluating most tradeoffs should ultimately be: “What course of action will ultimately increase the probability that the team succeeds?” Many factors may feed into that question: product choices, architecture tradeoffs, team culture, people, and more. But many also don’t. The best course of action for those that don’t might be to limit the discussion time, commit to a decision, and move on. ³

4. A tool-building mindset. Tools let you scale the limits of your most critical resource—your time. Effective engineers build a lot of tools, which is even more important at startups where your time is even more limited relative to how much needs to get done. Larger organizations might have dedicated tools teams to help engineering teams be more effective. At a startup, the more capable that you are as a tool builder, the more of your manual tasks that you can automate. If those tools get adopted by other team members as well, then that’s another big multiplier for productivity.

5. A strong generalist. Particularly in the early stages of a startup, a lot of the problems faced won’t require a specialist’s knowledge. The broader your skill set—even if it’s just a minimal, working familiarity with a diverse set of skills—the fewer bottlenecks you’ll find on your execution path. A frontend web engineer who has some basic server skills will be able to more effectively hack together prototypes, without being blocked for help from busy server engineers. A backend engineer with basic HTML, CSS, and Javascript skills can throw together a web interface in front of a tool that she’s built so that more team members can use it, without being blocked on a web designer. A growth engineer who’s fluent with the basic data analysis tools will be able to analyze the experiments she’s running without being blocked on a data analyst.

   One exception where a specialist might get further is if you’re working in a niche, technical space, such as a database startup, where deep expertise is required to be effective. Also, the more later-stage the startup, the more likely that there are sufficient people filling specific roles that you can afford to specialize and find others to help.

6. A desire to be a player and not a victim. In his book Conscious Business, Fred Kofman describes two attitudes that we can adopt toward any problem. We can either be victims and blame any problem (a slipped project deadline, a product launch that flops, or conflicts with teammates) as being due to external circumstances. Or, we can be players, and identify the aspects that are within our sphere of influence and focus our energy and efforts toward what we can actually affect and fix. The victim mindset may make us feel better in the short-term, but ultimately adopting a player mindset is the only way to productively make progress.

   Working at a startup can be stressful. With the high levels of stress, it’s easy to fall into a blame game, dodging responsibility rather than taking personal accountability for the parts that were under your control. Unfortunately, that path will only lead to disappointment and resentment.

7. Grit, combined with a willingness to learn and retrospect. A key observation about the other qualities is that they are all learnable skills—assuming that you’re motivated enough. The long-term motivation to learn these skills comes from a quality called grit. Angela Lee, in her TED talk “The key to success? Grit” gives a great definition:

   Grit is passion and perseverance for very long-term goals. Grit is having stamina. Grit is sticking with your future, day in, day out, not just for the week, not just for the month, but for years, and working really hard to make that future a reality.

   If you’re willing to invest the time to regularly retrospect, you’ll understand what you’re weak at and where you need to improve. With time and experience, you’ll become a better startup engineer. A bit of mentoring and guidance early on to nudge you in the right direction can also go a long way.

These skills would all be useful for engineers at more established companies as well; they just matter more if you’re at a startup because time is more limited. Furthermore, a lack of these skills doesn’t necessarily mean that you’re a bad engineer. It just means you might be less well-suited right now to a startup environment. But if you’re determined to be a good startup engineer, don’t let that stop you. Figure out a plan of action to improve on these skills.

This post was adapted from an answer I wrote on Quora.