moandcompany

8 か月前議論

Does anyone miss Meatless Mondays?

8 か月前議論

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.

moandcompany

9 か月前議論

Too big to burn

moandcompany

9 か月前議論

Yep... Along with this

Verification aligns with a specification. E.g. verify if what was implemented matches what was specified.

Validation aligns with a requirement. E.g. verify if what was implemented solves the actual problem.

moandcompany

9 か月前議論

Understand what your boss's boss cares about and make sure your work can described in relation to those goals or concerns.

moandcompany

10 か月前議論

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.

moandcompany

11 か月前議論

Google and Meta/Facebook have generally aligned and numerically equivalent levels for the main Software Engineer and Engineering Manager ladders.

moandcompany

11 か月前議論

Adding a correction on above ->

L7 is Senior Staff Engineering Manager (M2)

L6 is Staff Engineering Manager (M1)

they are of equal level to the SWE ladder L6 and L7 titles

moandcompany

11 か月前議論

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)

moandcompany

昨年議論

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.

moandcompany

3 年前議論

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":

https://en.wikipedia.org/wiki/Systems_engineering

https://www.nasa.gov/reference/2-0-fundamentals-of-systems-e...

moandcompany

3 年前議論

> 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.

moandcompany

3 年前議論

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.

moandcompany

3 年前議論

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.

moandcompany

3 年前議論

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.

moandcompany

3 年前議論

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.

moandcompany

3 年前議論

Yes. I wrote about exactly this in another comment:

https://news.ycombinator.com/item?id=34381884#34385570

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.

moandcompany

3 年前議論

Promotions seldom relate with OKRs on tech ladders, and more specifically for SWEs it is rarely the case, as the promotions are judged by committees who evaluate for difficulty and skill by ladder standards, not business objectives.

Launches are catalysts but insufficient for promotion.

moandcompany

3 年前議論

I am a Xoogler.

The source document/presentation ("Coordination Headwinds") and idea are many years old, and from what I recall were not aimed to be critical of the company and its organization, rather to give its employee readers a feeling of solace and understanding for why getting seemingly small things done can feel overly hard and slow… a less humorous, and less SWE-specific version of "Broccoliman" if you will.

Refer to the red panda that merely wants to serve 5TB of data.

  - https://www.youtube.com/watch?v=3t6L-FlfeaI
  - https://news.ycombinator.com/item?id=29082014

I’ll try to continue using the organism-metaphor in my commentary.

While the “slime mold” story provides a convenient and charitable explanation of Google's bureaucracy and dysfunctions, another explanation is:

  - As an organism, Google's executive decision-making functions are severely impaired by lack of accurate information, dysfunction of its middle-management “organs” or tiers, and impedance mismatches arising from genetic encodings or mental models associated with the slime-mold idea.

  - Despite being on a mission to “organize the world's information and make it universally accessible and useful,” Google is far less successful at doing this with its own information. These characteristics are not unique to Google, but some of Google’s cultural history makes this a particularly challenging problem.

It may be convenient to think of Google as a slime-mold organism, and in an individual contributor’s day-to-day engineering activities it may very well be, but as a corporation it is not.

The vast majority of Google’s product areas or business units, are not self-sustaining entities and all rely and draw upon resources, namely headcount, that unavoidably go through a centralized prioritization and allocation process. Ruth (Google CFO) and Sundar’s (Google CEO) jobs are quite difficult if you consider that: (1) they don’t have optimal or very accurate internal information, (2) they are constrained by what is provided to them and what people will actually do, (3) tributary sources of information generally have little understanding of broader processes, aside from what they expect to receive, and also have many incentives to fashion information in a manner that maximizes their own benefit – based on what they assume or understand.

Avery Pennarun (apenwarr@) touched on some of the above internally in a document called “View from Above” (go/vfa) and post-Google, on similar dynamics in a public blog post: https://apenwarr.ca/log/20190926

From my own experience at Google, where I served in engineering leadership roles and joined as an experienced industry hire, is that over time Google's culture – Namely its performance rating and promotion process, over-weight certain accomplishments and neglect critical characteristics and understandings needed from employees as they move into upper echelons of leveling (middle-management and higher), most importantly in the L6/L7 (manager, sr manager) and L8 (director) levels.

Many Googlers in those ranks continued to operate based on the understandings they held as project / technical leads (“TLs”), typically a Level 5 role, and continued to be promoted based on those understandings and/or increased headcount below them. Meanwhile, these roles, and the corporate organism’s need from these roles, are fundamentally from being a TL or project lead.

Compounding this problem is the fact that for most Googlers in these roles, scarcity of resources was rarely a problem, and getting headcount was easy. Most managers know how to ask for headcount but have no idea how to help support the conditions for its creation.

To be less wishy-washy, many people were promoted for continuing to do their jobs as they understood them, and their expanding team size to some degree, rather than understanding the full scope and understanding of the new level or role they were stepping into. And to some degree, it may not have been their fault as the persons and examples before them did the exact same thing.

Some might say this is the Peter Principle in practice, but at Google-scale.

Anyways… to wrap this up, I regularly encourage people to think about and learn to understand their boss’ boss’ problems, and ensure they are able to evaluate and represent their work in relation to those problems. Without establishing that context, your work may be completely misaligned or difficult to value when viewed from above.

コメント