[delaynomore]

>Created a new CMS for the company in Python that resulted in an ~70% reduction in website update times, from 1 hour to 18 minutes

Personally, I don't put too much emphasis on these numbers because most of them are probably BS. Don't get me wrong, it's still probably in a candidate's best interest to quantify their accomplishments since it's recommended everywhere but don't over do it.

[jacobsenscott]

They are absolutely BS because 99% of programming is unquantifiable. There are too many variables. I added 5 features this quarter and sales went up 5%. Is it because of the features, or better sales techniques, or dumb luck?

"Redesigned the web pages and user satisfaction went up 10%" - but also you hired 5 more customer support agents and a backend engineer improved the slow pages by 30%.

[razzimatazz]

"Created a new CMS in python (Based on the old CMS) (With a team of 2 others and one guru who did the design but I wrote his code) resulting in 70% reduction in update times (after we ran it in a cluster with twice the resources but I never could understand clustering so guess it was my coding)" "And didn't have time to write tests, and that project was canned because it took too long actually"

[matwood]

As engineers we're measuring everything, all the time right? The point is 'wrote a web api' is worse than saying 'wrote a web api that handled 1M tx/hour' or some such. Even if the number in this case was exaggerated, it stands out and we have something to discuss in the interview phase.

And if the software you write works with money at all, put the amounts in there. Moving around large amounts of money shows trust from your existing company, and attention to detail.

[legerdemain]

  > As engineers we're measuring everything, all the time right?

Is this mostly a joke? I've written plenty of APIs, but I have never load-tested them in isolation, never had to respond to underperforming latency or throughput metrics, or even face any feedback on software performance. In most cases, I don't know who uses the code I wrote, and no metrics from them ever make it back to me personally. For exactly 95.2% of what I've delivered, I couldn't tell you that I improved Foo by Bar units even if you held a gun to my head.

This is after years of delivering LOB software to clients in banking, manufacturing, and oil & gas industries.

[BeetleB]

> As engineers we're measuring everything, all the time right?

Ha ha ha ha!

Asking questions like "What data do you have to support this?" can often create a lot of enemies - including your manager.

[cduzz]

I'm not so sure about this. I support things and I've supported them over absurd growth periods for years. I've lost track of how many zeros are on the number of things per thing; it doesn't matter.

The process is: You're in charge of a thing, it grows, it breaks, you fix it, it grows, it breaks, you refactor it, it grows, it breaks, you fix it, it grows you replace it and shard it into N things, they grow, they break, etc. The metrics matter, but after a while it's just bigger and bigger but gotta work, so you just make it work.

Oh -- obviously I'm not an engineer -- I don't wear a striped hat and drive a train or sign blue prints.

[jedberg]

They might be, but they are a good jumping off point for a discussion during an interview. But also if you say something interesting, it will pique my interest enough that I at least want to talk to you about it in an interview.

[squeaky-clean]

Was going to say this. You need your resume to cover both types of people who will be looking at it. HR/Managers for initial screening and then developers for the real interview. For a startup where I know the dev or founder are seeing my resume right away, I wouldn't include those types of quantifications. If I'm applying at ${bigcorp} then it helps get you through round 1.

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

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

[anthonypasq]

im my experience this sort of stuff grabs the attention of HR people/recruiters doing phone screens, but not actual engineering managers.

[version_five]

I agree. I know it's the conventional wisdom to phrase things in that way. Having hired a lot of people and read a lot of resumes I personally either ignore these statements or have a chuckle over them when they are silly. In no world would someone capturing the "impact" of what they did make me more likely to hire them.

I'd actually say I'm much more interested in understanding what concretely a person actually did, so I know what kind of experience and capabilities they have, vs what it led to, which has so many external variables and is probably mostly BS anyway.

[liveoneggs]

also engineers doing an interview will tend to fixate on a number to an annoying degree