> Like I'm able to say a speech application I made was used in over a million calls, because I looked at the database and saw that many call records in there. And I'm able to say that I set up an one-click 30 minute devops process for deployment that was previously done over the span of 4-8 hours manually with multiple engineers onhand in case things went wrong (and they often did due to user error), because I was physically present during those manual processes and could directly compare and contrast the time difference.
These are both perfect for a resume. They are quantified and measurable and would be interesting to talk about in an interview. For example, I'd probably ask you what tools you used to set up your 30 minute deployment process and what they were using before and how you managed such a huge gain. I would ask you how you built your voice application to scale to a million calls.
These are both great for a resume. They don't all have to involve money.
Yeah, they are both bullet points on my resume, actually. But there are several jobs where I can't quite say this.
Like I worked on several games that didn't do well in the market (for various non-technical reasons), so I know I can't brag about saving money or time or usage for the company, but I learned a lot of skills by being on those projects, so I benefitted personally in ways that could help the prospective company out.
In fact I might have gotten more skills from those projects than that speech application, for example, despite that one being used a ton.
So I don't really have anything better I can say there than "did this this and this on the project, lead X number of people, etc", which are basically the 'responsible for...' bullets that everyone advises against including on a resume.
Also in case you're curious, I set up the process by using Octopus Deploy and several custom Powershell scripts after an audit of their existing processes and all the various information for all the servers, firewall settings, windows services, database snapshots and schema migrations, etc (there was a lot, each major system had like 40+ steps to it by the time they were done) etc.
Before the engineering director of the department would lock himself in his office and execute .BAT scripts one by one from a terminal and copy files and other things manually, while everyone else chilled in the main office, waiting (usually around 4-5 people). If anything ever went wrong, and usually it did, it would take several engineers to investigate and help revert things if necessary.
It was a mess. They knew it was a bad process, and had previously had another developer start investigating how to make things better using Octopus Deploy, and he gave up and quit the company and KT'd to me that it was impossible, no one was cooperating with him, he couldn't get the information needed, and well... I didn't have his experience and think he just didn't want to do it.
I had everything working for several processes (and we set up more and more over time after we had things working) in about the same time as he spent accomplishing very little (I started with his setup), and I didn't know anything about Octopus Deploy and barely anything about DevOps beforehand.
Great anecdote that, a real classic - previous experienced engineer couldn't get the cooperation and information he knew he needed to do it properly so barely started. Newer inexperienced engineer wasn't quite sure what was needed but built something to get several processes working and used that to convince everyone to provide the support to complete it.
I've closed $100k worth of consulting by opening with "My name is Zwayhowder and I've spent years making every cloud transformation mistake possible so you don't have to".
I'm not sure why you'd be willing to work on such a project but then be concerned about putting it on a CV. Assuming something I don't understand, you could talk about the impact it had on your employer without going into details of what it allowed them to do.
Woah there Betsy, I wasn't accusing anyone of anything, I literally didn't understand the comment as well as you apparently did.
So the second part of my comment stands. In the case of such a civil engineer, I'd focus on "Designed factory and rolled out process allowing organisation to achieve strategic objective to increase rate of baking ceramic products by 25%".
> Like I'm able to say a speech application I made was used in over a million calls, because I looked at the database and saw that many call records in there. And I'm able to say that I set up an one-click 30 minute devops process for deployment that was previously done over the span of 4-8 hours manually with multiple engineers onhand in case things went wrong (and they often did due to user error), because I was physically present during those manual processes and could directly compare and contrast the time difference.
These are both perfect for a resume. They are quantified and measurable and would be interesting to talk about in an interview. For example, I'd probably ask you what tools you used to set up your 30 minute deployment process and what they were using before and how you managed such a huge gain. I would ask you how you built your voice application to scale to a million calls.
These are both great for a resume. They don't all have to involve money.