Dan Feldman, Starsky Infrastructure Team Lead: “In a start-up, you can have a million different careers”
Always interested in self-driving cars and passionate about start-up working culture, Dan made his way from software contracting to becoming the lead of the Infrastructure team at Starsky — a department that started with a simple idea by Dan a few years ago and resulted in a fast-growing team.
Dan, you joined the company as a software engineer in 2016, even before they got out of stealth mode. How did you start working with Starsky?
Back then, I was in the process of leaving my previous start-up in the trucking industry. I chatted with Stefan and Kartik and got immediately hooked on the idea of autonomous trucks with a teleoperations component. I was struck by how forward-thinking they were in terms of what they wanted to achieve with the company, and their market focus.
I think we had just five people back then. We barely had a vehicle to work on. There was a truck parked in the East Bay and we were just doing very basic stuff to get it working. I did some software contracting, helping out with the base layer of our system, like integrating with various sensors and all these very early-stage things. I built our first user interfaces and truck-startup procedures.
Since then, things have changed a lot. The growth that Starsky has achieved in the last three years is amazing — the company has doubled in size every six months. I like this crazy growth and the fact that you can have multiple careers within the company in three years. It’s really exciting. If you get bored working on one thing you can transfer and work on whatever is interesting because all this work needs to be done.
Not only has Starsky been growing throughout these years, but your role in the company has been evolving as well. Now you’re the Infrastructure Team lead. What is your team working on?
The infrastructure team at Starsky deals with all the tools and development that’s needed to actually make self-driving trucks, including testing, deploying, building, data infra, and simulation. After a truck drives, we need to understand what went right or wrong, and then figure out how to fix it based on that. A big part of our work revolves around this feedback loop. If we make this loop as tight and as fast as possible, great things happen.
The way it started was I got very frustrated as a developer on the vehicle dealing with our data. If you wanted to find what the wheel did at 7:00 PM last night, you had to download 40GB files and read through it all, the interface was very clunky. So, I tried to find a way to read through that where you only have to look at one part of it. As I built that up, people on the team started asking if they could use this data in a different way or build this kind of thing on top of it or replace this tool with another one. So, eventually, that became a full-time job.
One of the things we’re working on right now is the vehicle simulator. People want to be able to use old data. Let’s say someone drove a month ago and there were some problems with the drive. And they want to take the new code where they fixed that exact bug and play that old data through the new code. We run the simulator that allows people to do that.
Also, prior to building the data infrastructure and data analytics, I think one of the biggest things that the team did was building out the unit testing and testing pipeline. So, people could write tests for the software and run through the truck code and make sure that it worked really well.
Now, I don’t even remember how we developed before we had this testing pipeline and all those things that the infrastructure group works on. And, I think what really made the difference was the fact that myself and the early developers on the infrastructure team were themselves truck developers, so we knew the main pain points.
You know your work is moving the company forward when people feel they can’t live without what you’ve built!
You were involved in multiple projects related to self-driving technology and transportation long before Starsky. Even in high school, you participated in robotics competitions and designed self-driving vehicles. So, it looks like you’ve always been passionate about this technology. Where does this passion come from?
It’s funny, but I got into programming really early on because I wanted to cheat at some of the video games I was playing. So, I’d find some cheap way to kill monsters and level up faster but then it would stop working. I was like ‘How do I fix that?’ That was my introduction to computer memory and computer hacking. Eventually, I got more interested in how the hacking tools were built and started learning C++.
Then, in high school, there was a robotics team that was starting up to build a small self-driving car that would compete later that year in the RoboGames “Olympics of Robotics”. We needed to build and program a robot that could drive itself from a part of a park to a GPS location, tap an orange cone, and then go to the next one, and then the next one and finish up. We got a remote-controlled car, stripped out the remote-control stuff, put a computer in.
We worked on this for a couple of years, and then finally won second place in the competition beating out a lot of colleges. I think MIT beat us, but still, that was pretty cool as a high school group to be able to do that. By then I was pretty sure that I wanted to stay in computer science.
And… I think it was the first semester of high school when my friend was killed in a drunk driving accident. A drunk driver hit him while he was putting something back in his car. That was just the most senseless stupid thing ever. And I think it also affected my vision of what I could do with programming in some way. I realized that this is something I can bring to the world and do well. So, I ended up going to Berkeley and studied computer science there.
And then you got a chance to work with self-driving vehicles during your internship at General Motors?
Yes. During sophomore year, I was applying for internships. I got rejected from everywhere I was interviewing: Google, Facebook, and Microsoft. I got an interview at General Motors, and they took a chance on me. And I’m so happy I got rejected from all of those places. Otherwise I would not have interviewed at GM, and that experience was amazing.
I was on the active safety team, which is now the autonomous driving team. I had to make some changes to the vehicles and go out and test them on the test tracks. We received a lot of professional driver training where we were purposely spinning the car out of control and then having to recover. It was a fun internship.
Also, I did a lot of tours of interesting technologies GM was working on. One of them was a vehicle-to-vehicle and vehicle-to-infrastructure technology, which would allow cars to communicate with each other. This way, autonomous vehicles don’t have to rely on cameras and radars to know what the car is doing. Instead, they can say ‘Hey, I’m going to steer 30 degrees to the right, watch out behind me.’ I thought this technology was going to be amazing but found out that all the radio sensors that the GM lab was working with cost thousands and thousands of dollars, which was crazy.
I applied to the Y Combinator Fellowship program. What I wanted to do was take v2v technology and kind of open it up to hobbyists like myself as a high schooler. We were taking Arduinos and putting them on a remote-controlled car, and I wanted to be able to do the same thing with v2v tech. I started making a developer toolkit. But the difficulty of making it was high, and legislation that was going to force manufacturers to put vehicle-to-vehicle in their cars kind of fell by the wayside. So, I ended up pivoting while I was in the YC program.
So you had a chance to see how a big company like General Motors works and then most of your jobs were in start-ups. What do you like about start-ups?
Essentially, GM engineering was the opposite of what I ever wanted to do. As much fun as I had there, there was a lot of time where I was just sitting on my hands waiting for IT requests or for my manager to give me a project or fighting through red-tape to be able to get my work done. I totally understand why — it’s a large company that has to move slowly, and mistakes kill people, but I spent half my internship waiting on other teams. The bureaucracy was stifling.
I just wanted to avoid that in the future. When I was interviewing with bigger companies, I could see a similar kind of thing. There’s a sense that you can’t change processes and a lot of things are already set in motion. Whereas with Starsky, we could try a bunch of things. We can be wrong as many times as needed as long as we’re right eventually.
That’s what I love about start-ups. If you see something that’s going wrong, you go and fix it and maybe you’re the only one who can do that. That’s how teams are built and that’s how new products are made.
As long as you keep that culture of moving quickly, being curious and open to trying new things, you will have a million careers through it. And that kind of work culture is what I wanted to go for.
Starsky is actively hiring, and you are also involved in that process. What type of engineers is Starsky looking for in the first place? What skills do potential candidates need in order to get hired?
If you’re going to be working on any of the software on the truck, you need to have great programming skills in any capacity, whether you’ve been working on web applications, data pipelines, school projects that are non-trivial, or even your own products. Great programming skills will get you through the interviews and will also get you through the resume screen.
Most of the positions are pretty specialized. So, you’d have to demonstrate some work in those special fields. For instance, if you are trying to apply as a robotics perception engineer, you’d probably have had to work with some of the images or work in the computer vision space beforehand.
On the infrastructure and the platform team, it’s less specialized. We need good programming skills because we deal with either incredibly high scale work, or the mission-critical parts of the robot. So, there’s no room for error there. You don’t have to write perfect code, but you have to know how to iteratively get code into a production-grade state.
We’re looking for people who have some experience with writing tests or bringing a product from idea to deployment and maintenance, and who have seen some of the mistakes that you can make along the way.
To succeed at Starsky (and most start-ups in general), you’ve got to come in with a growth mindset, be ready to dig deeper and wider to do work outside what your job title suggests you do.
I may be an infrastructure engineer on paper, but the amount of other responsibilities sometimes dwarfs my main focus! Starsky engineers are flexible and open to ideas from anywhere, and that’s key to how we work.
What could you recommend to those who want to get involved in the autonomous driving space and become an AV engineer?
Definitely work on your own personal projects that are kind of related to it. If you want to build your own small robot, go for that. You will learn a lot about the troubles that come with robotics. There are some interesting things in robotics about real-time operating systems that are fun to explore and which will definitely give you an edge up in knowing about what’s going on.
Also, just having a level of curiosity about what robotics is, and maybe going off in a direction tangential to robotics and building something on the imaging pipeline side of things could definitely help you break in as well.
But overall, the background of the team — especially on the infrastructure side or the platform side — is very random. We have people who’ve worked on 3D printers or streaming technology for the NBA. I worked in web applications before. So really just diving deep into large projects and owning large aspects of that will give you success, not just at Starsky, but at any start-up.
***
If you want to join the Starsky team and help us get unmanned trucks on the road, please apply here.
