As a result of this, could companies be expected to have a workforce age profile reflective of the local area or national pool, as might be the case in other recruitment efforts? How would they do by seniors or those approaching retirement age and reflecting those proportions in their workforce.
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?
I take issue with that. What if it's graduation time and a whole group of graduates without experience decide en masse to apply somewhere. Or lets say a group of retirees are given an assignment to liven up their lives and apply at places they would not normally consider. There are reasonable expectations.
It's more complicated than that. Even given that there is no demographically inherent advantage (something I generally believe), the hiring process is only one of the last steps in a long pipeline that can be damaged earlier on to skew the ratios.
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.
> The judge limited the class to people who had an in-person interview, which means that job applicants who only had phone interviews can't join the class.
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.
In addition to age discrimination (telling apart) via lecicon choice, one can also listen for heavy breathing, lethargy, etc. and come to conclusions which could be counter to proscribed hiring practices.
You can usually tell from a roughly how old a person is just from reading their resume. If they list themselves as a team lead in 1990, then you can be pretty sure that they are at least 50. I would guess that the judge wants to limit to people who had in-person interview because that shows that they were at least close to getting the job. If you have gotten past the phone interview stage then you have already demonstrated basic competence.
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.
> 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
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.
You're right. I probably oversimplified to save on typing. I actually work with a person who is 60ish and has held considerably more senior roles in the past. He seems pretty happy in his less senior role. I think he wanted something a little less demanding.
Older users of HN, would you mention requirements that possibly indicate older age in your phone interview? Like requirements for location and hours that may indicate or be justified by family priorities? I feel like those must be quite common and would necessitate the class include people who just phone screened..
I'd say it's more related to family than age. I'm very old by developer standards but have no problem relocating. Yet young developers with kids often don't want to relocate.
Ok down-voters. I left the search industry over my refusal to participate in search manipulation. So which part are you down-voting. The idea that it exists? or do you think I'm some alt-right conspiracy nut? I'd actually like to know. I don't care about points but I'm getting the message that I belong on HN and I'm perfectly happy to quit on the assumption that HN punishes dissent.
I didn't downvote. But I don't believe google does paid search manipulation.
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?
I'd really like to see problems like this addressed in another way. I'd like to see that people have other alternatives - so that being turned down for a job isn't a life destroying experience.
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.
thats a great trade. trying to address these issues after the fact by establishing protected classes, affirmative action, hiring diversity programs and punitive law suits is a losing game for so many reasons.
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.
Fallout from this: Companies will go to great lengths to avoid contact with people who submit resumes that imply they are old. No phone screens, no responses. It's going to be wintertime for folks in their late 30s now.
That would be great! Insta-lawsuit. Age is a protected class in the US, and if it is discovered that your company did something like this you are going to be paying out bigtime.
That's very difficult to do for age. If one applicant is 20 years older, he is expected to have longer work experience; if his work experience is too short, it's a red flag.
Of course they still might not hire the more experienced person because she is "overqualified".
If the two applicants have equal qualifications and you only hire the younger applicant then you are going to be open for an age-discrimination lawsuit. Being older and having a shorter relevant work experience is the sort of 'red flag' that puts you on the losing side of these lawsuits, as the two candidates are manifestly equal by definition here other than differences in age. You can't say "person X is older and should therefore have more work experience, so we will pick person Y" and expect to not end up spending the next few years in court.
Who puts age on a resume? But if you're suggesting age as measured by years of experience, that's supposed to be the most relevant deciding factor, so...
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.
As others have noted, you do it the same way EEOC and other orgs test for hiring discrimination based upon race or gender. You submit equal resumes (appropriately updated for age in this case) and see what response you get. You take a look at the company org details and do a few simple statistical runs to see how things net out. Since this is a protected class we are talking about it is a lot easier to make your case based on statistical evidence. "Gee your honor, it is purely a coincidence that all of our employees are <male/white/under-30>"...
If the goal of your company is to avoid getting sued, then you don't actually have a company. Companies hire to achieve real goals.
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?
Enterprises are ultimately comprised of moultiple goals, many of which involve mitigating or controlling for both upside and downside risk.
That's reflected in the very names of some organisations, e.g., "limited liability corporation". Incorporation is itself fundamentally a risk-control technology.
There are definitely companies that structure their internal processes to avoid lawsuits. My father was the CFO at one company that didn't keep written or electronic performance review records for that reason.
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.
The goal of the temp lawsuits, at least when I was at microsoft (in a fulltime job) imho was to get tons of money for the stock options they would have received if they had been regular fulltime employees. They were almost full timers, except they didn't have stock, and they had a small chance of not being employed.
Google accepts such a terribly small slice of applicants that it's easy for any engineer in the top 0.75% of overall engineers to think they're talented and deserving but come to find out they're just not in the top 0.5%. That distinction can be really hard to see and easy to attribute to ageism. That said, I suppose there could be some actual ageism going on too.
> 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.
The natural way to test this would be to see if the age distribution or applicants matches the age distribution of hires. If so, probably not ageism. If not, how could one argue that it's still not ageism?
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.
> The natural way to test this would be to see if the age distribution or applicants matches the age distribution of hires. If so, probably not ageism. If not, how could one argue that it's still not ageism?
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.
What if the older people who apply to google aren't as good as the young ones? Or what if they want more money? Both ways, you could have a fair process, but the distributions won't match.
The software field really needs to stop associating "top engineer" with Google interview process. The Google interview process has nothing to do with "top engineer". The only thing it measures is how much time you spent studying DS and algorithm books. It's just like the SATs for college, study and you do well, but has nothing to do with actual college work. There is only one correlation and it's as a measure of work ethic. If you study hard for SAT, you will probably study hard in college. Same thing for the Google interview.
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.
In addition to people who made it through a phone screen and got an in-person interview, there are those of us who simply never applied after hearing so many stories about Google's style of interviewing and their reputation of favoring young CS grads.
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. :-)
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.
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.
> 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.
"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.
That guy outed himself as just the kind of jerk that hiring pipelines are designed to identify and reject. Inflated opinion of own importance, attitude of entitlement.
Given that he develops software that Google engineers use frequently, I wouldn't exactly say he is inflating his sense of importance.
It sounds like he is a good software developer who has developed something widely used and appreciated, but the Google hiring script doesn't deal well with those kind of people.
It takes a lot of time and effort to go through interviews, I don't blame the guy for being pissed off that Google wasted his time.
Just because a piece of software is frequently used doesn't mean the engineer that wrote it is top of the field.
Calculator is a pretty widely used app, too, even by Google engineers. But that hardly qualifies the author to work at Google.
Similarly while Homebrew is widely used and fits a need, it doesn't mean that the author is equipped with the skills that Google wants. A package manager and something like Google Brain don't exactly share much in common. It doesn't mean Google's script failed nor does it mean he shouldn't be pissed off, it's just how things are sometimes.
It was an excellent argument against "inflated opinion of self importance" though. If you write something that's as widely used by developers as homebrew, you've earned that right.
So what if random Googlers could also have written it? They didn't.
"It was an excellent argument against "inflated opinion of self importance" though. If you write something that's as widely used by developers as homebrew, you've earned that right."
No, you actually never earn that right.
Seriously.
In fact, it's a sign of good engineers that they just view their stuff as stuff, and not "well, i am doing the super important stuff, everyone else is not".
Note that this is different than prioritizing, etc.
If you have a bunch of high level engineers in a room, and they don't value each other's work (IE recognize that a lot of stuff is "important", and there stuff is just part of that) because they think the stuff they do is super-important, that's going to go very badly.
At lower levels, pretty much none of it is so important that there is any value to having an inflated opinion of self importance.
The fact that you've achieved adoption does not necessarily make you a good engineer.
"well, i am doing the super important stuff, everyone else is not".
Straw man argument. Nobody stated this.
There's also a difference between thinking that your stuff is super important in isolation versus simply pointing out it's in wide use at a company and hence your previous efforts have in fact been productive and useful for them.
I guess I dont think anyone has EVER earned the right to have an "inflated self opinion". Acting like a jerk, being entitled and demanding things are never something earns. That's just not ok behavior.
I talk to people about interview stuff, I notice that most people who say "I shouldn't have to know X" seem to be the least intellectually curious, least great problem solvers and just generally combative folks. If you are going into an interview with a serious chip on your shoulder, demanding a job, asking to exempt yourself from having to show problem solving skills, then just how is that going to work out?
Regarding reversing a binary tree, yeah, the interviewer didn't expect you to know it. That's the point. It's something that's a little tricky, not impossible, requires you to be precise about memory ownership and pointers, and algorithmic. It takes no time at all to describe, and isn't impossible to solve. Yeah it's problem solving, but it's not random trivia. It's a functional test of your intelligence and yeah it filters out some who should be at Google, and they know it. However relaxing the bar is fraught with peril. You're quite literally banking the future of the company on it.
You shouldn't have an inflated self opinion. (Duh!) But those were the words used to describe mxcl just because he opinionated that Google ought to have given him a more serious consideration given the software he had already produced.
It's my opinion that wasn't an unreasonable assessment (from mxcl). Although if indeed nearly nobody at Google uses Homebrew, as now multiple people are claiming, it was, no matter how reasonable, wrong.
So here's the thing.. he was given the STANDARD interview that every engineer has to pass. How was that not a serious consideration? How is it fair to his future potential colleagues that he got in "easy"? They need to depend on him and his problem solving abilities.
I think he saw the question, and basically just refused to grapple with it, thinking it was below him, and then the rest pretty much was inevitable.
The number of googlers who meaningfully "use" homebrew in the course of their work is probably 4 or another figure similarly close to zero, which should therefore be treated as zero. If it didn't exist and someone needed it, they would write it in a week.
The number of googlers with Macs is not even 90% so this line of argument is just silly.
As an engineer at Google, this comment is correct. Some teams use it, but since most the development happens on Linux desktops, and not Macs, therefore Homebrew is not as commonly used as normal dev shops.
Basically the internal dev environment is already fully complete and works great. It's ultra custom and there are strict rules about bringing in open source code. The AGPL and GPL3 are good, but also one has to be wary about them in a commercial environment.
Yeah, that' totally the take-away message from that.
Not "it's how i personally view the attitude that because what i did is used by a lot of people, i'm super-important".
> Given that he develops software that Google engineers use frequently, I wouldn't exactly say he is inflating his sense of importance.
He may be important as a person who has developed software used by a variety of people (including many at Google), but that doesn't mean he is someone who ought to be important for Google to employ.
i wouldn't expect someone to know how to derive big-o bounds, I'm 45, an engineer at google and I couldn't do it if asked on the spot. I would however expect you to know of the basic asymptotic performance of typical data structures and algorithms. As a practical matter I've seen a number of critical bugs in software because of mistakes in choosing data structures.
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've been programming 40 years, turned 66 this year and I'm just as enthralled by computers as I was when I started, still working full-time, and still learning as often as my girl-friend will allow time for.
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.
I have what's been coined "aphantasia" too--no mind's eye--and I do fine on whiteboard interviews as a general rule. That suggests to me that it's either not your root cause, or it's one you can work around. Personally speaking, I can still conceptualize code (typically as a semi-physical machine, actually), I just can't "see" it. If you're a successful programmer, I'm sure you have some way you conceptualize algorithms too, even if it's not visual.
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.
Also, about algorithms, I walk through them a step at a time, keeping track of where things are in my memory. :) Once upon a time I could play an amateur level game of blindfold chess the same way. It never occurred to me that when Walter Browne was playing blindfold chess for money on the beach at Santa Monica before the 1976 US Open, with money and time odds 5:1, that he could actually see the board. I'm less impressed now, but was nowhere near his level anyway even if I could see the board.
Your memory is better than mine. I work from an abstract level downwards in a "how would a machine that does this thing work" sort of way, decomposing the machine into parts as I go. Interesting how different people have different approaches.
That is interesting. I'm pretty excellent at math concepts in general (750 SATs in math once upon a time) but can't do arithmetic in my head to save my life. It wouldn't surprise me at all if there's a relationship there, especially for processes like multiplication or long division where you have to hold an intermediate result.
The best real world problems I encounter at Google take months of learning to fully comprehend. They are not trivial, and have a huge base.
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.
Good points. I do understand that Google has no reason to modify its interview process to accommodate my personal style, but then I'm not really complaining, I just never wasted my time applying.
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.
Here's the thing... without explaining your thought process, how do you even demonstrate you have one? How do you get depth of understanding? It's via a conversation, over a hard problem. With lots of stops in between.
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.
I would be entirely comfortable in an interview explaining my thought processes and if I stumble into a whiteboard interview again I will try to do that. The result couldn't be worse than my previous result.
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.
FWIW - I went through the google process. Even though most of the people were very nice, I agree their interview process is not suited for diversity. I applied for a PM position at the time. I specifically said to the screeners (btw, they reached out me) that I was an enterprise software PM and all the questions related to the consumer side of the house. I told them flat out that i was interested in the GCP team. They said they hire "generalists". It wasn't a good use of time although at least I have first hand exp now. I suspect that's why they are having a tough time getting enterprise customers to use their cloud relative to AWS. I heard a rumor recently that Diane Greene is trying to change the hiring process for GCP in particular. Anyone know anything about that?
FWIW - I went through the google process. Even though most of the people were very nice, I agree their interview process is not suited for diversity. I applied for a PM position at the time. I specifically said to the screeners (btw, they reached out me) that I was an enterprise software PM and all the questions related to the consumer side of the house. I told them flat out that i was interested in the GCP team. They said they hire "generalists". It wasn't a good use of time although at least I have first hand exp now. I suspect that's why they are having a tough time getting enterprise customers to use their cloud relative to AWS. I heard a rumor recently that Diane Greene is trying to change the hiring process for GCP in particular. Anyone know anything about that?
I personally have only had a single phone screen with Google, and for only a data analyst position. It was one of the worst phone screens I've ever endured: antagonistic, unfriendly, and all around miserable. In contrast, phone screens with Amazon and Walmart for analyst and data scientist roles have been stellar, even enjoyable. After the miserable experience with the phone screen I have little interest in applying with them in the future. I've even been an Android and Chrome user for years--a Google diehard fan--but the experience made me consider my allegiance. I was expecting better from Google. They don't have to hire me, but I don't think it's too much to ask to expect to be treated with respect and courtesy.
I really don't know how I feel about the government legislating stuff like this.
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.
I share your sentiment. *ism is undoubtedly a bad thing, but legislating against these things feels like a particularly slippery slope. What next: sue modeling agencies for hiring young, attractive people?
Isn't it pretty easy to tell the age of someone by their resume? I mean, if they put the year they graduated college, that means they were 22 or close to that, right?
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 easier to convince young people to accept lower salaries and work long hours (e.g., if they have no family to support or spend time with).
- 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.)
> It's more expensive to buy health insurance for an older pool of employees.
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?
107 comments
[ 2.8 ms ] story [ 177 ms ] threadAs 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.
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 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.
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?
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.
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.
> 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.
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.
Given that he develops software that Google engineers use frequently, I wouldn't exactly say he is inflating his sense of importance.
It sounds like he is a good software developer who has developed something widely used and appreciated, but the Google hiring script doesn't deal well with those kind of people.
It takes a lot of time and effort to go through interviews, I don't blame the guy for being pissed off that Google wasted his time.
Calculator is a pretty widely used app, too, even by Google engineers. But that hardly qualifies the author to work at Google.
Similarly while Homebrew is widely used and fits a need, it doesn't mean that the author is equipped with the skills that Google wants. A package manager and something like Google Brain don't exactly share much in common. It doesn't mean Google's script failed nor does it mean he shouldn't be pissed off, it's just how things are sometimes.
So what if random Googlers could also have written it? They didn't.
No, you actually never earn that right. Seriously.
In fact, it's a sign of good engineers that they just view their stuff as stuff, and not "well, i am doing the super important stuff, everyone else is not".
Note that this is different than prioritizing, etc. If you have a bunch of high level engineers in a room, and they don't value each other's work (IE recognize that a lot of stuff is "important", and there stuff is just part of that) because they think the stuff they do is super-important, that's going to go very badly.
At lower levels, pretty much none of it is so important that there is any value to having an inflated opinion of self importance.
The fact that you've achieved adoption does not necessarily make you a good engineer.
Straw man argument. Nobody stated this.
There's also a difference between thinking that your stuff is super important in isolation versus simply pointing out it's in wide use at a company and hence your previous efforts have in fact been productive and useful for them.
This is pretty much exactly his attitude, even if he did not explicitly add the other 3 words.
"in wide use at a company and hence your previous efforts have in fact been productive and useful for them."
Except that assumes it's literally true. It's not, as a downvoted person said :)
It also assumes that him working on it would be useful or productive relative to doing something else. That is also probably a negative.
I talk to people about interview stuff, I notice that most people who say "I shouldn't have to know X" seem to be the least intellectually curious, least great problem solvers and just generally combative folks. If you are going into an interview with a serious chip on your shoulder, demanding a job, asking to exempt yourself from having to show problem solving skills, then just how is that going to work out?
Regarding reversing a binary tree, yeah, the interviewer didn't expect you to know it. That's the point. It's something that's a little tricky, not impossible, requires you to be precise about memory ownership and pointers, and algorithmic. It takes no time at all to describe, and isn't impossible to solve. Yeah it's problem solving, but it's not random trivia. It's a functional test of your intelligence and yeah it filters out some who should be at Google, and they know it. However relaxing the bar is fraught with peril. You're quite literally banking the future of the company on it.
It's my opinion that wasn't an unreasonable assessment (from mxcl). Although if indeed nearly nobody at Google uses Homebrew, as now multiple people are claiming, it was, no matter how reasonable, wrong.
I think he saw the question, and basically just refused to grapple with it, thinking it was below him, and then the rest pretty much was inevitable.
The rest of your post is speculation.
The number of googlers with Macs is not even 90% so this line of argument is just silly.
Basically the internal dev environment is already fully complete and works great. It's ultra custom and there are strict rules about bringing in open source code. The AGPL and GPL3 are good, but also one has to be wary about them in a commercial environment.
Why?
To quote one of the demotivational posters, "just because you are necessary doesn't mean you are important".
https://news.ycombinator.com/item?id=12662182
Cogs in a machine?
https://cdn.shopify.com/s/files/1/0535/6917/products/worthde...
He may be important as a person who has developed software used by a variety of people (including many at Google), but that doesn't mean he is someone who ought to be important for Google to employ.
But, hey feel free to judge someone for gasp having a sense of humor more complex than a fart joke.
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? :)
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.
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.
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.