How to Write a Star Resume According to Software Design Principles

We present to your attention an adaptation of an article by the developer Aga Zaboklicka, in which she talks about applying well-known software design principles to write a resume. Some time ago, I started helping IT people write resumes and look for jobs. And I noticed that many, including myself, have difficulty writing a resume. But in fact, in this difficult matter, it is quite possible to use popular programming mnemonic acronyms.

KISS - keep it short and simple

Or, a more popular deciphering of this design principle is “Keep It Simple, Stupid.” In any case, it means "short and clear". A resume is your ability to “sell” yourself and interest a recruiter or HR manager to invite you for an interview. A kind of marketing ploy (rather than a detailed essay about your work experience or projects). It should show how you fit the position you are applying for, highlight your strengths. I'm not saying that a resume should be very short on the page (this information is long outdated), but two pages is enough to let the other person know who you are and what you can do.

SOLID

Let your resume be SOLID like Uncle Bob (Uncle Bob is the nickname of Robert Martin, famous software consultant, founder of Object Mentor Inc.).

Single Responsibility Principle (S)

SRP (Single Responsibility Principle) in OOP means that each class should be assigned only one specific responsibility, and its behavior should be directed solely to ensuring this responsibility. Translated into the language of resume writing: one resume for one position, for one placement . Your presentation for the position of software architect and senior developer cannot be the same. And even for one position of Senior Software Engineer in different companies, resumes may well be different depending on the specifics of these same companies.

Open/Closed principle (O)

OCP (open/closed principle) is an OOP principle that establishes the following provision: “software entities (classes, modules, functions, etc.) must be open for extension and closed for changes.” In the case of a resume, we do not have a 100% open / closed principle, but I bring it up so that you have a clear association: you do not need to change your CV at the root. Just expand it by adding a cover letter.

Liskov Substitution principle (L)

LSP (Barbara Liskov Substitution Principle) in OOP is a specific definition of a subtype proposed by Barbara Liskov in 1987. Liskov succinctly formulated her principle as follows: Let q(x) be a property that is true for objects x of some type T . Then q(y) must also be true for objects y of type S , where S is a subtype of type T . Robert S. Martin defined this principle as "Functions that use a base type should be able to use subtypes of the base type without knowing it . "Objects in a program must be replaced by objects of subtypes without changing the program" . This means that if you could do it as a Junior, then you can do it with experience. By the way, the principle of DRY (don't repeat yourself) is also suitable here - please avoid repetitions. True, there is one exception here. If what you did in previous jobs is a basic requirement for a new job, it's a good idea to emphasize those skills on your resume. For example, if you are applying for the position of a JavaScript developer, describe all of your roles/jobs related to JavaScript. Change them so they don't look the same. For example: Software developer, company A:

• Developed, maintained, debugged, fixed bugs in distributed Java and JEE applications.

Software developer, company B:

• Worked as a Full Stack developer based on Java, Struts, JavaScript, Hibernate and DB2.

Interface Segregation Principle (I)

ISP (Interface Sharing Principle) - Robert Martin defined this principle as "Clients should not depend on methods they don't use." The principle of separation of interfaces says that interfaces that are too “thick” should be divided into smaller and more specific ones, so that clients of small interfaces know only about the methods that they need in their work. As a result, when changing an interface method, clients that do not use this method should not change. Translated into the CV plane , this means that it is better to create several detailed resumes than one general one. There is nothing to add here.

Dependency Inversion Principle (D)

DIP (Dependency Inversion Principle) Statement:

• Upper-level modules should not depend on lower-level modules. Both types of modules must depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

Abstraction is a new position that you are applying for, so everything you write on your resume should be relevant to her tasks. Leave only those details that are necessary, based on the job description. By the way, KISS also works great here.

Start with a Master Resume

The Master Resume is like a database of everything you've ever done. Written for himself, not for employers. This is a great starting point for your future resumes and lists all or the most important skills and accomplishments.

Achievements instead of tasks

It is better to list a few accomplishments than a full list of past responsibilities. For example: Assignment: Wrote JUnit tests; Achievement: Guaranteed expected application behavior by writing JUnit tests and providing 85% code coverage. If you still don't quite understand how to approach this question, here's a little tip for you:

Be the star of your own resume

Think about the situation when you completed the task. What action did you take and what was the result? Then write it in POR format:

• Past tense action verb - active action in the past tense;
• O bject - the object of the application of efforts;
• R esult - the result of your actions.

For example: Managed a team of four programmers using Kanban to develop, configure and test a RESTful loyalty card management system running on RedHat Linux. This post is taken from my blog , where you can see my resume in pdf format if you're interested.