SuperCruise and BlueCruise are technology names from GM and Ford for assisted driving in their car products, and not synonomous with Cruise the company providing ride share services.
What is your product goal? Both for the customer (solving a problem) and for the company(solve a marketing need, make money)?
Can you proof that you are meeting both? Then you are validating your goals successfully.
Most of the time products are missing defined goals, so lots of people have no idea what the fuck they are developing and everyone ends up with their own idea of the product.
Usually there's a separate document that has the requirements, and from that document you have a "software detailed design" which has the specifications for how to build the software such that it upholds the requirements. Subtle but important difference.
You can use nvidia-smi to set a target maximum power draw and performance mode to bring idle power levels down. Also make sure your computer is using the server/headless mode driver to keep idle power consumption down.
It's been a few years, but from what I recall, a Principal is a Director-equivalent (L8) level.
The prior poster is missing the L7 tier, which is Senior Staff Engineering Manager for the Engineering Manager Ladder.
L8 is a Director on the Engineering Manager Ladder
L8 is a Principal on the Software Engineer (SWE) Ladder.
Tech-Lead Managers (TL/M or TLMs) were on the SWE Ladder.
For reference:
Software Engineer Ladder
L8 - Principal Software Engineer
L7 - Senior Staff Software Engineer
L6 - Staff Software Engineer
L5 - Senior Software Engineer
L4 - Software Engineer II
L3 - Software Engineer (new graduates would start here)
----------------------
L2 and below exists in rare occasions.
Engineering Manager Ladder
L8 - Director
L7 - Staff Engineering Manager
L6 - Engineering Manager (M1)
L5 - Engineering Manager (M0 - normally this level does not exist for external hires and is for the rare situation when a SWE is converting to the Engineering Manager ladder)
One of the problems is that large corporations have such complicated role structures, and another problem is that they are also different from all other large corporations. A third problem is that the compensation models are again vastly different. A fourth problem is that they change over time.
All of this means as an individual you suffer from extreme information asymmetry.
Even if you got two offers from two different FAANGs, it would perhaps be hard to figure out which one is better.
Has anyone defined any mapping tables between role names across Amazon, Meta, Alphabet etc. and figured out salary ranges for them in a public spreadsheet?
BTW, has anyone got a leaked (anonymized) copy of FAANG employment contracts so one can compare the various clauses across employers, and track changes of their standard templates over time? (I haven't seen this topic discussed much on here in the systematic way that it deserves.)
Given the developer community invented open source it is surprising that corporations have so far succeeded in keeping such obvious things relatively secret (compared to, say, the emails of Sarah Palin and Ehud Barak ;-).
This is not really an accurate representation of FAANG hiring and job searching. In reality, there is a very very high amount of job hopping and also connections to people at other FAANGs (and there's also levels.fyi and blind) so we're well aware of comp structures, what employment agreements, levels, etc are across companies and how to compare then. There's very little information asymmetry in fact people go into negotiations with recruiters very well equipped, far better than at small companies.
> BTW, has anyone got a leaked (anonymized) copy of FAANG employment contracts so one can compare the various clauses across employers, and track changes of their standard templates over time
If this doesn't exist it's only because it's incredibly uninteresting. levels.fyi will tell you all you need to know. (also they aren't employment contracts, in the US we do agreements because we're at-will)
I've hopped multiple FAANG+s now across my career.
Senior engineer is usually focused on a single project, and knows it deeply. Usually directing and mentoring more junior engineers in the process.
Staff engineer typically is overseeing multiple projects, providing deep technical oversight and guidance on those projects, and mentoring Senior engineers. They start to influence technical culture. They are actively involved in ensuring business needs get met by the technical solutions their group is building.
Senior Staff Engineers will be overseeing a product function, and multiple Staff engineers. They build the correct technical culture. They ensure larger architectural issues get resolved. They are actively involved in ensuring the technical work being done is meeting business needs, and identifying business needs their technical org can be meeting - and working to make that happen.
Principal engineers are setting the tone for an entire large product (typically), and ensuring the Senior Staff engineers are doing the right things - and also often involved in driving strategic product direction.
Senior Staff and Principal tend to be increasingly political, but even Staff will get pulled into that type of thing somewhat regularly.
Adding some additional context on most of the above:
Yes, as commissioned US military officers they become subject to UCMJ.
USDS and DDS employees are/were civilian federal employees with capacity for legal authority to act on behalf of the US Government.
DoD and its branches have uniformed service members subject to UCMJ, but they also have many civilian employees with decision making authority and ultimately the services report to civilian secretaries; the ratio of uniformed service members (e.g. enlisted, and commissioned officers) to civilians can vary greatly by service. Another main difference to consider beyond UCMJ would be eligibility to be considered a combatant versus not; not all uniformed personnel should be considered combatants. "Authority" is not exclusive to uniformed personnel.
Many DoD programs can be led or managed by civilians, typically a GS-15 which is roughly equivalent to O-6 (e.g. Army/Air Force/Space Force Colonel, Navy Captain)
If I recall correctly, Palantir's main starting point beyond some of its fraud-tracking origins at Paypal were through its attempts to compete in the DCGS-A / replacement acquisition in DoD.
Crowdstrike had Dmitry, but its main US Government ties were through Shawn Henry, a former director of investigative operations at the FBI; Crowdstrike had a few business lines in its early days, which included its intel/research/analysis services, breach investigation/remediation services, while it was developing its endpoint protection products/platform.
---
And to the upstream parent comment:
> The key difference is the DDS folks were not uniformed military. That can make all the difference when trying to sell your product or service to a military decision maker.
A lot of DoD acquisitions, developments, operations decisions end up being materially informed by civilian personnel that are direct employees of the US Government, contractors supporting the US Government via Federally Funded Research and Development Corporations (FFRDCS, labs, etc.), other contractors, etc. In some cases, it seems like the DoD programs are entirely reliant (i.e. dependent) on their contractor support (via FFRDCs, labs, etc).
Some of this comes from the fact that the typical active duty officer's assignment duration in a particular role (e.g. acquisition program manager, chief engineer, etc) ends up being two years or less before a permanent change of assignment (PCA). Having organic civilian staff in these roles can be essential for maintaining continuity and can be a key part of a program/mission's success.
(Also worth noting that in a lot of cases where the head of a program is a civilian employee, it's not uncommon to find that are military retired, prior service but separated, and/or also a reserve officer in the same or very adjacent field)
Concur. This is part of why Suite A ciphers (algorithms) exist, and the second component includes robust key management practices are so important (this includes hardening of devices to prevent leakage of signals that could compromise those keys or the cryptographic processes themselves).
