Reflecting on a 3-month internship at Tesla

Disclaimer: the views and opinions expressed in this article are solely mine and do not reflect the views and opinions of Tesla or any other organizations or individuals.

In early January 2021, I started a software engineering internship at Tesla. I decided to take a quarter off from school for this opportunity, so I could experience what it’s like to work on mission-critical projects and have a tangible business impact. There’s a lot to do in a company that is growing as quickly as Tesla, so even as a second-year undergraduate, I was given a lot of meaningful responsibility. While this was certainly overwhelming to start off, my team and colleagues provided a great support network, and looking back I’m extremely grateful for everything I learned.

I spent some time thinking through the many lessons and areas of growth from my time at Tesla, and everything came down to four main points.

I. Real-world software development

Much of my prior programming background came from my coursework, hackathons, and personal projects. In many of my courses, all of the requirements and details were outlined beforehand, and I simply had to follow the instructions to write the code. I had a very strong hacker mentality for my projects since my main goal was to have a working solution.

Moving away from these paradigms of work presented quite a learning curve for me at Tesla. I learned how much more goes into software engineering than merely writing some code to build a feature or fix a bug, such as writing unit, feature, and integration tests; utilizing a CI/CD pipeline for testing and deployment, and monitoring the health and performance metrics in production. Other teams at Tesla also integrated with the user interfaces and backend gateway that my team was building, so everything we put out needed to be highly reliable.

Instead of simply fulfilling a set of predefined criteria through code, I found myself solving open-ended problems in a more exploratory manner. It was at this point that I began to notice the difference between being a programmer and being an engineer.

A lot of this certainly seems obvious in theory, but seeing it all happen in practice and doing several of these things myself was a huge learning experience.

II. Prioritizing the customer experience

I was on a backend engineering team, so the results of the code that I authored weren’t directly visible to customers. However, even though my code doesn’t affect what customers may see, it still affects what they experience. Therefore, I had to ensure that the projects I shipped did not cause any disruptions.

As a Tesla customer myself, I began to appreciate how many business-critical procedures occurred behind the scenes for a single transaction, something which is often taken for granted in the present day. Having been exposed to the complexity under the hood, I recognized that the simpler it feels on the customer’s side, the better of an experience they’ll have.

III. Effective teamwork

During my 3 months in the workplace, I observed how much cross-functional effort it takes to build software. Shipping a feature requires extensive collaboration between engineering managers, product managers, and engineers working on backend, frontend, QA, and releases. Each person’s work is part of a broader company initiative, so the whole team needs to be aligned on blockers, progress, approvals, and deadlines.

Since other people’s work depended on my progress (and vice versa), I had to improve at communicating my updates to my team in both spoken and written form, and I had to be more proactive about getting any updates I needed from my colleagues. And, since I wasn’t always working with backend engineers, I had to practice conveying complex technical ideas in a simple way. As I got better at communicating and collaborating, the development process became more iterative, since I quickly incorporated feedback and promptly worked with the right team member on any blockers. This helped me deliver results faster than before.

Like my first point, effective teamwork also seems like something that is obvious in theory, but putting it into practice regularly was a major area of growth for me.

IV. Running a global business

In his memoir That Will Never Work, Marc Randolph talks about the Canada Principle, a guideline that highlights what it takes to offer a company’s products and services in a new country. Some of the challenges he outlines are: translating content into a different language, accepting a new currency, adapting postage materials, and expanding communications to a new market.

Tesla has a lot of products (vehicles, supercharging, energy solutions, premium connectivity, servicing, etc.), which are available in different countries at different times. This brings a lot of business complexity due to the regulations, differing financial systems, and risk management requirements, all of which my team solved through software. For instance, one of the challenges my team handled was complying with PSD2, a regulation that requires multi-factor authentication to complete a purchase.

My time on this team allowed me to see the Canada Principle in action at a scale of over 30 countries. I gained a greater appreciation for the complexity of running a global business, as well as for the pace at which Tesla is scaling to new countries.

Conclusion

My time at Tesla was eye-opening in so many ways. I got to focus on a very unique set of software problems with the smartest and most driven people I’ve ever worked with. Going into my first day, I expected a heavy learning curve with the technical challenges that arise with Tesla’s scale. Without a doubt, I grew as a software engineer, but I’m also thankful to have developed a stronger system design mindset as well as better communication and teamwork skills. This internship was the most enriching learning experience of my life and, having witnessed first-hand how Tesla operates, I’m even more excited than ever to see the impact it has on the world.