One of the vehicles at GM's site in Israel needed to run a computer it wasn't technically designed for yet. The platform was still in development, which meant every system in the car had to be adapted to work with it, one at a time.

Ben Rubin, Senior Software Engineer, made it happen.

"I adapted all of the vehicle's systems to the new vehicle computer and built the first vehicle in the world running that configuration," he said.

The result is the easy part. The more interesting question is why Ben was the one who could do it.

Ben is an integration engineer working on the camera systems drivers actually see. He got to that job without holding the same kind of role twice: testing software as a student, driving prototypes on the proving grounds, running simulations, then working on autonomous vehicle platforms.

None of that added up to specialization. It added up to range, which is the foundation for the job he has now.

Why he could fix it

The retrofit worked because of the years spent behind the wheel.

"As a test driver, I learned how to work directly with the vehicle's systems: flashing software versions, sending and reading Controller Area Network (CAN) bus messages, and using tools I still rely on today," Ben said.

A second problem affected the same case. An infotainment computer wasn't communicating with the rest of the vehicle, which slows down anything built on top of it.

"Solving it required deep knowledge of the vehicle architecture and tools most engineers in the camera group hadn't worked with," Ben said. He connected to the vehicle's internal systems, aligned the computer with the other modules, and cleared it.

Both fixes leaned on things he learned in earlier jobs, which is how his current one tends to work.  

What each experience gave him

Ben started as a QA student testing an application that connects to GM vehicles.

His current group builds camera features that link to that same application, which means he knows both the software and the people who maintain it. Integration gets easier when you have already met the system on the other side of the handshake.

Test driving put him alongside Research and Development, acoustics, and radar teams, and gave him something no simulation environment can.

"When you spend that much time on the vehicle itself, you develop a feel for where a fault is actually coming from: hardware, software, or the vehicle," Ben said.

It also let him experience the product as a customer does, enabling him to give feedback as a driver rather than an engineer. The most durable lesson was procedural: how to build a professional test setup in a vehicle and execute it on schedule.

Work in the autonomous vehicle group taught him how the vehicle platform operates and how cameras feed into it. This is a perspective few people in his current group had when he brought it with him.

The interface

"My role sits right on the interface between the vehicle's systems and the software," Ben said, and the examples are ones any driver would recognize.

Consider the dynamic guidelines that appear when the driver reverses. They bend as the wheel turns, so steering angle and vehicle speed have to stay in sync, and testing them means knowing how those systems align and how to troubleshoot when they don't.

Flip a turn signal and the relevant camera view appears on the display. Connect a trailer and a sequence of events unfolds behind the scenes to unlock advanced trailering features. Braking, EV charging, and the vehicle's communication systems all touch the same software.

None of that registers as engineering to the driver. It shows up as a screen showing the right thing at the right moment. 

Where the code meets the car

Ben is often the first person to see software leave the laptop and enter the world.

"Because I do the integration on the vehicle, I'm the one who sees the software our developers write actually running in a real car," he said. "I help them understand whether a feature works and, if it doesn't, what needs to change."

The cameras he works on matter in ordinary moments: parking, towing, and helping drivers see what’s around the vehicle. He calls that the part of the job he is happiest about, and it is the clearest argument for the path he took. Systems knowledge is what lets him tell a developer not only that a feature needs improvement, but where.

His advice for others

"This path isn't right for everyone. It takes real curiosity and the ability to teach yourself about vehicle systems that often have nothing to do with what you're working on right now."

If that describes you, Ben said, the assignment is straightforward and slow: "Build genuine depth in all three areas: software, hardware, and the vehicle systems themselves."

Ben changed jobs four times in nearly seven years and never changed employers. Each move brought him closer to the vehicle, and all of it shows up now in what a driver sees on the screen.

See where your engineering range can take you

Ben Rubin’s path is one example of how broad technical experience can translate into real-world impact. Explore engineering opportunities at GM, then meet more of the engineers shaping software-defined vehicles and connected experiences.

• Explore engineering roles at GM
• Read What early-career ownership looks like in software engineering at GM, a GM Israel engineering story.
• Read The engineer helping to build GM’s software-defined future, an engineering-focused GM News story.

Learn more about careers at GM by visiting Careers.GM.com.