
Elon Musk: Tons of C++/C engineers needed - happy-go-lucky
https://twitter.com/elonmusk/status/1224182478501482497
======
hedora
If this is their actual hiring strategy (armies of junior whiteboard coders
with no preference for engineering experience or education), then the quality
of their product will tank rapidly. It’s not that junior engineers are bad
hires, it’s that it takes years of hard fought engineering experience to get
an idea of what designs will work, what won’t; when to pay down tech debt,
etc.

Edit: There are lots of junior-sounding devs on this thread. Don’t let me
discourage you. Just be sure you’re joining a team with strong engineering
leads that will be good mentors.

~~~
tga
What gives you the idea that Tesla is hiring junior whiteboard coders for
these roles? They wouldn't know anything about optimizing C++/C/raw metal
driver code for speed and wouldn't pass a real hardcore coding test.

~~~
g82918
Passing a "hardcore" coding test is something you can train for, and tends to
not correlate well with actual software architecting and optimization
knowledge.

~~~
pooya13
Also optimized code is not necessary well designed.

~~~
animalhot
Very true. Especially in embedded programming where custom code can yield
massive perf gains.

------
Someone1234
I could see working for for Tesla, I couldn't work on Tesla's AutoPilot
though.

I have deep reservations about using members of the public (and others on the
road) as guinea pigs. Before the Walter Huang fatality, maybe, but after that
and how Tesla acted about what was clearly a software bug in software that
wasn't fit to be on public roads ("beta" label or otherwise), I could never
justify working for such a company. Imagine being a software engineer on
AutoPilot at the time, and then having the company you work for excuse your
bugs by blaming the victim for not circumventing AutoPilot controlled steering
into a wall.

Software development ethics don't come up a lot. But I feel like AutoPilot is
up there with medical software, aviation, and military, in that mistakes can
easily cost lives. I want to be able to sleep at night.

It is a cool problem-space, but only academically.

~~~
SEJeff
The inverse is also true. There are plenty of videos of autopilot preventing
wrecks that the human drivers said they likely would have wrecked on
themselves. I happen to be one of those drivers when someone pulled onto the
highway from a field at night. AP swerved and missed the idiot but I'd not
even seen them and would have almost certainly hit them doing about 70mph. A
T-bone that fast would likely have messed both of us up really good.

AP will never prevent all injuries / fatalities due to road conditions and
other human drivers simply being imperfect. It has a good chance to prevent a
lot of otherwise fatal crashes in the meantime however. One could say it would
be unethical to not even consider the alternative here.

Just some food for thought. I'm a software engineer myself and Model 3 owner.

~~~
semi-extrinsic
On the flipside, in these cases where people self-report "I likely would have
wrecked myself", we can reasonably expect that they are paying less attention
to the driving situation while using AP than if they were driving a car
without AP. So we expect them to be strongly biased towards underestimating
their own abilities in the situation.

~~~
SEJeff
That's fair, but I'm sort of afraid / amazed by autopilot. I have been through
FAA flight school and you learn to develop an instrument panel "scan" in
instrument rated flight. I find myself having developed a "scan" that includes
looking side to side and behind me. With AP enabled I'm able to take in more
of the current situation around me, but in this case, I was not able to see
the car that drove into the middle of the highway from offroad at night. AP
did a better job than a human did. End.

~~~
viklove
AP did a better job than _you_, but it's a bit of a stretch to assume that
finding is true for most other people, or even just the average person. This
is why the scientific method exists, so we don't fall prey to our own bias.

------
blackrock
> Educational background is irrelevant, but all must pass hardcore coding
> test.

This sounds like another example where his hard core coding tests filters for
code-grifters.

You know the type: People who game the system by studying L33T coding
challenges, and can hack out some nonsense from copy/pasting stackoverflow.
They get ‘something’ working, and ship it, and declare that it is done. But
when you really investigate it, you find that it is a disaster waiting to
happen.

And in general, they cannot engineer a formally-verified, fault-tolerant
system to control complex systems, complex heavy machinery, and intricate
business logic.

But, these are the engineers that will pass his hard core coding challenge.
Welcome to the so-called world of Software “Engineering”.

~~~
wallacoloo
> And in general, they cannot engineer a formally-verified, fault-tolerant
> system

Do any automobile manufacturers actually use formal verification? How do you
even apply such techniques to things that leverage ML like Tesla’s autonomous
driver?

~~~
blackrock
ML for automotive sounds like a disaster waiting to happen.

It seems like ML is statistically safe for everyone else, until that moment
when you become the “statistic”.

------
the_hoser
I don't care to have a job where my mistakes could possibly end up killing
people months/years from now, but I wouldn't mind seeing what he means by
"hardcore coding test".

~~~
hedora
Almost any software bug can end up killing someone once it’s deployed to a
billion people.

It’s just less likely you’ll hear about it if it doesn’t involve a spectacular
plane/car crash, missile launch, radiation release, etc.

Ad targeting comes to mind (e.g., accidentally pushing opioids and worse at
mentally unstable people because the computer inferred they are likely to
buy).

~~~
SQueeeeeL
I like how you assume that was an "accident", especially after it came out
that Purdue and Allscripts teamed up to push pills through their software. The
system is working as expected, it just would horrifying it's original creators

------
JakeStone
A few years ago, I contacted a buddy of mine at Tesla to see if they were
hiring. That led to a call from their HR/recruiter and a nice chat. I remember
being interested enough to continue the process until we reached the end.

It sounded pretty straightforward. Coding test, talk to a bunch of people
onsite, etc. Each of the people would write up a report and it would work its
way up to Elon Musk and he would make the final decision as to whether or not
to hire me.

In a small company of up to ~200 people, sure. A department that's maybe a
layer or two beneath him, ok, maybe? I don't remember where this was exactly,
but it was something involving web services or similar in C#, and I don't even
think it was front-facing, but for internal use, so probably somewhere in the
IT department.

For my personal tastes, when the CEO is making hiring decisions on every
position, that's an element of micromanaging that I'm not comfortable with, so
Tesla is pretty much off my list.

------
misiti3780
I know Elon is sometimes not popular around here, but how many CEOs at that
level would know that level of details abouts the NNs. (he is totally in the
weeds, but that is very cool IMO)

I'd love to work there, but I know I would not put in the effort to pass the
coding tests.

~~~
rayiner
Many of them? 1/3 of Fortune 500 CEOs majored in engineering. For decades, the
CEO of Intel was a process engineer. The current CEO of AMD is also a process
engineer. You bet they know the details of their chip design and manufacturing
process. Ginny Rometty, CEO of IBM for more than a decade, had a degree in
computer science and electrical engineering. The current Boeing CEO is an
aerospace engineer. They’ve not necessarily been amazing leaders, but I bet
they know what language Watson/Boeing’s control code is written in.

~~~
nexuist
Dennis Muilenburg was fired. The current CEO of Boeing is a finance guy if I
remember correctly.

------
new_realist
Tesla doesn’t pay well enough to attract good software engineering talent.

~~~
rcMgD2BwE72F
It does compare badly versus employers in the oil & gas, defense, tobacco and
casino industry. A shame.

------
vsskanth
naive question, but shouldn't AV command and control algorithms be built on
some kind of formally verified system/language, considering lives are at play
here ?

I am aware of MISRA C for automotive but is something like that sufficient to
guarantee against unintended behavior ?

If not, can someone comment on why this isn't the case today ?

~~~
0xffff2
Is there _any_ production software in the world that is written and maintained
in a formally verified language? I have only ever seen toy problems and
simplified subsystems of real projects verified.

I work on space craft flight software and exactly none of it is formally
verified. As far as I know, it's not practical to do so. If we could do it
(without ballooning cost and schedule 10x), we would.

~~~
arianvanp
Amazon S3 and DynamoDB come to mind are good examples. They are model-checked
in TLA+ though the applications themselves are not written in TLA+.

A large portion of Microsoft's in house developed device drivers for windows
are formally verified.

Boeing together with DARPA built an autonomous helicopter on top of the
formally verified Sel4 microkernel
[https://ts.data61.csiro.au/projects/TS/SMACCM/](https://ts.data61.csiro.au/projects/TS/SMACCM/)

Another one:

Wireguard uses formally verified implementations of ed25519
[https://github.com/project-everest/hacl-star](https://github.com/project-
everest/hacl-star)

~~~
0xffff2
>Amazon S3 and DynamoDB come to mind are good examples. They are model-checked
in TLA+ though the applications themselves are not written in TLA+.

Honest question (I obviously don't have a ton of experience in this area),
what does "model-checked in TLA+ though the applications themselves are not
written in TLA+" mean (in terms of the guarantees you're getting)? If you're
not verifying the actual code, then how do you prevent bugs creeping during
whatever happens between verification and actually writing the application
code?

The HACL* project looks interesting. I would definitely accept that as an
affirmative answer to my original question.

~~~
hwayne
> If you're not verifying the actual code, then how do you prevent bugs
> creeping during whatever happens between verification and actually writing
> the application code?

Code review! So, SO much code review. Also testing and type systems and
linters and code review.

(There's also some work on automatic synthesis, like PGo, but that's all very,
very far from being production-ready.)

The main benefit of using TLA+ is that it lets you hammer out issues in the
high-level design. Less "oops this has a buffer overrun" and more "oops if
this service stalls out for too long our recovery mechanism will violate a
core safety guarantee." Turns out that lots of the nastiest bugs are in the
design, not the implementation, so using TLA+ saves a lot of time and money.
But you still need to code review!

~~~
0xffff2
>Less "oops this has a buffer overrun" and more "oops if this service stalls
out for too long our recovery mechanism will violate a core safety guarantee."

Yeah, but we already have processes to manage the latter. It's the (potential)
buffer overruns that keep me up at night!

>Turns out that lots of the nastiest bugs are in the design, not the
implementation

I'm not saying it never happens (does TLA plus make sure everyone's assuming
SI units?), but that hasn't been my experience at all.

~~~
hwayne
> Yeah, but we already have processes to manage the latter. It's the
> (potential) buffer overruns that keep me up at night!

I'd _hope_ you'd have those processes, working on space flight and all :P.
Good processes > good tools. It's easier to start using a good tool than
overhaul your process. So for people who don't have that kind of discipline or
heavyweight process, TLA+ gives a lot of benefits for really cheap. AWS, for
example, found it really easy to slot into their workflow.

Re buffer overruns, I just remembered OpenComRTOS, which used TLA+ to verify
low-level properties of their code.[1] They found it super helpful.

> I'm not saying it never happens (does TLA plus make sure everyone's assuming
> SI units?), but that hasn't been my experience at all.

'Fraid it probably can't help you with the SI units. I'm thinking about
"design bugs" more like this:

> 1\. Suppose we have a document with version 57

> 2\. A bulk of delete and reindex will remove the index-v57, increase the
> version to 58 (for the delete operation), then put a new doc with version
> 59. While the engine places the index-59 into the version map, the safe-
> access flag is flipped over (due to a concurrent fresh), the engine won't
> put that index entry into the version map, but also leave the delete-58
> tombstone in the version map. The delete-58 tombstone is stale because the
> latest version of that document is index-59.

> 3\. Another bulk of delete and reindex will increase the version to 59 (for
> a delete) but won't remove docs from Lucene because of the existing (stale)
> delete-58 tombstone. The index operation will append document (version 60)
> to Lucene (instead of overwriting). At this point, we will have two
> documents with the same id.

Which was a bug TLA+ found in ElasticSearch.[2]

[1]:
[https://dl.acm.org/doi/10.5555/1779934.1779955](https://dl.acm.org/doi/10.5555/1779934.1779955)
[2]:
[https://github.com/elastic/elasticsearch/issues/31976#issuec...](https://github.com/elastic/elasticsearch/issues/31976#issuecomment-404722753)

------
omarhaneef
Wilson Williams responds:

“ If you ever need a solid ideas man with no coding knowledge whatsoever, hit
me up.”

To which Scott Lawson responds:

“ Ideas are cheap, execution is gold.”

Finally Wilson again:

“ Anyone can learn to code, you can't learn how to have good ideas.”

I assume Wilson (I’m using their names as presented) is kidding, in which case
it’s very funny.

~~~
exhilaration
I don't think he's kidding. Most people think that being a "good ideas guy" is
how you succeed without understanding that everyone has those ideas, but few
can execute them. I'm sure many of us in tech were approached by friends and
family with amazing app ideas after iPhones became popular without
understanding that ideas are cheap and getting a product launched is the hard
part.

------
hadiz
I miss C++ a lot. The modern standard library is a thing of beauty IMO. Such a
shame that I could not find a good gig when I was looking few months ago, at
least not where I am.

Looks like Tesla though are doing C with C++ features rather than C++. I'd
also be interested in knowing what their "hardcore" questions are like...I
heard that they ask a lot from your past experience.

~~~
jcelerier
> Looks like Tesla though are doing C with C++ features rather than C++

Tesla's UI is in Qt 5 which is fairly C++

~~~
hadiz
Good point. Whenever I see a job ad advertising C/C++ together, it's basically
saying "we do C with objects".

------
wolfgke
> "but all must pass hardcore coding test."

The time necessary for this means a huge opportunity cost for every applicant.

------
imvetri
Ok. Recently few layoff happened at Tesla. New hires are a replacement.

------
bdcravens
Can’t they just build it all in React? /s

------
aey
Why not rust?

~~~
BubRoss
Rust's ecosystem is genuinely nowhere near the maturity of C++.

~~~
DoofusOfDeath
Can you elaborate on this, or point to a good source of more info on the
topic? As a longtime C++ programmer starting to look at Rust, I'm quite
interested.

~~~
rvz
Please name one GUI library written in Rust which is widely used in
production.

Exactly, there are none (yet). Unlike C++ which has Qt and WxWidgets which are
all mature open-source GUI libraries and are used in production and seen in
the wild.

~~~
DoofusOfDeath
I'm guessing that you think there's an agenda behind my question. Just to
clarify, I really am just trying to understand the current lay of the land
regarding Rust.

~~~
rvz
It is just an open question about the state of mature cross-platform GUI
libraries in Rust. My point is that the current state is that compared to C++,
the Rust ecosystem is not mature (yet) and there are no production ready
cross-platform GUI libraries written in Rust.

That is one setback when trying to consider using Rust for cross-platform GUI
development.

------
noncoml
C++ != C

~~~
shkkmo
I'm pretty sure that that would evaluate to false in C++

~~~
jcranmer
It's undefined behavior (in both C and C++), so it can evaluate to true and
false at the same time.

------
oceanghost
Ah, Elon needs more sweatshop programmers?

