DanFeldman

Starsky Robotics (YC S16) | Software, Sr. Software, Internships, All Robotics Positions, ML | San Francisco, CA | Onsite, INTERNS, VISA | Full-time

Come build self driving trucks! Starsky Robotics is a fantastic place to work, we're solving hard problems across the board and need help. We have positions open for all sides of the robotics stack, and are specifically looking for more Software eng. maturity for the Teleoperation stack. I personally work on the Infra side and am looking for extra hands on our data, simulator, and fleet management infrastructure. Interns welcome to apply as well! We have priority positions open for Perception, SWE Teleop, Controls, and Safety Validation.

Earlier this year we drove our truck with no one in the vehicle on a public highway in Florida, see video [1].

We recently opened new Software positions across all Truck systems.

Blurb:

We're working to make trucks autonomous on the highway and remote controlled by experienced remote drivers for the first and last mile. Our self driving trucks will make roads safer while giving drivers meaningful work close to their homes and families.

We currently run our trucks autonomously on the highway, with freight. We are looking for awesome engineers who are comfortable working on a scrappy, driven engineering team.

We use Python, C++, and lots of bash scripting. We are a group of PhDs, masters, bachelors, and college dropouts with a diverse set of backgrounds. We're looking for folks with experience building and shipping products and a history of diving excitedly into new fields. We can sponsor visas. All positions non-remote unless otherwise specified.

Apply online, every application is read: https://jobs.lever.co/starskyrobotics/ or email me (daniel + @<company_name>.com) with any questions, but do not send me your resume (please apply instead online).

[1] https://www.youtube.com/watch?v=UCNSZKXvi64

Very useful! I ran into the issue Early Decision might solve when I was interviewing for the YC Fellowship program. Our interviews were 2-3 days before my fall semester was to start. I had, at best, a 24 hour turn-around time between getting accepted and going on school-leave. Very little time to weigh the decision to join or not, and logistically stressful getting all the documents in order to make sure I didn't incur tuition costs for a partial semester.

He and his team created Stackoverflow, a site used by every developer every day. He's a prolific writer around software engineering & managing software engineering. He's got an incredibly blunt writing style w/o any fluff and his writing on topics such as interviewing, refactors, and technical debt are shared around often.

FWIW, Brex also offers this. I use my corporate card and immediately get a text reminding me to snap a picture of the transaction.

However, it almost never correctly identifies the transaction on the card and pings me immediately with another text "Could not match a transaction". I usually just ignore that though.

Yes, it was a pain for everyone when we had no tests in the early days (REALLY early). My main point to the OP is that you still get benefits with CI/CD for compiled projects if you only build during integration. We now have a very healthy test suite and workflow 2.5 years later.

It's ok to start small and not boil the ocean immediately when jumping into modern ci/cd workflows.

I disagree. My own company in the very early days had an immense boost of productivity without tests, just by building the damn thing and failing loudly. Once we got everything wired up and errant semi-colons were blocking merges, testing was a logical next-step.

We've found good luck w/ PyPika as well.

Starsky Robotics (YC S16) | Software, Sr. Software, Internships, All Robotics Positions, ML | San Francisco, CA | Onsite, INTERNS, VISA | Full-time

Come build self driving trucks! Starsky Robotics is a fantastic place to work, we're solving hard problems across the board and need help. We have positions open for all sides of the robotics stack, and are specifically looking for more Software eng. maturity for the Teleoperation stack. I personally work on the Infra side and am looking for extra hands on our data, simulator, and fleet management infrastructure. Interns welcome to apply as well! We have priority positions open for Perception, SWE Teleop, Controls, and Safety Validation.

Earlier this year we drove our truck with no one in the vehicle on a public highway in Florida, see video [1].

We recently opened new Software positions across all Truck systems.

Blurb:

We're working to make trucks autonomous on the highway and remote controlled by experienced remote drivers for the first and last mile. Our self driving trucks will make roads safer while giving drivers meaningful work close to their homes and families.

We currently run our trucks autonomously on the highway, with freight. We are looking for awesome engineers who are comfortable working on a scrappy, driven engineering team.

We use Python, C++, and lots of bash scripting. We are a group of PhDs, masters, bachelors, and college dropouts with a diverse set of backgrounds. We're looking for folks with experience building and shipping products and a history of diving excitedly into new fields. We can sponsor visas. All positions non-remote unless otherwise specified.

Apply online, every application is read: https://jobs.lever.co/starskyrobotics/ or email me (daniel + @<company_name>.com) with any questions, but do not send me your resume (please apply instead online).

[1] https://www.youtube.com/watch?v=UCNSZKXvi64

Which plugin do you use to go docstring->docs? I found it difficult out of the box to determine w/ Sphinx how to get everything to play nice.

It's easy to not take enough vacation at companies w/ unlimited vacation. Anecdotally, most of my peers at companies w/ unlimited vacation take less vacation than traditionally counted vacation days.

I work at a place w/ unlimited vacation and take about 4-4.5 weeks per year. A big reason I actually get to take this much vacation is because our founders & senior leadership also take vacation. I could easily see a world where our sr leadership didn't take any time off and there was implicit pressure to not use vacation time.

Starsky Robotics (YC S16) | Software, Sr. Software, Internships, All Robotics Positions, ML | San Francisco, CA | Onsite, INTERNS, VISA | Full-time

Come build self driving trucks! Starsky Robotics is a fantastic place to work, we're solving hard problems across the board and need help. We have positions open for all sides of the robotics stack, and are specifically looking for more Software eng. maturity for the platform and infrastructure teams. I personally work on the Infra side and am looking for extra hands on our data, simulator, and fleet management infrastructure. Interns welcome to apply as well!

Earlier this year we drove our truck with no one in the vehicle on a public highway in Florida, see video [1].

We recently opened new Software positions across all Truck systems.

Blurb:

We're working to make trucks autonomous on the highway and remote controlled by experienced remote drivers for the first and last mile. Our self driving trucks will make roads safer while giving drivers meaningful work close to their homes and families.

We currently run our trucks autonomously on the highway, with freight. We are looking for awesome engineers who are comfortable working on a scrappy, driven engineering team.

We use Python, C++, and lots of bash scripting. We are a group of PhDs, masters, bachelors, college dropouts, and high school interns all working together. No matter your experience, we're looking for intelligent folks who have a history of diving excitedly into new fields. We can sponsor visas. All positions non-remote unless otherwise specified.

Apply online, every application is read: https://jobs.lever.co/starskyrobotics/ or email me (daniel + @<company_name>.com) with any questions, but do not send me your resume (please apply instead online).

[1] https://www.youtube.com/watch?v=UCNSZKXvi64

It was a bit hacky, but we've basically implemented some of the stuff in [1] to achieve incremental builds. If a pr changes projects a,b,c and not x,y,z then it will only build a,b,c. But it's not truly incremental right now, as it won't test things that depend on A/B/C.

We have plans to use Bazel in the future, but you have to boil the ocean when moving to bazel and get everything ever inside bazel before you get any benefit out of it.

Jenkins can't do it "easily" but it definitely can. I'd be happy to share our Jenkinsfile if you'd like.

Our finding of changes is something like:

#!/bin/bash set -euxo pipefail

COMPARE_BRANCH=$1

MERGE_BASE=`git merge-base $COMPARE_BRANCH HEAD` FILES_CHANGED=$(git diff --name-only $MERGE_BASE | grep '/') echo ${FILES_CHANGED} | xargs dirname | cut -d "/" -f 1 | sort | uniq

[1] blog.shippable.com/ci/cd-of-microservices-using-mono-repos

My team just switched to a monorepo. It's been only a few weeks, so I can't claim any results yet, but we've lived w/ the pain of poly-repo for long enough that we were ready to invest in a single repo.

We've spent a lot of time building and iterating a unified ci/cd environment to support the new repo. Previously each project had it's own test/deploy/build/publish story and usually it's own jenkins project. Now, each project is registered and triggers its own steps. Cross-project edits can happen in a single pull request. We have an incredible amount of integration tests (more so than unit tests), and getting them to work corss-project while migrating has been challenging.

We've gone from ~10-15 actively maintained repos to about 3 as we're slowly migrating. We have a mix of services, libraries, and batch processing all mixed in.

The authors points about forking and long-lived branching being incredibly difficult for most teams is really crucial. We're going to have to invest in education for new members about WHY we have a monorepo, what it means for your development, and how to change your perspective for developing at HEAD. I don't think 'bad' developers make it easier or harder. Instead, clearly articulating behaviors that exist in a poly-repo vs mono-repo world to developers is the Differentiator.

These articles were absolutely crucial to developing our monorepo.

https://trunkbaseddevelopment.com/

http://blog.shippable.com/ci/cd-of-microservices-using-mono-...

https://www.godaddy.com/engineering/2018/06/05/cicd-best-pra...

Or, if you had any shame, its growth would be up and to the right!

Starsky Robotics (YC S16) | Software, Sr. Software, Internships, All Robotics Positions, ML | San Francisco, CA | Onsite, INTERNS, VISA | Full-time Come build self driving trucks! Starsky Robotics is a fantastic place to work, we're solving hard problems across the board and need help. We have positions open for all sides of the robotics stack, and are specifically looking for more Software eng. maturity for the platform and infrastructure teams. I personally work on the Infra side and am looking for extra hands on our data, simulator, and fleet management infrastructure. Interns welcome to apply as well!

We recently opened new Software positions across all Truck systems.

Blurb:

We're working to make trucks autonomous on the highway and remote controlled by experienced remote drivers for the first and last mile. Our self driving trucks will make roads safer while giving drivers meaningful work close to their homes and families.

We currently run our trucks autonomously on the highway, with freight. We are looking for awesome engineers who are comfortable working on a scrappy, driven engineering team.

We use Python, C++, and lots of bash scripting. We are a group of PhDs, masters, bachelors, college dropouts, and high school interns all working together. No matter your experience, we're looking for intelligent folks who have a history of diving excitedly into new fields. We can sponsor visas. All positions non-remote unless otherwise specified.

Apply online, every application is read: https://jobs.lever.co/starskyrobotics/ or email me (daniel + @<company_name>.com) with any questions, but do not send me your resume (please apply instead online).

Some previous discussion 2 weeks back on our unmanned test on a closed road at 55: https://news.ycombinator.com/item?id=20177593. There we were testing our emergency procedures, safety operations, hardware checklists, and running through the game plan for the unmanned run.

For this milestone we're making public today, we demonstrated our truck driving without a person in it on a public highway.

It was remote-controlled (teleoperated) from a rest position onto the highway, supervised by the same driver at higher speeds, and then driven off the highway to a stopped position again by the same driver.

> it can be surprisingly hard to get a job at BigCorp with CEO on your resume

Why do you think that is? It's so common to hear advice that bigco's will always want to hire people w/ Startup experience, but does that not extend to the founders?

Got to this question late. We had this happen [1] during our first unmanned run completely unintentionally. We were testing our 1st gen emergency and diagnostics systems, and the truck ground to a halt a few minutes into the test. Our teleoperation center lost complete power (freak outage, no weather or anything) so the teleop station disconnected, even though our UPS was still working along. We've made a few changes to support this case a bit more, but the broad strokes worked in that case. Long story short, the truck will stop itself. There are many different ways we try to do that more safely depending on road conditions, and those are outlined in the VSSA linked elsewhere.

Link below is a dramatized account of the events, couldn't find anything less editorialized, sorry!

[1] https://www.caranddriver.com/news/a19177797/self-driving-tru...

This is REALLY hard stuff, but fascinating from a UI/Human-machine interaction perspective. Shameless plug - we're actively hiring for software engineers and product management around the Teleoperation system. We need more people fully focusing on making this better and working with our drivers on feedback, features, and other enablers for the remote-control experience.

https://jobs.lever.co/starskyrobotics/

> Do you see the move towards autonomous driving being regulated to the point where they are required to adhere to posted limits.

Yes. Starsky early on made a choice that we will operate in an explicitly legal manner, and avoid the grey areas of self-driving. That means a person behind the wheel on public roads in California, but we're all-clear in places like Florida to remove the person behind the vehicle.

> Are you free to talk about liability concerns? Is there a consensus on how unmanned vehicle will affect the outcome of a suit arising from any accident. I assume these trucks have more than every angle covered to protect against false claims

It's still an open question about how best to insure autonomous trucks. Getting a truck on the road, legally able to drive is surprisingly difficult. Watching Starsky struggle from the inside to get our first truck on the road hauling freight at the beginning was sort of a confidence builder in how the DoT and the regulatory organizations work. We are legally insured, both our normal trucks and autonomous trucks. And of course, we've got a ton of cameras in case of an accident.

Well, legally...

Not sure how we're thinking about this now internally. If there was such a technologically adept actor targeting us I'd be more worried personally about safety than the cargo itself.

There are updated videos of our UI floating around the internet. This one is pretty recent: https://www.youtube.com/watch?v=6HtOhbMSv5c&amp

Excuse the mood lighting, we're experimenting with eye-strain on the remote drivers.

Great question. We're now public[1] with the news that we're operating a trucking company, and by headcount a significant amount of starsky employees are truck drivers. Part of how we're approaching the trucking business is to automate as much of it as possible, including all this invoicing, bill of lading movement, automatic payments, doc signing, unloading/loading, and dispatch.

It's pretty easy for a carrier like ourselves to decide how to manage this business process, so we have carte blanche to work with our shipping partners on novel solutions. They're also interested in transparency and speed of transaction, and especially interested in being able to work with a truck that is easily traceable. There are modern shipping depots that have robotic unloading, but also a significant portion of freight is unloaded by the people manning the shipping/receiving offices of our freights' end destination.

[1] https://www.freightwaves.com/news/starsky-robotics-sees-truc...

Well if your father in law is looking for a different pace of driving have him check https://www.drivestarsky.com/.

With regards to fueling, there are a good amount of fuel stops around the country that will do "concierge" services for fueling up the truck, giving it a wash, etc. There's some infrastructure in place for when we need to get there.

> I'm curious as to the ways that the self driving problems in trucks might be different to the problems of self driving cars. For example, with heavy trucks, your braking distance must be a lot larger than a normal car. So things like following distance must be different. Also having to worry about skidding and the direction the trailer might move.

Right on the money. If you slam on the brakes on a truck, you and your trailer can jack-knife, sending the trailer the wrong direction. It's a more complicated controls problem than in a car as well!

> Also, I imagine that you have to be pretty careful about cars cutting you off. It seems to happen all the time on the road, and is more dangerous than people give it credit for.

I've spent hundreds of hours in our truck over the last 3 years and my god drivers are absolutely terrible around trucks. You have an incredible view of the road from up on high in a semi, and the spatial awareness compared to a sedan is way better, so the crazy maneuvers happening around us seem a lot crazier. In California trucks can only go 55 mph, so we get a lot of folks (even in normal driving) trying to speed around us during merges on/off highways.

Starsky engineer here. We spent a few days getting all of our emergency procedures in place and testing all fail-safe aspects of our system on the road in preparation of the run. We've done unmanned runs before (also in Florida), but at much lower speed and with a vastly less sophisticated emergency system.

Happy to answer any questions

Starsky Robotics (YC S16) | Software, Sr. Software, Internships, All Robotics Positions, ML | San Francisco, CA | Onsite, INTERNS, VISA | Full-time

Come build self driving trucks! Starsky Robotics is a fantastic place to work, we're solving hard problems across the board and need help. We have positions open for all sides of the robotics stack, and are specifically looking for more Software eng. maturity for the platform and infrastructure teams. I personally work on the Infra side and am looking for extra hands on our data, simulator, and fleet management infrastructure. Interns welcome to apply as well!

We recently opened new Software positions across all Truck systems.

Blurb:

We're working to make trucks autonomous on the highway and remote controlled by experienced remote drivers for the first and last mile. Our self driving trucks will make roads safer while giving drivers meaningful work close to their homes and families.

We currently run our trucks autonomously on the highway, with freight. We are looking for awesome engineers who are comfortable working on a scrappy, driven engineering team.

We use Python, C++, and lots of bash scripting. We are a group of PhDs, masters, bachelors, college dropouts, and high school interns all working together. No matter your experience, we're looking for intelligent folks who have a history of diving excitedly into new fields. We can sponsor visas. All positions non-remote unless otherwise specified.

Apply online, every application is read: https://jobs.lever.co/starskyrobotics/ or email me (daniel + @<company_name>.com) with any questions, but do not send me your resume (please apply instead online).

I don't see an issue, their widget allows me to go back to my default ctrl-f by pressing it again.

There's just something enticing about watching home-cooking. It's better than any TV you've ever seen. If your subject is a better cook than you or has a much larger range of recipe comfort, watching their technique or process is really eye-opening. I love seeing what my friends do or don't do in the kitchen, always something to learn about.

It smells amazing too being near the action. Sight + smell getting stimulated all at once.