Originally published in Ramp’s Emerging Talent Blog here
Introduction
During the summer of 2023, I had the opportunity to intern at Ramp. As a student from the University of Waterloo, I had the fortune of trying out internships at various companies, but Ramp was the most unique and challenging company that I ever worked at. Interning at Ramp felt like an inflection point in my career. In this post, I will share my experience interning at Ramp, how it changed my perspective on software engineering and ultimately led me to return back to Ramp as a new grad engineer.
My Time as a Growth Engineer Intern
For most of my college internships, I was working on backend engineering at large companies. These taught me the fundamentals of writing good code and how to design scalable systems, but I wanted to learn how to operate at a hyper-growth company for my last internship. When I mentioned my interest to a few of my seniors, one of them mentioned Ramp. Through meeting the people in my interview loops, I knew that this would be the perfect opportunity to push my engineering abilities to the limit.
I joined a growth engineering team focused on accelerating our outbound sales channel. The systems that this team builds accounts for a sizable portion of our sales volume and contributes to our industry-leading customer acquisition costs. However, this team was extremely different than any other engineering team that I have been on for a few reasons:
1. Fast experimentation is king: To really succeed in growth engineering, you have to be willing to build experiments, quickly determine if the experiment is working and then decide whether it is worth building out a system to make the growth strategy work at scale. This is quite different from regular engineering projects, where we already have a problem in mind and we think about edge cases, scalability concerns, write out thorough specs and ensure that correctness is met. This was a big shift in engineering thinking for me.
2. Ownership: as a growth engineer at Ramp, I wasn’t just responsible for writing code. I was responsible for monitoring north star metrics & input metrics, designing experiments that would help drive better results and analyzing these experiments. The team was built like this by design so that each individual could be an independent operator that was only limited by their own bandwidth. Indirectly, this gave me a huge amount of exposure to the business of Ramp and our own sales processes. I never experienced this level of ownership anywhere else during my internships.
My time on this engineering team pushed me to levels that I had never dreamed of reaching while I was an intern. Some projects that I worked on include:
- Optimizing calls to third party data enrichment services to reduce costs for our system
- Implementing various AI-driven tools for outbound sales folks
- Driving better engineering practices in growth code, such as implementing common observability patterns and setting up monitors for our third-party services
- Competitive intelligence projects
This was by far my most impactful 4 month internship and it forced me to grow in new and uncomfortable ways as an engineer, exactly what I was seeking in my last internship. While there were a lot of lessons I learned specifically related to growth engineering, my exposure to working at Ramp also taught me some crucial lessons:
1. Speed matters: Joining Ramp, I realized why velocity is paramount in our culture. Jay Sommers summarizes this best in his blog post “Speed Matters”, “If there’s something you want to do a lot of and get good at…you should try to do it faster.” Ramp is in the business of building beautiful financial automation software for customers and velocity helps us determine whether what we are shipping is worthwhile. By shipping quickly and working on feedback, we can get better at shipping products. This virtuous cycle is crucial for the company to get better.
2. Iteration is better than perfection: During many of the projects that I led, there were always quick solutions that did not address all edge cases and there were perfect solutions that would take some time to build out. If we could afford to, we always chose to go with the quicker solution. The process of building out a system is not valuable; customer feedback is.
3. Think before full-sending: While velocity and iteration are core values of Ramp’s culture, it doesn’t entail shipping sloppy projects. We set a high bar for ourselves and made sure that we can both ship quickly and ship quality work. This necessarily meant thinking through edge cases and working extra hard, but this gave interns like me a better opportunity to learn the fine details and prevent costly mistakes.
For all the intensity of the engineering culture at Ramp, I was pleasantly surprised by the kindness and humor of my teammates and the rest of the folks at Ramp. I had such a good time meeting new people at happy hours, going on impromptu dinners with fellow interns and sharing laughs with my team as we built out new capabilities onto our growth system. My summer internship at Ramp was genuinely one of the best internship experiences to date.
Why Did I Decide to Come Back?
While my experience at Ramp as an intern was unparalleled, I wanted to make sure I was taking the right decision when contemplating other options. I decided to use a mental model of a skill stack to make this decision.
I figured that every company specializes in particular skill stacks. Some companies can teach you to be extremely technical in a particular area. Others can teach you to be customer obsessed. Some focus on building intuitive software. If none of the companies offer a skill stack you want to get better at, then you could build your own skill stack working at early-stage startups.
Ramp’s skill stack is extremely clear: it was an opportunity to up-level my ability to ship beautiful software at speed. Out of the other options I had, I felt that this skill was the one that I really wanted to get better at. It also helped out a lot that I greatly enjoyed working with the people. After a couple of weeks of reflection, it became clear to me that returning back to Ramp as a new grad was probably the best for me.
New grad engineering on the procurement team
I decided to return to a different team to try out a new challenge as a new grad. After my time working with a couple of different teams during my internship, I was pretty confident that Ramp’s culture is quite similar across most teams, so I would probably have a good time at any team. After talking with my recruiter and a couple of friends, I decided to join the procurement team, one of Ramp’s newest product lines. I mainly wanted to work on a brand-new, growing product line that would offer me lots of space to lead projects. Procurement perfectly fit my checkboxes.
In typical Ramp fashion, I was thrown into projects within my first week of joining the team. One of the projects I joined was matching card transactions to purchase orders, opening up a new way to track spend against procurement requests. Since August, I have been involved in numerous projects and entrusted to lead a few, mirroring the level of ownership I had in my last internship.
Procurement has been an absolute blast to work on and I am really looking forward to building out more features for this rocketship!
Tips for interns returning as new grads
Full-time software engineering is a slightly different ball game than being an intern. Here are some tips that I got that helped me transition into the role:
1. Gain as much context as fast as possible: Interns are usually focused on a couple of projects and often have a narrow view of the system that they worked on. This can be a limitation as engineers work on broader systems that sometimes span multiple teams. There are a couple of surefire ways to gain this context quickly:
- Review code: This was the fastest way for me to gain context. Seeing how new code paths are created not only gave me a great sense of the broader system, but also gave me some context on engineering tradeoffs and unique team coding styles.
- Get involved in operational incidents: On-call work is often a scary black hole for new grad engineers, but the fear stems from unknown unknowns. Shadow your team’s on-call as soon as you can. Doing so can help you understand how engineers debug code paths and how to lead various people to resolve an incident. This can give you a huge amount of context on tricky parts of a system
- Keep a list of dumb questions: I found this incredibly helpful as I onboarded onto procurement, a world which can have some jargon. During any meetings, I would write down anything that confused me and set aside time to hash it out with coworkers and my manager.
2. Start thinking about maintainability: One of the nice things about being an intern is that you don’t have to worry too much about how your project will perform after your internship. While this shouldn’t excuse sloppy engineering, it often means that maintainability and long-term thinking are not as heavily prioritized.
As a full-time engineer, you may be the person dealing with the repercussions of a bad decision many months down the line. It’s crucial to slow down and think whether it is worth trading off velocity in the present for maintainability in the future.
3. Take initiative: As an intern, we are often given a known problem and asked to go solve it with a particular plan in mind. Full-time engineering requires solving far more nebulous problems that require thinking through certain tradeoffs. Practicing the skills of identifying problems, prioritizing them, creating a methodical plan and tackling the plan with velocity is incredibly important to prioritize in full-time engineering. I am extremely grateful that I got the opportunity to do so on the procurement team.
Working at a company that is growing at break-neck speeds is a tremendous challenge and yet a special place to work as it pushes you to your limits. It is a very special opportunity to hop on this train and get to work on some of the most exciting features in the financial automation sphere.