Google dealt setback in age bias case by judge interested in 'Googleyness'
computerworld.com
computerworld.com
I feel (anecdotal only) that it's pretty easy to approximate age due e.g. to lexicon and potentially dialect, and that it's even easier to pick up on certain vocal changes in older candidates, so I can see the argument in favor of including phone interviews in the class.
That said, the argument for restricting it to only people who passed the phone screens appears to be that the phone screen establishes an initial impression of qualification (skimmed from page 13 of the ruling; I could be entirely wrong and could've quoted an irrelevant passage, but I'd like to think this is accurate):
> The proposed class would include an unknown number of “applicants” who demonstrate no plausible qualifications for the job. To establish a prima facie case of an ADEA violation, the plaintiff must show, among other things, that he was qualified for the position.
https://www.scribd.com/document/326637833/Google-Age-Discrim...
If you're trying to fill a junior position, then you don't want to hire someone who has been working as a chief architect for the last 10 years. It's not about their age. It's about the fact that they are way overqualified and will probably quit as soon as they can find something that they are qualified for.
That's not necessarily true. Maybe they burned out and want a less stressful role. Or maybe they've cashed out and are looking for a job they would enjoy and can afford to not worry about the paycheck. Frankly, job titles can also be pretty meaningless.
If I saw a resume on my desk for a junior role with somebody with senior experience I'd probably ask them "why are you looking to move into this role?". I wouldn't rule them off outright, because I understand that people's circumstances often change, and not everybody is driven by a career trajectory that's constantly moving upwards.
https://hbr.org/2010/12/the-myth-of-the-overqualified-worker
Someone who is in their 50s could have kids who have already grown up and moved out.
He was, by far, the best prof I've ever had. The Google experience was so distasteful to him he doesn't even list that employment on his resume.
The 'More Perfect' podcast had a great episode about Batson, jury selection, and racially motivated peremptory challenge that speaks to the same points (though sadly, still unresolved in our justice system). See http://www.wnyc.org/story/object-anyway/ https://en.wikipedia.org/wiki/Batson_v._Kentucky http://www.nytimes.com/2016/05/24/us/supreme-court-black-jur...
If the laws need changing then that's a discussion we should have. But you shouldn't be able to weasel around them by inventing a term and then equating it to things that are illegal.
I think of "corporativism" - where multiple interest groups are involved in creating policies. In Scandinavia they decided to allow companies to "fire at will" in exchange for free education and a good social safety net. But I think that system can be much improved, with much better alternatives.
since the value of people's hands and backs is rapidly decreasing, we need a much better framework for harvesting the important things like creativity from the working population.
I worked as a contractor for Google from 2008 through 2013 (along with other clients), building election results and voter information maps for their Maps and News teams. My maps ran on google.com and were syndicated out to a number of news sites.
How I got in was an odd fluke: I'd been active on the Maps API mailing list answering people's questions, and a couple of weeks before the 2008 Iowa caucus and New Hampshire primary, Google realized that the company they'd hired to build those maps wasn't going to deliver, so they asked if I could jump in and build something in a hurry that worked.
The first year I did the whole thing myself: GIS processing to turn geographic boundary files into usable form, back-end processing to gather vote data from AP and other sources, and the front-end UI design and map development. Among other things, I developed a way to display polygons on a map many times faster than the Maps API itself.
A couple of the maps blew up in a spectacular way (I managed to DDOS Google Code on Super Tuesday 2008!), but mostly they were pretty successful with millions of viewers.
After that a couple of Google developers handled the back-end vote processing and I took care of the GIS and front-end work, both for the US and a number of international election maps. For some of the international maps, local teams worked with my front-end code to enhance it for their needs.
It was a pretty good run and Google seemed very pleased with my work. Eventually a great team in their DC office took over the map development, and I started to think about what to do next.
One obvious idea, of course, was to apply for a job at Google! After all, I'd already worked for them rather successfully for five years.
But I didn't even apply. Perhaps this was a mistake on my part. I just had a feeling that my history of developing successful products for Google wouldn't count for much - that instead I'd get logic puzzles, quizzes about algorithmic minutiae and have to code a red-black tree on the spot on a whiteboard - all things that favor recent CS grads. Plus, I'd just turned 61!
I wonder how many other people there are like me, experienced developers with demonstrated ability, who never applied because of Google's interview practices (or the rumors about them)?
FWIW, I'm still actively programming, getting into something new every year or two - right now it's an odd mix of VR and Microsoft Office development - and definitely looking for the next great opportunity. Anyone who wants a multitalented developer and doesn't care how old I am, email is in my profile. :-)
This is actually a good point that there might be a strong bias in this towards fresh graduates who in most cases are younger folk.
Yes that seems to be how it works. https://twitter.com/mxcl/status/608682016205344768
"Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off."
My interview process with Google only made it to the technical phone screening because I didn't know the Big O complexity of read/write/sort for Trie structures. (https://en.wikipedia.org/wiki/Trie) The interviewer was pretty cool and we had an interesting technical discussion, so I wouldn't consider it a complete waste of time.
As a side note, I joined Google at age 39.
As the guy in charge of the DC office (and the google side of this at the time) - I happily would have hired you if I had headcount :-)
You did an amazing job.
(in fact, i specifically asked for HC intending to try to hire you a number of times, but at that point, the politics of getting resources in remote offices sucked)
I was contacted by Google several times but chose not to submit myself to an interview process which I feel is biased in favor of CS graduates and consists of exercises which provide little insight into the most important characteristic of a good software engineer; the ability to understand the nature of a given new domain, the problems to be solved in that domain, and good ways to solve those problems.
I cut my teeth on MIT's Computations Finite and Infinite by Minsky (now out of print), Donald Knuth's three volume classic, and later The Structure and Interpretation of Computer Programs, which, at least, I suppose recent CS graduates are familiar with. And many many books after those.
Over the subsequent decades I have developed many unique algorithms to solve specific problems. Most recently, the past month, I increased performance of a graph database issue by an order of magnitude by creating an abstract representation of the graph connections in RAM. That is not a terribly unique approach but somehow it never occurred to the CS types here that the cause of their performance problems was a failure to understand the fundamental nature of the problem being solved.
If Google's filtering consisted of solving a real-world problem, one requiring some days of research and development, then I'd be happy to go toe-to-toe with recent CS graduates. I know how to use The Google to find related domains, problems, and solutions. After understanding the nature of a problem research is step #1, regardless of whether I think I already know a good solution, it is almost always the case that someone has already solved a similar problem (if not the exact same problem), there is value in understanding the differences.
But I suppose that's not a practical filtering process for a company hiring many engineers and not having the resources to evaluate real solutions to real problems.
Also, side note, approximately 5% of the population do not imagine the same way the other 95% do. Like me they cannot, to varying degrees, actually visualize anything with their eyes closed. I never see anything but black with my eyes closed, when not dreaming. I suspect that this is related to my inability to do whiteboard exercises. I don't visualize, I think.
'nuff said
The one thing I'll say is that with your background, it's a shame you filtered yourself out. You might not have gotten through the interview process, but if you retained anything significant from what you cut your teeth on you also might have been more successful than you think.
http://nautil.us/blog/why-blind-people-are-better-at-math
It seems that I'm better at doing math in my head than most people. I've wondered whether that might be related to aphantasia.
Even a simpler real world problem whereby it takes days of research is not respectful of your time. I've seen people note they can't take a 6 hour time-out of their busy work/home lives to do coding challenges that are popular among startups.
So the balance is in-person interviews. Ones where you have to give difficult problems, ones you haven't seen before and ones that don't take days to explain. This usually means algorithmic, data structures, or mathematical in nature. They have subtleness, depth and complexity. As for 'reverse a string', you'd be surprised how many people who have "programming jobs" who apparently can't do basic programming.
And do I use these skill sat my job here? Yes. All the time. I'll spare you the spiel about "everything's different at scale". Google is a different kind of company that attempts to solve as many problems as possible with CS.
For reference, I work at Google, given interviews here, and passed the interview bar twice. Once at 29 and once at 39. Some of my coworkers are older than me. Many of them have children. Some are younger than me. I see plenty of people in the office with grey hair (I work in the SF office).
I refuse to defend past practices, but I believe the company currently sincerely overall seeks to be the best employer for any age. Small pockets of suck happen, but the internal transfer rules let you switch without your manager's permission. The interview process is known to not be perfect, but that is inevitable for any process - nothing is ever perfect!
However, the interviews do involve whiteboard problem solving. I understand some can't do it, and this is one of the blind spots. I personally love diagrams, and think visually, so it works for me. I also prefer when my colleagues use diagrams as well.
About diagrams.
I had the whiteboard experience once and will avoid repeating it.
When I get a problem I want to sit back and think about it. The interviewers kept insisting that I draw diagrams, and that interrupted my thought process, they were not impressed.
However that does not mean I am incapable of making diagrams once I've sorted the problem out in my mind. After I've arrived at a proposed problem solution I like to produce a written document with just enough information to convey the problem and the solution approach, together with whatever diagrams, data structures, and pseudocode are required to communicate.
That's how I roll. ymmv :)
As a side note, I think there are fundamental limitations to "solve entire problem in mind" - tooling, including written word, pens, pencils, crayons, paper, documents, diagrams, whiteboards, provide methods for expanding your working memory.
One other thing "just enough information" is a phrase that worries me. I've seen a lot of academically written papers that basically "by implications you should know that the resulting answer is X". I'm not sure this is your style or not, but it is one style that personally I believe has no place in the workplace. Convey your ideas clearly, and help your coworkers.
With regard to your other two points I either wasn't clear or you took my comments too literally. Be that as it may, let me clarify.
I do form my entire impression of the problem and various solutions entirely in my mind, without the aid of external memory. However, and this is important, that evolves out of research. During research I build something like an intuitive understanding of the problem. Along the way I consider possible solutions to the evolving problem, solutions by others or that happen to occur to me. Eventually, usually at night when it's quiet, I have an insight, which often turns out to not be quite right. Rinse and repeat until I have something that seems good. At which point I will sketch out some data structures (as struct or object like things, or simple diagrams) and some pseudo code to operate over the data. If that finds a flaw in my idea I go back for more rinse and repeat cycles.
When I say "just enough information" I mean just enough for any engineer with sufficient experience and background to fully understand the problem and solution. I don't leave anything out, I want feedback and I don't want the feedback to be "huh?". By "sufficient experience and background" I am leaving open the possibility that there might be someone in the group who doesn't quite get it, but to tell the truth most good solutions to most problems turn out to be reasonably simple, simplicity is one of my target criteria. Simple solutions are easier to implement, less likely to have bugs, and if the solution is both simple and good the performance is likely to be at least acceptable as well.
Better? :)
There are several organizations that are doing this in my country, but for immigrants.
Of course they still might not hire the more experienced person because she is "overqualified".
1. Company X is smart enough to never record this illegal policy in documents/email/etc.
2. The policy is verbally communicated to all recruiters and many upper managers.
3. Company X is growing and employs hundreds of recruiters.
If the recruiter turn-over at company X is similar to other companies (i.e. it's pretty high), it's only a matter of time before a recently fired recruiter talks to a lawyer or the press.
The simpler thing to do is only advertise very low-level positions and pay new hires poorly enough that only new grads will apply in the first place. Of course, then you've got to develop the folks that you hire or have a model that is predicated on just throwing large numbers of people at problems.
https://www.fordfoundation.org/ideas/equals-change-blog/post...
You seem to be implying that a company that wanted to grow their workforce is better off actively filtering out people on the basis of their age. Why do you think that?
That's reflected in the very names of some organisations, e.g., "limited liability corporation". Incorporation is itself fundamentally a risk-control technology.
The permatemp lawsuit against MSFT ended up being completely counterproductive. Now temps have to take a "vacation" every X years for at least 100 days. So temps at MSFT have LESS job security after "winning" their lawsuit.
Be careful what you wish for - the laws of unintended consequences.
I know that's a generalization, but given Google's data on people, I think it would insanely simple for them to discriminate based on age even if you tried to hide it from them.
I don't know, clearly, but I would guess Google and other tech companies do this because it's cheaper to hire young people, right?
- It's more expensive to buy health insurance for an older pool of employees.
- Young people are probably less likely to be dissatisfied with cheap work accommodations like open-plan offices.
On the other hand, there are increased efficiencies associated with older employees:
- People earlier in their career might have significantly higher job-turnover rates.
- Older employees have more work experience, and can prevent lots of problems before they happen.
- Older employees have had the time to become better at what they do. I don't think the best developers reach their peak skills after only working for 5 years.[1] Learning from your mistakes takes time.
(I'm a developer in my 50s, and I work with lots of older developers who are good at what they do.)
[1] See, for example, Peter Norvig's "Teach Yourself Programming in Ten Years": https://norvig.com/21-days.html
Until we disconnect health insurance from employment like everywhere else in the world, ageism will be a problem in every industry. We don't get auto, life, home or any other insurance from employment, why the most important and one that contributes to ageism?
I agree that US health care should catch up with 20th century advanced nations.
As the demographics change does a company's workforce have to change along with it, if so to what degree and with what allowable lag?
For example males tend to have resume's which over qualify oneself vs females. Asians and Westerners also have these kind of differences.
This causes the rate of resume to hire to be different for different demographics.
Generally though interview feedback will state the facts and can be pulled up to back a companies actions. This is what needs to be judged.
Sure, I understand all the -isms of the world make it so that we can't have nice things.
But what if a business figures out that a certain demographic, young or old, fits their business better? That over the course of 10+ years it leads to drastic differences in value creation? Are we really saying, ignore that, and hire for diversity anyway?
It just always feels like we're running against the wind. I don't know what the solution is but there has got to be a better way, to sound cliche at 9:55AM.
The only time I've heard google accused of that was the Hillary and Trump liar autocomplete thing, which was completely false.
Of course there are people manipulating search results from the outside, SEO is a job. But are you saying you have evidence that google is doing manipulation, or just that other companies do it?
> The lawsuit claimed the median age at Google was 29, based on data collected by Payscale, which the judge cited in the ruling.
Article also said that Google's going to guesstimate ages based on graduation dates in order to provide evidence of applicant ages. But knowing the median age of applicants is critical. It's a shame they included the median age of employees without including the median age of applicants in the article. "29" might match perfectly with the applicant pool.
This is an honest question, I think I can imagine some scenarios where unequal age distribution != age discrimination, but I'd like to hear others thoughts.
It could quite easily not be ageism if the distribution of the skills actually sought and relevant to the job were not equally distributed by age within the applicant pool. Providing direct evidence of this in court may be difficult (or not, depending on how Google documents its interviews.)
(And, really, the scenario where the age distribution matches because of age discrimination is also possible, for the same reason.)
- Preference for new technologies or languages will favor people who were recently trained or recently spent a period training, which will tend to be people younger in their careers. Can test for this bias versus ageism by comparing pairs of candidates with similar learned technologies, and seeing just their outcomes. (May have to control for confounding factors, though.)
- Preference for candidates who are willing to accept more intrusive or abusive working conditions. This will tend to skew towards people with less work experience and fewer other commitments in life, which again would bias towards younger candidates. Again, you could test for this versus ageism, but the pairings of matched candidates becomes harder because it depends on psychological profiles and life circumstances.
- Google has a bona fide business reason to prefer recent graduates (ie, even if this is agist, it might still be legal), because there's a higher variability in their career engineering RoI (lifetime value generated over lifetime cost to employ) versus established engineers, and Google's main mechanism of value creation is people farming -- getting high returns on engineers, which requires the underlying variability of recent graduates to generate high returns. It's similar to CDOs on mortgages: you can generate a higher return by increasing the variability of the underlying asset and decreasing the risk of systemic failure. Google just does that with engineering talent. This is testable versus ageism by pairing people based on recent graduation, or a score of outcome variability, and see if Google is preferring highly variable people.
I would expect that the reality is a combination of these, often enacted by different departments: HR prefers the abusable hires; technical interviewers prefer the new technologies and languages; both prefer the variability, as part of a broader corporate strategy, and because it provides benefits to each department individually.
However, with several legitimate business decisions each giving a slight bias towards younger candidates, you can get a situation with a heavy hiring bias against older candidates without any agist policy in place (or any agist bias on the part of hiring manager or interviewers), simply because lots of other developmental processes correlate highly with the process of aging.
It's actually not a bad system for fresh graduates. If they studied hard in college, all that DS and algorithm knowledge should still be fresh. And it's away to see who studied in college and who didn't. But it's only useful here because there's nothing else to look at for fresh graduates, they have no experience.
However, it's a very bad process for senior engineers. Google should have a different process for seniors, but they probably don't care enough to change.