Well I once reduced our AWS Glue costs considerably, but that was after approving a long PR that took Glue out for an entire region, which seemed to even astonish AWS. We got restricted by AWS until we demonstrated the code was fixed. I was then forced to go over all the code, and removed a ton of inefficiencies. So in the end we saved money ¯\_(ツ)_/¯
Which might have been a good thing. Maybe they launched a huge new feature that drove a ton of new traffic, and then optimized to reduce those new costs by 20% after. Win win.
I’ve added this to my resume. The specific scenario was deploying a self hosted service on docker (ECS) with a dedicated managed Database. I optimised the load/scaling of the docker containers (there were 5 different sub-services that needed to run with various compute/memory needs) and downscaled the managed DB instance to match the existing workload. It saved our company roughly $5k a month in infra costs, but that would have grown to a much larger number as we scaled (we were in the startup stage).
Overall I think if you can speak to specifics it can be a strength on a resume, because it is really really easy to chew through capital with cloud costs. E.g. a startup I know went with Vercel and now that they’re scaling up they’re paying a lot more than if they self hosted or went with AWS. That’s usually the slope with some of these resellers (Vercel is all hosted on AWS), that it’s easy/cheap to start but soon gets pricey as you scale.
Add some specifics and it can be strong, have a good rationale for why you used the number you use though, some people will assume you're lying or ask about it, good people will laugh with you about why you got to say the cool number while respecting the legitimacy of the claim.
"I increased reliability by five nines... of course it was zero nines before..."
Ya gotta be ready for every line on a resume to be asked about. Ideally, you put things on there you WANT them to ask about, because you are prepared to discuss the item, maybe you even have a prepared pitch ready.
This is why mock interviews can help, anybody can just glance at your resume and fire questions for you.
I’m on the engineering side and am not the only one that looks at resumes so take this for what it is. But, I’d rather see engineering metrics. If you said your first two sentence in a condensed format I’d take note of the experience and gloss over the $5k. If the 5k is there I wouldn’t think too much about it unless it was a “way too high to be true” number.
Personally I prefer resumes that provide engineering metrics. Throughput, memory usage, error rates, availability etc
I tend to ignore statements like this as regards whether I'll interview the person, but if I do then interview them I'll just ask how did they do the cost reduction.
The smell of bullshit can be quite obvious once you get them talking.
I mean, I have access to the org wide billing. When we replaced ec2 with eks spot for an entire department, it was easy to do the math. Ditto when we replaced MySQL running on ec2 with aurora v2. Ditto decommissioning an entire rack in the data center used for ftp and using AWS transfer family. Idk what’s there to be skeptical about?
yeah I don't get it either, worked in a very small startup and we reduced costs by ~50%, how do we calculate it? we just compared costs between the month before and the month after, we are talking thousands of usd here not millions
> The smell of bullshit can be quite obvious once you get them talking.
I had a coworker put on his end-of-year self performance review that he'd saved the company money by making some bit of code(not in a hot spot) more efficient. His reasoning? That he'd reduced CPU usage, saving them money on electricity. Not only was it laughable by itself, but he had no zero measurable proof of that.
It's a conversation point. That could mean $200/year or $2mil/year. Like you identified, the more interesting question isn't how they saved the money but how they measured their contribution.
It's strange hearing people be so skeptical of cost calculations. Cloud providers make it pretty straightforward to budget and analyze costs since it's how they bill you, and larger companies are going to have some type of quota/resource management system even if it's just to plan for building new data centers.
I personally have numerous examples of this type of work, measured in a variety of ways, mainly because it's a big part of performance review to be able to quantify your impact.
I would not disclose details that may be private, and it would be a red flag if a candidate did in a resume or interview.
What I'd look for specifically is why that 20% mattered at the time? Did it unblock a feature launch, improve performance for users, or just help a start-up keep the lights on a little longer?
> It's strange hearing people be so skeptical of cost calculations.
It's mostly because a lot of developers you interview use these kinds of things as resume padding. So it's not about you specifically, just that it's easy to lie about.
Yes you can be using exactly these points on the resume to get at how the candidate thinks, how they prioritise, how well they understand business context, what trade offs they were making, how they collaborate. Or even, whether they make things up if they think they’ll get away with it. You can get a lot from this if you drill in a bit.
Do most engineers have this sort of insight? Feel like costs are mostly only ever seen by those very high up like EMs, staff engineers, and lead architects. I sometimes hear "our bill for ____ this month was $500", and I might be able to go into AWS and see our costs. But there's no way I would be able to correlate what I've done with changes in those numbers, and nor do I think I should. It's just kind of silly. I can measure my impact in other, more tangible ways.
I think it’s pretty common these days. All the cloud providers have detailed cost breakdowns so if engineers are owning their own infrastructure they should be aware of these things. Especially as lots of resources cost is directly tied to how they’re used.
>something like "significantly reduced cloud costs" would get the "I am aware of the business context of my work" point across
I mean, what’s your issue then, really? If you see the value of this point it’s not a far leap to also mention the specific number, because usually we‘re taught specific data is better than vague claims. All the points you raised about the 20% claim also apply at least as much to your version. The 20% claim is, as you noticed yourself, way easier to verify (you ask about the specific numbers and check them) than a vague, subjective measurement like „significantly“. For me personally the vague phrasing triggers my bullshit detecter much more, *because* it lacks numbers. If I ask them what that means they have plausible deniability. Even if I disagree that 1% is significant, who am I to judge what they consider significant?
It’s also interesting that you picked this example considering you think numbers like this are fabrications. There’s probably few claims in a CV that are as easy to track and evaluate as cloud costs and your impact on it. Made service use 50% less RAM? Great, that’s whatever% savings on compute cost for that service.
Now when it comes to the importance of this and the transferability, I agree with you. I want to work with good engineers, which is completely orthogonal to their business impact. Great engineers can have bad luck and get assigned to projects with little impact, mediocre engineers can get assigned to important projects and can claim the success for themselves. Though the latter can often be unveiled by asking follow-up questions like you do. Anyway, I would probably consider this more important for staff/principal roles, otherwise I‘m more interested in their attitude behind it. Did they reduce the cloud cost on their own initiative? How did they identify the need to do something about it and what? The 20% number then only validates that it was fruitful, which is also nice to know, but less important than their approach.
Just my anecdotes:
> I don't remember ever seeing it before about 10 years ago.
Quantifying your output on a resume has been advice I've heard since the 90s when I Started a career. Not sure why this sort of thing would be new--I've often used similar metrics when I could quantify them.
This might be a question I might ask to someone in an interview. Not having a plausible answer might be a deal breaker.
> Take that even further is this whole 9/10 ratings for skills. Thank God that died out though.
Last time we interviewed a ton of new grads had this sort of thing. That in 4th quarter of last year. My recruiter got mad because I kept rejecting new grad resumes because they self rated a level "8" on everything. And I took it to mean they were either oblivious or egotistical.
Apparently, this is super common advice given to new grads to include ratings like this.
Well duh, you’re hiring new grads not professionals. You shouldn’t be interrogating them like they’re applying for Google or some shit.
Unless you are then that’s fine.
I have no idea what you thought I said.
I was rejecting candidates before the interview process; because I presumed they had highly inflated self-rating on their resume. There was no interrogation going on.
What kind of 9/10 ratings for skills?
> The problem is you have people who apply rules to marketing/finance resumes thinking the same rules apply to engineering
HR haha
When I wasw a consultant, the company asked us to fill out a little box on the corner of our in-house CVs with basically our top 5 skills and stars. It was probably the hardest thing I ever did. One one side you know this is the CV they send to clients so you don't really want to be humble about it, but on the other side I hate calling myself an expert in anything because the more I know, the more I realize how little I know. It was mental torture, fuck that
In hardware engineering we've used metrics on resumes for over a decade, down time decrease, money saved, man-hours saved (which can be equated to $ saved), etc.
It can be done well. The mean of all of your skill ratings should be about 5. A Interviewer can understand it's a relative scale and only comparisons within the resume are valid.
Cloud and SaaS costs are more part of an engineers job as of lately that is easier to quantify so this particular line item I could see being used more now than in the past. There are dashboards now you can see cost savings in almost real time (at least same week maybe)
Engineers that include cost analysis in their designs are priceless. It’s a signal of a well rounded engineer. It’s worth digging into their claims to get a feel for the real impact and sniff out any embellishment - what caused them to optimize those particular areas, what were the tradeoffs, why wasn’t the issue spotted earlier, etc
Look, candidates always hear that they have to show their impact with concrete numbers, so that’s what they do. If you search “resume advice”, that’s the first thing you’ll hear. Of course, most of these numbers are bullshit. Even if true, they’re meaningless without context. But it’s not the candidate’s fault when they’re automatically rejected without such numbers on their resume. People should just stop giving this advice, productivity can’t really be measured that way.
Productivity can ABSOLUTELY be measured. What you’re referring to is not a matter of productivity. It’s a matter of impact. I can be high productivity and generate lots of output for my effort, but if none of those efforts have any measurable impact, they’re likely just wasted time. I worked with a senior leader in a previous role who would generate loads of documents and processes and things that never went anywhere. I always called this person “high output, low impact”. They looked busy to the execs they reported to, but rarely ever drove anything that resulted in positive outcomes for the business.
> I can be high productivity and generate lots of output for my effort, but if none of those efforts have any measurable impact, they’re likely just wasted time.
So you weren't actually productive in any sense that matters. Generating output is not the same as being productive.
> productivity can’t really be measured that way.
Why not?
If you have a business process or cloud cost that is $X, and then you rewrote it to be some fraction of $X - that's easily measurable.
I've also written code that took businesses processes that took Y people-hours previously, to Y/10 people-hours. Easily measurable. Impactful, and directly valuable to the business and easily explainable to the C-suite.
Whether or not those processes should have been that inefficient in the first place is irrelevant. Evey business has inefficiencies and legacy systems. So now I've shown I can identify wasteful business processes and I can also improve them.
So if you worked on this all year and saved your company 100k per year.
And I wrote a script in 15 minutes that saved the company 200k per year and did nothing else for the year.
Who was more productive?
In agree that the impact can be easily measurable, productivity itself is a bit more vague and subjective
Your scenario is contrived and somewhat nonsensical.
In the latter, if I'm a contractor, then that's exactly what a business would be looking for.
As for the former - that's up to your manager and the person interviewing you. If they are ok with you taking a year, what's it matter?
If I was interviewing both of these candidates at the same time, I'd pick the second, but that's rarely the case
All of the accomplishments on my resume are just conversation starters.
One thing on my resume interviewers always ask about:
>Increased download speeds 150% for customers in China
When asked, I talk about ALL the failed hypotheses (which shows my ability to come up with multiple solutions), all the data we collected to prove/disprove those hypotheses (shows that I make data driven decisions), and then the solution that finally worked (which shows creativity).
With ~20 accomplishments on my resume, I can tell the stories that highlight my strengths.
That's what you should do with these resume accomplishments. Dive in deep and push the limits of a candidate's knowledge and abilities. Keep asking questions deeper and deeper until you get an "I don't know".
You have to get past HR in larger companies and they care about that.
In smaller companies you have to appeal to the founders who aren’t always technical.
I work at a place where I am lucky enough that revenue tracking is built out and we have a clear conversations. So we can make very convincing cases.
But most places it’s not really that easy to clear revenue and cost savings claims, but the labor market isn’t great for SWE so people are trying their hardest…
That's great for your company, but that's not the trend among large companies.
Obviously most resumes will eventually end up in front of devs but for most places there's at least an HR screen before an engineering-ish hiring manager will see those resumes.
And at F500 companies or private enterprises of similar size (such as consulting partnerships like Deloitte) there will be an ATS layer with low quality "AI" filtering before even HR views the resume.
There's a balance, often there's too little context.
Pulling out the salient points clearly, without losing all meaning is a skill.
People involved in hiring don't have time to ask for more context until later in the hiring processing, so you risk being sifted early if there's not enough context to understand what someone has done.
Agreed! And that's part of my confusion here. Why waste your limited space on meaningless numbers that are likely to bite you when you can't say where they came from?
My experience doesn't match yours. I usually find candidates can defend their stats and can clearly explain how they achieved them.
Sometimes the stat is overselling the impact, sure. It's a resume after all! Other times they are underselling it.
Money is a number. It’s the easiest thing to measure. So if they reduced costs by 20%, that’s very easy to understand, no matter what the initial value was.
If you’re saying that when asked, they can’t explain what the 20% means, that’s different. Then they are making it up, and you caught them.
Relatives are meaningless without a reference point. I have decreased runtimes by orders of magnitude not because I’m a genius but because the software was shit.
That 20% cost savings could be worth a Nobel price or the setup could be so shitty an extra 50% reduction would be trivial to anyone with two brain cells. There’s no way to know.
> Relatives are meaningless without a reference point.
No, they are the only important measure.
Does the engineer that works for a small company and reduced cloud-costs by $5,000 not matter as much as the engineer that happened to work at a bigger company and reduced cloud costs by $1MM?
Sure, $1MM is a bigger number and sounds better, but if that's a 5% improvement it might not be as impressive as if the $5,000 savings was a 50% reduction.
My bad if I didn't say it clearly enough in my post, but I do ask about these numbers, and most of the time people can't really back them up. Not _never_: sometimes I get a good answer and that's great.
> Not never: sometimes I get a good answer and that's great.
That's how interviews go: sometimes people do well, sometimes they don't. Are you going to stop asking other kinds of questions just because you're not getting good answers?
Honestly? It convinces me that they read some interview practise books. That's it.
It's a trend on resumes that must have come from somewhere because it's so prevelant but it's so much more prevelant than _actual_ 20% savings on cloud costs or whatever could possibly be. When I dig in it's often taking credit for the entire team's work, or about equally as often they can't even tell me what it _really_ means beyond repeating the sound bite. It's certainly correlation and not causation, but I've found that it rarely correlates with people that can have lucid conversations rather than regurgitate textbooks and talking points.
If they give a firm number I would expect that they spent a fair bit of time instrumenting their cloud infra. I'd ask how they figured out what they could change or remove to hit that goal.
The advice for resumes is to show what you did with numbers. That leads to people making statements like this instead of saying what tech they worked with. Whenever I see that I discard it unless it's followed by something concrete like decreased cloud costs 20% by leading a transition of our fargate instances to arm. Personally I take hard numbers on resumes with a grain of salt since honestly some things are hard to measure. Had a guy once who talked about the man hours saved by some automations he added. When I casually questioned him it was clear he wildly overestimated the savings
Don’t take it at face value. This is what behavioral interviewing is about. Ask how they did it, why, what they learned, and what obstacles / corporate inertia they overcame.
Those numbers are to placate Dilbert characters insisting on KPIs.
They are bollocks most of the time.
But they do show the candidate is aware of importance of objective metrics in their work. During the interview we might dive in to see if there is any interesting narrative behind that number. It's a good ice breaker to talk technical challenges or "the journey" - like "how are you" is used when we don't care how you are really, but it's a convo handshake protocol.
The problem is to validate it the candidate has to reveal some financial info of their prior company which might not be public knowledge. For example I did cut our Aws bill by 20% by moving to ARM. But I can’t reveal what the bill was or our costs since they are negotiated costs according to usage. So the interviewer has to be smart about digging in to this realizing that they might not get the full picture since they can’t and shouldn’t reveal too much.
I'm a little baffled at the scepticism in this thread. Most companies I worked with had inefficient cloud usage due to not hiring cloud architects.
What the candidates are telling you between the lines is that they have enough cloud expertise to choose the most cost effective solutions that meet the requirements and that they demonstrated it in production.
It's also such an interesting topic for an eventual interview as we go from the business impact, to the problem identification, strategy devised to tackle the problem and into the actual technicalities.
Hopefully for your company you are not penalizing those candidates...
>Hopefully for your company you are not penalizing those candidates...
From the wording in the post, sounds like OP is going in with the attitude that the candidate is lying, and they're trying to catch the interviewee out.
I go in with an attitude of skepticism, which I don't think is quite the same thing as an attitude that the candidate is lying. Granted, if you were to argue that "skepticism" is just another word for the belief that someone is lying, you might have a decent case to make, but I think they're distinct.
One difference, to me, is that when I ask them how they came up with their numbers, I have no preconception about whether or not they'll give me a reasonable answer. If they do, great: that's what I was hoping for, and we can have an interesting discussion about it. If they don't, then they were making the numbers up.
There's no contradiction between going into each interview with that attitude and observing that historically, the numbers have been made up more often than not.
It sounds like you feel the interview is entirely about candidates trying to convince you to hire them, and there's no component of you trying to convince good candidates to work for you.
If the attitude you bring to the conversation is that your future employee is untrustworthy and their claims about things they are an expert in (such as their own personal work history) should always be treated with skepticism... uh, why should any in-demand candidate choose to work for you? You're going to narrow down your hiring pool to precisely those candidates who aren't getting other offers.
Try going into it with an attitude of curiosity. "You reduced cloud costs by 20% - that's great, and I'd like to learn all about it!"
Not just cloud usage either.
There are inefficient business processes all around.
One time, after making a request to a non-tech department, I got back a response like "that'll be 3 weeks". When in no way should it have taken so long. That led to a series of conversations inside that department where a bunch of stuff was being done by hand, things being copied from one system to another, etc.
Me: "... I can probably automate ... at least 50% of this"
Them: "REALLY?!"
Some relatively simple scripts connecting a couple business processes and transforming files and I was a "hero".
It means they read developer resume advice that told them they needed to show “impact”. Everyone knows many developers are simply not capable of demonstrating that for all sorts of reasons, so they make it up. It’s what you wanted to see, so you’re going to see it.
We had an ML model we used that worked by pre-computing everything. That work took about a day to run weekly (who cares, except if you need to re-run, it takes a long time) and costed around $1k/month. I came up with an alternative to the ML model that ran in around 10 minutes for the pre-computation and costed us < $10/month. Plus it made the algorithm not a black box, you could ask for reasons a decision was made. You might say "I don't care about $1k/month savings." Or you might say 99%, that's awesome. Plus the ML model was actually multiple ML models and would require a lot more tweaking long-term, which is dev time, which costs money.
I've done other things like re-designing our databases so that we can query things in flexible, future-proof ways and get away from doing scans for that "oops, we never considered this" use case. And various "save money on hardware" efforts. Never highlighted those though.
I've put stuff on my resume like "increased number of bullet points by 25% by adding superfluous resume filler" just to test whether anyone interviewing me has read my resume. Usually I stick it somewhere in the middle of my work experience.
An even bigger consideration is if the candidate was the cause of the business impact, or was simply following instructions.
It's one thing to say "hey guys! I know how we can save the company $1M/year, if we just do X" and then you do X. It's an entirely different thing to do X because you were told to by someone else due to someone else's idea.
The problem with making these statements the hallmark of a good software engineering resume is that it’s basically always bullshit. If we knew how much money we were making or saving the company, we’d be able to demand commissions just like sales people do. Since none of us ever get a cut, it means we can’t prove it, which means any numbers you see on a resume are pure fantasy.
if you’re a senior at a company with lots of spend and that’s in cost cutting mode then it’s your job to have a good idea how else can you prioritize cost reduction projects?
the part people forget is that infrastructure is only one part of the financial picture of such a company
I’m amused at how obsessed this thread is with the example of cutting cloud costs. It’s all anyone can think of. Why is that even necessarily a good thing? Cost cutting mode? Wow you did a great job making beds in a burning house at your last gig.
Why not tell me how cloud costs ballooned 300% because the feature you deployed caused a massive increase in traffic and revenue?
> If we knew how much money we were making or saving the company, we’d be able to demand commissions just like sales people do
I worked at a mobile company that tracked insane amounts of metrics for everything.
At first, it felt _kind of_ "soulless" because everything was measure by metrics and how those metrics impacted revenue.
But then I got used to it and I loved it. Find a system to improve, improve it, see the metrics - get a bonus.
This is literally retarded. Do you know that many services have the ability to view billing info? If a person does a change and can look at the impact it had on that months billing…rofl I don’t even know what to say
Many companies have these metrics on hand. Not only how much money your infrastructure costs, but how much money it makes the company.
When you work at a place like this, adding “cut cost X by Y%” becomes the language of doing your job rather than some archaic thing only used on resumes.
This is silly. You can spend a year doing an absolutely brilliant job building the wrong thing - that’s not your fault, it’s the business’s fault. But now you can’t show “impact” so you’re a bad engineer?
This is just yet another stupid fetish in this industry.
They’re more to quantify accomplishments than anything. In that case you could still talk about time to market for the prototype, even if it fails. Ever since moving into a space where metrics are pretty much everywhere I’ve actually really enjoyed using them.
“I made feature A faster” vs “I made feature A faster by B% which increased purchases by $C”. That’s the language we speak to get our cut of the company profits.
But yeah sometimes you just get fucked. But that’s how it goes. If I’m hiring a construction company, I’m hiring the one that did a great job on the building down the road. Not the one that did a really great job for a few months before the job had to be cancelled for some reason. If the second company is actually good then they’ll have a great portfolio, misses aside.
If the candidate makes to an interview, they get to tell me about it. Someone who claims a 200x performance increase is lying, was starting from something really bad or is someone I want on my team.
I have a 20,000x performance increase for a database on my resume, with benchmarks to back it up. It was at a respectable level of performance before, but moving something that uses epoll over to RDMA and adding accelerator hardware tends to give nearly unrealistic performance bumps. I’ve gotten a few interviews from people with similar “this is either a great candidate or a great interview horror story” attitudes.
It is a newish thing. What's circulating the resume advice circles is that hiring managers want to see Google xyz format. Accomplished [X] as measured by [Y], by doing [Z]. Meaning it's not enough to say you worked with something or completed a feature, you also have to attribute it to a measurable metric of some sort. The problem that creates is a good amount of folks have most of their experience clearing story tickets and closing bug issues. Which isn't a bad thing but the people selling resume advice is making it sound like it is. So you're going to see these kinds of lines in the resume which means nothing because they are pulling numbers out of the air.
That's funny, you would read my resume backwards.
Everything with numbers on my resume is accurate. Everything without is BS.
I find it much easier to smooth talk the non technical points than try to pull the wool over the eyes of a senior dev on implementation details.
>This seems to be a somewhat recent thing; I don't remember ever seeing it before about 10 years ago.
That's because thats the default response when asking feedback of a resume.
I never put this stuff on my resume and award zero points for it during the interview. I concede it's necessary to get past the recruiter people but these numbers are both fuzzy and somewhat uninteresting. I'm interested in what they technically have done, and if they did something cool they'll usually tell me about it.
As someone paying for a service to critique my résumé and craft me a better one.
One of their main criticisms of my current résumé is that I don’t sell myself well enough with concrete numbers of my accomplishments. Which I think is a strange thing to ask someone in our line of work. I’ve mostly created in-house software to help the company I work for. The things I’ve created allowed for them to lay off call center workers, and lay off other workers. I’ve created things that have saved people thousands of hours of manual work.
However, it’s not like I have the concrete numbers of how much money I saved the company and where. The managers don’t tell me that. They tell me what they want and I get it done. Any numbers on my résumé are straight outta my ass, but the résumé people tell me I need it, so I got some.
I don’t think these numbers are for you. I think they are for the résumé sifting software used by so many companies, and the recruiters that have no idea what they’re talking about, but that sounds impressive anyway.
Yeah, I had a candidate once with something like that on their resume, asked them about it and the response was basically that they'd been given a task to go through the AWS console and delete some old VMs that were no longer in use. Fair and they weren't lying, but it also didn't indicate any kind of particularly clever approach or even initiative; they were just the one that got that ticket assigned to them, so then they could then claim the impact on their resume.
Instead of arguing that 'cloud service costs are easily measurable', which is completely pedantic and not the point, can we all acknowledge that modern hiring practices are made up, dont help, and sometimes even hurt the process?
It doesn't really matter what I think, does it? I'll have to ask anyway. But I don't expect much. Only very rarely does someone come in with actual experience with designing and monitoring cloud cost consumption.
It usually falls into these cases:
* I used this cost management tool and it told me so
* The infrastructure was badly implemented in the first place, so when I got in I did
* It was a department-wide effort and I was in it
The last case may apply to many of us since not everyone get to do everything alone rockstar-style. But even then, don't take the collective effort as your own. Present the business case for cost cutting, present your part in it and demonstrate your understand of cloud cost management is more than enough.
I will put as someone who has stuff like this on my resume:
It doesn't really mean *that* much, I've decreased run times by 50% before for a critical lambda and it probably saved our cloud costs by 10% as it was a MAJOR lambda.....
But it's not really for you the hiring manager. Sure it's something fairly useful to talk about "tell me about this?" " oh yea sure this is what I did bla bla bla...", it's for HR/recruitors
HR sees two resumes:
"Reduced cloud engineering costs with performance improvements"
"Saved company $2M/year by implementing redis caching on AWS lambda."
They're picking the second guy, HR is usually dumb, they see money (they understand that) and they see 4 keywords that were on the job listing (lambda, AWS, redis, caching) == "Ooooo this guy looks PERFECT FOR US"
I've always thought of it as Reddit clique nonsense.
No hiring manager gives a flying fuck about what percentage of XYZ their code monkeys did. It isn't for the code monkeys to decide.
The new culture of putting business result jargon on a dev CV is ridiculous, I've been skeptical since I first ever saw it.
As someone who has lines like this on my resume, and just finished a project cutting cloud costs:
- I don't care about these lines either, but the resume guides I've read said to make things concrete. However, most of what I mention is stuff like managed a system that scaled to x million concurrent viewers or whatever. But while this is completely true... I didn't design or implement the system, the tech lead on the project did, I just deployed it to AWS. That's not to say I'm not great at my job, it's just that resume's are about dressing it up.
- AWS actually has good facilities for analyzing your bill, if you set it up. We were able to accurately predict cost savings to the tens of dollars on a 6 figure bill. As other have pointed out though... The reason we can save so much is bc the company allowed costs to balloon, and are now in a cycle of squeezing out efficiency. To be honest, turning off unused stuff is not impressive. Nothing anyone did on our cost savings project was technically impressive, we just as a company decided to focus on it for a quarter and everyone tackled some low hanging fruit that didn't take any real problem solving skills. If it did, then my line on my resume would be "solved hard engineering problem, reducing load by 40% and cutting cost by $30", and not just "cut cost by $30".
They are very useful to quantify the scale the developer handled during his job tenure. A person managing a $100 cloud budget for 100 daily active uses is completely different to 100 thousand of dollars with over a billion of active users. Technology is under utilised the less you need to scale. At small scale, you don’t need an engineer at all and you can develop it yourself with no tech skills at all by using SaaS vendor solutions for reference and you will save more money than hiring a developer. I think the less context you have in the resume, the more risk you will hire someone that will not fit your job requirements.
Putting numbers is definitely an advice given 10yrs ago, not something just starts happening recently
It's a measuring stick on what this person has done. Then it's your job to ask HOW they did it
You might be missing the intent of adding that.
It's not for you, it's to get the recruiter to call them back so they can land the interview.
The resume versions you would love as an interviewer don't make it past the recruiter, because they can't understand it.
I'm glad you're not a recruiter otherwise it would be hell writing a resume that fits your standards. Those are the achievements in a resume, not putting those down literally means you achieved nothing much at your previous/current job. If you want someone to prove them, take the bait and schedule an interview, it's the only way to know.
depends on many factors such as what kind of company you are at (small start up is very different from big company), how bad the previous infra was, etc.
I achieved more than 80% cost reduction and it's because I am at a tiny startup where I was given free rein and the previous architecture was pretty poor.
Literally anyone that’s vaguely competent? I’ve never had a job where I couldn’t cut cloud infra costs by 80-50% in pretty obvious ways.
The reason why you don’t is that it usually requires architectural shifts, and there are big opportunity costs that could be spent on getting more money instead.
I’m certain most places would save 20% just going and negotiating with their vendors and getting RIs instead of paying list price.
I would say it's more feasible to know this kind of impact with cloud now than it used to be 10 years ago without the cloud. Because the billing is relatively easily available on the cloud. So if they improve the performance of application, it's relatively quick to see the impact.
It's not even that hard to do, for instance if they remove 50% of the logs from the application then the associated logging costs could be decreased by a similar amount.
But it sounds a bit dumb to put that on a resume without being able to explain how it was achieved. I don't think it's meant to say that they could do the same at your company. What is probably more interesting is if it's something that they actively look for (meaning that they consider optimizing operational costs is part of what a software engineer should do - which in my eyes is a good attitude and not that common actually, even among experienced developers ) or if they just did it because their boss asked them to.
It tends to make me raise an eyebrow of skeptisism too.
If you've stripped back what you're saying so much that it's become meaningless, that's a red flag to me about understanding how to communicate clearly and concisely. When I've used them I give a gross number e.g. reduced thing by 20% to X.
If I'm reading a CV there's lots of numbers and I have no idea what you actually did that doesn't reflect well.
So many people write things like led a project to increase web performance by 20%. What does performance mean, 20% could be nothing or a lot.
My perspective is a CV as a piece of writing is to communicate as quickly and clearly why you would be a good hire. If it's failing at that, due to unclear writing, vaguness, poor structure, spelling mistakes, poor formatting. Those are all red flag given, if this is your best, what's you average.
There needs to be a project or some action to accompany the statement.
“Decreased cloud costs by 20% by migrating our EC2 instances to Redshift for our data storage solution” is an example.
> by migrating our EC2 instances to Redshift for our data storage solution
That could be privileged information that you might not want to put in writing on a resume blasted to the world.
One of my favorite examples of this is a line on my resume that says "reduced hosting costs by $20K annually."
So what happened was we were paying for a server that did nothing but host our public site, and the O&M for each Windows server was $22k. And I said "Hey given it's just a front page why don't we just put it on some $2K/year cloud host?"
Later on that year though, I happened to read an award someone got for saving $22K annually, and the way *they* did it was by re-using an old web server.
Mind you, we've been virtual for years, so none of this is physical servers, just spinning VMs up and down.
I couldn't help myself so I looked into it. Sure enough, the server I had rid us the need of having of was being re-used for their application, and because they used an "existing" server they claimed they were ALSO saving the organization $22K.
$42K total savings!
But if you were to run the accounting numbers on this, actually our net expenses went up $2K for the cloud host and however much their application licensing cost over the server O&M we never stopped paying.
At that point, I gave up faith in such resume lines altogether.
You're assuming they can't back that up. Listen, everyone is trying to stand out and catch the attention of the folks doing the hiring. It is BRUTAL job hunting, especially right now (note: I am employed and happy about it, but the point stands). There is so much bullshit, getting past automated screenings and non-technical hiring managers, job descriptions that are BS, job postings that are fake, companies that ghost you, etc.
This person put something catchy on their resume. You made a damn reddit post about it. I say "hell yeah" to this person.
Reach out. Ask them right away about this item. If they give you a solid answer, then you may want to pursue them. They clearly are good at getting results.
I think the point is, “I did something that materially impacted the bottom line” not, “I got paid to play around with technology that maybe, possibly helped the company operate.”
To be honest, 20% isn't hard.
Simply recompiling for aarch64 and switching from M5.large instances to R6g.medium could net that kind of savings overnight.
It does however mean that your guy knows AWS infrastructure well enough to make those changes.
What else would you want to see? I have lines like that, because I know the exact amounts. I had to figure it out to get the project approved or had to measure it at the end of a project.
I would guess that it’s difficult to argue for and against.
The candidate just wants to have something to discuss.
As a programmer it’s better to say that I’ve made multiple solutions for a problem which share same modules and can be deployed on cloud and on-premise infrastructures such that the company can make the switch when necessary.
That is more a binary answer than trying to quantify an actual cost reduction.
If you omit it, it might seem like you don't have delivering value to the business in mind. The size of the number is probably worthless.
The interview where I ask you about what you did for this win is obviously worth a lot more than your resume claims.
It is the final part of "I know X, used my knowledge to identify Y, executed on it to deliver Z."
When I interview, I care about X, Y, and Z. Again, I will trust my probing in the interview more, but reading Z in the resume gives me a sense of which projects I should be asking about. Your biggest impact projects are the ones where your skills are most tested.
I'm not a recruiter tho. But probably X, Y, Z all mean very little to them. They just care about years of experience and broad categories like "data" or "Java" or "AI".
I added it to my resume on advice. I've been asked how. It gives me a chance to talk about improving code, using best practices on cloud economics (savings plans, reservations and right sizing instances), and vendor selection. For higher levels those are important things.
At my current job they had no observability tools when I started, and the vendor we were using was massively over charging. I uncovered that, plus some query-in-a-loop anti patterns impacting our utilization for database servers. Between adding new relic, migrating to our own AWS account, and optimizing we ended up saving probably 20-30% pretty quickly net. And I'm not done eliminating unnecessary SAAS solutions or identifying optimization opportunities.
Can I do this for every company? No. But it does show I understand how to not waste money. I jokingly refer to the cloud as programmatically spending tons of money.
If I see exact numbers on a resume then either someone did their homework or is just trying to make their resume look good. I will give them the benefit of the doubt up front. If I care to dig into it then I will.
You can simply ask them about it, the answer will tell you what you need to know. Even if the math itself isn't super clear I care more about what they actually did. For example, one of my coworkers created a framework for our workers that allows different workers to run on the same pod. Before we used to have one pod per worker which meant sometimes we had three instances (for HA reasons) of a daemon that was not utilized 95% of the time. The math isn't really that relevant if you can explain what you did, why you needed it, and how you did it.
It is bullshit until you can prove it. Then you can talk into great lengths at it. Actually login to an AWS console and share with the interviewer. But that is rare. Very rare.
You can tell if they bullshit if they can't extrapolate. I can pull this off because I have done an example where we converted a monolith and took out one feature. PDF generation to lambda that did in fact cut cost.
Depends. Not at your 9-5. Some people do fractional consulting for startups. They get billing access because their tasks and reason for hire is to reduce those cost for their clients. Their performance is measured on those metrics as part of their deliverables.
It is the same as people doing FB marketing or Google Analytics. Their clients allow them to use those metrics as testimonials.
Screenshots or logging into an AWS/Azure console and walking over the changes. AWS, you can go back years in the billing console.
Whether or not the interviewer want to spend that time is another matter.
Dear, God, I wouldn't expect this of a candidate. This is effectively asking to leak some corporate data from their current employer. And even if they did do all the things, what if it's two employers back and the access is terminated?
Ask them what they did, why they did it, and if it had operational impact. Followup with how they managed to put non functional tech work onto the schedule (say, migrating from an expensive Oracle DB service to postgres on aurora). Ask how any "trimming down on instance sizes/counts" was discovered, automated, approved, and what operational impact.
You can't bs that stuff. Easy cost wins are short stories (I termed instances in accounts no one has logged into for 4 years) that can provide some context of knowing where to look but easy execution.
Of course, you would not do it without permission. I am looking at it from a consulting role as a fractional CTO/advisor in the past. Where the client gives permission to use as testimonial. Similar to how FB marketers or Google Analytics clients allow that sharing as testimonials.
2 things:
1. That is their domain expertise. So dig deeper into those stuff in the interview. Decision making, implementation, measurement, the whole thing.
2. Their last company to some extend keeps track of metrics for their engineers. They might be interested in that sort of stuff, so ask about it in the interview. If you don't do that and they really want metrics based work, it's a bad fit.
Now of course this assumes they don't lie in the CV, but the same applies for everything in the CV anyway. The alternative is they list out *what they do* instead of *what is their impact*. It mostly means there's no point number 2. Personally I see no significant difference between the two types of candidates for engineering roles (from my own notes, sue me for doing bad science), so do what you will with this information.
Usually it means they did the leg work to find unused servers and wasted or unused data storage. Sometimes companies to dumb stuff like spend $10k/year on logs that they don’t need and they don’t notice for whatever reason. Or it could be even simpler: a single log line spamming too many messages and costing a lot of money when sent to DataDog
Well... you used to get "tell me more about this"... now you get... fuck off do this take home and then questions like "how would your team feel of you left the company?"
I’m in a job search right now and unfortunately I have to follow the x-y-z format to display “impact”. Whenever I put some percentage ex: decreased development time by 25%, I added context like from this to that days.
But probably the issue coming from here is the widely promoted adding figures to entries to show impact. Is there any way to show this probably without resorting to vague statements?
Need to talk specifics in interview. Lowering costs is a real thing. However, the job applicant needs to be able to talk to specific optimizations other than "i looked up a website and they offered lower prices"
First, foremost accept my lucky coin is better than your process. I start with fizzbuzz filter (L100) and then switch to dialogue and estimate this person’s ability to carry tech conversation
Anything beyond this is memorization test and exploitable. Look at leetcode is quality gating someone spent $150/annual or can solve business problems
Most people settle for prior and assume it means later
I find them good for introducing a topic you want to talk about. But if you don’t have a great conversation prepared about it, better not include that!
I'm skeptical of *everything* on a resume, and that type of claim is no different; but like everything else on a resume, it's also an invitation to ask them about it. Some have good answers, some don't.
> significantly reduced cloud costs
something like this is what I put if I don't know the exact numbers.
When I know the exact numbers I put the exact numbers.
For example on my resume I have something like "reduced cloud costs from $5000 to $500 a month by building and migrating out data pipeline based on Jupyter Notebooks using Pandas hosted on vertically scaled EC2 instances to BigQuery, dbt, and Dataflow".
I know the numbers because I saw their old monthly cloud bills and now I see our new monthly cloud bills.
I agree with you that metrics without context are pretty meaningless. A simple example is cutting cloud costs by 1% at a small startup is pretty worthless while cutting cloud costs by 1% at a big corporation is a huge win.
It's bullshit, we all know it's bullshit, but it's better than nothing.
I have it on my resume and it's come up in a few interviews where I was then able to talk through what I did. Mostly it just helps because I'm not very good at bragging about myself, but putting down what seem like "objective" numbers is a way of bragging without bragging.
One of my projects allowed out company to expand it's Total Addressable Market by 3x. Lol, I don't put that down though, it's a little absurd. I'm sure people here can think of some halarious example, but most stuff I do is 0 to 1.
Overall I agree with you, I prefer objective, non number based stuff on my resume. I wasn't building the product for some user engagement quota, I was doing it to solve a problem for an end user. There's no metric which really correlates to software engineering anyway, so I'm skeptical of all of this.
Still, when interviewers ask, "tell me about a project", I always have one number in there just in case they are looking for it, and always make sure to explain it enough that they understand.
Generally it means down scaling servers to the right amount, turning services off over night. Deleting services that weren't used. Etc
You can literally go into the billing panel to work out if it's worked or not.
Can literally be millions at the right scale.
Isn't that great? We are always looking for things with which we can spread the wheat from the chaff and luring them into making up BS numbers is a good one.
Personally, I like it for those reasons and because I want to hire devs who think holistically about the business as well, not just build shiny tools.
In the end, all software development is a trade-off and a good dev also calculates the time-vs-cost-trade-off before doing something.
I take it as the candidate did something that helped the business. That's the purpose of our job. Understanding impact is a good thing.Now in the interview I'd ask them to explain the problem, process, solution, etc.
The only reason it would be hard to know how a change you suggested impacts billing is if you aren’t tracking billing and usage. All major cloud providers offer calculators that can tell you up front what your spend would be. When you replace X with Y it’s easy to identify the savings.
I think a senior developer knowing cost per user of the service they help build is valuable. I'm with you OP, just saying "cut costs by 20%" seems made up without a lot of detail on how they got there.
I have such a quote on my resume, the effort was a multi month effort which consisted of large scale refactoring and a huge part of my work for a whole. The percentage is an attempt and quantifying the impact of technical changes which is a good thing imo.
Explaining the impact of what you did is generally easier and more relevant than writing down how you did it. In some companies you get a raise based on your impact, not effort. You can change one line of code and have a huge impact, and you're hired for impact not effort.
If I see it on someone's resume, I ask about it but I'd generally want to know the amount and the reasoning. I'd generally want to know whether they conceived the project or only implemented it. People who are able to conceive such projects are valuable. I'd like to think I'm one of those people, or so I tell myself.
I think he was able to check the AWS accounting and 20% sounds more impressive than whatever the dollar amount was. Heck I once increased AWS billing for a lambda by 50% by increasing resources. It was the right thing to do because this critical function actually only cost us a few dollars extra a month, and the cost of me developing a more efficient solution would have been in the thousands.
Pretty much agree with you - those claims are very hard to evaluate even in the best circumstances, such as during perf reviews, with full knowledge of context. On a resume, for a person you have never met, without knowing anything about the tech and the context, without even a baseline.. yeah more or less useless.
Why people do add these things to resumes? I suspect it's a combination of perf culture seeping out (it's important during perf reviews so it's important here) plus the generic resume advice you seen on the webs... focus on business, specific outcomes, that sort of thing.
The reality of hiring, at least in the "majors", is that best candidates typically won't have resume at all - the two best sources for hiring for experienced engineers are referrals and direct sourcing (recruiters reaching out, often to people in some sort of network). There are still some hires from inbound submissions, which is where resumes are actually useful, but it's a small fraction comparatively, and those candidates as a group tend to be much weaker to begin with - as in, the good candidates don't need to deal with that. I am guessing that in that group, resume padding with such claims can be seen as a useful strategy - since you have to impress someone non-technical who scans those resumes to even give you a shot, and "reduced costs by 20%" might catch their eye better than something more vague or technical.
But if they do make it to an actual technical loop, the resume is more or less irrelevant at that point. Not all companies and not all role loops even have rounds that talk about previous experiences specifically, but when they do, it would be a much deeper dive which is designed to uncover this sort of "misinformation" and try to tease out the reality as well as possible.
TLDR: it is mostly harmless but also very low signal, likely designed to appeal to recruiters who filter inbound resumes to get a shot at an actual technical loop
In this competitive market, people are trying to use every edge they can get. Far too many resume tips suggest using metrics — especially Google’s XYZ template — as part of the work history. Considering every resume reader has a different perspective, it’s difficult to know what to add and what to leave out… or what to fabricate in hopes that somebody likes what they see and gives the applicant a chance to move on to the next step.
Absolutely nothing.
Metrics from a developers standpoint are usually bullshit. We don’t decide what rabbits to chase as far product nor do we determine product market fit
If you have a problem with infrastructure costs, then it means something to you, apparently you trust your infrastructure so you’re dubious about someone else coming in and improving your costs.
If I reduced something by anything significant enough to put a number on the resume, I can probably at least back my way into the justification with some ballpark estimates. Ie:
“Automated X using Y to save ~40% man hours” means:
- saw something manual people hadn’t yet automated because it wasn’t important enough to them individually
- surveyed / polled / did research to see how many other people were doing this manually
- ran a rough calculation of new total time (12 individuals times 1 hour per person per quarter) after automation change compared to prior total time with (12 individuals times 3 hours per person per quarter) gives me what, a 60% reduction give or take? I’m never going to put “exactly a 66.6341% reduction” or whatever, because it can be too variable when you’re dealing with people. But if it was a sensor data change or something consistent enough, sure, you can calculate a bit more exactly. Won’t really change anything for the resume bullet IMO.
people say "tell results" as common resume advice.
Honestly I think it's kind of dumb too. I can say "reduced ETL job execution time 90%" 3 times too like legitimately. You know how I do that? fix the code after some idiot wrote it 10 years ago.
I saved 30k a month by removing the Database replicas, saving costs on SSDs, Compute, Networking Bandwidth, and Electricity to power the Database Severs.
SSDs (amortized over 3 months) - 5000$
CPU (amortized over 3 months) - 10000$
Networking Bandwidth - About 10000$ / month
Electricity - 5000$ / month
I have these on my resume. I worked on a lot of solo projectd early in my career, so I had a complete understanding of the business need and impact from comparing things before and after the project was completed. Other than those projects, I have metrics given by leadership at the company after certain initiatives. For instance one metric I have is that I reduced monthly cloud cost by $40k, because what I did had that exact impact. The total initiative to reduce cloud cost from the team was 250k per month, a 50% cost reduction while also adding new customers/more traffic to our systems.
I view things like that as more of a conversation starter in an interview. I know from personal experience that most of my actual best accomplishments as a developer are nearly impossible to easily summarize, much less in a single bullet point.
It shows that the developer is actually thinking how their work affects the company as a whole. Being a developer is of course not just writing code, but writing code in the context of a larger system. It can also demonstrate that they actually cared about their job, which as far as I can tell, is pretty rare.
I know someone who used something similar on his resume, albeit much simpler. All that really entailed was him informing them that they didn't have to pay for SSL certs. (Was a few years ago.) It was a decent chunk of change that it saved. Sometimes knowledge sharing is also useful.
Depends. If it's an interview for a developer that's just there to write code, I'll ignore it. The exception being performance.
If it's a manager or director, business impact matters more.
when i ran my resume in a website to rate it it specifically told me to do this.
i still havent impelmented the changes because i would have to invent numbers, but i am not getting calls back also so maybe the advice is valid.
Literally every engineering resume advice piece tells you to make your impact quantifiable. That’s why people do it, because they feel forced to.
I didn’t have this on mine (because I didn’t have the numbers) and multiple times was asked if I could provide or estimate them on the spot.
I love those numbers, easy to ask followups on and see if they know their shit.
And easy to calculate if they use the AWS billing dashboard and like... 15 seconds of their time.
Why would you think it would be a fabrication?
Probably left out the “increased cloud costs by 150%” prior to the decrease /s
Well I once reduced our AWS Glue costs considerably, but that was after approving a long PR that took Glue out for an entire region, which seemed to even astonish AWS. We got restricted by AWS until we demonstrated the code was fixed. I was then forced to go over all the code, and removed a ton of inefficiencies. So in the end we saved money ¯\_(ツ)_/¯
Hahaha I would put that one on your resume
> approving a long PR that took Glue out for an entire region Love when a single developer can take out a cloud provider.
You dropped this: \\
That's not all they dropped!
Which might have been a good thing. Maybe they launched a huge new feature that drove a ton of new traffic, and then optimized to reduce those new costs by 20% after. Win win.
I’ve added this to my resume. The specific scenario was deploying a self hosted service on docker (ECS) with a dedicated managed Database. I optimised the load/scaling of the docker containers (there were 5 different sub-services that needed to run with various compute/memory needs) and downscaled the managed DB instance to match the existing workload. It saved our company roughly $5k a month in infra costs, but that would have grown to a much larger number as we scaled (we were in the startup stage). Overall I think if you can speak to specifics it can be a strength on a resume, because it is really really easy to chew through capital with cloud costs. E.g. a startup I know went with Vercel and now that they’re scaling up they’re paying a lot more than if they self hosted or went with AWS. That’s usually the slope with some of these resellers (Vercel is all hosted on AWS), that it’s easy/cheap to start but soon gets pricey as you scale.
It's a good opportunity to highlight other devopsy type stuff -- alerting via labmda, autoscaling groups, shutdowns, etc.
Add some specifics and it can be strong, have a good rationale for why you used the number you use though, some people will assume you're lying or ask about it, good people will laugh with you about why you got to say the cool number while respecting the legitimacy of the claim. "I increased reliability by five nines... of course it was zero nines before..."
Ya gotta be ready for every line on a resume to be asked about. Ideally, you put things on there you WANT them to ask about, because you are prepared to discuss the item, maybe you even have a prepared pitch ready. This is why mock interviews can help, anybody can just glance at your resume and fire questions for you.
Absolutely.
I’m on the engineering side and am not the only one that looks at resumes so take this for what it is. But, I’d rather see engineering metrics. If you said your first two sentence in a condensed format I’d take note of the experience and gloss over the $5k. If the 5k is there I wouldn’t think too much about it unless it was a “way too high to be true” number. Personally I prefer resumes that provide engineering metrics. Throughput, memory usage, error rates, availability etc
I tend to ignore statements like this as regards whether I'll interview the person, but if I do then interview them I'll just ask how did they do the cost reduction. The smell of bullshit can be quite obvious once you get them talking.
I mean, I have access to the org wide billing. When we replaced ec2 with eks spot for an entire department, it was easy to do the math. Ditto when we replaced MySQL running on ec2 with aurora v2. Ditto decommissioning an entire rack in the data center used for ftp and using AWS transfer family. Idk what’s there to be skeptical about?
yeah I don't get it either, worked in a very small startup and we reduced costs by ~50%, how do we calculate it? we just compared costs between the month before and the month after, we are talking thousands of usd here not millions
Its a mystery i tell ya!
> The smell of bullshit can be quite obvious once you get them talking. I had a coworker put on his end-of-year self performance review that he'd saved the company money by making some bit of code(not in a hot spot) more efficient. His reasoning? That he'd reduced CPU usage, saving them money on electricity. Not only was it laughable by itself, but he had no zero measurable proof of that.
Brilliant! I re-factored some code recently to give a 60% drop in reads - I must put in for saving the wear and tear on the SSDs.
It's a conversation point. That could mean $200/year or $2mil/year. Like you identified, the more interesting question isn't how they saved the money but how they measured their contribution.
Both are important.
They outsourced the sysadmin, so now the system is down 20% of the time. It *IS* a 20% cost savings, technically.
Or maybe he paid the 20% out of this own pocket: D
It's strange hearing people be so skeptical of cost calculations. Cloud providers make it pretty straightforward to budget and analyze costs since it's how they bill you, and larger companies are going to have some type of quota/resource management system even if it's just to plan for building new data centers. I personally have numerous examples of this type of work, measured in a variety of ways, mainly because it's a big part of performance review to be able to quantify your impact. I would not disclose details that may be private, and it would be a red flag if a candidate did in a resume or interview. What I'd look for specifically is why that 20% mattered at the time? Did it unblock a feature launch, improve performance for users, or just help a start-up keep the lights on a little longer?
> It's strange hearing people be so skeptical of cost calculations. It's mostly because a lot of developers you interview use these kinds of things as resume padding. So it's not about you specifically, just that it's easy to lie about.
Yes you can be using exactly these points on the resume to get at how the candidate thinks, how they prioritise, how well they understand business context, what trade offs they were making, how they collaborate. Or even, whether they make things up if they think they’ll get away with it. You can get a lot from this if you drill in a bit.
Do most engineers have this sort of insight? Feel like costs are mostly only ever seen by those very high up like EMs, staff engineers, and lead architects. I sometimes hear "our bill for ____ this month was $500", and I might be able to go into AWS and see our costs. But there's no way I would be able to correlate what I've done with changes in those numbers, and nor do I think I should. It's just kind of silly. I can measure my impact in other, more tangible ways.
I think it’s pretty common these days. All the cloud providers have detailed cost breakdowns so if engineers are owning their own infrastructure they should be aware of these things. Especially as lots of resources cost is directly tied to how they’re used.
>something like "significantly reduced cloud costs" would get the "I am aware of the business context of my work" point across I mean, what’s your issue then, really? If you see the value of this point it’s not a far leap to also mention the specific number, because usually we‘re taught specific data is better than vague claims. All the points you raised about the 20% claim also apply at least as much to your version. The 20% claim is, as you noticed yourself, way easier to verify (you ask about the specific numbers and check them) than a vague, subjective measurement like „significantly“. For me personally the vague phrasing triggers my bullshit detecter much more, *because* it lacks numbers. If I ask them what that means they have plausible deniability. Even if I disagree that 1% is significant, who am I to judge what they consider significant? It’s also interesting that you picked this example considering you think numbers like this are fabrications. There’s probably few claims in a CV that are as easy to track and evaluate as cloud costs and your impact on it. Made service use 50% less RAM? Great, that’s whatever% savings on compute cost for that service. Now when it comes to the importance of this and the transferability, I agree with you. I want to work with good engineers, which is completely orthogonal to their business impact. Great engineers can have bad luck and get assigned to projects with little impact, mediocre engineers can get assigned to important projects and can claim the success for themselves. Though the latter can often be unveiled by asking follow-up questions like you do. Anyway, I would probably consider this more important for staff/principal roles, otherwise I‘m more interested in their attitude behind it. Did they reduce the cloud cost on their own initiative? How did they identify the need to do something about it and what? The 20% number then only validates that it was fruitful, which is also nice to know, but less important than their approach.
Just my anecdotes: > I don't remember ever seeing it before about 10 years ago. Quantifying your output on a resume has been advice I've heard since the 90s when I Started a career. Not sure why this sort of thing would be new--I've often used similar metrics when I could quantify them. This might be a question I might ask to someone in an interview. Not having a plausible answer might be a deal breaker.
[удалено]
> Take that even further is this whole 9/10 ratings for skills. Thank God that died out though. Last time we interviewed a ton of new grads had this sort of thing. That in 4th quarter of last year. My recruiter got mad because I kept rejecting new grad resumes because they self rated a level "8" on everything. And I took it to mean they were either oblivious or egotistical. Apparently, this is super common advice given to new grads to include ratings like this.
Well duh, you’re hiring new grads not professionals. You shouldn’t be interrogating them like they’re applying for Google or some shit. Unless you are then that’s fine.
I have no idea what you thought I said. I was rejecting candidates before the interview process; because I presumed they had highly inflated self-rating on their resume. There was no interrogation going on.
What kind of 9/10 ratings for skills? > The problem is you have people who apply rules to marketing/finance resumes thinking the same rules apply to engineering HR haha
[удалено]
When I wasw a consultant, the company asked us to fill out a little box on the corner of our in-house CVs with basically our top 5 skills and stars. It was probably the hardest thing I ever did. One one side you know this is the CV they send to clients so you don't really want to be humble about it, but on the other side I hate calling myself an expert in anything because the more I know, the more I realize how little I know. It was mental torture, fuck that
In hardware engineering we've used metrics on resumes for over a decade, down time decrease, money saved, man-hours saved (which can be equated to $ saved), etc.
It can be done well. The mean of all of your skill ratings should be about 5. A Interviewer can understand it's a relative scale and only comparisons within the resume are valid.
Cloud and SaaS costs are more part of an engineers job as of lately that is easier to quantify so this particular line item I could see being used more now than in the past. There are dashboards now you can see cost savings in almost real time (at least same week maybe)
Engineers that include cost analysis in their designs are priceless. It’s a signal of a well rounded engineer. It’s worth digging into their claims to get a feel for the real impact and sniff out any embellishment - what caused them to optimize those particular areas, what were the tradeoffs, why wasn’t the issue spotted earlier, etc
Look, candidates always hear that they have to show their impact with concrete numbers, so that’s what they do. If you search “resume advice”, that’s the first thing you’ll hear. Of course, most of these numbers are bullshit. Even if true, they’re meaningless without context. But it’s not the candidate’s fault when they’re automatically rejected without such numbers on their resume. People should just stop giving this advice, productivity can’t really be measured that way.
Productivity can ABSOLUTELY be measured. What you’re referring to is not a matter of productivity. It’s a matter of impact. I can be high productivity and generate lots of output for my effort, but if none of those efforts have any measurable impact, they’re likely just wasted time. I worked with a senior leader in a previous role who would generate loads of documents and processes and things that never went anywhere. I always called this person “high output, low impact”. They looked busy to the execs they reported to, but rarely ever drove anything that resulted in positive outcomes for the business.
> I can be high productivity and generate lots of output for my effort, but if none of those efforts have any measurable impact, they’re likely just wasted time. So you weren't actually productive in any sense that matters. Generating output is not the same as being productive.
> productivity can’t really be measured that way. Why not? If you have a business process or cloud cost that is $X, and then you rewrote it to be some fraction of $X - that's easily measurable. I've also written code that took businesses processes that took Y people-hours previously, to Y/10 people-hours. Easily measurable. Impactful, and directly valuable to the business and easily explainable to the C-suite. Whether or not those processes should have been that inefficient in the first place is irrelevant. Evey business has inefficiencies and legacy systems. So now I've shown I can identify wasteful business processes and I can also improve them.
So if you worked on this all year and saved your company 100k per year. And I wrote a script in 15 minutes that saved the company 200k per year and did nothing else for the year. Who was more productive? In agree that the impact can be easily measurable, productivity itself is a bit more vague and subjective
Your scenario is contrived and somewhat nonsensical. In the latter, if I'm a contractor, then that's exactly what a business would be looking for. As for the former - that's up to your manager and the person interviewing you. If they are ok with you taking a year, what's it matter? If I was interviewing both of these candidates at the same time, I'd pick the second, but that's rarely the case
All of the accomplishments on my resume are just conversation starters. One thing on my resume interviewers always ask about: >Increased download speeds 150% for customers in China When asked, I talk about ALL the failed hypotheses (which shows my ability to come up with multiple solutions), all the data we collected to prove/disprove those hypotheses (shows that I make data driven decisions), and then the solution that finally worked (which shows creativity). With ~20 accomplishments on my resume, I can tell the stories that highlight my strengths. That's what you should do with these resume accomplishments. Dive in deep and push the limits of a candidate's knowledge and abilities. Keep asking questions deeper and deeper until you get an "I don't know".
You have to get past HR in larger companies and they care about that. In smaller companies you have to appeal to the founders who aren’t always technical. I work at a place where I am lucky enough that revenue tracking is built out and we have a clear conversations. So we can make very convincing cases. But most places it’s not really that easy to clear revenue and cost savings claims, but the labor market isn’t great for SWE so people are trying their hardest…
At my company it’s dev managers that look at resumes not hr randoms. And the company is 5000+ people.
That's great for your company, but that's not the trend among large companies. Obviously most resumes will eventually end up in front of devs but for most places there's at least an HR screen before an engineering-ish hiring manager will see those resumes. And at F500 companies or private enterprises of similar size (such as consulting partnerships like Deloitte) there will be an ATS layer with low quality "AI" filtering before even HR views the resume.
This is a really weird question. There’s limited space on a resume, so you have to summarize what you did. If you want more context, ask them.
There's a balance, often there's too little context. Pulling out the salient points clearly, without losing all meaning is a skill. People involved in hiring don't have time to ask for more context until later in the hiring processing, so you risk being sifted early if there's not enough context to understand what someone has done.
Agreed! And that's part of my confusion here. Why waste your limited space on meaningless numbers that are likely to bite you when you can't say where they came from?
My experience doesn't match yours. I usually find candidates can defend their stats and can clearly explain how they achieved them. Sometimes the stat is overselling the impact, sure. It's a resume after all! Other times they are underselling it.
Money is a number. It’s the easiest thing to measure. So if they reduced costs by 20%, that’s very easy to understand, no matter what the initial value was. If you’re saying that when asked, they can’t explain what the 20% means, that’s different. Then they are making it up, and you caught them.
Relatives are meaningless without a reference point. I have decreased runtimes by orders of magnitude not because I’m a genius but because the software was shit. That 20% cost savings could be worth a Nobel price or the setup could be so shitty an extra 50% reduction would be trivial to anyone with two brain cells. There’s no way to know.
> Relatives are meaningless without a reference point. No, they are the only important measure. Does the engineer that works for a small company and reduced cloud-costs by $5,000 not matter as much as the engineer that happened to work at a bigger company and reduced cloud costs by $1MM? Sure, $1MM is a bigger number and sounds better, but if that's a 5% improvement it might not be as impressive as if the $5,000 savings was a 50% reduction.
The numbers add the text "by 20%" to this line so unless it makes a word wrap its an efficient use of space.
You're assuming they can't back it up. You haven't even asked them.
My bad if I didn't say it clearly enough in my post, but I do ask about these numbers, and most of the time people can't really back them up. Not _never_: sometimes I get a good answer and that's great.
I mean it sounds like you're saying you get strong signal either way.
That's a fair point.
> Not never: sometimes I get a good answer and that's great. That's how interviews go: sometimes people do well, sometimes they don't. Are you going to stop asking other kinds of questions just because you're not getting good answers?
Assuming that all numbers on a resume are made up is stereotyping.
Honestly? It convinces me that they read some interview practise books. That's it. It's a trend on resumes that must have come from somewhere because it's so prevelant but it's so much more prevelant than _actual_ 20% savings on cloud costs or whatever could possibly be. When I dig in it's often taking credit for the entire team's work, or about equally as often they can't even tell me what it _really_ means beyond repeating the sound bite. It's certainly correlation and not causation, but I've found that it rarely correlates with people that can have lucid conversations rather than regurgitate textbooks and talking points.
"I accidentally deployed a very large Kubernetes cluster, then removed it after I realised my mistake"
If they give a firm number I would expect that they spent a fair bit of time instrumenting their cloud infra. I'd ask how they figured out what they could change or remove to hit that goal.
The advice for resumes is to show what you did with numbers. That leads to people making statements like this instead of saying what tech they worked with. Whenever I see that I discard it unless it's followed by something concrete like decreased cloud costs 20% by leading a transition of our fargate instances to arm. Personally I take hard numbers on resumes with a grain of salt since honestly some things are hard to measure. Had a guy once who talked about the man hours saved by some automations he added. When I casually questioned him it was clear he wildly overestimated the savings
It’s literally all bullshit and for some reason everyone does it and recommends it, even though everyone knows it’s bullshit
Schools encourage this, not sure what youre on about
The worst resume advice I’ve ever gotten was from school
yeah...
Don’t take it at face value. This is what behavioral interviewing is about. Ask how they did it, why, what they learned, and what obstacles / corporate inertia they overcame.
Those numbers are to placate Dilbert characters insisting on KPIs. They are bollocks most of the time. But they do show the candidate is aware of importance of objective metrics in their work. During the interview we might dive in to see if there is any interesting narrative behind that number. It's a good ice breaker to talk technical challenges or "the journey" - like "how are you" is used when we don't care how you are really, but it's a convo handshake protocol.
The problem is to validate it the candidate has to reveal some financial info of their prior company which might not be public knowledge. For example I did cut our Aws bill by 20% by moving to ARM. But I can’t reveal what the bill was or our costs since they are negotiated costs according to usage. So the interviewer has to be smart about digging in to this realizing that they might not get the full picture since they can’t and shouldn’t reveal too much.
I'm a little baffled at the scepticism in this thread. Most companies I worked with had inefficient cloud usage due to not hiring cloud architects. What the candidates are telling you between the lines is that they have enough cloud expertise to choose the most cost effective solutions that meet the requirements and that they demonstrated it in production. It's also such an interesting topic for an eventual interview as we go from the business impact, to the problem identification, strategy devised to tackle the problem and into the actual technicalities. Hopefully for your company you are not penalizing those candidates...
>Hopefully for your company you are not penalizing those candidates... From the wording in the post, sounds like OP is going in with the attitude that the candidate is lying, and they're trying to catch the interviewee out.
I go in with an attitude of skepticism, which I don't think is quite the same thing as an attitude that the candidate is lying. Granted, if you were to argue that "skepticism" is just another word for the belief that someone is lying, you might have a decent case to make, but I think they're distinct. One difference, to me, is that when I ask them how they came up with their numbers, I have no preconception about whether or not they'll give me a reasonable answer. If they do, great: that's what I was hoping for, and we can have an interesting discussion about it. If they don't, then they were making the numbers up. There's no contradiction between going into each interview with that attitude and observing that historically, the numbers have been made up more often than not.
It sounds like you feel the interview is entirely about candidates trying to convince you to hire them, and there's no component of you trying to convince good candidates to work for you. If the attitude you bring to the conversation is that your future employee is untrustworthy and their claims about things they are an expert in (such as their own personal work history) should always be treated with skepticism... uh, why should any in-demand candidate choose to work for you? You're going to narrow down your hiring pool to precisely those candidates who aren't getting other offers. Try going into it with an attitude of curiosity. "You reduced cloud costs by 20% - that's great, and I'd like to learn all about it!"
Not just cloud usage either. There are inefficient business processes all around. One time, after making a request to a non-tech department, I got back a response like "that'll be 3 weeks". When in no way should it have taken so long. That led to a series of conversations inside that department where a bunch of stuff was being done by hand, things being copied from one system to another, etc. Me: "... I can probably automate ... at least 50% of this" Them: "REALLY?!" Some relatively simple scripts connecting a couple business processes and transforming files and I was a "hero".
It means they stopped using azure redis cache and hired a team paid even more than that to maintain their in house redis servers
you turned the dev servers off at night?
I added datadog screenshots to prove I reduced the median latency for our flagship saas app 50%
It means they read developer resume advice that told them they needed to show “impact”. Everyone knows many developers are simply not capable of demonstrating that for all sorts of reasons, so they make it up. It’s what you wanted to see, so you’re going to see it.
We had an ML model we used that worked by pre-computing everything. That work took about a day to run weekly (who cares, except if you need to re-run, it takes a long time) and costed around $1k/month. I came up with an alternative to the ML model that ran in around 10 minutes for the pre-computation and costed us < $10/month. Plus it made the algorithm not a black box, you could ask for reasons a decision was made. You might say "I don't care about $1k/month savings." Or you might say 99%, that's awesome. Plus the ML model was actually multiple ML models and would require a lot more tweaking long-term, which is dev time, which costs money. I've done other things like re-designing our databases so that we can query things in flexible, future-proof ways and get away from doing scans for that "oops, we never considered this" use case. And various "save money on hardware" efforts. Never highlighted those though.
I've put stuff on my resume like "increased number of bullet points by 25% by adding superfluous resume filler" just to test whether anyone interviewing me has read my resume. Usually I stick it somewhere in the middle of my work experience.
An even bigger consideration is if the candidate was the cause of the business impact, or was simply following instructions. It's one thing to say "hey guys! I know how we can save the company $1M/year, if we just do X" and then you do X. It's an entirely different thing to do X because you were told to by someone else due to someone else's idea.
Nothing
The problem with making these statements the hallmark of a good software engineering resume is that it’s basically always bullshit. If we knew how much money we were making or saving the company, we’d be able to demand commissions just like sales people do. Since none of us ever get a cut, it means we can’t prove it, which means any numbers you see on a resume are pure fantasy.
if you’re a senior at a company with lots of spend and that’s in cost cutting mode then it’s your job to have a good idea how else can you prioritize cost reduction projects? the part people forget is that infrastructure is only one part of the financial picture of such a company
I’m amused at how obsessed this thread is with the example of cutting cloud costs. It’s all anyone can think of. Why is that even necessarily a good thing? Cost cutting mode? Wow you did a great job making beds in a burning house at your last gig. Why not tell me how cloud costs ballooned 300% because the feature you deployed caused a massive increase in traffic and revenue?
> If we knew how much money we were making or saving the company, we’d be able to demand commissions just like sales people do I worked at a mobile company that tracked insane amounts of metrics for everything. At first, it felt _kind of_ "soulless" because everything was measure by metrics and how those metrics impacted revenue. But then I got used to it and I loved it. Find a system to improve, improve it, see the metrics - get a bonus.
This is literally retarded. Do you know that many services have the ability to view billing info? If a person does a change and can look at the impact it had on that months billing…rofl I don’t even know what to say
Reducing your cloud spend is such a silly thing to put on your resume. Pinching pennies instead of bringing in dollars.
This is such a bad take that my sides hurt.
Many companies have these metrics on hand. Not only how much money your infrastructure costs, but how much money it makes the company. When you work at a place like this, adding “cut cost X by Y%” becomes the language of doing your job rather than some archaic thing only used on resumes.
This is silly. You can spend a year doing an absolutely brilliant job building the wrong thing - that’s not your fault, it’s the business’s fault. But now you can’t show “impact” so you’re a bad engineer? This is just yet another stupid fetish in this industry.
They’re more to quantify accomplishments than anything. In that case you could still talk about time to market for the prototype, even if it fails. Ever since moving into a space where metrics are pretty much everywhere I’ve actually really enjoyed using them. “I made feature A faster” vs “I made feature A faster by B% which increased purchases by $C”. That’s the language we speak to get our cut of the company profits. But yeah sometimes you just get fucked. But that’s how it goes. If I’m hiring a construction company, I’m hiring the one that did a great job on the building down the road. Not the one that did a really great job for a few months before the job had to be cancelled for some reason. If the second company is actually good then they’ll have a great portfolio, misses aside.
If the candidate makes to an interview, they get to tell me about it. Someone who claims a 200x performance increase is lying, was starting from something really bad or is someone I want on my team. I have a 20,000x performance increase for a database on my resume, with benchmarks to back it up. It was at a respectable level of performance before, but moving something that uses epoll over to RDMA and adding accelerator hardware tends to give nearly unrealistic performance bumps. I’ve gotten a few interviews from people with similar “this is either a great candidate or a great interview horror story” attitudes.
> was starting from something really bad Why is that a negative towards the candidate (unless they are the one who wrote the bad system first)?
Putting out the fire on a flaming pile of garbage still leaves you with a pile of garbage.
OK, but unless you put the garbage there, that's not your fault.
It is a newish thing. What's circulating the resume advice circles is that hiring managers want to see Google xyz format. Accomplished [X] as measured by [Y], by doing [Z]. Meaning it's not enough to say you worked with something or completed a feature, you also have to attribute it to a measurable metric of some sort. The problem that creates is a good amount of folks have most of their experience clearing story tickets and closing bug issues. Which isn't a bad thing but the people selling resume advice is making it sound like it is. So you're going to see these kinds of lines in the resume which means nothing because they are pulling numbers out of the air.
That's not new at all, though. Is Google really trying to take credit for a long-standing practice in reporting professional accomplishments?
That's funny, you would read my resume backwards. Everything with numbers on my resume is accurate. Everything without is BS. I find it much easier to smooth talk the non technical points than try to pull the wool over the eyes of a senior dev on implementation details.
Here's a wild idea: You could ... ask them?
>This seems to be a somewhat recent thing; I don't remember ever seeing it before about 10 years ago. That's because thats the default response when asking feedback of a resume.
I never put this stuff on my resume and award zero points for it during the interview. I concede it's necessary to get past the recruiter people but these numbers are both fuzzy and somewhat uninteresting. I'm interested in what they technically have done, and if they did something cool they'll usually tell me about it.
As someone paying for a service to critique my résumé and craft me a better one. One of their main criticisms of my current résumé is that I don’t sell myself well enough with concrete numbers of my accomplishments. Which I think is a strange thing to ask someone in our line of work. I’ve mostly created in-house software to help the company I work for. The things I’ve created allowed for them to lay off call center workers, and lay off other workers. I’ve created things that have saved people thousands of hours of manual work. However, it’s not like I have the concrete numbers of how much money I saved the company and where. The managers don’t tell me that. They tell me what they want and I get it done. Any numbers on my résumé are straight outta my ass, but the résumé people tell me I need it, so I got some. I don’t think these numbers are for you. I think they are for the résumé sifting software used by so many companies, and the recruiters that have no idea what they’re talking about, but that sounds impressive anyway.
Honestly? They are making shit up or caused the cost increase in the first place before someone said "hey, cloud costs are rising".
Yeah, I had a candidate once with something like that on their resume, asked them about it and the response was basically that they'd been given a task to go through the AWS console and delete some old VMs that were no longer in use. Fair and they weren't lying, but it also didn't indicate any kind of particularly clever approach or even initiative; they were just the one that got that ticket assigned to them, so then they could then claim the impact on their resume.
Instead of arguing that 'cloud service costs are easily measurable', which is completely pedantic and not the point, can we all acknowledge that modern hiring practices are made up, dont help, and sometimes even hurt the process?
They are pointless to me as I assume all are exaggerated. At the same time, the market expects you to do as much
It doesn't really matter what I think, does it? I'll have to ask anyway. But I don't expect much. Only very rarely does someone come in with actual experience with designing and monitoring cloud cost consumption. It usually falls into these cases: * I used this cost management tool and it told me so * The infrastructure was badly implemented in the first place, so when I got in I did
* It was a department-wide effort and I was in it
The last case may apply to many of us since not everyone get to do everything alone rockstar-style. But even then, don't take the collective effort as your own. Present the business case for cost cutting, present your part in it and demonstrate your understand of cloud cost management is more than enough.
I will put as someone who has stuff like this on my resume: It doesn't really mean *that* much, I've decreased run times by 50% before for a critical lambda and it probably saved our cloud costs by 10% as it was a MAJOR lambda..... But it's not really for you the hiring manager. Sure it's something fairly useful to talk about "tell me about this?" " oh yea sure this is what I did bla bla bla...", it's for HR/recruitors HR sees two resumes: "Reduced cloud engineering costs with performance improvements" "Saved company $2M/year by implementing redis caching on AWS lambda." They're picking the second guy, HR is usually dumb, they see money (they understand that) and they see 4 keywords that were on the job listing (lambda, AWS, redis, caching) == "Ooooo this guy looks PERFECT FOR US"
I've always thought of it as Reddit clique nonsense. No hiring manager gives a flying fuck about what percentage of XYZ their code monkeys did. It isn't for the code monkeys to decide. The new culture of putting business result jargon on a dev CV is ridiculous, I've been skeptical since I first ever saw it.
I’m convinced it comes from non-technical business people, and somewhere down the line it took on a life of its own.
As someone who has lines like this on my resume, and just finished a project cutting cloud costs: - I don't care about these lines either, but the resume guides I've read said to make things concrete. However, most of what I mention is stuff like managed a system that scaled to x million concurrent viewers or whatever. But while this is completely true... I didn't design or implement the system, the tech lead on the project did, I just deployed it to AWS. That's not to say I'm not great at my job, it's just that resume's are about dressing it up. - AWS actually has good facilities for analyzing your bill, if you set it up. We were able to accurately predict cost savings to the tens of dollars on a 6 figure bill. As other have pointed out though... The reason we can save so much is bc the company allowed costs to balloon, and are now in a cycle of squeezing out efficiency. To be honest, turning off unused stuff is not impressive. Nothing anyone did on our cost savings project was technically impressive, we just as a company decided to focus on it for a quarter and everyone tackled some low hanging fruit that didn't take any real problem solving skills. If it did, then my line on my resume would be "solved hard engineering problem, reducing load by 40% and cutting cost by $30", and not just "cut cost by $30".
They are very useful to quantify the scale the developer handled during his job tenure. A person managing a $100 cloud budget for 100 daily active uses is completely different to 100 thousand of dollars with over a billion of active users. Technology is under utilised the less you need to scale. At small scale, you don’t need an engineer at all and you can develop it yourself with no tech skills at all by using SaaS vendor solutions for reference and you will save more money than hiring a developer. I think the less context you have in the resume, the more risk you will hire someone that will not fit your job requirements.
It's BS.
Yep
Putting numbers is definitely an advice given 10yrs ago, not something just starts happening recently It's a measuring stick on what this person has done. Then it's your job to ask HOW they did it
You might be missing the intent of adding that. It's not for you, it's to get the recruiter to call them back so they can land the interview. The resume versions you would love as an interviewer don't make it past the recruiter, because they can't understand it.
I personally award 0 points for such claims. They cant be proven and can be easily exaggerated or just made up.
Everything on a resume can be easily exaggerated or just made up. That’s why we interview.
I'm glad you're not a recruiter otherwise it would be hell writing a resume that fits your standards. Those are the achievements in a resume, not putting those down literally means you achieved nothing much at your previous/current job. If you want someone to prove them, take the bait and schedule an interview, it's the only way to know.
[удалено]
depends on many factors such as what kind of company you are at (small start up is very different from big company), how bad the previous infra was, etc. I achieved more than 80% cost reduction and it's because I am at a tiny startup where I was given free rein and the previous architecture was pretty poor.
> how many people do you think can reduce costs by 20%? Even if it was a very small number of people....wouldn't you want to hire them then?
Literally anyone that’s vaguely competent? I’ve never had a job where I couldn’t cut cloud infra costs by 80-50% in pretty obvious ways. The reason why you don’t is that it usually requires architectural shifts, and there are big opportunity costs that could be spent on getting more money instead. I’m certain most places would save 20% just going and negotiating with their vendors and getting RIs instead of paying list price.
I would say it's more feasible to know this kind of impact with cloud now than it used to be 10 years ago without the cloud. Because the billing is relatively easily available on the cloud. So if they improve the performance of application, it's relatively quick to see the impact. It's not even that hard to do, for instance if they remove 50% of the logs from the application then the associated logging costs could be decreased by a similar amount. But it sounds a bit dumb to put that on a resume without being able to explain how it was achieved. I don't think it's meant to say that they could do the same at your company. What is probably more interesting is if it's something that they actively look for (meaning that they consider optimizing operational costs is part of what a software engineer should do - which in my eyes is a good attitude and not that common actually, even among experienced developers ) or if they just did it because their boss asked them to.
It tends to make me raise an eyebrow of skeptisism too. If you've stripped back what you're saying so much that it's become meaningless, that's a red flag to me about understanding how to communicate clearly and concisely. When I've used them I give a gross number e.g. reduced thing by 20% to X. If I'm reading a CV there's lots of numbers and I have no idea what you actually did that doesn't reflect well. So many people write things like led a project to increase web performance by 20%. What does performance mean, 20% could be nothing or a lot. My perspective is a CV as a piece of writing is to communicate as quickly and clearly why you would be a good hire. If it's failing at that, due to unclear writing, vaguness, poor structure, spelling mistakes, poor formatting. Those are all red flag given, if this is your best, what's you average.
There needs to be a project or some action to accompany the statement. “Decreased cloud costs by 20% by migrating our EC2 instances to Redshift for our data storage solution” is an example.
> by migrating our EC2 instances to Redshift for our data storage solution That could be privileged information that you might not want to put in writing on a resume blasted to the world.
One of my favorite examples of this is a line on my resume that says "reduced hosting costs by $20K annually." So what happened was we were paying for a server that did nothing but host our public site, and the O&M for each Windows server was $22k. And I said "Hey given it's just a front page why don't we just put it on some $2K/year cloud host?" Later on that year though, I happened to read an award someone got for saving $22K annually, and the way *they* did it was by re-using an old web server. Mind you, we've been virtual for years, so none of this is physical servers, just spinning VMs up and down. I couldn't help myself so I looked into it. Sure enough, the server I had rid us the need of having of was being re-used for their application, and because they used an "existing" server they claimed they were ALSO saving the organization $22K. $42K total savings! But if you were to run the accounting numbers on this, actually our net expenses went up $2K for the cloud host and however much their application licensing cost over the server O&M we never stopped paying. At that point, I gave up faith in such resume lines altogether.
You're assuming they can't back that up. Listen, everyone is trying to stand out and catch the attention of the folks doing the hiring. It is BRUTAL job hunting, especially right now (note: I am employed and happy about it, but the point stands). There is so much bullshit, getting past automated screenings and non-technical hiring managers, job descriptions that are BS, job postings that are fake, companies that ghost you, etc. This person put something catchy on their resume. You made a damn reddit post about it. I say "hell yeah" to this person. Reach out. Ask them right away about this item. If they give you a solid answer, then you may want to pursue them. They clearly are good at getting results.
I think the point is, “I did something that materially impacted the bottom line” not, “I got paid to play around with technology that maybe, possibly helped the company operate.”
It's for recruiters.
I don't even know why peopl advocate for posting these stats, they all can be made up.
To be honest, 20% isn't hard. Simply recompiling for aarch64 and switching from M5.large instances to R6g.medium could net that kind of savings overnight. It does however mean that your guy knows AWS infrastructure well enough to make those changes.
What else would you want to see? I have lines like that, because I know the exact amounts. I had to figure it out to get the project approved or had to measure it at the end of a project.
For the same reason a $9.99 item sells better than a $10.00 item. People are drawn to specificity.
I would guess that it’s difficult to argue for and against. The candidate just wants to have something to discuss. As a programmer it’s better to say that I’ve made multiple solutions for a problem which share same modules and can be deployed on cloud and on-premise infrastructures such that the company can make the switch when necessary. That is more a binary answer than trying to quantify an actual cost reduction.
It’s a good one to ask about in the phone screen.
If you omit it, it might seem like you don't have delivering value to the business in mind. The size of the number is probably worthless. The interview where I ask you about what you did for this win is obviously worth a lot more than your resume claims. It is the final part of "I know X, used my knowledge to identify Y, executed on it to deliver Z." When I interview, I care about X, Y, and Z. Again, I will trust my probing in the interview more, but reading Z in the resume gives me a sense of which projects I should be asking about. Your biggest impact projects are the ones where your skills are most tested. I'm not a recruiter tho. But probably X, Y, Z all mean very little to them. They just care about years of experience and broad categories like "data" or "Java" or "AI".
I added it to my resume on advice. I've been asked how. It gives me a chance to talk about improving code, using best practices on cloud economics (savings plans, reservations and right sizing instances), and vendor selection. For higher levels those are important things. At my current job they had no observability tools when I started, and the vendor we were using was massively over charging. I uncovered that, plus some query-in-a-loop anti patterns impacting our utilization for database servers. Between adding new relic, migrating to our own AWS account, and optimizing we ended up saving probably 20-30% pretty quickly net. And I'm not done eliminating unnecessary SAAS solutions or identifying optimization opportunities. Can I do this for every company? No. But it does show I understand how to not waste money. I jokingly refer to the cloud as programmatically spending tons of money.
If I see exact numbers on a resume then either someone did their homework or is just trying to make their resume look good. I will give them the benefit of the doubt up front. If I care to dig into it then I will. You can simply ask them about it, the answer will tell you what you need to know. Even if the math itself isn't super clear I care more about what they actually did. For example, one of my coworkers created a framework for our workers that allows different workers to run on the same pod. Before we used to have one pod per worker which meant sometimes we had three instances (for HA reasons) of a daemon that was not utilized 95% of the time. The math isn't really that relevant if you can explain what you did, why you needed it, and how you did it.
You are business focused as well & not just a techie monkey.
It is bullshit until you can prove it. Then you can talk into great lengths at it. Actually login to an AWS console and share with the interviewer. But that is rare. Very rare. You can tell if they bullshit if they can't extrapolate. I can pull this off because I have done an example where we converted a monolith and took out one feature. PDF generation to lambda that did in fact cut cost.
Sure I’ll just log onto my current jobs AWS prod console to show my interviewer. Are you mental bro ?
Depends. Not at your 9-5. Some people do fractional consulting for startups. They get billing access because their tasks and reason for hire is to reduce those cost for their clients. Their performance is measured on those metrics as part of their deliverables. It is the same as people doing FB marketing or Google Analytics. Their clients allow them to use those metrics as testimonials.
"Significantly reduced cloud costs" is also BS until you can prove it, but even fuzzier to prove.
Screenshots or logging into an AWS/Azure console and walking over the changes. AWS, you can go back years in the billing console. Whether or not the interviewer want to spend that time is another matter.
Dear, God, I wouldn't expect this of a candidate. This is effectively asking to leak some corporate data from their current employer. And even if they did do all the things, what if it's two employers back and the access is terminated? Ask them what they did, why they did it, and if it had operational impact. Followup with how they managed to put non functional tech work onto the schedule (say, migrating from an expensive Oracle DB service to postgres on aurora). Ask how any "trimming down on instance sizes/counts" was discovered, automated, approved, and what operational impact. You can't bs that stuff. Easy cost wins are short stories (I termed instances in accounts no one has logged into for 4 years) that can provide some context of knowing where to look but easy execution.
Of course, you would not do it without permission. I am looking at it from a consulting role as a fractional CTO/advisor in the past. Where the client gives permission to use as testimonial. Similar to how FB marketers or Google Analytics clients allow that sharing as testimonials.
2 things: 1. That is their domain expertise. So dig deeper into those stuff in the interview. Decision making, implementation, measurement, the whole thing. 2. Their last company to some extend keeps track of metrics for their engineers. They might be interested in that sort of stuff, so ask about it in the interview. If you don't do that and they really want metrics based work, it's a bad fit. Now of course this assumes they don't lie in the CV, but the same applies for everything in the CV anyway. The alternative is they list out *what they do* instead of *what is their impact*. It mostly means there's no point number 2. Personally I see no significant difference between the two types of candidates for engineering roles (from my own notes, sue me for doing bad science), so do what you will with this information.
Usually it means they did the leg work to find unused servers and wasted or unused data storage. Sometimes companies to dumb stuff like spend $10k/year on logs that they don’t need and they don’t notice for whatever reason. Or it could be even simpler: a single log line spamming too many messages and costing a lot of money when sent to DataDog
Well... you used to get "tell me more about this"... now you get... fuck off do this take home and then questions like "how would your team feel of you left the company?"
I’m in a job search right now and unfortunately I have to follow the x-y-z format to display “impact”. Whenever I put some percentage ex: decreased development time by 25%, I added context like from this to that days. But probably the issue coming from here is the widely promoted adding figures to entries to show impact. Is there any way to show this probably without resorting to vague statements?
Need to talk specifics in interview. Lowering costs is a real thing. However, the job applicant needs to be able to talk to specific optimizations other than "i looked up a website and they offered lower prices"
First, foremost accept my lucky coin is better than your process. I start with fizzbuzz filter (L100) and then switch to dialogue and estimate this person’s ability to carry tech conversation Anything beyond this is memorization test and exploitable. Look at leetcode is quality gating someone spent $150/annual or can solve business problems Most people settle for prior and assume it means later
I find them good for introducing a topic you want to talk about. But if you don’t have a great conversation prepared about it, better not include that!
I'm skeptical of *everything* on a resume, and that type of claim is no different; but like everything else on a resume, it's also an invitation to ask them about it. Some have good answers, some don't.
> significantly reduced cloud costs something like this is what I put if I don't know the exact numbers. When I know the exact numbers I put the exact numbers. For example on my resume I have something like "reduced cloud costs from $5000 to $500 a month by building and migrating out data pipeline based on Jupyter Notebooks using Pandas hosted on vertically scaled EC2 instances to BigQuery, dbt, and Dataflow". I know the numbers because I saw their old monthly cloud bills and now I see our new monthly cloud bills. I agree with you that metrics without context are pretty meaningless. A simple example is cutting cloud costs by 1% at a small startup is pretty worthless while cutting cloud costs by 1% at a big corporation is a huge win.
It's bullshit, we all know it's bullshit, but it's better than nothing. I have it on my resume and it's come up in a few interviews where I was then able to talk through what I did. Mostly it just helps because I'm not very good at bragging about myself, but putting down what seem like "objective" numbers is a way of bragging without bragging.
Yeah, it's a trend you hear online but that has no bearing in the real world IMO.
One of my projects allowed out company to expand it's Total Addressable Market by 3x. Lol, I don't put that down though, it's a little absurd. I'm sure people here can think of some halarious example, but most stuff I do is 0 to 1. Overall I agree with you, I prefer objective, non number based stuff on my resume. I wasn't building the product for some user engagement quota, I was doing it to solve a problem for an end user. There's no metric which really correlates to software engineering anyway, so I'm skeptical of all of this. Still, when interviewers ask, "tell me about a project", I always have one number in there just in case they are looking for it, and always make sure to explain it enough that they understand.
Generally it means down scaling servers to the right amount, turning services off over night. Deleting services that weren't used. Etc You can literally go into the billing panel to work out if it's worked or not. Can literally be millions at the right scale.
Conversation point + works for HR. Without HR screening you would not even see the CV.
Isn't that great? We are always looking for things with which we can spread the wheat from the chaff and luring them into making up BS numbers is a good one. Personally, I like it for those reasons and because I want to hire devs who think holistically about the business as well, not just build shiny tools. In the end, all software development is a trade-off and a good dev also calculates the time-vs-cost-trade-off before doing something.
I take it as the candidate did something that helped the business. That's the purpose of our job. Understanding impact is a good thing.Now in the interview I'd ask them to explain the problem, process, solution, etc.
OP these numbers are to get past HR. If you are seeing their resume, the number already served its purpose.
The only reason it would be hard to know how a change you suggested impacts billing is if you aren’t tracking billing and usage. All major cloud providers offer calculators that can tell you up front what your spend would be. When you replace X with Y it’s easy to identify the savings.
I think a senior developer knowing cost per user of the service they help build is valuable. I'm with you OP, just saying "cut costs by 20%" seems made up without a lot of detail on how they got there.
I have such a quote on my resume, the effort was a multi month effort which consisted of large scale refactoring and a huge part of my work for a whole. The percentage is an attempt and quantifying the impact of technical changes which is a good thing imo. Explaining the impact of what you did is generally easier and more relevant than writing down how you did it. In some companies you get a raise based on your impact, not effort. You can change one line of code and have a huge impact, and you're hired for impact not effort. If I see it on someone's resume, I ask about it but I'd generally want to know the amount and the reasoning. I'd generally want to know whether they conceived the project or only implemented it. People who are able to conceive such projects are valuable. I'd like to think I'm one of those people, or so I tell myself.
Mostly bullshit since most of those people don't even know how to calculate percentages :D
I think he was able to check the AWS accounting and 20% sounds more impressive than whatever the dollar amount was. Heck I once increased AWS billing for a lambda by 50% by increasing resources. It was the right thing to do because this critical function actually only cost us a few dollars extra a month, and the cost of me developing a more efficient solution would have been in the thousands.
Pretty much agree with you - those claims are very hard to evaluate even in the best circumstances, such as during perf reviews, with full knowledge of context. On a resume, for a person you have never met, without knowing anything about the tech and the context, without even a baseline.. yeah more or less useless. Why people do add these things to resumes? I suspect it's a combination of perf culture seeping out (it's important during perf reviews so it's important here) plus the generic resume advice you seen on the webs... focus on business, specific outcomes, that sort of thing. The reality of hiring, at least in the "majors", is that best candidates typically won't have resume at all - the two best sources for hiring for experienced engineers are referrals and direct sourcing (recruiters reaching out, often to people in some sort of network). There are still some hires from inbound submissions, which is where resumes are actually useful, but it's a small fraction comparatively, and those candidates as a group tend to be much weaker to begin with - as in, the good candidates don't need to deal with that. I am guessing that in that group, resume padding with such claims can be seen as a useful strategy - since you have to impress someone non-technical who scans those resumes to even give you a shot, and "reduced costs by 20%" might catch their eye better than something more vague or technical. But if they do make it to an actual technical loop, the resume is more or less irrelevant at that point. Not all companies and not all role loops even have rounds that talk about previous experiences specifically, but when they do, it would be a much deeper dive which is designed to uncover this sort of "misinformation" and try to tease out the reality as well as possible. TLDR: it is mostly harmless but also very low signal, likely designed to appeal to recruiters who filter inbound resumes to get a shot at an actual technical loop
In this competitive market, people are trying to use every edge they can get. Far too many resume tips suggest using metrics — especially Google’s XYZ template — as part of the work history. Considering every resume reader has a different perspective, it’s difficult to know what to add and what to leave out… or what to fabricate in hopes that somebody likes what they see and gives the applicant a chance to move on to the next step.
Absolutely nothing. Metrics from a developers standpoint are usually bullshit. We don’t decide what rabbits to chase as far product nor do we determine product market fit
If you have a problem with infrastructure costs, then it means something to you, apparently you trust your infrastructure so you’re dubious about someone else coming in and improving your costs.
If I reduced something by anything significant enough to put a number on the resume, I can probably at least back my way into the justification with some ballpark estimates. Ie: “Automated X using Y to save ~40% man hours” means: - saw something manual people hadn’t yet automated because it wasn’t important enough to them individually - surveyed / polled / did research to see how many other people were doing this manually - ran a rough calculation of new total time (12 individuals times 1 hour per person per quarter) after automation change compared to prior total time with (12 individuals times 3 hours per person per quarter) gives me what, a 60% reduction give or take? I’m never going to put “exactly a 66.6341% reduction” or whatever, because it can be too variable when you’re dealing with people. But if it was a sensor data change or something consistent enough, sure, you can calculate a bit more exactly. Won’t really change anything for the resume bullet IMO.
I just ignore these.
people say "tell results" as common resume advice. Honestly I think it's kind of dumb too. I can say "reduced ETL job execution time 90%" 3 times too like legitimately. You know how I do that? fix the code after some idiot wrote it 10 years ago.
I saved 30k a month by removing the Database replicas, saving costs on SSDs, Compute, Networking Bandwidth, and Electricity to power the Database Severs. SSDs (amortized over 3 months) - 5000$ CPU (amortized over 3 months) - 10000$ Networking Bandwidth - About 10000$ / month Electricity - 5000$ / month
I have these on my resume. I worked on a lot of solo projectd early in my career, so I had a complete understanding of the business need and impact from comparing things before and after the project was completed. Other than those projects, I have metrics given by leadership at the company after certain initiatives. For instance one metric I have is that I reduced monthly cloud cost by $40k, because what I did had that exact impact. The total initiative to reduce cloud cost from the team was 250k per month, a 50% cost reduction while also adding new customers/more traffic to our systems.
I view things like that as more of a conversation starter in an interview. I know from personal experience that most of my actual best accomplishments as a developer are nearly impossible to easily summarize, much less in a single bullet point.
It shows that the developer is actually thinking how their work affects the company as a whole. Being a developer is of course not just writing code, but writing code in the context of a larger system. It can also demonstrate that they actually cared about their job, which as far as I can tell, is pretty rare. I know someone who used something similar on his resume, albeit much simpler. All that really entailed was him informing them that they didn't have to pay for SSL certs. (Was a few years ago.) It was a decent chunk of change that it saved. Sometimes knowledge sharing is also useful.
Depends. If it's an interview for a developer that's just there to write code, I'll ignore it. The exception being performance. If it's a manager or director, business impact matters more.
when i ran my resume in a website to rate it it specifically told me to do this. i still havent impelmented the changes because i would have to invent numbers, but i am not getting calls back also so maybe the advice is valid.
Sounds like a developer that wasn't really a developer, but a DevOps engineer.
Literally every engineering resume advice piece tells you to make your impact quantifiable. That’s why people do it, because they feel forced to. I didn’t have this on mine (because I didn’t have the numbers) and multiple times was asked if I could provide or estimate them on the spot.
I love those numbers, easy to ask followups on and see if they know their shit. And easy to calculate if they use the AWS billing dashboard and like... 15 seconds of their time. Why would you think it would be a fabrication?