Shortly after graduating university, I decided to apply to all sorts of companies – big and small from coast to coast. I didn't know exactly what kind of company I wanted to be a part of, but one thing I did know was I wanted growth and new experiences. I remember being especially drawn to startups due to the diverse range of responsibilities I could dive into.
I started by browsing job postings on AngelList. I interviewed at companies of all sizes — from early stage to established companies. Lo and behold, I landed a job at a seed startup named Anvil as its eighth employee. It's already been two years since then, and while that sounds like a short time it certainly doesn't feel that way. I've experienced a great deal working in the startup environment and want to share some key takeaways.
1. Independence
Within the first couple of days I recognized the level of independence needed while working at a startup. This started with onboarding. In larger companies, the onboarding process may last several weeks with another engineer dedicated to helping you adjust. At a startup, however, onboarding is much less structured: read this document and here's a project.
My first task was to build a comprehensive integration test suite that was quick to run for our web app UI. I was given defined end goals, but it was up to me to determine the best course of action to structure and build out the tests.
I started by experimenting with the product and learning about its potential pitfalls in order to achieve good test coverage. I then proceeded to learn the testing framework's best practices. Only after would I start writing tests that cover common areas and known edge cases. To ensure the quality of my tests, I ran them repeatedly to check for flakiness, which would lead me to add some code in the app. To accomplish the secondary goal of making the tests fast, I configured the tests to run in parallel in our continuous integration (CI) pipeline.
Not every project has a clear approach, however. I've come across issues that involve many moving parts or code without documentation. I'd have to experiment with and read code from all parts of the codebase, which was part of the fun. While it's fun to spelunk through the code, it has taught me that knowing when to ask for help is crucial.
When I first joined, I wanted to be able to work independently and not be overly reliant on others. There have been numerous instances where a simple five minute conversation would have saved an hour of debugging. Balancing self-reliance and teamwork is an ongoing effort when you work at a startup.
Tasks may not be fully specced out, so to do the task well I needed to be comfortable wearing many hats, this includes scoping out pitfalls and making technical design decisions. It was difficult initially but building the ability to work independently is crucial. Asking the right questions, more intuitively understanding the relationships between pieces of code in different files, and structuring code to avoid foreseeable pitfalls are all aspects I've improved in to becoming a better engineer. One such example is knowing where to find a related helper function and adapting it to your use case instead of writing a completely new piece of code.
2. Flexibility
When I first came to Anvil, the engineering team consisted of six people, including myself. We didn't have specialized eng teams dedicated to objectives like growth, payments, web, etc. Instead, we all knew a bit of everything and how all of our code works.
A big reason I accepted the job was because I was given a lot of flexibility in deciding what I could work on. Startups are the ideal place for those who want to wear many hats. Of course, everyone still has their preferences for where they want to contribute most, but having a voice in deciding what projects I take is a huge source of motivation. The fact that I was given the opportunity to build a new PDF generation feature using Java when I expressed that I was looking for a new challenge exemplifies that.
Throughout the past two years I've built new UIs on the Anvil web app, I dove into generating PDFs in the backend, wrote integration tests, and created npm libraries for clients. I have written code in every part of the codebase and don't think I would have that opportunity if I had worked for a bigger company.
Another reason being flexible is key at early stage companies is due to the constantly evolving environment. Plans tend to be fluid as goals can rapidly change. This may be due to a shifting of go-to-market (GTM) strategy after experimentation, client requests, or unexpected bugs.
3. Ownership
With a small team, it's important for every engineer to take responsibility for parts of the code they've worked on. Other engineers will look to you for advice when dabbling in your area of expertise. This is the case in every other company, but at a startup you begin taking ownership when you start your first project.
For the first couple months, my focus was improving developer experience by building out the integration test suite. At a smaller company you may 'own' a huge chunk of the code. Whereas in big companies, you almost never hear junior engineers taking ownership in areas of the codebase. Usually they work on an already in-progress and supervised project.
In this case, I was given the opportunity to be the sole owner of integration tests and be known as the int test guy. It's pretty cool having senior engineers ask you questions and being able to confidently answer them because you wrote all of the code. The pace from onboarding to pushing code was accelerated and I was already making a meaningful impact within the first few months.
Now, in addition to covering integration tests, I take ownership of improving user onboarding experience and building requested features. Being deeply invested in what I’m building has led me to gain a better understanding of what needs improvement in the product, voice my opinion confidently, and ultimately become a more capable engineer.
Conclusion
Through my time at Anvil, I've realized that independence, flexibility, and ownership are vital characteristics that have helped me succeed.
Two years ago I wasn't sure how I'd contribute or where my strengths lie as an engineer, but I have since realized I'm very capable in transforming a nebulous product goal into a defined and fleshed-out feature ready for launch. I'm comfortable making hard design decisions when working independently, and it's clear when to ask for help when digging into a bug. Having many times released features that touch all parts of the codebase, I'm comfortable taking projects in areas I'm less familiar with.
I'm now an owner of large sections of the frontend code. I'm more cautious releasing code now that I'm more aware of how miniscule changes can lead to breaking bugs, after having developed a clearer mental image of how pieces of code interact with each other. My time here has accelerated my growth in all these areas.
Now that I'm more confident in my own abilities, I wish to invest into people around me and pour what I've learned into my fellow engineers when reviewing pull requests or discussing solutions. I'm also interested in taking ownership in more areas I'm particularly interested in.
I certainly don't speak for everyone, but I recommend taking on the challenge of joining a startup.
If you're interested in learning more about working at Anvil, reach out to us at hello@useanvil.com. We'd love to hear from you.