Perhaps companies over-list requirements because everyone knows requirements are not ANDed together. There is a scoring scheme that combines all of these, and the quality of the requirement.
And let’s be honest having spent “5 years of Python” at a Google is a different story from having spent “5 years of Python” at an Infosys.
To be honest, I’ve never seen a job description that exactly lays out what you’re going to be doing. And the reason for that is that hiring software engineers, you don’t actually know. You want them to also come up with what the future looks like.
Experienced recruiters (and employees) can see through the BS of job descriptions. Once the right candidate gets an interview it often becomes very clear there's a "match" to everyone involved and folks don't even bother to look at how closely they've "checked the boxes" in the job descriptions.
Sadly, many talented tech candidates early in their careers tend to interpret job descriptions far too literally and self-select themselves out of good opportunities. These same candidates also rely too much on responding to impersonal web-based job-postings rather than working through their networks of contacts, or just putting themselves out there and reaching out to real people.
I love the "looking for experts in X" followed by "with one to two years experience". And then I see my neighbor who is an expert in X, can code rings around anybody, but can't find a job after his company shut down. His only fault is he's 60.
I think there is an assumption that if a candidate doesn't have experience in 'Y' but they have ten years of 'X' (which is similar to, or a precursor of Y) then the candidate is somehow biased against Y or unwilling to work with it.
Two decades of OpenGL experience?, sorry we are looking for someone with Vulkan experience. Two years of OpenGL experience? when can you come in?
As someone who does hiring, I have a different interpretation. Let's say I'm a rails shop and I'm looking for mid to sr. level candidates and someone has 10 years of experience working on Java 1.4 spring based application. I think to myself "this is great, they are willing to do some grunt work but I need to know they haven't stagnated".
It's the stagnation that leads to lower job offers. You need to convince me that you were a dedicated employee for 10 years (which you are), but you also need to show that you're willing to learn something completely different. This can be a side project (doesn't have to be crazy, but slightly more then just going through the tutorial), certification of some sort, or _something_ that tells me you're not just going to write java-esque rails.
I would even go so far as I prefer people with diverse backgrounds, who are really willing to learn, so that we benefit from mistakes they made at previous employers.
> You need to convince me that you were a dedicated employee for 10 years (which you are), but you also need to show that you're willing to learn something completely different.
Have you actually had examples where this wasn't the case? This seems like a common sentiment that I myself have thought, but I honestly can't think of a single instance where a candidate with good experience or knowledge wouldn't actually be willing to learn something new, or wouldn't model code they write along existing idioms.
I can't comment on every sector but it absolutely exists in the financial technology realm. Plenty of people working in tech don't view it as an evolving set of skills and it's common to have candidates come with 1 - 2 decades of experience despite ending their search for knowledge around java 3.
Really? You can't just talk to the person and gauge their enthusiasm? I talk to devs all the time and they typically wear their tech bias on their sleeves. You know who is hard core C# and wouldn't touch java w/ a ten foot usb cord after just a few moments.
At 60 you just got a few more years to work until you have to retire. It takes 2-3 years to really get comfortable with some bigger code base... So if you are looking for some longterm employee (if such a thing even exists), it's not worth it.
I disagree, unless you and I have radically different definitions of what "comfortable" means. If I'm hiring an engineer with the seniority I'd expect them to have at 20, 30 or 40 years in industry then I want them to ramp up inside of a year.
I'm not going to expect them to be completely self-sufficient within a month. But they should be capable of implementing performant solutions to nontrivial problems with autonomy and collaboratively reviewing code with their peers.
Stated another way - what are they doing for 2 - 3 years before they're comfortable that isn't worth it to hire them?
I meant comfortable as in knowing exactly how to solve something, instead of first having to read and debug through (legacy) code for 1-2 days everytime you touch some new area of the application.
For me personally the worst unsecurity is not knowing where to put new code, without messing up some architectural separation that I'm not aware of.
I think that level of security is only even possible at companies with small codebases or a high degree of siloing. I totally fit this description as a junior with 2 or 3 years experience at my first job where I wrote half the product. At my current job where I've been for 7 or 8 years I can't imagine anyone on any team ever achieving that. Maybe for a little while when you're working in some corner of the codebase that you happen to know really well, but not long term. There's just too many devs making too many changes and nobody "owns" any area. I bet a third to a half of the code I wrote 3 years ago is gone or heavily modified already.
I once worked on a very large project in the healthcare industry. During code reviews you had to provide evidence you did a full impact analysis because the system was so large that not a single person could keep it all in their head. We're talking millions of lines of code. Being senior doesn't make you a superhuman.
If you were hiring an intern and you got two resumes in order to comply with the law you'd have to consider a 60 year old intern still in college the same way you'd consider a 19 year old intern still in college.
Does US anti-discrimination law really operate like "you have to serve the protected class whatever the consequences for unprotected ones?" European ones typically require both weak and strong classes be served equally, not in results, but in the manner and the matter.
> Does US anti-discrimination law really operate like "you have to serve the protected class whatever the consequences for unprotected ones?"
“Protected class” is something of a misleading piece of legal jargon; “class”, in it, means something closer to “axis of differentiation” than “group”. [0]
So, “black” is not a “protected class”, “race” is.
(This gets confusing because there is a related concept in Constitutional anti-discrimination jurisprudence of a suspect class, in which “class” does mean “group"; blacks are a suspect class—a group historically subject to discrimination, such that government actions which discriminate against them are subject to strict scrutiny—and whites are not, but both blacks and whites are protected by employment anti-discrimination law because race is a protected class.)
[0] There's a wrinkle in that “age over 40” is an asymetric “protected class” in employment anti-discrimination law.
I think you're confusing "weak and strong classes" with "protected and unprotected classes"
For example, national origin is a protected class and there was a case a few years ago where the EEOC got involved. It was a company owned by Indian-Americans(?) (might have been another nationality) who routinely turned down non-Indian-American job seekers (mostly whites) solely because they where non-Indian-American and they pretty much only hired other Indian-Americans and Indians. This was official policy.
So everyone's national origin is protected, no matter what it is. Everyone is in a protected class.
But say, people who have finger or face tattoos could be turned down for a job solely for having finger and face tattoos because people who have finger and face tattoos aren't a protected class.
Not sure what you mean by 'consequences' for the unprotected classes in this context, but the age discrimination case would only be valid if both the Over-40 candidate and Under-40 candidate were equally qualified, and the Over-40 candidate was rejected solely because they are too close to retirement age.
Note that due to the letter of the EEO law, there is NOT actionable age discrimination if all candidates were over 40, and for example, the 60 year old was rejected in favor of a 41 year old for the same reason as above.
People need legal reasons to say no. In a bureaucracy, that means that administrative types come up with objective measures to identify the perfect candidate, or to defend against less than honorable or completely fake people who simply lie about their skills. I have seen every level of bullshit, from a guy who told me he dealt with conflict at his last job by taking a swing at his boss to situation where three different people impersonated a candidate. Sometimes institutions come up with unique ways to handle that.
In reality, the meaning varies depending on the bureaucracy and how stringent oversight is. If someone is going to get an audit finding for hiring someone with 4 years, 11 months of experience, they care. Usually people choose to see what they see. Another reason for the laundry list is that editing is impossible. In a big company, the recruiter in Timbuktu has a phalanx of bureaucrats between the job req and the hiring manager. It's easier to have a mandatory requirement for 15 years of Windows 95 experience and add Python as an optional skill than to re-write.
> And let’s be honest “5 years of Python” at a Google is a different story from “5 years of Python” at an Infosys.
I don't think I've ever seen an ad from Google that spells out years of experience in any given technology. Their requirements are incredibly terse, usually along the lines of 'BS/BA in Computer Science or equivalent, experience in some programming language'.
I read that a different way. I understood it as an ad from Company X which lists '5 years of Python' as the requirement. Candidate 1 has 5 years of Python at Google, and Candidate 2 has 5 years Python at InfoSys.
Does the Google experience really teach one that much better? Or is it just perception?
I mean, at the end you are just a little cogwheel in some big corporation anyway. The python tasks you need to solve there are probably just as mundane as everywhere else.
Google doesn't list years of experience per technology but they do have hard tiers for years of experience and their salary bands. So they don't care that you have 5 years-of-experience with Python but you're not allowed to be an L5 without 5 years of industry experience.
Google is extremely strict about the number and wording of job requirements (5) and nice-to-haves (either 4 or 5) allowed in job descriptions. This is a good thing, but it does sometimes lead to confusion on the candidate's end because JDs can be so general as to be useless.
Hah. That's an understatement. It's even worse for research roles. Try finding a research scientist position at Google which is substantially different from any other research scientist position.
That and the fact that by applying your CV is typically sent to 4 - 6 other offices around the country and world, each for identical roles.
>>And let’s be honest having spent “5 years of Python” at a Google is a different story from having spent “5 years of Python” at an Infosys.
Unless Infosys employees code on computers bought to earth by aliens, for their business software requirements, I can't even imagine what the difference between code written at Google and Infosys could be. Its code, at the end of the day. The differences are in productivity and quality of projects at hand.
You would also be a little surprised to learn given the narrow profit margins at places like Infosys, the productivity demands are way higher compared to any web company you will ever work at. That includes Google. There are places at Infosys, where your average joe is doing 3x - 5x more work, both volume and quality wise than Google.
Google is a classic example of Gate keeping through leet code style interview proxy. People getting in feel they are indulging in some highly intellectual activity and are a part of some special club. So they are above homo sapiens.
The typical differences between one implementation and another is:
Both implementations might work for the original use-case in the happy-path case. However as soon as the first unexpected error occurs, the bad implementation might break down. It might be a lot bigger in size than the better one and contain a lot of duplication. And it might not be extensible or maintainable, and have not (regression) tests. And of course the time it took to produce the codebases might have been very different.
Those are typical differences one sees between code that had been written at more professional software shops, and code that had been written elsewhere (e.g. by electrical engineers, students, non-engineers, etc.). However I have no idea how things look like at Google or Infosys, so I can't speak for those.
As a consultant I've seen the code quality produced by developers at several companies, and there is absolutely a difference. I've worked with experienced 3rd party developers on offshore teams who seemed unfamiliar with basic architecture patterns such as reusing code. Their productivity was incredible but they were incurring a lot of tech debt.
> “5 years of Python” at a Google is a different story from having spent “5 years of Python” at an Infosys.
Yep the Infosys guy has experience of being airdropped into unfamiliar companies in foreign countries, getting up to speed with business requirements and technical constraints and producing something reasonable in three months.
The Google guy probably spent five years writing Yet Another Messager App.
We even set the requirements to match what we felt could do the job. The roll has actually been fairly difficult to fill though. Recruiting decks I have seen actually suggest creating more requirements and being vague in an attempt to lure more applicants. After this experience, they are probably correct. Lure them in then explain more after they meet the team (i.e. get them excited)
No, the problem is that you are looking for a unicorn in the first half of the requirements, then subverting it by asking for someone with only one year of experience in three things, then double-subverting it by suggesting that you want an academic who has nonetheless designed microservices and done machine learning. And it doesn't really help that you're in a large stodgy bank.
Let me rewrite this into two different job openings:
1. Junior Machine Learning Software Engineer
Bachelor's Degree or equivalent experience /
At least 1 year working with statistics, mathematics or engineering programming /
At least 1 year programming in Python and one or more of Ruby, R, Matlab, C++, Scala or Java /
At least 1 year of experience working on full stack solutions
2. Machine Learning Software Architect
Master's Degree or PhD /
At least 2 years of experience with cloud software design using microservices /
At least 2 years of experience with machine learning libraries such as TensorFlow, Pytorch or Keras /
Demonstrated original research in this or related area
Do you see how different those two are? But you set up the ad to switch between them.
It's also partially caused by the fact that most of the time, HR people write those ads (maybe with some input by the division). A lot can get 'lost in translation' here.
And let’s be honest having spent “5 years of Python” at a Google is a different story from having spent “5 years of Python” at an Infosys.
To be honest, I’ve never seen a job description that exactly lays out what you’re going to be doing. And the reason for that is that hiring software engineers, you don’t actually know. You want them to also come up with what the future looks like.