Размышления о поиске работы. Ответ на пост

Наткнулся я, листая ленту, на пост и, признаюсь, немного у меня подгорело. И очень мне захотелось ответить. Написал я комментарий и понял, что текста много и лучше немного подождать, остыть и структурировать мысли.

Итак, о нюансах поиска работы с точки зрения разработчика.

Начнём, пожалуй, с того, что вспомним основные советы HR для составления резюме:

  • приводить цифры и достижения;
  • резюме объёмом не больше пары страниц;
  • не сыпать в резюме техническими терминами;
  • продавать не свои навыки, а решение болей работодателя.

Начнём с болей. Напоминаю, что с точки зрения разработчика.

У компании есть потребность создать фронт/бэк продукта или поддерживать его на конкретном технологическом стеке.

Соискатель в свою очередь умеет писать фронт/бэк продукта на определённом технологическом стеке.

В этот момент мы сталкиваемся с первым вопросом без ответа: о какой боли идёт речь? Есть конкретная задача и я, как технический специалист, могу предложить конкретное её решение.

Допустим, у компании есть конкретная проблема, например, в неподдерживаемом куске спагетти вместо кодовой базы. Или в том, что от аналитики в компании только первые две-три буквы. Какова вероятность, что компания скажет об этом в описании вакансии?

Допустим, предположим, что компания честно написала «нам нужно рефачить кодовую базу и оптимизировать архитектуру». Вот что должен писать потенциальный сеньор, чтобы «решить боль компании»? «Строил DDD, хорошо знаю SOLID, умею работать с DI и CQRS»?

Тут мы плавно подошли к советам «Не сыпьте техническими терминами» и «объём резюме не больше двух страниц».

И вопрос: как?

Нет, если у меня опыт работы два-три года, то я могу уложиться в пару страниц, не вопрос. Но за пять-шесть лет у многих разработчиков столько опыта скапливается, что без технических терминов рассказ займёт страниц пять текста. Почему? Да потому что технические термины придётся объяснять «простым языком». А это долго. Технические термины потому и появляются. Что быстро дают много информации в малом объёме текста.

Поехали дальше. Самое интересное на мой взгляд. Цифры.

Начнём с того, что разработчику зачастую никто не предоставляет доступ к аналитике, по которой можно рассчитать конкретные цифры.

Но, представим, что данные всё же есть. Что считать?

Увеличение продаж? ТТМ? И как это должно выглядеть?  «Внедрил архитектуру, которая повысила продажи на 26%»? Или, может, «... Увеличила средний ttm на 17%»? Так это же, прошу прощения, звездёж. Не посчитать такие значения изолировано. Так, чтобы исключить влияние других факторов. При всём желании.

А если разработчик, допустим, проработал техническую документацию продукта и кодовой базы? И хорошо, если в компании документацией пользовались и это, к примеру, упростило онбординг новичков (кстати, как тут цифры посчитать?). А если компания сложила доку в дальнем углу Confluence и она там пылью заросла? Что писать? «Я написал доку, но всем было на#&@ть».

И, что самое интересное, все эти рекомендации «смотреть на цифры», «искать решение болей», работают против самих работодателей. Потому что это прекрасный способ найти балаболов. Тех, кто красивее может себе цифры нарисовать, а не тех, кто на самом деле будет работать и решать проблемы.

Очередной раз можно убедиться, что поиск работы проверяет главным образом навык поиска работы, в не выполнения конкретных рабочих задач.

Написано человеком для человеков. Без использования ИИ.