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.

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.

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.

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.

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

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?

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.