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

Резюме - что в слове том?

Дисклеймер: знать, как правильно писать резюме, как быстро его читать и потом им пользоваться на собесе, не равно иметь правильное написанное свое резюме 🫠

Сейчас снова подключился к анализу резюме кандидатов и собесам (как ни странно, DevOps-в).

Что можно сказать? А то, что люди, как и раньше, как не “умели” писать резюме, так и не “умеют”.
Просто набор ключевых слов обрамленный глаголами “применял”, “настраивал”, “мониторил” и тп.

А что такое “уметь” писать резюме? Важный ли это навык? (присоединяйтесь к обсуждению в телеге)

Имхо, влияние качества резюме на итог поиска работы* сильно переоценено: в 80% случаев на собесе ты будешь его пересказывать и половина собеседующих его даже не прочитают. Важно пройти фильтр, тут помогут ключевые слова и, иногда, имена предыдущих компаний. Фсе. 

*если речь про первую работу (джун), то не все так “просто”. Там придется потрудится сначала над тем, что ты сможешь описать (приобрести знания/умения), а потом, как это подать.

Тут вот статья "Resumes suck. Here's the data" (автор ее недавно подкорректировал, раньше она была жестче и категоричней) с описанием эксперимента по качеству отбора по резюме, которая предвещала чуть ли не “смерть” резюме еще 9 лет назад. Но они все еще живее всех живых. 

И это логично - это самый популярный и простой способ себя проиндексировать, классифицировать и отобраться в качестве кандидата на собес (я знаю только 3 способа: резюме, личный бренд, “по блату”)

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

Само “умение писать резюме” в целом - это умение описать свои задачи и их результаты (это важнее) интересно, зацепить. Но на фоне дефицита опытных IT-шников спокойно приглашаешь даже просто по “ранжированию ключевых слов” из технологий, задач и прошлых компаний.

Давайте попробуем почитать резюме традиционного HeadHunter формата (у LinkedIn тоже есть свои приколы). Иногда складывается ощущение, что HH целенаправленно делает (ничего личного, бизнес: “дольше ищешь-дольше платишь”) критикуемый многими формат резюме, где раздел “обо мне” (который как раз можно сделать чуть ли не единственным), находится глубоко внизу. 

В итоге до него мало кто и доходит, если вспомнить с какой частотой сегодня IT-шники меняют работу, а значит все смотрящие застревают на перечислении компаний с одинаковыми задачами. Обычно я быстро пролистываю до конца и смотрю, есть ли там в “обо мне” что-то обобщенное о кандидате, его задачах и предпочтениях. Это то, от чего отталкиваюсь.

Дальше смотрим последние пару мест работы: выполняемые задачи и какими инструментами (речь не только про инженеров, у менеджера тоже есть свои инструменты, и это не Jira 😃). Про достижения мало кто пишет, но если есть, дополнительный “+” к вопросу приглашения. Из остального формируются будущие вопросы на собесе.

Частота смены работ: я старовер, считаю, что ничего толкового за срок меньше чем за год-полтора (зависит от роли, у кого-то и дольше) сделать нельзя: просто задачеклепатель. Если товарищ регулярно меняет работу чаще, то дополнительный “?”.

Что очень редко смотрю в резюме: образование. Обычно на него смотрю, когда специалист начального уровня, дальше уже все равно. Были случаи, когда уже после выхода на работу и пары месяцев работы, я узнавал, что у новенького нет высшего образования. Знаю менеджеров, которые, наоборот, уделяют этому разделу большое внимание и ищут там любимые ВУЗы, которые по их мнению отражают квалификацию кандидата. И если нет таких вузов, значит кандидат не годится.

В Питере раньше была фишка, выпускники “ФМЛ 239” (очень продвинутая, но школа) всегда его писали в резюме. Есть подозрение, что это такая метка для своих 😉 Потому что я чаще всего триггерился в обратную сторону.

Ссылки на дополнительные ресурсы соискателя (GitHub, блог и тп) тоже люблю смотреть. Нужны ли они в принципе в резюме? Если там есть что-то, чем вы гордитесь и лично вам нравится - пишите. Если в гитхабе, кроме пары тестовых больше ничего нет, а в блоге все заброшено 3 года назад, то бесполезная затея (лично меня раздражает). 

По собеседованиям меня могу сказать, что еще ни разу на собесах никто не сказал про мой блог, а многие еще и удивлялись, когда речь про него заходила, так что лично сам не переоцениваю важность этого ресурса в резюме.

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

И вот это все смотрится и читается через призму потенциальных задач, которые будет решать у нас кандидат, когда выйдет на работу. Через призму культуры и процессов в команде и ее состава. И если “+” перевесили “?“ - погнали общаться.

Полезные ссылки:
Стрим про резюме и подготовку к интервью 
В IT чудес не бывает (мой телеграмм-канал)


Комментарии

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

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