Are you taking part in a hackathon as an engineer fresh out of college? Wondering if what you bring to the table is up to par with the industry? You might feel confident interviewing to work for the big corporations, but in the startup world, being successful takes much more than coding well.
Take this as a confidence booster as we share the traits that Edmond Lau (from Quip) thinks makes or breaks a good startup engineer. After being an engineer for all-stars like Google and Quora, as well as nimbler environments like Quip, Edmund can show us how to survive in two radically different landscapes.
Here’s his take on what makes an engineer indispensable for a startup:
What Qualities Make a Good Startup Engineer?
Not every good engineer makes for 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 excelled at his current job. We just thought he wouldn’t make a particularly good startup engineer.
Having spent many years interviewing candidates, as well as training and mentoring other engineers, I’ve found that certain qualities make engineers more likely to succeed within startup environments. Ultimately, these qualities stem from a few key differences in working at a startup versus a more established company. At a startup:
You have a higher surface area in terms of the product, software systems, team, and culture that you’re responsible for.
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 on your own strong, individual contributions. At a small startup, there might not even be a career ladder.
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 chunk 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 help you 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… you get the idea 1
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. Being able to quickly navigate large codebases and to hone in on the relevant portions becomes critical. Much of that ability comes from experience - in this case, from 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 there, 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 may not be code-related. It’s fairly common for a startup engineer to handle customer support, work with salespeople to scope the feasibility of a customer request, train new engineers, and perform 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. 2 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.
When evaluating most tradeoffs, ask yourself: “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 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. 3
4. A tool-building mindset.
Tools let you scale the limits of your most critical resource — 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 productivity multiplier.
5. A strongly generalist approach.
One exception where a specialist might get further is if you’re working in a niche, technical space (like a database startup) where deep expertise is required to be effective. Also, the more later-stage the startup, the more likely it’ll have 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, identify what’s 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 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.
If you notice, you’ll see that the other qualities 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 are also useful for engineers at more established companies; they just matter more at a startup, because time is more limited. Furthermore, lacking 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, and work on it.
This post was adapted from an answer I wrote on Quora.
For instance, I learned a lot about scaling engineering teams while at Google: What Google Taught Me About Scaling Engineering Teams. But at a startup, it’s important to be pragmatic about applying those lessons.↩
About The Author
Edmond Lau builds documents and messaging software at Quip. He's also writing a book called The Effective Engineer to share stories, lessons, and habits on how engineers can be more effective. Previously, he was an early engineer at both Quora and Ooyala and a search quality engineer at Google. He enjoys helping engineering teams to build good culture and practices and to develop onboarding and mentoring programs.