|
|
|
|
|
by mym1990
1237 days ago
|
|
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). |
|
"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.
Two different hiring managers in this thread have already said this, but in case that's not enough here's another https://www.askamanager.org/2020/02/my-step-by-step-guide-to.... You might even want to spend some time with her whole section on resumes, she answers many of your other questions too https://www.askamanager.org/category/resumes.