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.
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)
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).
It would be interesting to analyze a dataset of commercially sold prepared "coffee" drinks from vendors like Starbucks to see how many are actually coffee, versus coffee-flavored soft drinks, and how this changed over the last few decades.
An engineer's understanding of requirements entails determination, evaluation, and articulation of those requirements. Calling oneself an engineer doesn't preclude their ability to do these things, and force them to call themselves a "product manager" for doing so. And quite often, especially at more senior levels, an engineer must do these things.
Once upon a time, this too was a formalized practice in engineering that people called "Systems Engineering":
> When this role is dumped into engineering, engineering management or general management, it weakens the engineering practice. If I need engineers, I need to select for that ability and frankly shield them from people on the outside. If the org requires that my teams handle interaction, now I'm hiring people with mixed skillsets in one org, which inevitably waters down the engineering side.
I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management. Part of the problem plaguing the tech industry is the "dumping" of this responsibility, and others such as "project management" into some other role. What some like to call a "specialization" may also be called an abdication of responsibilities and ultimately accountability.
In my opinion, the essence of engineering is the methodical art and practice of solving problems. A fundamental part of engineering is understanding the problem(s) to be solved, the constraints, as well as the trade space and trade offs of solutions for those problems.
Not all aspects of (engineering) problems are "technical" in nature, and a failure to understand this and cultivate this understanding weakens the engineering practice.
And ironically it seem like the things you'd positively attribute here to a product manager used to be/are actually part of the scope of what was traditionally a "project manager" or "program manager."
For example, look at the scope and definition of a "program manager" from Microsoft or the US DoD in the 1980s, 1990s+, as well as literature describing the role of a program manager and the discipline from that time.
Unfortunately, that type of experience is becoming more and more common, and that speaks to the interviewers and their lack of understanding of the whys of the systems design interview process itself...
I suppose this is one more sad byproduct of the title/level-inflation or skill-dilution that has been happening across industry, as well as the 'gamification' of the interview process on both sides.
Some interviewers can also end up being lazy as well.
I'm also a former interviewer from Google. I typically interview people for L6+ roles.
What's being called "bias" here may simply be "experience" and a fundamentally different understanding of the System Design interview's purpose.
Side note: Systems Design interviews are reserved for "senior" level candidates (L5+). It is a significant inflection point for expectations, as senior-level employees are expected to navigate through and resolve ambiguity. These interviews are not about determining if the candidate can or has solved a particular problem. When a candidate has a particular solution in mind for the presented problem, they better be prepared to explain and justify why.
(Take everything I say with a grain of salt, as there's no guarantee that an arbitrary interviewer you encounter shares the following understandings)
While Google's interviewing process for tech ladders is deliberately designed to minimize any potential interviewer bias in the process (i.e. the interviewer's role is structured to ask, as a starting point, approved questions and take notes --sometimes verbatim-- on the candidate's response for the hiring committee to make a hiring decision, the Systems Design interview is the one type of interview that does and --should-- rely on the interviewer's judgment.
The same Systems Design interview question can be given to candidates across a range of target levels.
What may be frustrating for junior candidates in particular is that unlike leetcode or cracking the coding interview questions, these questions are not intended to be or can be "completely solved." There are no specific "correct" answers. There is no book of solutions to be memorized for such questions. This is deliberate, knowing that people try to memorize answers for interviews. This does not mean a candidate can not, nor should not practice how to show their experience.
The tenets of systems design questions in engineering interviews are to:
0) Foster collaboration. The interview is about understanding how the candidate goes about solving a problem and understanding their experience solving problems (with others).
1) Give the candidate an open-ended question that is not meant to be memorizable, nor exhaustively solvable within the allotted time. This allows an interviewer/hiring committee to observe and judge a candidate's problem solving approach and experience, versus memorization.
2) Give the candidate an opportunity to show their experience -- The question and approach should be sufficiently broad to allow the candidate to surface areas where they have particular depth from their past work experience, and the interviewer to probe/explore those depths.
The interviewer's evaluation of the candidate responses and performance during a systems design interview should include the interviewer's expectations of what a candidate would at least ask or address with the presented problem. Better yet, the interviewer should include what they would expect a candidate for a given target level to address, and further specify what additional things an L+1, L+2, etc would have addressed.
Ultimately systems design interviews are not about a candidate's answers for "What" or "How" to build ______, but surfacing a candidate's judgement skills and understanding of the "Whys" along the way.
One of the "heavy practice/coaching/leetcode grinding" signals is when the interviewee immediately dives into proposing a solution and discusses facets of that solution in great detail without bothering to ask clarifying questions or discussing assumptions and the risks/consequences of those assumptions.
As the corporate organism itself grows larger and faces newer challenges, it may need to evolve and develop new, more specialized organs that a slime mold does not inherently possess or function well at to scale.
Many organisms in the natural world could not scale exactly as-is to 10x or 100x their normal size with their existing structures.
The idea of a slime mold representing the whole company may have once been true a decade or more ago when Google was much smaller and less extended, but the mental model is much like newer people at Google yearning for the "old Google" that never worked there during its earlier days. It's a nice fantasy.