Ethan Swain (software engineering)
Ethan (he/him) worked as a software integration engineer intern with Rivian and Volkswagen in Vancouver, BC.
This photo was taken in the vehicle bay at the Vancouver office. Ethan is sitting in the driver's seat of a test vehicle with a diagnostic cable running from the On-Board Diagnostics port to his laptop, reading the messages the vehicle's computers send to each other.
Gaining diverse experience
Ethan spent eight months with Rivian and Volkswagen Group Technology and over that time he worked with three different teams.
"I started on a mobile software kit that was so early in its development that there was no established way to test it," says Ethan.
"Half of my job was working out what testing should even look like, alongside the developers who were building it. It was an unfamiliar position for someone used to assignments with defined answers, and it turned out to be the most useful thing I learned all term."
Partway through his work term, another team asked Ethan to help validate changes to the vehicle's navigation software in the run-up to a product launch.
"The pace was unlike anything in coursework," he says. "Every morning we'd find the day's new software builds, flash them onto a test bench, and while that was running, work through the five to twenty changes waiting to be verified that day. I was doing it alongside a colleague nine time zones away in Serbia, in a domain I'd known nothing about a month earlier."
"The software I helped verify is running in vehicles that are now on the road, which is not something I expected to be able to say after a work term," says Ethan.
Impacting real-world products
For the rest of Ethan's work term, he worked on vehicle access software that decides, in a fraction of a second, whether the person approaching a vehicle is genuinely its owner. It's the system behind unlocking a car with a phone or a key fob, and it has to be both reliable and secure.
"If it fails in one direction, someone is locked out of their own vehicle. If it fails in the other, that's a serious safety problem," he says.
"Most of my work was building the tools and simulations that test this automatically, so that problems get caught long before a vehicle reaches anyone's driveway. Part of that meant building a simulated version of the system that runs the real vehicle software without needing the physical hardware, which lets us test far more thoroughly and far earlier."
Leaving a legacy
Ethan also set up a process that will help future co-op students succeed.
"The contribution I'm proudest of is the least photogenic," he says. "Our automated tests run on rows of small Linux computers wired to test benches, and every one of those machines used to be set up by hand. It took days, and no two machines ended up quite identical, which meant tests would fail for reasons that had nothing to do with the software being tested.
I built a "golden image" (a perfected snapshot of an entire configured machine) that can be copied onto any new computer. Setting up a bench went from a multi-day job to a short, repeatable one, and every machine now comes out the same. I wrote the documentation for it too, which is how the next co-op student will learn to do this. That's the part that will outlast me. Every test bench built after I leave gets built with the pipeline I made."
Learning about himself
"The single best thing that happened to me was being moved between teams. I hadn't asked for it and I didn't feel ready. I was just getting comfortable when I got pulled onto something completely different. It was disorienting for about a week, and then it became the most valuable part of my term."
"The technical skills transferred far more than I expected. What didn't transfer, but instead accumulated, were the people: by August I knew three teams instead of one."
Advice to other students
"If someone offers you an unfamiliar problem, take it. I came in assuming I'd be judged on clever solutions. What actually made a difference was writing things down properly.
Documenting how to set up a machine so nobody after me had to rediscover it. At the time that felt like busywork. It's now the onboarding material for the next student, and it's the piece of my work that will still be in use in two years.
Co-op let me find out what kind of engineer I want to be, which is difficult to learn from coursework. I discovered I like infrastructure and I would not have guessed that about myself before this term.
It also gave me the experience of being trusted with real problems, on real products, with real consequences if I got them wrong. That changes how you approach your degree when you go back. I'd recommend it to anyone considering it, particularly if you're unsure what you want, because there's no faster way to find out.