7 ms·

>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

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

liveoneggs 4y ago
also engineers doing an interview will tend to fixate on a number to an annoying degree
jedberg 4y ago
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 4y ago
  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.
  - berniedurfee 4y ago
    100% agree. Including numbers along with accomplishments was hammered into me at $bigcorp during performance review time. Same applies to resumes. They are impressive to recruiters, HR and often hiring managers themselves.
renewiltord 4y ago
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 4y ago
  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.
  - Haegin 4y ago
    > 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 4y ago
      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?
anthonypasq 4y ago
im my experience this sort of stuff grabs the attention of HR people/recruiters doing phone screens, but not actual engineering managers.
- version_five 4y ago
  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.
jacobsenscott 4y ago
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 4y ago
  "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 4y ago
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 4y ago
  > 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.
  - b4je7d7wb 4y ago
    I think it depends on work culture. We recently merged with an american corporate and their engineers are obsessed with measuring, pilots, ab testing, RFCs etc. It's so slow to work with them even on the smallest features. Poor 10% of users who miss out on awesome features for 4 months because we "need" a control group.
    - PeterisP 4y ago
      I think that the point of the parent poster is that often even when the work culture is obsessed with measuring, the people doing the A/B testing and careful study of the benefit to the company are quite separate from the people implementing the change; the information will be used in some decisions and flow to various layers of management, but the developer who built that feature won't necessarily even get a message when it eventually got chosen for widespread deployment or got abandoned after 4 months of being shown to a control group, much less getting the data on what the estimates of financial impact showed.

liveoneggs 4y ago

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

jedberg 4y ago

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 4y ago
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.
- berniedurfee 4y ago
  100% agree. Including numbers along with accomplishments was hammered into me at $bigcorp during performance review time. Same applies to resumes. They are impressive to recruiters, HR and often hiring managers themselves.

renewiltord 4y ago

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 4y ago
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.
- Haegin 4y ago
  > 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 4y ago
    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?

anthonypasq 4y ago

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

version_five 4y ago
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.

jacobsenscott 4y ago

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 4y ago
"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 4y ago

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 4y ago
> 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.
- b4je7d7wb 4y ago
  I think it depends on work culture. We recently merged with an american corporate and their engineers are obsessed with measuring, pilots, ab testing, RFCs etc. It's so slow to work with them even on the smallest features. Poor 10% of users who miss out on awesome features for 4 months because we "need" a control group.
  - PeterisP 4y ago
    I think that the point of the parent poster is that often even when the work culture is obsessed with measuring, the people doing the A/B testing and careful study of the benefit to the company are quite separate from the people implementing the change; the information will be used in some decisions and flow to various layers of management, but the developer who built that feature won't necessarily even get a message when it eventually got chosen for widespread deployment or got abandoned after 4 months of being shown to a control group, much less getting the data on what the estimates of financial impact showed.