К основному контенту

Про достижения в числах в резюме

Копия поста в телеге (подключайтесь 🙂)

Навеяло постом в тви с советам для резюме для поиска работы за рубежом.


Я бы выбрал скорее выбрал 3 (и именно такое часто и вижу). Хотя и 4, и 5 тоже норм, но есть нюансы.

Совет Киры (см. детали в комментах) касался в первую очередь поиска работы в международных компаниях, а я смотрю через призму отечественных, но думаю, что мои советы ниже могут быть полезны для всех.

Но сначала небольшой экскурс в историю (ну, так принято в высших сферах).
*и да, еще раз, речь по отечественный IT, я хз че там происходит сейчас в других интернетах, но подозреваю, что люди в культуре могут отличаться, но в своей сути похожи.

Я застал те времена, когда тестировщики в резюме писали "инженер по тестированию" и в вакансиях писали ровно это же.

Потом какие-то умники, глядя на "как там" начали активно форсить тему с QC, почти мгновенно переключившись на использование букв QA.

При этом никто даже не парился над тем, чтобы люди в головах осознали, что значат эти буквы. Просто во всех резюме и вакансиях появилось QA и все. Я абсолютно уверен, что "раскрутка" была через вакансии, на которую среагировали те, кто пишут резюме. 

Потом та же история повторилась с DevOps (которые сначала просто админы с большими ЗП, а потом СИАЙ-админы и админа в КУБЕ). И снова раскрутка через вакансии и отражение в резюме.

Теперь вот та же фигня с цифрами по результатам в резюме, которая 100% пришла из резюме сейлзов/маркетологов и прочих продаванов.

Все рекрутеры теперь ждут числа в резюме инженеров (и уж тем более инженерных менеджеров) и предлагают всем это использовать.

И все кандидаты будут писать вот такую фигню, типа "разработал и успешно внедрил новую систему рекомендаций для e-commerce проекта, используя Python (Scikit-learn, NumPy, SciPy, PyTorch, Surprise), PostgreSQL, что позволило увеличить продажи на 15% за первые три месяца после запуска".

Что не так с такими циферками в резюме? 

Есть риск попасть в анекдот "Это ребята курили. Я просто рядом стоял"

1. Если вы не знаете, как именно ваша работа повлияла на эти циферки - не надо это писать

2. Если вы не знаете, как эти циферки меряются - не надо это писать

3. Если вы не можете рассказать, сколько времени занял рост до этих циферок, сколько людей и как в этом участвовало - не надо это писать

И чем больше была команда - тем меньше вероятность, что это надо писать...

Что же можно писать вместо этого, чтобы сделать резюме более привлекательным?

Только про то, что сам сделал, предложил и протащил, а ты можешь объяснить ход истории этого проекта.

Примеры:

- обучил 100500 падаванов

- проработал изменение архитектуры, которое привело к ускорению (циферка), повышению RPS, повышение производительности и тдтп

- затащил новый подход к написанию тестов и скорость написания тестов увеличилась с X до Y

- ускорение выполнения тестов с N до M

- протащил проект изменений через X команд

- провел X собесов из них Y прошли испытательный срок (или заонбордил 100 чуваков)

- запустил 300 новых команд 

Главное помнить, с высокой вероятностью, все это произошло благодаря командной работе. Важно понимать и уметь объяснить свою роль во всем этом и то, что именно делал ты.

Иначе цифрами в резюме рекрутера/нанимающего менеджера то ты зацепишь, а на собесе будешь выглядеть треплом (а нахер ты такой нужен).

В целом, работающий подход - это тюнить резюме, в зависимости от того, куда его подаешь. С высокой вероятностью, числа могут выглядеть привлекательно для стартапа, но могут помешать, если ищут в большую компанию: нанимающие менеджеры там более циничны, а деньги чаще всего приносят люди в костюмах, которые просто продают то, чего еще нет (и хорошо, если оно хоть было в планах).

ЗЫ
Для тех, у кого могут быть вопросы, зачем такое в резюме в принципе.

Числа про деньги интересны с точки зрения:

1) косвенно показывают, что инженер знает про то, как меняются бизнес-метрики его продукта

2) можно предположить, что насколько человек вовлечен в культуру product engineering

Комментарии

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu