PM is a super heavily overloaded term that you'll run across in pretty much any company larger than small, definitely not specific to Google (disclaimer: I work at Google and don't speak for the company, but I'm brand new so my conception of the categories comes from what I've seen elsewhere). Engineers tend to raise an eyebrow at the entire job category because they're thinking of bad experiences with one particular flavor of PM (and often a particularly poor specimen at that), but that can be unfair, a lot of what they do is absolutely critical to business.
The acronym simply means either product manager, project manager, or program manager, but the responsibilities can be any/all of the following, and probably more, depending on the company:
- Full product owner, "the buck stops here" person. Many different possible titles here other than PM (usually "project manager" if that's the title), like general manager (GM), different flavors of producer, product owner (PO), VP of X, etc.
- Feature designer/owner/manager (product manager): writing specs (junior), pitching specs (mid-level), setting and selling product vision (senior), driving strategy (staff/exec, though at that level all roles start to get blurry). Decent business school grad representation here, you have to be good at strategy, negotiation, communication, and Powerpoint; having good product ideas helps a lot, too, but not if you can't sell them. A persuasive PM of this type is a force to be reckoned with and will get a lot of executive attention, which can be very good or very bad depending on whether the strategy they're into pans out or not. This is probably the type of PM the parent was talking about "armies of".
- Development director (project manager or program manager): a whip-cracker at worst or an impenetrable shitshield at best, they manage the practicalities of running a project, like project scoping, meeting and managing hard/soft deadlines, handling support, cross-team communications, processes, compliance, etc., often stepping in as an all-purpose guard against randomization so that others can focus on producing the product. Many PMs of this type ended up being the go-to folks for GDPR compliance over the past couple years, so it's not just internal process stuff that they deal with.
- Task checker: can blend into to the development director mentioned above, but at some companies this sort of PM will mainly focus on tracking tasks that are in-progress, getting estimates, watching velocity, and sending reports up the chain. Some devs find this role pointless and annoying, but it really depends on how good they are - if they're solid, they'll find a lot of ways to improve things instead of just tracking them.
- Scrum Master (project manager): Big-S Scrum is falling out of favor so it's not as fashionable to have this title anymore, but within some processes a similar role still exists as a type of project manager. In a nutshell, Scrum is a simple yet effective "People Over Process" process that consists of a bi-weekly no-laptops-allowed retrospective meeting where you get the team together to have a free-ranging discussion where everyone feels heard, so that you can all decide together whether the team should estimate engineering tasks in terms of hours or hats. You need a trained and certified Master because otherwise people new to Scrum might not know to pick hats. A more seasoned Scrum Master will also schedule a quarterly retrospective-retrospective where the team discusses a strategy for what guidelines to put in place for the next retrospective so that the team can decide on hats faster and leave more time for the less settled question about whether or not the Fibonacci sequence is the right way to count hats or if a size-based approach will make people feel better supported in their work.
- Monetization designer (product manager): mainly at game companies, PM is often a super different role, probably best described as the profitability-focused counterpart to a game designer. They focus on setting prices, managing game economies, speccing and evaluating A/B tests, inventing loot boxes, etc. Ideally PM and designer would be one and the same, and the game design would be holistic with the monetization, with a designer that has serious Excel/analytics chops and deep inspiration and sensitivity about gameplay, but that's a more rare combination than you'd think, so a lot of companies split them out.
I'm probably missing some other ways this acronym is overloaded, but I think this covers most of it.
> You need a trained and certified Master because otherwise people new to Scrum might not know to pick hats
You certainly don't need a certified scrum master. Ideally, the scrum master should be somebody who is already in the team. A scrum master who does just that is really a project manager, and having a project manager is, IMHO, antithetical to doing scrum.
According to scrum, the scrum master is not the product owner and not a member of the dev team, but rather an objective person who does just the scrum master duties, e.g. facilitating when needed, e.g. making sure people are following scrum instead of getting distracted, not stalled by roadblocks, not taking marching orders from more than one product owner, etc. In scrum, the dev team organizes its time after priorities are set. Scrum does not want a scrum master to be a project manager - if you’ve seen that they’re just mixing unnecessary stuff into scrum and scrum is getting a bad rap for that. I don’t see a scrum master as being a full-time job unless they’re working with multiple teams, so it could easily be anyone knowledgeable outside the team who will objectively play the role.
In my experience, and from what I remember from my own training, the scrum master can very well be part of the team. Having somebody external, objective, well trained, and available exactly when the team needs him looks very good... but pretty difficult to do in practice.
I 100% disagree. Have had extremely interesting conversations out of essentially this question regardless of my status relative to the person I'm asking (plus or minus 3 levels in the management chain), except in the rare case that the person is so super shy that they can't come up with anything to say even with coaxing. People that don't give a shit about me are even more interesting when they answer.
With a person who is higher status than you, they invariably have a life story that they are practiced at and enjoy telling, and know how to answer this question in a really satisfying and engaging manner because it's been asked so many times. That's the easy one, and pretty much no high level person will be upset if you ask.
It's toughest with someone not used to answering this question, or someone who thinks of you as higher status - in those cases, you can't just say "tell me about you", you have to make them comfortable and coax them into getting excited to tell you about things they care about. That requires active attention and listening, and is not necessarily easy.
Asking people to tell you about themselves is never rude, in any case. If your conception of "rude" includes that, then you're gonna have a rough time in all but the most wonky parts of business.
> they invariably have a life story that they are practiced at and enjoy telling, and know how to answer this question in a really satisfying and engaging manner because it's been asked so many times.
Yeah the point is you have prepared and practiced an engaging "sales pitch" for yourself. If you are experienced in networking or interviewing this is second nature to you. But it would be pretty rude to ask outside of a professional or networking setting IMHO. You are challenging the person to "sell themselves" to you, which is highly inappropriate outside of business.
I agree that it comes off as pretentious to a lot of people if you open with that in any normal context. I think the right context for it is if you are expected to be sharing life stories, e.g dating, interviews, networking and stuff like that. I think Terry Gross gets away with it in other contexts because she's a famous interviewer.
"Tell me about yourself" is not question, it is instruction. You give instructions and expect other one to obey them.
The discussions where the other person don't expect me to be the one who has to reveal all details or where I get to ask questions too are more comfortable.
> If the curvature were slightly less than 1, the topology would be "closed", meaning it would be finite, and traveling in a straight line ends back where you started.
Doesn't this require the assumption that the spacetime is embedded in a higher dimensional spacetime?
It's been a while, but IIRC there are perfectly valid topologically open cosmologies that have locally sphere-like curvatures (in other words, there's no necessary connection between curvature and topology without adding an embeddability constraint), right?
> You're assuming that it was based on whether or not the candidate was hire. Nobody with an iota of experience in machine learning would do something like that. (For obvious reasons: you can't tell from your data whether people you did not hire were truly bad.)
It's a fine strategy if all you're trying to do is cost-cut and replace the people that currently make these decisions (without changing the decisions).
I agree that most people with ML experience would want to do better, and could think of ways to do so with the right data, but if all the data that's available is "resume + hire/no-hire", then this might be the best they could do (or at least the limit of their assignment).
If they were using any sort of neural networks approach with stochastic gradient descent, the network would have to spend some "gradient juice" to cut a divot that recognizes and penalizes women's colleges and the like. It wouldn't do this just because there were fewer women in the batches, rather it would just not assign any weight to those factors.
Unless they presented lots of unqualified resumes of people not in tech as part of the training, which seems like something someone might think reasonable. Then, the model would (correctly) determine that very few people coming from women's colleges are CS majors, and penalize them. However, I'd still expect a well built model to adjust so that if someone was a CS major, it would adjust accordingly and get rid of any default penalty for being at a particular college.
If the whole thing was hand-engineered, then of course all bets are off. It's hard to deal well with unbalanced classes, and as you mentioned, without knowing what their data looks like we can only speculate on what really happened.
But I will say this: this is not a general failure of ML, these sorts of problems can be avoided if you know what you're doing, unless your data is garbage.
> It wouldn't do this just because there were fewer women in the batches, rather it would just not assign any weight to those factors.
That's exactly the issue we are talking about here. Woman's colleges would have less training data so they would get updated less. For many classes of models (such as neural networks with weight decay or common initialization schemes) this would encourage the model to be more "neutral" about women and assign predictions closer to 0.5 for them. This might not affect the overall accuracy for women (as it might not influence whether or not they go above or below 0.5), but it would cause the predictions for women to be less confident and thus have a lower ranking (closer to the middle of the pack as opposed to the top).
I don't think I'm with you. A neural net cannot do this - picking apart male and female tokens requires a signal in the gradients that force the two classes apart. If there's no gradient, then something like weight decay will just zero out the weights for the "gender" feature, even if it's there to begin with. Confidence wouldn't enter in, because the feature is irrelevant to the loss function.
A class imbalance doesn't change that: if there's no gradient to follow, then the class in question will be strictly ignored unless you've somehow forced the model to pay attention to it in the architecture (which is possible, but would take some specific effort).
What I'm suggesting is that it's likely that they did (perhaps accidentally?) let a loss gradient between the classes slip into their data, because they had a whole bunch of female resumes that were from people not in tech. That would explain the difference, whereas at least with NNs, simply having imbalanced classes would not.
supposing waiter and waitress are both equally qualifying for a job, and most applicants are men, won't the ai score waiter as being more valuable than waitress?
Not generally. The entire point being made is that whether one feature is deemed to be more valuable than another feature depends not just on the data fed into the system but also on the training method used.
Specifically, the gp is pointing out that typical approaches will not pay attention to a feature that doesn't have many data points associated with it. In other words, if it hasn't seen very much of something then it won't "form an opinion" about it and thus the other features will be the ones determining the output value.
Additionally, the gp also points out that if you were to accidentally do something (say, feed in non-tech resumes) that exposed your model to an otherwise missing feature (say, predominantly female hobbies or women's colleges or whatever) in a negative light, then you will have (inadvertently) directly trained your model to treat those features as negatives.
Of course, another (hacky) hypothetical (noted elsewhere in this thread) would be to use "resume + hire/pass" as your data set. In that case, your model would simply try to emulate your current hiring practices. If your current practices exhibit a notable bias towards a given feature, then your model presumably will too.
Once your test suite is big enough that it won't run within a minute or two, it's kind of hard to keep a "green on each commit" workflow, though. Especially with UI and visual diff tests in the mix, I certainly don't want to tie up my local computer for a full test run when I'm just fixing a small bug; pushing the commits in a branch and letting the full suite run against that while I move on to another task is a much better use of resources, and that's where the PR model seems most useful to me.
Are there workflows that avoid this problem but still enforce every commit being green?
Sure, I separate heavyweight tests out into integration/acceptance tests (the side effects make them slow; the side effects mean they're not really unit tests). So, I don't commit until the unit tests pass, and then a PR triggers heavyweight tests on my build server, to be sure you're clean before the merge to master.
But if there's too much divergence between unit test and integration test pass/fail rates, then unit test coverage needs to be improved; obviously, easier said then done when you have old pre-TDD that's tightly coupled and/or code that's interacting with the system and incurring side effects that are hard/expensive to test.
In Phabricator you make your changes on a local branch, running "arc diff" to post or update a changeset. CI runs on each update to the changeset. You're expected to have CI passing before you "arc land" (squash merge to master and push), and usually before you solicit code review. Commit whatever garbage you want locally and even publish it to the Diff, but your code doesn't touch master in the central repository until reviewed and passing.
Will the other tech companies be remembered for never resisting in the first place? IIRC Microsoft and Yahoo we're both like "censorship and tracking? HELL YEAH, where do we sign?" from day one.
That's quite different than Google tying search queries to a phone number. Though I also don't agree with censorship in Bing's regard either. Also from my understanding a lot of Bing/Yahoo results aren't "official policy" and the reports of censorship from 2014 have been addressed, a lot having to do with simplified Chinese characters/bad translation. Google even has higher share in China than Bing. Google already operates in China with .cn domain through Hong Kong, the new action is an entirely different posture.
Yeah...and that thread says that the change is basically nothing, just a UI indicator:
> Q: I don’t get, though — if you’re signed in to the browser but sync is off, then what does it mean to be signed in to the browser? What does it do besides sync?
> A: Not much, you can think of it like a Gmail login state indicator.
If that's fully the case, then there's nothing to see here and people are freaking out over nothing. Am I missing an important element here, other than that people don't trust Google?
@__apf__ is being slightly disingenuous when she says "Not much ... like a Gmail login state indicator." Google logins are used across the web by a lot of sites. For instance here's what happens when you visit an Indian financial paper, the Economic Times, using Chrome 69: https://imgur.com/a/nFvxI0U (some personal info has been blurred out).
I almost never visit the Economic Times, and I certainly never log in, but now it gets a chance to log me in using my 'real' identity, and there's even a popup to nudge me in that direction. Any site that implements Google Logins can do this, as far as I can tell. I'm pretty sure most people who chose to enable browser sync in Chrome didn't opt for this.
I think the Chrome team really screwed up on this by not considering how Google IDs are used across the web. And for what? The rather marginal scenario of eliminating confusion in shared-browser situations?
Or they knew the full implications and did it anyway, which is even more disturbing.
It all makes sense if the end goal is for the browser to push google login across the web, and make google accounts the preferred way to log in to websites. In that case they're doing you a favour, it's all in your best interests, as well as Google's of course. [/sarcasm]
I simply don't trust a single corporation that much.
They are not doing me a favor. Software companies need to stop believing their own paternalistic propaganda. Nobody at Google is in a position to determine whether they are doing me a favor or not.
It's not the case though. Google's privacy policy has two different "modes" for Chrome, one for being logged in and one for being logged out. By tricking people into logging in without their consent they are also tricking people into allowing that extra data to be collected.
Their current argument is that they aren't actually collecting that data- just getting permission to- but that's kind of sketchy and still leaves them open to other changes that do start collecting things.
The other big issue people have with this is that the use case they're talking about- accidentally logging into a site and not logging out- is an issue with all websites, not just Google. Adding a UI for Google services explicitly is something only Google could do, which makes their browser less "neutral". This is why people keep bringing up antitrust. By taking advantage of their monopoly to further entrench that monopoly they are breaking the trust of their users.
You're misreading the privacy policy. Google's privacy policy has two modes, one for sync on, and one for sync off. Logging into Chrome does not turn sync on, so you can be logged into Chrome and still covered by the "basic" privacy policy.
They aren't actually collecting that data because you haven't turned sync on.
Yeah, well, but what keeps them from silently changing that, seeing that users are already logged in? The UI for the sync preferences is sketchy at best as it is right now and you're basically just one misclick away from handing all your browsing data over to Google.
It's almost a certainty that they will continue down the slippery slope and start syncing data automatically in a future update. That sort of change has happened several times, so there is precedent.
The acronym simply means either product manager, project manager, or program manager, but the responsibilities can be any/all of the following, and probably more, depending on the company:
- Full product owner, "the buck stops here" person. Many different possible titles here other than PM (usually "project manager" if that's the title), like general manager (GM), different flavors of producer, product owner (PO), VP of X, etc.
- Feature designer/owner/manager (product manager): writing specs (junior), pitching specs (mid-level), setting and selling product vision (senior), driving strategy (staff/exec, though at that level all roles start to get blurry). Decent business school grad representation here, you have to be good at strategy, negotiation, communication, and Powerpoint; having good product ideas helps a lot, too, but not if you can't sell them. A persuasive PM of this type is a force to be reckoned with and will get a lot of executive attention, which can be very good or very bad depending on whether the strategy they're into pans out or not. This is probably the type of PM the parent was talking about "armies of".
- Development director (project manager or program manager): a whip-cracker at worst or an impenetrable shitshield at best, they manage the practicalities of running a project, like project scoping, meeting and managing hard/soft deadlines, handling support, cross-team communications, processes, compliance, etc., often stepping in as an all-purpose guard against randomization so that others can focus on producing the product. Many PMs of this type ended up being the go-to folks for GDPR compliance over the past couple years, so it's not just internal process stuff that they deal with.
- Task checker: can blend into to the development director mentioned above, but at some companies this sort of PM will mainly focus on tracking tasks that are in-progress, getting estimates, watching velocity, and sending reports up the chain. Some devs find this role pointless and annoying, but it really depends on how good they are - if they're solid, they'll find a lot of ways to improve things instead of just tracking them.
- Scrum Master (project manager): Big-S Scrum is falling out of favor so it's not as fashionable to have this title anymore, but within some processes a similar role still exists as a type of project manager. In a nutshell, Scrum is a simple yet effective "People Over Process" process that consists of a bi-weekly no-laptops-allowed retrospective meeting where you get the team together to have a free-ranging discussion where everyone feels heard, so that you can all decide together whether the team should estimate engineering tasks in terms of hours or hats. You need a trained and certified Master because otherwise people new to Scrum might not know to pick hats. A more seasoned Scrum Master will also schedule a quarterly retrospective-retrospective where the team discusses a strategy for what guidelines to put in place for the next retrospective so that the team can decide on hats faster and leave more time for the less settled question about whether or not the Fibonacci sequence is the right way to count hats or if a size-based approach will make people feel better supported in their work.
- Monetization designer (product manager): mainly at game companies, PM is often a super different role, probably best described as the profitability-focused counterpart to a game designer. They focus on setting prices, managing game economies, speccing and evaluating A/B tests, inventing loot boxes, etc. Ideally PM and designer would be one and the same, and the game design would be holistic with the monetization, with a designer that has serious Excel/analytics chops and deep inspiration and sensitivity about gameplay, but that's a more rare combination than you'd think, so a lot of companies split them out.
I'm probably missing some other ways this acronym is overloaded, but I think this covers most of it.