This is a weirdly aggressive response to what is literally the core purpose of collecting resumes. Like it or not a hiring manager likely has hundreds of resumes they are looking at and nowhere near enough time to review them all. Making judgement calls on limited information is necessary. Maybe the hypothetical engineer with this resume does understand the goals and outcomes of these tasks, but they have failed to demonstrate it in this resume. Given another engineer who gives me details about the business need they were meeting and the outcome, why would I interview the first instead of the second?
The core purpose of collecting resumes is gauging the likelihood that a candidate may have the skillsets to align with what the job is, and then bringing them further into the process to dive deeper into their experiences. It is not to make wild assumptions about how someone is probably incompetent because they put put 'GIT' or 'JAVA' or omitted the business need and outcome on every project they have worked on(good luck getting all that on one page). It is almost a certainty that someone making snap judgements on what capitalization was used for a specific tech is also making those judgements on things like nationality, origin, sex, etc...
To be honest, why do you even care what the business need was? Maybe it is classified? Maybe it just landed on their desk and they crushed it? You honestly want to read about the business needs of things that are completely irrelevant to you and in the past? Go download a white paper.
Your whole paragraph is a juxtaposition. You are saying that hiring managers are strapped for time to thoroughly review all the resumes(I agree) but then say that a resume should have the business needs and outcomes of any number of projects that a dev has worked on in their career(and we haven't even touched on what they actually DID for those projects).
The core purpose of collecting resumes is to determine which candidates are most worth bringing in for an interview. A candidate who understands the business purpose of what they are doing and is capable of calibrating their task to best meet that need and gauging the outcomes of how well it did so is infinitely more valuable than one who just blindly does whatever task with no knowledge or understanding. Skillsets are more than just a list of technologies you've worked with.
"Deployed our core application to Kubernetes": Cool you once saw a Dockerfile and Kubernetes YAML.Like every single other applicant. I don't even know from this if you have a basic understanding of Kubernetes. "Deployed our application to Kubernetes for better server utilization and resiliency increasing our uptime by 20% while reducing cutting our server costs by 10%". This person at minimum has some idea of how to configure Kubernetes for application resiliency, knows how to measure and maximize hardware utilization, knows how to measure and minimize downtime, and probably knows enough about Kubernetes to provide advice about when to use it and when not to. Maybe the first person does too, but they did nothing to show it.
> It is not to make wild assumptions about how someone is probably incompetent because they put put 'GIT' or 'JAVA'
No one said wildly incompetent.
> every project they have worked on(good luck getting all that on one page)
Don't put every project on your resume. Pick the most interesting ones for the job your applying for. If you are sufficiently senior that this still doesn't fit one one page, use two.
> It is almost a certainty that someone making snap judgements on what capitalization was used for a specific tech is also making those judgements on things like nationality, origin, sex, etc...
No.
> To be honest, why do you even care what the business need was?
Most hiring managers. Someone who understands WHY they are doing something will make better choices than someone who sees "Move our application to Kubernetes" in the backlog, grabs a yaml template off the internet and calls it day.
> Maybe it is classified?
Government resumes tend to be EVEN MORE outcome focused than private industry. You can write "increased pipeline throughput by 50%" without writing the national secrets in that pipeline.
> Maybe it just landed on their desk and they crushed it?
How can they possibly know they crushed it without understanding why they were doing it in the first place, or anything about what happened after they released it?
> You honestly want to read about the business needs of things that are completely irrelevant to you and in the past? Go download a white paper.
A white paper tells me nothing about the candidate.
> Your whole paragraph is a juxtaposition. You are saying that hiring managers are strapped for time to thoroughly review all the resumes(I agree) but then say that a resume should have the business needs and outcomes of any number of projects that a dev has worked on in their career(and we haven't even touched on what they actually DID for those projects).
You know what takes longer than reading a resume? Interviewing someone. Your right. Resumes are going to get a skim first. Only the most relevant ones are going to actually get read thoroughly. This is exactly why you want numbers and metrics as much as possible. Numbers catch the eye far more easily than sentences. If I see "saved $100,000" on a page, that's going to get caught on my first skim. It's an effective hook. I want to know more. Without it I've just got "Kubernetes, C#, Javascript", I might as well have a computer read the resume and build me a checklist.
I appreciate the thorough response. I guess we disagree about the purpose of a resume, I just think it is wrong to assess someone's worth off a one-pager(two pager max). There is obviously a lot of grey area between what a perfect resume and an atrocious one looks like, and that will vary even between each job application. Matching the expectations of candidates with those of the hiring managers is extremely difficult, dating can be thought of as a similar problem that has not found a great solution(and in no way am I saying dating is like interviewing).
For classification I meant that generally a company you have worked at will not be keen on you going around talking about their internal business needs, especially if it is close to the product.
Lastly, as some have mentioned, statements like 'increased this by X' are usually either fudged, or marginally related to what the candidate worked on, conflating factors being in the mix.
