1

Background

I'm used to explaining specific job duties and results on my resume (for US full time positions), to give more information about a title, skills, and what the job comprised of.

However in my software developer role, most of my work day is doing routine actions -- (As a developer, this means coming up with a design, breaking things into functions, writing up the code, doing unit tests, and adding documentation and comments as necessary.)

Concern

My concern with listing the routine duties is that it feels like air/padding, as it's in many developers' experience. I don't want to imply these are unusual skills. How can I list what I've done in this position?

The only similar question I've found so far is on Writing resume: job description vs achievements in a software developer's resume but this deals more with resume tips.

Ideas

I'm fairly proud of how I do each of these things, but don't have specific metrics to account for them (for example, measuring how good a design is, or how many lines the documenation is). So I'm not sure how to differentiate these skills.

I could list out what specifically my clients/customers goals were (such as "Produced Java backend code for rapidly changing ABC shoe company website") but I'm not sure I'd want to expand this to more than one line.

I could comment on the 10-20% unusual (and more difficult) situations, but each is unusual in its own way and only lasts a week or two, so I'm not sure it's worth a line in my resume. Grouping them together would be hard without being vague.

Improve this question

2 Answers 2

Reset to default
2

Describe what you excel at most, what your strongest proficiencies are.

Of course you can mention the mundane tasks in a sentence or two. They're part of your responsibilities after all.

You need to sell yourself and your capabilities to your prospective employer.

Make sure they see you understand your craft exceptionally well and are open to learn the new and unexpected.

Improve this answer
1

In your resume, you should focus on the impact your work has on the company and its customers and why the company you're applying to would hire you over other applicants. Typically, you should focus on particular projects you worked on and/or metrics you were able to move with your work. If you focus on the common skills it's really hard to pick your resume out of the whole bunch of resumes you're competing with.

For instance, you say wrote unit tests. For what feature did you write the unit tests for? How many customer use that feature? How much code coverage were you able to achieve? What framework did you use? Etc. Etc.

Improve this answer
4
  • Thanks for the response -- it sounds like the idea is to be more precise with what was accomplished (so expanding these routine duties to give more specifics on what makes them special)
    – Nate 8
    Commented Nov 19, 2018 at 4:49
  • 1
    @Nate8 Yup that's right. If you focus on the routine, it does feel like you have nothing else special to talk about. I've done a lot of resume review for hiring engineers and there are just so many engineers that know how to write code, tests and documentation. But an engineer that understand how to measure impact and actually does some impact, now that's someone worth looking at.
    – jcmack
    Commented Nov 19, 2018 at 17:49
  • This is helpful. As a side note, I do commonly hear to provide metrics, but it feels harder to quantify design and implementation improvement (than say how fast the code runs). For example, it's easy to work 10% faster if code quality decreases, or you decrease the scope the project. Or maybe that was due to an earlier employee improving the methods used, or because you were more familiar with the process.
    – Nate 8
    Commented Nov 20, 2018 at 1:19
  • 1
    @Nate8 Agreed. I wouldn't focus on how quickly you were able to deliver the project, because, like you said, you might just reducing the scope of the project. But instead focus on performance enhancements such as make the product faster (X% faster response times), scale better (increase to support X% increase in new customers without decreasing existing response time), more resilient (X% reduction in customer issues), etc. The hard part is that you have to measure the current state of the product(s), but you should be doing that anyway to prioritize.
    – jcmack
    Commented Nov 20, 2018 at 3:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .