What I Learned from Interning in Factory Software 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 and individuals.

I returned to Tesla in autumn 2021 for a second software engineering internship. I learned and grew a lot from my first stint, but I wanted to return and experience a different problem space within the company. This led me to the Core Automation Services team, where I got to work on Tesla’s lineside manufacturing execution system.

Like the last time, I had quite a bit of ownership over some very interesting projects, but this time I also got a crash course on manufacturing and the role of software in it. I also had the unique opportunity to work with people across multiple countries, since Tesla has a global network of factories. In hindsight, I now feel like a more mature problem solver, thanks to the support from everyone on my team and the level of responsibility I was given. I picked up many valuable lessons from this internship, but a few of them stand out to me in particular.

I. Understanding business context

Manufacturing is an extremely complex domain because there are a ton of different groups that are pushing initiatives forward, all of which need to seamlessly work together. Therefore, it’s critical for software engineers on my team to get a strong grasp of the business context behind a project, since we often play a role in said initiatives. For my team, this means answering questions such as:

• What’s the problem we’re seeing on the assembly line?
• Why is that problem occurring?
• What’s the current behavior of our software when the problem occurs?

I realized, after making some mistakes, that it’s important to seek out this context down to the smallest detail because there are so many moving parts when vehicles are being built that the software needs to account for. This helps ensure that the software will remain fault-tolerant.

Learning to understand the business context well helped me in a few ways:

1. I closely considered any requirements that I’m given, but I also began questioning and redefining them in case there’s a better approach.
2. I improved at analyzing implementation tradeoffs (storage, speed, code complexity, etc.) and defending my choices based on the problem at hand.
3. I got better at spotting and accounting for edge cases based on what could occur on the assembly line.

I also learned that business understanding is essential for prioritization. My team determines the importance of tasks by looking at what will help produce vehicles faster and with higher quality. This is crucial since everyone on the team is juggling many projects at once and we receive quite a few inbound requests from others. I recognized that it’s important to have a framework like this and to follow it when balancing multiple things.

II. Owning product as an engineer

My team operates like a small startup. Each software engineer is almost like their own PM, so they directly engage with stakeholders, incorporate feedback, and see their projects through to production. My team also makes an effort to not limit the scope of one person’s work, since the problem space that we operate in requires people to go above and beyond. This enables everyone to deliver results quickly, and it helps the engineers better understand the ins and outs of how our software works.

This way of work was far more cross-functional and self-driven than I was used to. I had engaged with test and release engineers in the past but never with process and quality engineers who have an entirely different scope of work. I also realized that these stakeholders are occupied by many different things at once, which meant it was often up to me to initiate critical conversations. Through my projects, I learned to be more proactive in collaborating with people than I was initially comfortable with. This was necessary for me to clarify my assumptions, remove blockers, and validate my work. After overcoming the initial learning curve from this style of work, I found that I enjoy a team culture where everyone owns everything and keeps a common north star in mind.

III. Learning on the fly

Many parts of this internship were new to me at the start. I had almost no prior experience with the team’s tech stack (ex. Golang, Kafka), advanced technical concepts (ex. concurrency), the manufacturing and automotive spaces, and being close to the hardware-software interface. I was used to picking up things on the go, but not to the extent that I had to for this internship. This pushed me to deal with a lot of ambiguity but, with consistent effort, I adjusted to the new environment and grew to enjoy it as well.

There were admittedly many difficult points while working through my projects, where I was uncertain about my ability to deliver. Looking back, this helped strengthen my problem-solving resilience, and I also felt very fulfilled when I finally did finish. I learned that, especially in an environment like Tesla, it’s important to be able to adapt quickly when requirements and priorities change.

Conclusion

My original reason to intern at Tesla again was to experience how the obstacles in a different problem space within the company are being tackled. In addition to achieving this, I improved at strategic decision making, iterating my work quickly, and applying new knowledge immediately. I also discovered a lot about myself: I enjoy being in a very fast-paced environment, having a lot of responsibility, and working in a hard-tech problem space. In the end, this internship proved to be uniquely rewarding in that I got to see my contributions to the software on the assembly line.

My biggest area of growth from this internship is that I became a more independent problem solver. I was given a ton of freedom to be creative and tackle open-ended challenges, instead of simply taking action items and mechanically completing them. I think the lessons I learned as a result of owning the entire development process, from getting business context to coming up with solutions and seeing one through, will be very beneficial down the road when working in another similarly challenging domain.

Interning on the Core Automation Services team was a huge privilege, and I’m grateful for every moment of the experience. I’m excited to see how my takeaways from these three months will benefit me down the road!