Как составить «звёздное» резюме согласно принципам проектирования ПО

Представляем вашему вниманию адаптацию статьи разработчика 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 в корне. Просто расширьте его, добавив сопроводительное письмо.

Liskov Substitution principle (L)

LSP (принцип подстановки Барбары Лисков) в ООП является специфичным определением подтипа, предложенным Барбарой Лисков в 1987году. Лисков кратко сформулировала свой принцип следующим образом: Пусть q(x) является свойством, верным относительно объектов х некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T. Роберт С. Мартин определил этот принцип так: «Функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом». «Объекты в программе должны быть заменены объектами подтипов без изменения программы». Это означает, что если вы могли сделать это, будучи Junior, то вы способны делать это с приобритением опыта. Сюда, к слову, подходит и принцип DRY (don’t repeat yourself) — пожалуйста, избегайте повторений. Правда, здесь есть одно исключение. Если то, что вы делали на предыдущих местах работы, является базовым требованием новой вакансии, будет правильным подчеркнуть эти навыки в своём резюме. Например, если вы претендуете на должность 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:

• Past tense action verb — активное действие в прошедшем времени;
• Object — объект приложения усилий;
• Result — результат ваших действий.

Например: Руководил группой из четырёх программистов, использующих Kanban для разработки, настройки и тестирования системы управления картами лояльности RESTful, работающей на RedHat Linux. Этот пост взят из моего блога, где вы можете увидеть моё резюме в формате pdf, если вам интересно.