3 ms·

Measuring accomplishments for OP isn't likely to be easy, but for more senior candidates that's the ideal situation. You're correct about generalizing duties a

by fecak 10y ago

Measuring accomplishments for OP isn't likely to be easy, but for more senior candidates that's the ideal situation. You're correct about generalizing duties and skills. Bullet points on resumes that talk about non-specific day-to-day responsibilities are mostly filler.

pmiller2 10y ago
I agree that it's ideal to have numbers attached to accomplishments, but how many devs actually know those numbers? I've written code that's run literally millions of times, because it's deep in the core of some task execution code, that enables easier debugging of tasks, and I have no idea how much debugging time it's actually saved. I wrote a large part of a couple of important features in a product for the company I work for now, and I have no idea how much revenue these features are going to help bring in or how many sales they'll generate. Do you have any tips on how a dev can quantify his/her work in an easily digestible format like all the resume books suggest?
- fecak 10y ago
  We all understand that it's often highly complex if not impossible for most devs to quantify an accomplishment. It's easy for some things to be quantified obviously - downloads, traction - though those aren't exclusive to engineering (could be marketing). Scalability numbers and measurable performance improvements are relatively common. So if you built something that is able to handle n requests maybe. The amount of revenue generated by a feature is clearly tough - but you might be able to find out new subscribers since the feature was introduced. Even if you can't, just saying you built a certain feature is probably enough in most cases. It really boils down to unique, one-off accomplishments for me. Specificity. That code that runs millions of times - tell me the product name, what that product does, what your code does, and what tools you used to build it. Even if you can't point to a quantifiable figure, the specificity gives you some credibility.
  - nojvek 10y ago
    I saw your website. It's great. I would advise networking and attending meetups, asking for referrals. Every job I have is mostly due to referrals. Someone putting a good word on behalf of you means a lot. Also don't fire and shoot. Target like a sniper.
    - moftz 10y ago
      Exactly. My first real job out of college was due to a referral. Girlfriend's stepdad put in a good word for me a a major engineering firm. I went to the interview open-house and realized quickly the people around me seemed much more accomplished and more knowledgeable about the company and the industry its in. I had some interviews later, they seemed to have gone ok, not awesome but not a disaster. Then the VP of engineering comes up to me and tells me how excited they were to have talked to me. This threw me because it all seemed way out of my league but I didn't see her approach anyone else except for a couple other candidates. I ended up getting an offer a month later. I knew my gf's stepdad definitely put in a good word for me, I just wasn't expecting it to help me that much. If I tried to get an interview from this company through the job fair at my school, I would have most likely not even gotten a phone interview. The only thing, I haven't told any of my coworkers who referred me. I'm not totally sure how prepared I am for this work and I wouldn't want any poor performance to reflect back onto him.
- PeterisP 10y ago
  This is a great illustrative example of why those numbers are informative - most developers are like you, and can't do that, but the reason is not in "CV writing" but in actual content of the work. From what you say, it sounds like that whatever you did was driven by (initiated by, started because of) (a) technical need (b) order from above or (c) guessing. However, what people mean by "show the impact" is that they are looking for someone who has already done work mostly driven by their observations of business needs, their initiative to improve specific business results by technical means. If you had no idea "how much revenue these features are going to help bring in or how many sales they'll generate" then you were performing a different role/function than e.g. a person who looked at a need to increase sales (or whatever else was the main business/strategic goal of their company at the time) and figured out a software feature to achieve that. Perhaps you are capable of more than just implementation, but how would a potential employer know? It's not like they'd just ask you, they want to see evidence that you have done this before, that you have been not only implementer of ideas but initiator of changes driven by your personal understanding of business needs - not matter how your role was called or what your nominal job description did/didn't include.
- user5994461 10y ago
  - Put down debugging time from hours to minutes, by improving developer tools. - Automated the manual week-long test and QA procedure for critical aerospace devices into a daily 1-hour automated routine. - Increased application performances by over 9000%, allowing us to save 1M million a year in AWS server costs. - Ensured we delivered consistently and with due diligence, every single day, month over month, to our 586 millions users. - Interviewed and graded 23 candidates. # Typical stuff you'll find in my resume. As you can see, there are plenty of numbers to talk about, no matter your position. Costs, time, users, revenues, latency, percentage, improvements, progress, duration... You just need to think harder about what you've done and put numbers on it. ;) It doesn't have to be perfect, approximate and round if you have too.
chrishacken 10y ago
> Bullet points on resumes that talk about non-specific day-to-day responsibilities are mostly filler. This. A co-worker interviewed a guy last week who had 3 pages full of bullet points and when he asked him about his experience with any of them, he gave us some generic response like, "We used Java on project X that did Y". List 6-7 core skills; or better yet, list projects you worked on, the stack you built it on, and a very brief summary of how you kicked ass on it. He has example projects on his site, which is great; most people don't even have that. When I go into an interview as a developer, I always go in with a running example of a project that I built, with source code. Towards the end of the interview I'll bring it up: "I brought along a project I built; I'd love to go through it quick with you." At which point I go through the UI to show what it does and then open up the code to review the architecture and anything clever I did within the code itself. Note that this all happens in about 5 minutes; no one wants to sit through a 30 minute demo.
- rex-mundi 10y ago
  could you give an example of an app you've shown (no need for links if you don't want, just a short desc would be very helpful)

by fecak 10y ago

pmiller2 10y ago

I agree that it's ideal to have numbers attached to accomplishments, but how many devs actually know those numbers? I've written code that's run literally millions of times, because it's deep in the core of some task execution code, that enables easier debugging of tasks, and I have no idea how much debugging time it's actually saved. I wrote a large part of a couple of important features in a product for the company I work for now, and I have no idea how much revenue these features are going to help bring in or how many sales they'll generate. Do you have any tips on how a dev can quantify his/her work in an easily digestible format like all the resume books suggest?

fecak 10y ago
We all understand that it's often highly complex if not impossible for most devs to quantify an accomplishment. It's easy for some things to be quantified obviously - downloads, traction - though those aren't exclusive to engineering (could be marketing). Scalability numbers and measurable performance improvements are relatively common. So if you built something that is able to handle n requests maybe. The amount of revenue generated by a feature is clearly tough - but you might be able to find out new subscribers since the feature was introduced. Even if you can't, just saying you built a certain feature is probably enough in most cases. It really boils down to unique, one-off accomplishments for me. Specificity. That code that runs millions of times - tell me the product name, what that product does, what your code does, and what tools you used to build it. Even if you can't point to a quantifiable figure, the specificity gives you some credibility.
- nojvek 10y ago
  I saw your website. It's great. I would advise networking and attending meetups, asking for referrals. Every job I have is mostly due to referrals. Someone putting a good word on behalf of you means a lot. Also don't fire and shoot. Target like a sniper.
  - moftz 10y ago
    Exactly. My first real job out of college was due to a referral. Girlfriend's stepdad put in a good word for me a a major engineering firm. I went to the interview open-house and realized quickly the people around me seemed much more accomplished and more knowledgeable about the company and the industry its in. I had some interviews later, they seemed to have gone ok, not awesome but not a disaster. Then the VP of engineering comes up to me and tells me how excited they were to have talked to me. This threw me because it all seemed way out of my league but I didn't see her approach anyone else except for a couple other candidates. I ended up getting an offer a month later. I knew my gf's stepdad definitely put in a good word for me, I just wasn't expecting it to help me that much. If I tried to get an interview from this company through the job fair at my school, I would have most likely not even gotten a phone interview. The only thing, I haven't told any of my coworkers who referred me. I'm not totally sure how prepared I am for this work and I wouldn't want any poor performance to reflect back onto him.
PeterisP 10y ago
This is a great illustrative example of why those numbers are informative - most developers are like you, and can't do that, but the reason is not in "CV writing" but in actual content of the work. From what you say, it sounds like that whatever you did was driven by (initiated by, started because of) (a) technical need (b) order from above or (c) guessing. However, what people mean by "show the impact" is that they are looking for someone who has already done work mostly driven by their observations of business needs, their initiative to improve specific business results by technical means. If you had no idea "how much revenue these features are going to help bring in or how many sales they'll generate" then you were performing a different role/function than e.g. a person who looked at a need to increase sales (or whatever else was the main business/strategic goal of their company at the time) and figured out a software feature to achieve that. Perhaps you are capable of more than just implementation, but how would a potential employer know? It's not like they'd just ask you, they want to see evidence that you have done this before, that you have been not only implementer of ideas but initiator of changes driven by your personal understanding of business needs - not matter how your role was called or what your nominal job description did/didn't include.
user5994461 10y ago
- Put down debugging time from hours to minutes, by improving developer tools. - Automated the manual week-long test and QA procedure for critical aerospace devices into a daily 1-hour automated routine. - Increased application performances by over 9000%, allowing us to save 1M million a year in AWS server costs. - Ensured we delivered consistently and with due diligence, every single day, month over month, to our 586 millions users. - Interviewed and graded 23 candidates. # Typical stuff you'll find in my resume. As you can see, there are plenty of numbers to talk about, no matter your position. Costs, time, users, revenues, latency, percentage, improvements, progress, duration... You just need to think harder about what you've done and put numbers on it. ;) It doesn't have to be perfect, approximate and round if you have too.

chrishacken 10y ago

> Bullet points on resumes that talk about non-specific day-to-day responsibilities are mostly filler. This. A co-worker interviewed a guy last week who had 3 pages full of bullet points and when he asked him about his experience with any of them, he gave us some generic response like, "We used Java on project X that did Y". List 6-7 core skills; or better yet, list projects you worked on, the stack you built it on, and a very brief summary of how you kicked ass on it. He has example projects on his site, which is great; most people don't even have that. When I go into an interview as a developer, I always go in with a running example of a project that I built, with source code. Towards the end of the interview I'll bring it up: "I brought along a project I built; I'd love to go through it quick with you." At which point I go through the UI to show what it does and then open up the code to review the architecture and anything clever I did within the code itself. Note that this all happens in about 5 minutes; no one wants to sit through a 30 minute demo.

rex-mundi 10y ago
could you give an example of an app you've shown (no need for links if you don't want, just a short desc would be very helpful)