Як скласти «зіркове» резюме згідно з принципами проектування ПЗ

Пропонуємо до вашої уваги адаптацію статті розробника Aga Zaboklicka, в якій вона розповідає про застосування відомих принципів проектування програмного забезпечення для складання резюме. Якийсь час тому я почала допомагати людям з ІТ-сфери складати резюме та шукати роботу. І я помітила, що багато хто, у тому числі і я, відчуває труднощі при складанні резюме. Але насправді в цій непростій справі можна скористатися популярними програмістськими мнемонічними акронімами.

KISS - keep it short and simple

Або популярніша розшифровка цього принципу проектування — «Keep It Simple, Stupid». У будь-якому випадку це означає «коротко і ясно». Резюме — це ваше вміння себе «продати» та зацікавити рекрутера чи менеджера з персоналу, щоб він запитив вас на співбесіду. Своєрідний маркетинговий хід (а не докладне есе про ваш досвід роботи або проекти). Воно має показувати, наскільки ви відповідаєте посаді, на яку претендуєте, підкреслювати ваші сильні сторони. Я не кажу, що резюме має бути зовсім коротким на сторінку (ця інформація давно застаріла), але двох сторінок цілком достатньо, щоб дати зрозуміти іншій людині хто ви і що ви вмієте.

SOLID

Нехай ваше резюме буде SOLID , як у дядька Боба (дядько Боб — прізвисько Роберта Мартіна, відомого консультанта з програмного забезпечення, засновника Object Mentor Inc.).

Single Responsibility Principle (S)

SRP (принцип єдиної відповідальності) в ОВП означає, що на кожен клас потрібно покласти лише одну певну відповідальність, і його поведінка має бути спрямована виключно на забезпечення цієї відповідальності. Перекладаючи мову складання резюме: одне резюме для однієї позиції, для одного розміщення . Ваша презентація на позицію архітектора програмного забезпечення та Senior-розробника не може бути однаковою. І навіть для однієї позиції Senior Software Engineer в різні компанії резюме цілком можуть бути різними в залежності від специфіки цих компаній.

Open/Closed principle (O)

OCP (принцип відкритості/закритості) — принцип ОВП, що встановлює таке положення: «програмні сутності (класи, модулі, функції тощо) мають бути відкриті для розширення та закриті для змін». У випадку з резюме у нас не стовідсотковий принцип відкритості/закритості, але я наводжу його для того, щоб ви мали чітку асоціацію: не потрібно змінювати своє CV докорінно. Просто розширте його, додавши супровідний лист.

Лісков Substitution principle (L)

LSP (принцип підстановки Барбари Лисков) в ОВП є специфічним визначенням підтипу, запропонованим Барбарою Лисков у 1987 році. Лисков коротко сформулювала свій принцип наступним чином: Нехай q(x) є властивістю, вірною щодо об'єктів х деякого типу T . Тоді q(y) також має бути вірним для об'єктів y типу S де S є підтипом типу T . Роберт С. Мартін визначив цей принцип так: «Функції, які використовують базовий тип, повинні мати можливість використовувати підтипи базового типу, не знаючи про це» . "Об'єкти в програмі повинні бути замінені об'єктами підтипів без зміни програми" . Це означає, що якщо ви могли зробити це, будучи Junior, то ви здатні робити це з набуттям досвіду. Сюди, до речі, підходить і принцип DRY (ні в якому разі не будь-який) - будь ласка, уникайте повторень. Щоправда, тут є один виняток. Якщо те, що ви робабо на попередніх місцях роботи, є базовою вимогою нової вакансії, буде правильно підкреслити ці навички у своєму резюме. Наприклад, якщо ви претендуєте на посаду розробника JavaScript, опишіть всі свої ролі/завдання, пов'язані з JavaScript. Змініть їх так, щоб вони не виглядали однаково. Наприклад: Розробник ПЗ, компанія А:

• Розробляв, підтримував, налагоджував, виправляв баги у розподілених Java та JEE додатках.

Розробник ПЗ, компанія Б:

• Працював як Full Stack розробника на основі Java, Struts, JavaScript, Hibernate та DB2.

Interface Segregation Principle (I)

ISP (принцип поділу інтерфейсу) — Роберт Мартін визначив цей принцип так: «Клієнти не повинні залежати від методів, які вони не використовують». Принцип поділу інтерфейсів говорить про те, що занадто «товсті» інтерфейси необхідно розділяти на більш маленькі та специфічні, щоб клієнти маленьких інтерфейсів знали лише про методи, які їм необхідні в роботі. У результаті, при зміні методу інтерфейсу нічого не винні змінюватися клієнти, які цей метод не використовують. У перекладі в площину CV це означає, що краще створити кілька деталізованих резюме, ніж одне загальне. Тут і додати нічого.

Dependency Inversion Principle (D)

DIP (принцип інверсії залежностей) Формулювання:

• Модулі верхніх рівнів не повинні залежати від нижніх модулів. Обидва типи модулів мають залежати від абстракцій.
• Абстракції не повинні залежати від деталей. Деталі мають залежати від абстракцій.

Абстракція - це нова посада, на яку ви претендуєте, тому все, що ви пишете в резюме, має відповідати її завданням. Залишіть лише ті деталі, які необхідні, виходячи з опису вакансії. До речі, KISS теж чудово тут працює.

Почніть із Майстер-Резюме

Майстер-резюме - це своєрідна база даних всього, що ви коли-небудь робабо. Пишеться для себе, а не для роботодавців. Це — відмінна точка відліку для ваших майбутніх резюме і перераховує всі, або ж найважливіші навички та досягнення.

Досягнення замість завдань

Краще вказати кілька досягнень, ніж повний список минулих обов'язків. Наприклад: Завдання: Писав JUnit-тести; Досягнення: гарантовано очікувана поведінка додатків шляхом написання JUnit тестів та забезпечення 85% покриття коду. Якщо ви досі не дуже зрозуміли, як підійти до цього питання, ось вам невелика порада:

Будьте Зіркою власного резюме

Подумайте про ситуацію, коли ви виконали завдання. Яку дію ви вчинабо і який був результат? Потім запишіть це у форматі POR:

• P ast tense action verb - активна дія в минулому часі;
• O bject - об'єкт докладання зусиль;
• Result - результат ваших дій.

Наприклад: Керував групою з чотирьох програмістів, що використовують Kanban для розробки, налаштування та тестування системи управління картами лояльності RESTful, що працює на RedHat Linux. Цей пост взято з мого блогу , де ви можете побачити моє резюме у форматі pdf, якщо вам цікаво.