Комментарии 94
Что? Предложение о работе мечты?
>Что делать
6. Networking, попросту говоря поддержание профессиональных связей, по личному опыту min не менее важно, чем 1-5, чем ответственнее позиция тем важнее (относится к опыту вне россии)
Ну, то что выявляется токсичность HR-ом, это прям прикольно, жаргонное слово, у которого нет четкого определения и которое появилось, ну года 4 назад, наверное.
- Почему не взяли?
-Ну он токсичный, душный и вообще зашквар
-А как надо?
А надо, чтобы был огонь, файный и сасный.
Пришлось гуглить "сасный", эхх.
лень гуглить - поделитесь
жарг. привлекательный, милый; вызывающий вожделение ◆ Что за сасный мальчик на первом [фото]? «ВКонтакте», обсуждение ◆ Ае, сасный. «ВКонтакте», обсуждение ◆ Поц не очень, а тёлочка сасная. «ВКонтакте», обсуждение записи
жарг. красивый; приятный ◆ Админ очень старается выкладывать сасные сохры и топовую музыку. «ВКонтакте», запись
ru.wiktionary.org/wiki/%D1%81%D0%B0%D1%81%D0%BD%D1%8B%D0%B9
И чтобы два раза не вставать
Сохры — это разнообразные картинки, фотографии, мемчики, гифки со стен друзей из новостей, которые пользователь ВК сохраняет в своём профиле, а именно в альбоме «сохранённые фотографии».
Другой красный флаг из резюме — работа на одной позиции 5+ лет.
Что-то меня триггернуло. На одном проекте есть самописный фреймворк. Когда новые проекты давались - использовали новые фреймворки. Там постгрес, тут кликхаус понадобился. Там фласк, тут fastapi подойдет и т.д. Бредовая позиция, что на одном месте если, то обязательно отстал на 5 лет.
А у меня более 5 лет и позиция таже (сеньор) и один проект все эти пять лет. Но быстрее чем в этом проекте я развивался только в самом начале карьеры. Тут получил опыт перехода в облако, поработал и с облаками Амазона и Ажуром, и разные архитектурные решения попробовал, и с базами разными поработал и с системами ивентов. Причем это реальные системы, которые приносят реальные деньги.
Так что если проект развивается, то и в одном проекте можно развиваться. И такой опыт может быть даже более полезен - ты знаешь не только как использовать какую-то технологию, но и видишь последствия ее использования в проекте, и плюсы и минусы.
приходишь в другое место, а там все кардинально по другому, вместо кубера — swarm, вместо удобной отладки — куча скриптов и makefile (в питоновском проекте), деплой наполовину вручную, мониторинг на неизвестной вам софтине и какихто странных для вас данных. нет под рукой удобной либы ф-ций которые вы 10 лет под себя пилили… но с собой взять ее нельзя и пилить надо по новой.
и… и вам надо это срочно учить или подстраиваться или пытаться поменять чужой проект.
замени 10 лет на 1 год. Что поменяется в последнем предложении?
а вот 10 лет, вполне
я в 14 году 'вернулся в айти'… докер считался игрушкой для сумасшедших… а сегодня деплой и прод не в кубере/чемто-аналогичным считается уже чемто странным
далее, я в 10 году помню сел и решил что учить рельсы, яву, или питон? (в итоге решил яву)… с 15 года гдето три проекта встретил которые переходили я руби на питон… и все программеры хором шли его учить чтобы не уходить с проекта
а вот пошел бы рубистом в 10 году (капец как популярно было), попал бы на проект и сидел бы там лет 10… нет конечно с руби много работы и сейчас но верить в его светлое будущее уже сложновато… и пришлось бы или переключатся сейчас или сидеть в болотце
Тут сильно от культуры зависит. Если в Штатах к частой смене работы относятся в целом положительно, то где-нибудь, скажем, в UK если вы за 5 лет пару раз меняли работу, то вас уже могут посчитать job hopper'ом.
Тоже триггернуло :) Во-первых во всяких епамах и так новые проекты дают. Во-вторых зачем менять если нет никаких проблем с повышением зп и коллективом? Чтоб внезапно узнать что на новой работе повышают зп на $50 раз в три года и путем чуть ли собеседования повторного? Может на протяжении 8 лет это и была работы мечты? В-третьих банально рост внутри компании за программерские позиции. Ну не стать архитектором за 3 года увы.
Аналогично думаю. Сидел 10 лет в одной конторе, при этом и проекты кардинально менялись и технологии (переходили на тот же докер/куб) и успел язык программирования сменить. Это не обязательно красный флаг, ситуации разные бывают. И можно просто поговорить, но даже по резюме это видно - так что если вас на этом этапе зарубают - то и к лучшему, что вы даже не потратили на такую компанию время.
Про 5 лет на одной позиции ничего не понял.
Почему сеньор должен менять позицию чаще? На какую? Почему именно так?
Не все молодые и горячие, которые меняют работы раз в год и готовы впахивать за идею. Как бы этого HR не желали.
Меняет работу каждые 1-2 года - не надежный, быстро от нас сбежит
Меняет работу каждые 3-4 года - плохие софт-скиллы или токсичный, не сможет сработаться с командой
Не меняет работу дольше 5 лет - не хочет развиваться, потянет компанию вниз
Ну да, ну да пошел я нахер ... :)
я работал в одной конторе, где тимлид работал на этот момент уже около 8 лет… был категорически против любых «новых ненужных веяний» если они не совпадали с его точкой зрения «как должно быть (на уровне текущий год минус 8 лет)»
скорее это минус для тех кто с такими людьми сталкивался по работе
А реально бывают люди по 10+ лет на сеньорской/лид позиции, которые развиваются.
Не очень понимаю, что за внешний опыт такой и почему его не может быть без смены компании?
реально бывает ситуации когдаТак нужно проверять, что человек думает и знает. Хоть сколько он проработал на текущем месте.
Смотря что вы понимаете под "новыми веяниями" а то может он был прав и спас бизнес от ненужных трат, и такой человек может быть гораздо ценнее...
Почему сеньор должен менять позицию чаще?
Известно почему
Соглашаюсь на собесы HR, только, чтобы узнать больше о компании. По опыту скажу, что обычно этот пункт присутствует либо в очень больших компаниях, вроде сбера и здесь всё понятно - им и правда пишут миллионы, даже интересно поговорить и послушать. Либо в компаниях в которые вообще никто не хочет идти
Какой FUD...
Тезисы, которые пропихивает компания, занимающаяся HR'ством:
Слишком долго сидеть на одной позиции плохо, бегом на рынок труда. Казалось бы, какой интерес у HR-компании звать людей постоянно менять места работы? Конфликт интересов? Нэт, дарагой, просто бызнес.
Утверждение о том, что софтскиллы важнее навыков. Тихой сапой подвливают приятную менеджерскую мантру с обесцениванием сложных знаний. При том, что софтскиллы важны для работы команды, кто-то должен понимать как "оно" работает. Если у всех софтскиллы и только, то ваш фундамент основан на софтскиллах и устойчивость у него соответствующая.
Всё это не отменяет того, что для прохождения этих фильтров стоит о них знать.
Нанимать сложно, никто толком не знает как это делать качественно, отсюда и всякая ересь про 5+ лет и т.п. - надо же на какие-то факторы ориентироваться, вот и придумывают эти самые факторы. HR-компании придумывают те факторы, которые понимают и с которыми умеют работать (т.е. которые им выгодны, да) - софт-скиллы и стаж они проверить могут, хард-скиллы нет. Первичную фильтрацию от HR-ов требуют, а делать они её могут только на основании того, что сами понимают. Отсюда и завышенный приоритет именно на этих факторах.
Идея, что негатив к 5+ лет основан на желании увеличить доход HR-компаний - по-моему это всё-таки перебор. При текущем состоянии рынка и так идёт непрерывный найм везде, вроде работы у HR-ов выше крыши и без таких манипуляций.
Начальник отдела, который HR-фильтром отфильтрует доступных на рынке интровертов-профи и останется с широким набором приятных в общении мидлов с невероятно развитыми софт-скиллами, сам себе злобный буратина.
HR, который мешает набору, ничем не лучше, чем, например, охранник на входе в здание, который не пускает собеседуемых. дурак и дурак, что с него взять. А вот его начальник - некомпетентен.
В целом, те разумные процессы, которые я видел, включали очень мягкое участие HR'а.
А две мои последние работы с точки зрения трудоустройства вообще не включали HR'ов, потому что "начальной фильтрации" не требовалось, работала репутация.
И хороший начальник отдела внимательно следит за "именными фигурами" для их приглашения, а не выкидывает неподъёмную задачу "найти толкового сеньёра" на HR'а, который сам, мягко говоря, даже не джуниор.
Вот откуда у вас "душки и лапочки" я не понял. У многих тяжёлый характер. Может быть, даже слегка токсичное поведение. И это сложное раздумие - стоит ли брать человека, который ас в технологии, но с которым некомфортно было говорить; а вовсе не непредодолимый "фильтр от HR'ов".
Как это следует из «интроверт»? На мой взгляд — это разные вещи. Во всяком случае официальное определение вроде ничего такого не говорит.
Экстраверт не может быть токсичным что ли? Интроверт будет сидеть тихо, а экстроверту будет не сложно каждому донести свою точку зрения по 3 раза на день )) HR обычно все экстраверты или притворяются ими, вот с ними интровертам общаться легко. Два интроверта или два экстраверта наверное уже сложнее будет, как 2 одинаковых заряда должны отталкиваться.
Мягкое участие HR-ов - это как конкретно? Если они вообще фильтровать не будут - от этого лучше не станет. Фильтровать качественно, с учётом хард-скиллов - они не в состоянии. Именных фигур на всех явно не хватит.
Ну т.е. я-то с Вами не спорю, проблема есть. Вопрос в том, есть ли решение?
Работа HR, это:
а) выяснение, работал ли человек хотя бы примерно в этой области (отсеить людей "прислал резюме на удачу"). В целом, это может быть просто по резюме или с помощью уточняющего вопроса.
б) Сопровождение процесса - согласование дат, сроков собеседований, выяснения, где живёт кандидат, готов ли к релокации/удалёнке и т.д.
в) Коммуникация при отправке тестового задания (мы присылаем тривиальное 10-минутное тестовое задание до первого технического собеседования, это отсеивает 90% мимо забежавших и даёт повод для конкретного разговора на собеседовании).
г) Предоставляет свои наблюдения по кандидату с точки зрения кооперации (HR представляет участников собеседования друг другу, молчит всё собеседование, в конце прощается и обеспечивает приятное завершение процесса), в ходе собеседования HR не слушает про MLPS с датаклассами, а слушает интонации, кто кого перебивает, как реагирует и т.д.
д) Ведёт дело собеседуемого (помнит про его существование, следит за процессом, имеет полный комплект данных в удобном для обсуждения виде)
е) Выполняет требования GDPR по персональным данным.
Ну т.е. по факту фильтрацией, с Вашей точки зрения, HR заниматься не должен вообще? Любой кандидат, который считает что "работал или точно смогу работать примерно в этой области" доходит до технического интервью (тестовое многие могут отказаться делать, скажут смотрите мой гитхаб, или даже сделают, но смотреть тестовое - это же тоже время, и это время тратит не HR)?
Любой кандидат, который сумел поддержать разговор с HR и подтвердил, что знает технологию, по которой ТЗ, получает ТЗ. В этот момент не тратятся ресурсы специалистов.
Дальше (практика показывает, что) 90% мимо забежавших отсеиваются, потому что надо иметь хоть какие-то знания, чтобы сделать ТЗ. Оставшиеся 10% уже можно рассматривать.
Если кандидат отказывается делать ТЗ и показывает на гитхаб, то это транслируется в техотдел и кто-то поверхностно смотрит, похож человек на знающего или нет. Для этого достаточно увидеть несколько коммитов в предметной области (не chore). Вообще, живой профиль на GH сильно облегчает первичную оценку кандидата, и времени на это надо даже меньше, чем на чтение решения ТЗ.
Задача HR'а тут отсеить неформатное (например, человек никогда не работал за компьютером, но уверен, что с лёгкостью обучится, или человек перестаёт отвечать), снять головную боль с людей по "трекингу" (кому что отвечали, кому нет) и дать фидбэк по своим наблюдениям.
HR не обладает компетенцией для оценки навыков от слова "совсем" и с этим стоит смириться. Те, кто пытаются с помощью HR'а, который не умеет программировать, найти программиста, найдут кандидатов, которые умеют программировать как HR.
В целом, звучит здраво. Если стратегия - посмотреть лично всех возможных кандидатов, чтобы случайно не упустить хорошего.
Но есть и обратная сторона - если позиция сеньорная или выше, или даже если нужен реально крепкий миддл, то большинство кандидатов обычно сильно до этого уровня не дотягивают. И "посмотреть лично всех" превращается в чёрную дыру, куда без какой-либо пользы утекает время, и это время тратит не миддл, а CTO или тимлид, чьё время довольно дорого. В результате чего появляются статьи, вроде Коллеги, вы меня огорчаете от @onokonem.
Ещё одна (небольшая, на самом деле) проблема описанного Вами подхода - работа HR превращается в тупую отработку по скрипту, и тогда это уже не совсем HR, а что-то ближе к "специалисту" первого уровня тех.поддержки, и, в целом, работа скорее для телеграм-бота, а не человека.
Именно тут срабатывает 10 минутное ТЗ, потому что без знаний в области его не сделать, а если сделал, то это уже миддл+, а различить миддла от сеньёра - совершенно нерешаемая косвенными методами задача, так что говорить со всеми подходящими.
Мне буквально пару недель назад прислали как раз такое "сделанное" ТЗ. И даже не 10-минутное, а заметно сложнее. И оно съело с полчаса моего времени - сначала на то, чтобы понять, может кандидат просто неправильно понял задание или решил проявить инициативу, а потом на то, чтобы таки найти откуда он это решение украл (что и объяснило почему решена совершенно другая задача, а не то, что просили в ТЗ).
Плюс очень многие, включая и меня самого, не любят бесплатно делать тестовое. У меня на гитхабе 143 репо, если их мало и работодатель всё-равно упирается и хочет тестовое - для меня это красный флаг и я его посылаю. Плюс тестовое, которое я могу сделать за 10 минут - мало что покажет. Ладно, не буду играть словами и смягчать выражения: ничего оно не покажет! Я не знаю, как в Вашей области у админов, но у разработчиков за 10 минут ничего показательного не сделаешь. Простое тестовое - это 2-3 часа работы (если хорошо знать, что делаешь, а иначе это превращается в пару дней), так что не удивительно, что делать это бесплатно желающих мало.
Ну и в целом, факт выполнения тестового - показывает только готовность делать тестовые и то, что кандидат считает, что понял постановку задачи в тестовом и умеет кое-как кодить. Как правило, этого и близко не достаточно, чтобы отсеять слабых кандидатов - как правило тестовые охотнее всего делают как раз джуны и слабые миддлы.
В общем, есть у меня подозрение, что разница в наших подходах вызвана разницей в особенностях найма разработчиков и админов.
Я бы сказал, что вам было трудно читать именно потому, что задание не 10-минутное.
10-минутное задание с одним-двумя-тремя разумными решениями хорошо тем, что человек либо применил разумное решение, либо нет. Если вместо 30-40 строк решения вам присылают ужас, то вы его сразу видите. Более того, чем компактнее задание, тем выше вероятность, что человек его сделает. Вместо необъятной работы он видит <s>интересную</s> задачку, которую можно решить за один короткий заход.
Вот пример такого задания (придумываю на ходу): Написать плейбуку для поднятия point-to-point туннеля между двумя серверами. У серверов есть белые IP. Туннель должен быть симметричным (без выделения сервера и клиента). Шифрование не обязательно. Туннелю не обязательно сохраняться после перезагруки. IP адреса внутри туннеля могут быть заданы в инвентори. На входе даются белые IP серверов (linux), с запущенным ssh, имя пользователя и приватный ключ для доступа к обоим. Тест для testinfra для группы tun_servers прилагается. Ожидаемый размер решения - 6-12 task'ок. Формат - плейбука ансибла плюс инвентори, роли не обязательны. Использование molecula для запуска теста - в плюс.
Я согласен, что хорошо подобранное тестовое - это важно. Но придумать хорошее тестовое - не так-то просто.
Что конкретно покажет Ваше тестовое, кроме того, что кандидат знаком с ансиблом и либо уже поднимал такие туннели ранее, либо умеет за 10 секунд нагуглить набор команд вроде https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts#Passing_Through_a_Gateway_with_an_Ad_Hoc_VPN?
Написать это на ансибле можно несколькими методами, и то, как человек напишет, скажет мне о том, как это человек владеет ансиблом больше, чем на большом проекте.
Найденное за 10с точно не будет соответствовать определению "симметричного туннеля". В целом, если кто-то слепит два встречных ssh-клиента, технически это будет соответствовать задаче, но человеку будет трудно это интегрировать обратно. Два tap'а в бридже? Я вот с ходу не придумаю как с помощью ssh сделать два симметричных туннеля. В целом, опции ip link гуглятся за секунды, но только хорошо понимающий сеть на хосте человек оные опции поймёт.
Если кто-то пришлёт нашкрябанные два command для ssh в плейбуке, то мы попросим мягкого HR'а сказать, что туннель должен был быть симметричным (без деления на сервер и клиент). Дальше HR на себя берёт всех гневающихся, несогласных и т.д. Если человек вчитается и исправит, ок, если нет - ну на нет и суда нет.
Просто из любопытства - а это вот по ссылке выше, которую я реально нагуглил за 10 секунд (никогда раньше не знал, что на ssh можно такое делать, но я вроде понимаю смысл термина "симметричный", и из описания задания вроде бы следовало, что ssh такое умеет) - это разве не оно? Там как раз пара tun-интерфейсов через ssh связывается.
У вас два участника соединения. В ssh у вас всегда сервер и клиент (я написал в задании "без выделения сервера и клиента"). Есть класс туннельных протоколов, которые не требуют использования userspace приложений.
Грубо говоря:
ip l a dev mytun type \
gre remote 1.1.1.1 \
local 8.8.8.8 key=42
ip l s up dev mytun
ip a a 192.168.1.1/31 dev mytunНо - на ансибле, т.е. идемпотентно, с поддержкой check-mode и т.д. - sky is the limit.
У ансибла нет штатных модулей для ip link, и как человек в этой ситуации бы поступил, было бы очень интересно увидеть.
Точнее, перефразирую вопрос. Не "что конкретно покажет Ваше тестовое" - показать оно может много чего, смотря что кандидат напишет в плейбуке, - а "как по факту выполнения тестового отличить джуна от сениора". Т.е. иными словами - даёт ли такое тестовое хоть что-нибудь, кроме уже упомянутого мной "кандидат готов делать тестовые и понял задание"?
Мне - скажет. Я способен увидеть по этим 6-10 таскам как человек пишет на ансибле, понимает ли он принципы хороших плейбук на ансибле, владеет ли он хостовой сетью в linux.
Этого достаточно, чтобы отсечь тех, кто не умеет или "кое-как нашкрябал".
Всё дальнейшее - на собеседовании, человек как минимум уже довольно хорошо знает по крайней мере две области.
А если кандидат работал с asible, salt, puppet и chef, но сходу не сможет написать грамотный плейбук, вы ему откажите? Ведь у этих систем несколько отличается подход к описанию.
Зависит от степени ошибок. У всех четырёх, насколько я понимаю, ценится идемпотентность. У всех четырёх, видимо, ценится разумное именование переменных.
Но вот если человек начнёт делать странное по сути (например, притащит код, которого не должно быть, или сделает socks proxy, хотя в тексте фигурировали IP внутри туннеля), то задание будет не сделано.
>различить миддла от сеньёра - совершенно нерешаемая косвенными методами задача
ув. Георгий, позвольте с вами не согласиться, лично провел не менее 300 интервью принимая людей на работу, если интересуетесь могу поделиться (в личку конечно)
А что в личку? Думаю, остальным тоже интересно.
людей принимали по возможности сильных, примерно уровень физтеха, где образование получил смотрели, но не очень, обычно уровень виден в первые 10 минут разговора (но бывало, что и по два дня говорили), долгая история, работал project leader, sw manager, sw director, (все development) всего порядка 10 компаний, все связано с сетями, типа voip и пр., nda подписано достаточно, в общем не положено детали выкладывать, но на вопросы можно попробовать, все же предпочел бы в личку :)
ps
посмотрел типа что есть webzilla и пр., ничего близкого конечно, могу добавить что программированием занимаюсь порядка 50 лет, первую embedded на основе linux сделали примерно 21 год назад
Ну вот скажите честно, в вашей практике их сколько было, кандидатов? Я один раз общался с коллегами, которые провели 50 интервью, и никого не наняли. Это максимальное известное мне число кандидатов. Да, многовато, этож минимум 50 часов наверное.
Но я лично никогда и близко ничего не наблюдал. Если кандидатов бывает скажем 10 — это уже хорошо, при этом процентов 90 из них я легко сам отсеиваю по резюме (и очевидно, что как технический специалист технические же навыки кандидата я оцениваю лучше, чем HR, а еще и быстрее).
Количество "лишних" кандидатов как раз и зависит от работы HR. И да, по часу на каждого - это минимум. На практике лично у меня получается ближе к 2 часам: полчаса-час уходит на посмотреть тестовое, минут 15 на общение с HR, минут 15 на подготовку к собесу, и час обычно на сам созвон-собес. При этом надо понимать, что если бы день целиком состоял из собесов - было бы проще и эффективнее, но когда приходится вытаскивать себя из кода, настраиваться на общение, аккуратно разговаривать (и да, я вообще-то тоже интроверт, и от меня это требует определённых усилий) чтобы обеспечить кандидату максимальный психологический комфорт насколько это вообще возможно на собесе, и потом снова возвращаться в код - на выйти из кода и вернуться обратно уходит ещё где-то час… и 2 часа легко превращаются в результате в практически 3 часа вычеркнутых из продуктивной работы. 2-3 собеса - минус рабочий день. 50 собесов - минус рабочий месяц. А это и компании довольно дорого обходится, и я тоже нанимался не только собесы проводить… отсюда и желание адекватной фильтрации кандидатов на уровне HR.
Т.е. если в таких масштабах смотреть — затраты на кандидата в проекте вообще несуществены. Поэтому в моем окружении я бы предпочел увеличить число кандидатов, и уменьшить отсев.
Вот поэтому и интересно, ваши 50 штук — это реально месяц, или это происходило скажем в течение года? Каков размер команды? Откуда столько желающих, по какой причине их так много приходит?
Я не очень понял, к чему ведут Ваши вопросы, в чём их смысл. Поэтому ответ получился несколько сумбурный, и тоже без особого смысла - не считая "всё плохо".
Это зависит от проекта и HR-ов. Сколько лично я насобеседовал за 30+ лет работы - не знаю, никогда не приходило в голову посчитать. Я видел разное - и как все 10 человек в такую команду набирали очень быстро по знакомству без HR, и как уже 3.5 месяца не могут набрать пару джунов при активном содействии HR. Об этом-то и речь: при вполне рыночной и даже чуть выше рыночной зарплате кандидатов должно быть более чем достаточно, особенно джунов. А когда HR-компания за месяц находит 7 человек на три открытые позиции закрывающие, по сути, почти все основные уровни квалификации (пара джунов плюс сениор или хотя бы сильный миддл), и абсолютное большинство из них и близко не тянут заявленный уровень - это крайне печально.
Отвечая на Ваш вопрос, при моих темпах на текущем проекте в 7 человек в месяц - 50 наберётся за полгода где-то. Но какая разница, на какой период времени растянуто выкинутое впустую время, если в результате этого времени как раз месяц и наберётся?
И нет, я не считаю, что 7 кандидатов на 3 позиции в месяц - это много кандидатов и "откуда столько берётся". Я считаю, что учитывая качество этих кандидатов - это очень мало кандидатов. Если бы нашли 7 удовлетворяющих требованиям - был бы другой разговор, тогда да, это много. А когда реально имело смысл собеседовать 1 из 10, пусть даже он и не подошёл, но там хотя бы был шанс - это очень много лично моего времени потрачено впустую, и я не хочу, чтобы таких кандидатов находили в разы больше.
P.S. Если у кого-то возникло подозрение, что мы джунов не можем найти потому, что ищем миддлов с зарплатой джуна - это не так. Текущие требования к джуну на уровне "полгода/год опыта на Go плюс наличие интереса к программированию (а не очередное войтивайти) и желание активно учиться писать качественный код", и да, мы готовы активно обучать, никто не ждёт что от этих джунов будет реальная польза ближайшие месяцы.
Смысл? Ну я просто пытаюсь понять, 50 собеседований или 7 в месяц — это какой масштаб проекта? Потому что даже если команда крупная — зачем их собеседовать всех одному? Если в команде есть синьоры или тимлиды — почему не разделить собеседования и не отдать кандидатов лидам? Ведь тем более, если вы джунов ищете — их же кто-то будет учить потом? Вот пусть эти люди их понемногу и собеседовали бы? Я понимаю, что общие затраты при этом все равно будут велики — но по крайней мере, это не будет ложиться на одного человека.
Я и буду учить, по крайней мере - поначалу. Если важен результат, то чем раньше получится исправить неправильные привычки, сформировать правильное отношение к работе, дать недостающие базовые знания - тем лучше. А вот когда эта база есть - тогда появляется смысл немного ослабить контроль и передать "шефство" другому разработчику, это им обоим на пользу пойдёт. Так что для меня важно, кого брать, и пропускать эти собесы - мне может дорого обойтись потом.
Ну и в более традиционном случае Ваше предложение всё-равно звучит странно. Собес обычно проводит не миддл, и даже не сениор - обычно это тимлид или CTO. Так что чьи бы это ни были часы, мои или не мои, это будут довольно дорогие часы. Найм вообще дело очень дорогое, и меня временами поражает, насколько компании эту цену недооценивают, когда умудряются из-за мелочей терять хороших разработчиков.
Отличная статья, спасибо!
Думаю автор писал про 5 лет на той же позиции с той же ответственностью (технической и софт-скилами). Надо через CV и на интервью показать что вы развивались в компании, а не тупо сидели на месте.
Повышение? - отдельной графой и периодом в резюме в той же компании. Это сложно, учитывая что ответственность не меняется резко с повышением. Но надо попытаться разделить.
Новый большой проект? - отдельной графой и периодом в резюме в той же компании. И новыми техническими решениями и тулами.
5. Не жаловаться на предыдущих работодателей!
Типичный взгляд HR, прямо скажем. Как технический специалист, проводящий технические интервью, я бы как раз охотно послушал бы жалобы на предыдущих работодателей. И сам бы пожаловался бы. Не вижу в этом ровно никаких проблем вообще. Даже интересно, что именно человек расскажет. Вот в зависимости от того, что расскажет — выводы могут быть разными.
Никакой работодатель не идеален, у них у всех могут быть недостатки, тем более что я бы лично жаловался бы на проекты и руководителей, а не на работодателя как компанию — потому что проблемы в жизни именно с ними, а не с компанией.
Такие жалобы нередко выглядят как "Я д'Артяньян, все п-сы.". Норм указывать несоответствие желаний и реальности как причину ухода. Но это не должно звучать как "все зае-ло".
Могут, да.
Но я поэтому и говорю, что в зависимости от претензий выводы могут быть разные. Но как член команды, я предпочел бы сам с кандидатом поговорить на эту тему, если он захочет, а не оставлять HR такие решения. Почему? А почему должно быть наоборот? Ну вот с чего бы мне априори считать, что HR опытнее меня и лучше разбирается в людях, тем более, если с этим человеком работать именно мне?
Ну и опять же — я такие вещи выслушаю, но не буду на них настаивать. Если человек не хочет про такое рассказывать — он нем это тоже кое-что да говорит.
Плюсую, правильно поданный рассказ про проблемы на предыдущих местах работы с соответсвующими выводами и lessons learned может смотреться весьма выигрышно.
Чтобы такого не происходило, стоит минимизировать рассказ о проблемах на прошлой работе
Вначале вы не рассказываете о проблемах на прошлой работе.
Потом не рассказываете о проблемах на текущем проекте.
А потом мы получаем компании, где все плохо, но все делают вид, что все хорошо.
У меня всегда вопрос людям, которые советуют что-то врать и недоговаривать - почему честно отрабатывая свои 40 часов в неделю я должен что-то врать и чего-то стесняться? Что за бред?
Пункт №6
Без сожаления дропать конторы которым "софт скилы", "важно покопаться в себе даже если вы правы" и прочий социальный карго-культ важнее чем работать работу.
Вы одни - контор вокруг много. Стучите и вам откроют.
На любой экстремизм есть офферы, от которых трудно отказываться. Возможно, кому-то важен карго-культ и дресс-коды, но и зарплата существенно выше рынка. Каждый решает для себя сам.
Имеет смысл подкачать софт-скилы в любом случае.
В конце концов ITшники люди в основном умные и способны понять на что идет плохая реакция, а на что нормальная. В итоге адаптировать своё поведение. Другое дело, что большинство ITшников просто не хочет это делать. Типа я пришел работать сюда, а не с людьми контактирвоать. Такое тоже имеет право на существование, но если вы хотите рост зарплат и карьеры - софт-скилы весьма полезны.
про 5 лет на одном месте
Я, когда в Канаду попал, и начал работать, на одном корпоративе одной конторы прям в осадок выпал, когда руководство начало поздравлять работников - кто-то 13 лет уже работает, а кто-то и больше 20ти
Можно, конечно, рассматривать их как тормозных старперов - а можно как редких профессионалов в своей области. Никто почему-то не упрекает, скажем, профессоров физики в том, что они не меняют направление на биологию/астрономию/химию каждые 5 лет
Почему в девелопменте софта должно быть по-другому? Или работы настолько рутинны и однообразны, что сидеть там 5 лет просто потеря времени?
Ну и давайте не будем забывать, что в крупных компаниях есть еще и движение по горизонтали, зачастую с радикальной сменой поля деятельности
потому что профессор/доктор физики решает нерешенную проблему физики. а разраб получает готовую технологию и смотрит как ею пользоваться и пользуется, как футболист просто оттачивая свое мастерство с уже готовым мячем
Решает не с нуля, а используя знания и опыт накопленный за сотни/тысячи лет. Не все разрабы занимаются копипастой со stackoverflow и то это касается только технологической части разработки, при решении бизнес задач обычно никакого фреймворка не существует.
Ну, положим, большую часть времени профессор занимается ну совершеннейшей рутиной — обучает студентов. Причём если обучает бакалавров, то эта рутина вообще уже лет 25 как не меняется. :-)
за грантами он будет бегать, а не нерешенные проблемы решать:)) Ну если не профессор в канаде или в европе, там профессором стал - и уже можно начинать ковырять в носу
что до готовых технологий девам которые они одинаково везде используют - это от профиля работы зависит. Понятно, что если работа сводится к перекладыванию jsonов из таблички в табличку(ц), то лучше там не задерживаться, но не все ж работы такие
эйчары, пожалуйста, начните уже понастоящему учиться. вы уже задолбали
не слишком токсично?
— Все как-то сложно. Надо как у Паркинсона.
«идеальное объявление привлечет одного человека, и того именно, кто нужен. Начнем с предельного случая: «Требуется акробат, который может пройти по проволоке на высоте 200 метров над бушующим пламенем. Ходить придется дважды в день, по субботам — трижды. Плата — 25 фунтов в неделю. Ни пенсии, ни компенсации за увечье не будет. Явиться лично в цирк „Дикий Кот“ от 9:00 до 10:00».
Быть может, слог и не очень хорош, но цель ясна: нужно так уравновесить риском денежную выгоду, чтобы не явилось больше одного соискателя. О мелочах тут спрашивать не придется.
Тех, кто не очень ловко ходит по проволоке, объявление не привлечет. Незачем указывать, что претендент должен быть здоровым, непьющим и не подверженным головокружению. Это поймут без слов. Незачем и говорить, что не годятся люди, страдающие высотобоязнью. Они и так не придут. Искусство тут в том, чтобы плата соответствовала опасности.
1000 фунтов в неделю может приманить человек десять, 15 фунтов не приманят никого. Где-то посередине — нужная сумма, которая и привлечет того, кто годится. Если придут двое, это значит, что мы завысили цифру».
Поделюсь своим опытом. Тема очень узкая, SAP программистов наверное 0.1% от общего количетсва и число их думаю только снижается, так как Java, Python заметно веселее и порог вхождения ниже, при том что часто вопросы решаются те же самые (бизнес логика поверх Oracle БД). По некоторым модулям все разработчики страны чуть ли не лично знакомы. Собеседования прохожу периодически, собеседование ведут профессионалы и фанаты своего дела, типично минут 40 собеседования пролетают как 5 минут, делимся своим опытом, переходе на On Memory Database, какими-то наработками по взаимодействию с MS Office, SQL запросами. Собеседующему нет цели валить или брать кого попало, у меня тоже нет цели устраиваться любой ценой (везде свои плюсы и минусы), поэтому собеседование протекает как дружеская беседа. Чтобы упростить собеседование сразу упоминаю вопросы на которых "завалился" на предыдущих собеседовениях, где кончается порог компетенции. Собеседующий тоже может сказать что зарплаты у них невысокие, фирма консалтинговая (галера?), параллельно много задач и может потребоваться работа в выходные, типа вы подумайте, подойдет ли вам такой режим работы.
Проверка на софт скилы действительно важна, хочется все же работать в дружеском коллективе, а не токсичном. Я именно в такие и попадаю, или HR прекрасно работают или везет просто.
Другой красный флаг из резюме — работа на одной позиции 5+ лет.…Классно, если пересидели, то попробуйте обратно в миддлы.
Что с этим делать? ..., временно снизить свои запросы и попробовать зайти на сеньорскую позицию через мидла...
Обратный пример — если вы сидите на одной позиции 5+ лет: заподозрят в отсутствии инициативы и стремления к развитию, а также узости профессиональных знаний.Человек с сильной инициативой и стремлением к развитию не задерживается на одном месте? Какая вообще связь? Особенно, если мы говорим о продуктовой компании, которая все эти годы идёт вперёд, а не сидит на поддержке, например.
При этом лучше трезво оценивать свои софт-скилы. Если с ними беда, может, не стоит пытаться выдать себя за кого-то другого? На рынке по-прежнему достаточно сеньорских вакансий «рабочих лошадок», требующих в первую очередь глубоких технических знаний, а не навыков «проблем-солвинга», где будет комфортно и вам, и работодателю.Как будто навыки «проблем-солвинга» и проверяемые софт-скиллы однозначно совпадают.
Если вы раз за разом не можете пробиться во второй этап или раз за разом получаете отписку про «сейчас не готовы» после успешно пройденного технического, возможно, стоит задуматься о визите к карьерному консультантуЭто довольно рациональный подход для кандидата, но не свидетельствует ли о проблемах в HR такая необходимость подготовки к собеседованиям на софт-скиллы у профессионала по подготовке к интервью? Как бы софт-скиллы — это основная область ответственности и проверки выделенных специалистов HR.
Другой красный флаг из резюме — работа на одной позиции 5+ лет. Некоторые собеседующие понимают это как то, что человек в принципе не хочет узнавать что-то новое и развиваться за пределами рабочих обязанностей, его все устраивает. Не самый годный перк для сеньора, и на собеседовании это обязательно проверят.
Что с этим делать? Кроме очевидного «всегда учиться и развиваться», можно также признать наличие проблемы, временно снизить свои запросы и попробовать зайти на сеньорскую позицию через мидла или искать компанию с более низкими требованиями.
Переходить на мидла - бред. Достаточно рассказать про проекты которые были эти самые 5+ лет, наверняка они были не один и разные.
Проработал в одной и то-же организации около 15-и лет, когда решил все-таки менять работу, прокачал профиль линкедина, расписал там про свои проекты в этой организации за последние лет 10 и пошли приглашения на собеседования т.ч. и от ФААНГов, а также предложения от контор поменьше на позиции Staff, или Principal.
Другой красный флаг из резюме — работа на одной позиции 5+ лет.Но при этом работодатели хотят, чтобы сотрудник работал на них чуть ли не до пенсии.
Что-то здесь не сходится.
Проблема с отказами из-за софт-скиллов — в том, что вам никто эту причину не назовет.Но при этом рекрутеры часто отказывают именно из-за soft skills, а потом постоянно жалуются на недостаток достойных кандидатов. Так откуда взяться достойным кандидатам, если никто не говорит в каком направлении им нужно работать над собой?
Опять не сходится.
Даже если формулировки будут более обтекаемыми, про «командный дух» и «слегка завышенную самооценку», вы же прочитаете именно так, как выше, правда? Вот поэтому фидбек по софт-скиллам везде находится под строгим запретом.Здесь наконец-то сошлось.
Если несколько рекрутеров говорят кандидату об одном и том же, но он не хочет меняться, то проблема матчинга (match) в кандидате.
Но рекрутеры ничего не говорят кандидату. Поэтому проблема матчинга — в рекрутерах.
Так что, уважаемые HR'ы, не жалуйтесь, а лучше не жалейте времени на предоставление кандидатам развернутой обратной связи. В конечном счете от этого выиграют все. И вам меньше работы будет.
Задушевно, особенно хорош пассаж о необходимости умерить аппетиты и пойти на мидловую позицию. Сейчас нехватка IT специалистов во всех сферах, поэтому ребята ситуация другая: Вам придется заплатить. И скоро вы будете платить за то, что к вам пришли на собеседование и тратят свое время на беседу с hr.
Во время поиска работы я столкнулся с тем, что люди в принципе не понимают, разницы между ответами юниора, мидла и сеньора. Например от сеньора ждут что он все время с утра до ночи кодирует и на вопрос об оптимизации запроса отвечает, что самое главное это cost запроса.
Почему не все сеньоры получают оффер мечты, и что с этим делать