Note: Some technical details of my work have been left intentionally vague. This is because I signed an NDA, and I don’t want to get sued.
It’s 3 PM on a mid-August Friday in Fremont, California. Sunlight warms my face as I slurp down some doordashed ramen on the office patio - a plan B for my final team lunch, derailed by a production bug from last night’s release. Classes start on Monday, new grad recruiting is already underway, but right now I’m just enjoying my (second) last day as a Tesla intern.
Exactly one month later, that afternoon remains as fresh in my mind as it was when it ended, perfectly preserved to account for my procrastination in writing this reflection. Now that I’ve finally gotten around to it, allow me to impart some wisdom from my time at the coolest electricvehiclegiantbatterysolarartificialintelligencerobotics company in the world.
I completed two software engineering internships at Tesla. One in Summer 2023 and another in Summer 2024, returning to the same team. The team’s work focused on developing and maintaining critical internal tooling for Tesla’s supply chain, purchasing, and procurement. One of the first things I learned at Tesla is what many other engineers here would tell you:
Move fast, fail faster!
On day one, I was given the keys to design and develop what would eventually become a cornerstone feature in one of our larger applications. The feature was loosely described as “a system to ingest and store a high volume of CDC data for efficient visualization.” While there were some basic consistency requirements and load parameters to keep in mind, this was the basic idea. The ambiguity of this task meant that speed of iteration was critical.
There were a handful of approaches that were being considered, and I was to develop multiple proof-of-concepts for each of these to see which would meet the requirements while integrating best with the existing application. Over the course of the project, I built three distinct prototypes - one using a relational database, another using a document store, and a third based on a time-series database. Each iteration brought its own lessons, successes, and failures, and each helped narrow the path toward the final solution.
This entire process of building quickly to see what would go wrong taught me a lot about effective engineering. Failing faster meant being able to pivot or adjust sooner, ultimately leading to a more effective and optimized solution in less time. During this project, I also learned that:
Great engineers communicate well!
Imagine an extremely intelligent individual with subpar communication skills. They would no doubt be extremely productive on their own, but just as it is in computing, some workloads must scale horizontally. In such cases, this metaphorical distributed system of engineers should not be capped by network bandwidth. I say this because the engineers I worked with were all exceptional communicators!
I’d be lying if I said these internships were always was a walk in the park. The biggest challenge was getting up to speed with the multiple, large codebases we maintained so that I could meaningfully contribute. While there was some documentation, a handful of our applications were so specifically tailored to Tesla operations that at times, the best solution was to just talk to the person who made it.
Whenever a nontrivial question came up while reading code or documentation, a brilliant engineer (sometimes on an entirely different team) was always just a ping away. Again, what impressed me most was their eloquence in deconstructing and explaining these complex systems. These individuals taught me that high performing engineers optimize everything - especially their communication! The third lesson I learned was that:
Repetition breeds optimization!
By the time my second internship rolled around, I had grown more comfortable with the codebase and workflows, and took on more day-to-day developer responsibilities. With this came some repetition, but also a myriad of opportunities for optimization. I got much more familiar with the debugger, marking the end of my sole reliance on print statements. Mastering keyboard shortcuts led to a massive productivity boost as well, allowing me to become one with my laptop as I carved through code with newfound efficiency. (I’m no Vim master yet, but that’s on the agenda.)
The biggest lesson that repetition taught me was the value of building on existing solutions. Instead of reinventing the wheel, I learned to fully leverage our frameworks and internal libraries. Each repeated task became an opportunity to streamline my approach. By the end of my second internship, I had built a set of strategies that allowed me to work more efficiently, confidently, and with fewer errors. Lastly and most importantly:
Do great work.
I conclude with this point as a call to action for both myself and you, dear reader! Being at Tesla for two summers put me side by side with some of the most cracked people I’d ever met. Day in and day out, I was challenged, mentored, and inspired by those who were better than me. I learned what it felt like to fail and get back up, to bring out the best in others, and to do truly great work. I believe that doing such work is our responsibility - a calling from our Creator to cultivate and steward the unique talents entrusted to us.
With that being said, I’ve grown increasingly curious of what lies beyond, and have decided to branch out. In pursuit of ever-widening horizons, I hope to test my software engineering mettle in distant realms of other industries, new technologies, or perhaps an endeavor of my own. Maybe one day I might find my way back to Tesla, but in the meantime - there’s great work to be done.
