[renewiltord]

The value is as a hook in a conversation. e.g. if you have:

- moved from Kafka to Flume

- installed Kubernetes and Dockerized our code

- binary serialized our data

Then this is going to happen:

1. I will assume you don't care about the outcomes of what you do, only the task

2. I will assume you don't know how to communicate why something matters

3. I am going to have to pick at random and hope it's interesting

On the other hand, if each one has the outcomes listed, not only is it clear that you know why, but perhaps more importantly, it is a conversation hook that I can use to enter the discussion. Well, why was it important that the size of the data be small? Couldn't you just zstd your JSON instead of binary serializing some processed version? etc. etc. and then you get to show off why and what that thing you made does and I get to enjoy that and we're both happy.

[friedman23]

Most developers don't have agency to choose what they work on within a company. Expecting the developer to have any influence on the outcome of what they produce other than the implementation quality shows a lack of understanding in how actual software development works.

And to be fair to you, almost all management two steps removed from actual coding does not understand how actual software development works. If you are interviewing a PM you should care about the outcome, for engineers focus on quality, timeliness and skill.

[Volundr]

Have you considered... Asking? Asking why you are doing something? All of these changes are going to have a purpose behind them, and at least in these examples those reasons are likely to be things a dev is in a position to metric the results of themselves. How much throughput did you add by switching to Flume? How much did you reduce bandwidth with that binary format? Even if you don't have access to the production metrics (and most places you will) you could estimate based on synthetic data.

Even for product work I've yet to meet the product person who isn't eager to talk about how a new feature was received when a dev asks.

[Haegin]

> for engineers focus on quality, timeliness and skill.

So put that in the resume. Say how you delivered it better, faster or cheaper than the next candidate in the pile would have.

[legerdemain]

This is also garbage.

Does your company put you head to head with another developer to see who can develop the same feature the fastest?

Or maybe you secretly keep tabs on all of your teammates and their delivery speed, so that you can calculate how much faster than your teammates you are at delivering and how many fewer bugs you ship?

[ebiester]

As a manager, that's half true. We have business needs, but I am hiring for the ability to think past "what is being asked of me" and into "What do we really need, and how can we deliver it?"

That isn't rewarded in all jobs, mind you, but it is something to look for when you have a choice.

[friedman23]

I've been a software engineer at a few highly regarded companies for a decade now, at none of them did I have the ability to make large product or design decisions as a software engineer. I was able to suggest things, I was able to call out issues in the design and I was able to propose ideas but I was never able to unilaterally make any decisions and a lot of the time any ideas I had were put on the backlog because the company was in focus mode on one specific goal (and I'm not criticizing this idea of having focus).

So my point is, if leadership and product are bad and ask engineers to produce turds. The engineers don't really have control over the fact that they are producing turds but they have control over the quality, how buggy, and the shinyness of the turds.

[lelanthran]

There's three questions for every product - "Why?", "What?" and "How?"

> I've been a software engineer at a few highly regarded companies for a decade now, at none of them did I have the ability to make large product or design decisions as a software engineer.

IME, even the highest engineer at the company has little to no ability to make even small product design decisions.

I'm not saying whether I think it's a good thing or a bad thing, but the truth is there's a role at every organisation who's job it is to decide what the product should look like and what it should do. That role decides all the "what" questions.

Engineering is all about "How?"

Even the product design role doesn't have all the power - the "Why?" is decided by someone else.

[razzimatazz]

Key point: quantify the shinyness of the turds, so that HR screen likes the look of the CV, and be prepared to talk about turd shinyness and why it would matter.

[mym1990]

Get over yourself.

How about we start with you not making 2 massive assumptions off of a sentence in a document that summarizes anywhere from 1-30+ years of someone's work.

Then how about we move away from you thinking that interviews are for your entertainment and the interviewee is a circus animal where 'you get to enjoy that' as they 'show off'.

[Volundr]

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?

[mym1990]

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).

[Volundr]

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.

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.

[mym1990]

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.

[renewiltord]

Isn't it preferable to you that I continue to be like this so overtly? Since you dislike how I am and you may well dislike working with me, you can instantly reject me and my org. This is good for both of us.

I don't think people are "circus animals". But I do like to work with people who have done things that they are proud of and who do like talking about those things. And it is important to me that we both enjoy the conversation, yes.