How to write a SOLID dev resume to be 2018 STAR
Tags: resume, career, careerchange
Published: 2018-01-22 06:23:58

---
title: How to write a SOLID dev resume to be 2018 STAR
published: true
description: For 2018 but may be slightly overdue, but a little on resume writing (with some help from @unclebobmartin)
tags: resume, career, career change
cover_image: https://spmjumpstart.files.wordpress.com/2018/01/nurseryresume.jpg?w=1084
---
*The post comes from [my blog](https://jumpstart.blog/2018/01/21/how-to-write-solid-dev-resume-to-be-2018-star/), where you can find my resume (more or less) in *.pdf if you're interested.*

I've been coaching IT people with their job search and resume writing since the end of November. And I've noticed that a lot of us struggle (and yes, I do too) with writing this scary piece of paper. So here is the compilation of the knowledge and most common tips I gave so far.

###KISS - Keep it short and simple

A resume is your marketing piece to encourage recruiter or hiring manager to interview you (and not an elaborate essay on your experience/projects). Your resume shows your most important and relevant skills for the position you apply for. I'm not telling you to do a one-pager (this info is long outdated), but 2 pages are enough space to give the other person of who you are and what you know.

###Make it SOLID (as in SOLID by Uncle Bob)

####Single Responsibility Principle

One resume for one position/one job posting. Your resume will be different for IT Architect Role than for Senior Software Engineer position. And it'll be different for Senior Software Engineer in ABC Company and for XYZ Corp.

####Open/Close

Close it for modification by opening it up for extension: you'd want to extend your resume by adding extra info in cover letter by  there (yeah I know it's not 100% like this in open/close but I think you can relate ;))

####Liskov substitution

*“Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”*
Meaning: if you were able to do something as a junior it's you're still capable of doing it with more experience. 
DRY comes in handy here. So please **don't repeat yourself**.

There's one exception here, though. If what you did in each job is a basic need for the position you're applying it's good to showcase throughout your career. E.g.: applying for JavaScript Dev describe all JavaScript development roles/tasks. Tweak it so they don't seem the same, e.g:

*Software Developer, ABC company*
- Developed, maintained, debugged and fixed bugs in distributed Java and JEE applications

*Software Developer, XYZ Corp.*
- Involved in full-stack software development based on Java, Struts, JavaScript, Hibernate and DB2

####Interface segregation principle

Many role-specific resumes are better than one generic resume. (There's nothing more to add to it)

####Dependency inversion principle

*"High-level modules should not depend on low-level modules. Both should depend on abstractions.  Abstractions should not depend on details. Details should depend on abstractions."*

Your abstraction is the job you apply for so everything you write should be based on that job/job posting. Keep only the details you're asked for in the job description. Again KISS works nicely here too :)

###Start with master resume

A master resume is like a database of everything you did thus far. It's a great reference point for your future resumes and lists all or the most important skills and accomplishments.

###Accomplishments instead of tasks

Few accomplishments are better than just to list your duties. E.g:
**Task**: Wrote JUnit tests
**Accomplishment**: Assured expected behavior of applications by writing JUnit tests and ensured 85% code coverage

You can find a lot of generic articles on how to turn your task into accomplishments, like [this one on The Muse](https://www.themuse.com/advice/resume-revamp-how-to-turn-your-duties-into-accomplishments).

If you are still not sure on how to approach it here's a little advice:

###Be a STAR of your resume

Think about a **Situation** when you performed that **Task**.
What **Action** did you take and what was the **Result**?

Then write it in POR format:
**P**ast tense action verb
**O**bject of your statement
**R**esult of your action

And try to add some keywords in between.

E.g: _Guided a team of 4 developers using **Kanban** to design, configure, and test **RESTful** loyalty cards management system run on **RedHat Linux**_

***I welcome all questions, so don't hesitate to ask :)***