Итак, ситуация: вполне себе квалифицированный и успешный сеньор хочет устроиться в конкретную большую компанию, собеседуется, проходит все этапы, но оффера так и не видит. Почему? Что он делает не так? Давайте разбираться.
Необходимая вводная
В одной из статей про собеседования, первым комментом идет вот такой:
В целом, комментатор прав — не то, чтобы прямо очереди стояли из работодателей, но ситуация на рынке такова, что для каждого разработчика найдется подходящая вакансия, куда он впишется, как влитой, и всем будет комфортно. Но для того, чтобы это произошло, кандидат должен быть готов рассматривать любые предложения. Если же он хочет оказаться в конкретной компании из FAANG или около-FAANG, ему придется подстраиваться и, скорее всего, работать над собой — потому что на такие вакансии есть конкурс, да и самих сеньоров с каждым годом становится больше.
Причины отказов
Основная причина — несоответствие уровню и заваленное техническое задание/собеседование. Дело в том, что само понятие senior — очень субъективное, разнится от компании к компании и от страны к стране. Часто кандидаты, позиционирующие себя как сеньоры, оцениваются работодателем как мидлы (а то и вовсе как джуны, есть такой случай). Иногда это делается с корыстной целью — ведь платить мидлу можно меньше, нежели сеньору.
В некоторых компаниях разработчики растут очень быстро, выходят на сеньорскую позицию и вроде способны решать серьезные задачи и менторить, но все это в очень узких рамках. Как правило, такой быстрый рост не позволяет человеку гармонично развиваться и служит для собеседователей красным флагом: кандидата начинают проверять на знание смежных технологий (или хотя бы интерес к ним) или задают вопросы по его узкой специализации, но с подводными камнями.
Другой красный флаг из резюме — работа на одной позиции 5+ лет. Некоторые собеседующие понимают это как то, что человек в принципе не хочет узнавать что-то новое и развиваться за пределами рабочих обязанностей, его все устраивает. Не самый годный перк для сеньора, и на собеседовании это обязательно проверят.
Что с этим делать? Кроме очевидного «всегда учиться и развиваться», можно также признать наличие проблемы, временно снизить свои запросы и попробовать зайти на сеньорскую позицию через мидла или искать компанию с более низкими требованиями.
Вторая причина — недостаток софт-скиллов и подача неверных (не подходящих для вакансии или компании) сигналов, описанных в том числе и в этой статье. Сеньор воспринимается работодателем как человек, который придет в компанию и будет «решать проблемы, а не создавать их», работать самостоятельно, не будет полностью полагаться на тимлида, его не надо будет контролировать.
Умение быстро принимать решения, стрессоустойчивость, автономность, понимание задач бизнеса — эти качества сеньоров ценятся все больше, и даже на техническом этапе собеседования многие вопросы тестируют их, а не алгоритмы и знание фреймворков. Но кандидаты часто зацикливаются на технологиях, к тому же сами такие вопросы иногда маскируются под технические, чтобы показать естественный образ мысли человека.
Как распознать вопросы про софт-скиллы на техническом собеседовании? Сигналы подаются с обеих сторон, их надо правильно интерпретировать, подумать, что именно интервьюер хочет узнать.
Тут может помочь контекст: так, обычно софт-вопросы относятся к конкретному кейсу из практики, например, «вспомните решенную проблему на прошлой работе и расскажите про нее». Здесь почти наверняка важен не написанный код, а оценка проблемы, процесс выбора решения, связь этого выбора с контекстом бизнеса, коммуникативные навыки.
В принципе, любой вопрос, в котором не упоминаются конкретные технология/язык/фреймворк, должен вызывать подозрение, а если нет уверенности — можно просто спросить. Вовремя заданный встречный вопрос может оказаться ценнее правильного ответа, т.к. подаст нужный сигнал.
При этом лучше трезво оценивать свои софт-скилы. Если с ними беда, может, не стоит пытаться выдать себя за кого-то другого? На рынке по-прежнему достаточно сеньорских вакансий «рабочих лошадок», требующих в первую очередь глубоких технических знаний, а не навыков «проблем-солвинга», где будет комфортно и вам, и работодателю.
Еще одна тема с сигналами — не всегда важно, что говорится, а важно — как. Любое сказанное на собеседовании слово может стать красным флагом, компрометирующим соискателя. Дальше собеседники начинают копать в сторону этого флага, и человек сыпется.
Часто подобные флаги поднимаются при рассказе о проблемах на прошлых местах работы: «я хотел сделать так, но они ничего не поняли, тимлид запретил, пришлось делать как сказали» — это неизбежно приведет к разборке, точно ли проблемы были в компании, а не в вас.
Чтобы такого не происходило, стоит минимизировать рассказ о проблемах на прошлой работе, заранее продумать его таким образом, чтобы к софт-скиллам не возникало вопросов. Или, если есть моменты, про которые надо рассказать, быть готовым признать свою вину в формате «возможно, я бы мог проявить больше настойчивости в разговоре с начальством для решения этой проблемы», а не просто говорить, что вас никто не слушал. Важно показать, что вы готовы искать проблему в себе, а не только в окружающих людях, даже если они действительно глупые.
Но бывают и куда менее очевидные мелкие детали, от которых в голове у собеседующих загорается красная лампочка. Надо стараться подбирать слова так, чтобы минимизировать количество дополнительных и уточняющих вопросов — они почти всегда будут не в вашу пользу. Пусть сами придумывают, что спросить.
Три этапа собеседования
Как правило, собеседование на сеньорские должности состоит из трех частей. Самих этапов может быть больше или меньше, к ним может добавляться что-то специфическое (типа СБ), они могут вплетаться друг в друга, но в целом решение об оффере принимается на основании результатов работы этих трех функционально разных алгоритмов.
1. Собеседование с HR
К беседе с HR большинство кандидатов относится традиционно плохо, считая ее бессмысленной тратой времени. Прямо скажем, это отношение возникло не на пустом месте — если HR сидит на зарплате, а KPI считается по количеству проведенных «скринингов», ясно, что такой специалист будет готов и с фонарным столбом задушевно побеседовать, был бы у столба релевантный CV.
К счастью, подобное встречается все реже, ну и к тому же в этой статье мы говорим о работе в крутой компании, куда хочется устроиться, а значит, там все должно быть заведомо правильно.
Правильно — это когда HR помогает бизнесу сократить издержки в виде времени высокооплачиваемых специалистов, которое тратится на интервью с кандидатами. А значит, уже на первом этапе кто-то отсеивается. И это не только случайные и/или неадекватные люди, получившие вакансию по ошибке или пытающиеся залезть туда, где им не место, но и вполне годные профессионалы, не подходящие по каким-то другим причинам.
Если бы не было отсеивания на HR-этапе, все бы сразу попадали на более объемное техническое собеседование, и его бы приходилось ждать месяцами, а сама процедура найма удлинялась бы для всех кандидатов. Конечно, настоящих сеньоров на HR-этапе отсеивают редко, ведь за них говорят CV, опыт и GitHub, но все же и такое случается — к тому же для них HR-собеседование часто вплетается в техническое.
«Другие причины» в общем случае можно поделить на четыре вида:
- неадекватность;
- токсичность;
- несоответствие внутренним требованиям работодателя по софт-скиллам;
- нежелательные сигналы (aka красные флаги).
Разберем их по отдельности.
Неадекватность проявляется, например, в нежелании общаться с HR — «я уже тысячу раз отвечал на эти тупые вопросы, можно сразу на техническое?» Это реальный случай, кандидат (на самом деле не слишком сильный) уже год искал работу и действительно много раз отвечал на «тупые вопросы». Но так и не задумался, почему его никто не позвал на второй этап. А ответ простой: если он не демонстрирует адекватности в простой беседе с рекрутером, то что от него ждать на техническом интервью? Что станет с репутацией HR, который пропустит такого персонажа?
Токсичность, как правило, выявляется при рассказе о прошлых местах работы, где все были тупые, ленивые, злые и/или жадные. Кажется, все знают, что так говорить нельзя — но таких кандидатов по-прежнему хватает. Есть еще ребята, путающие HR и психотерапевта, начинающие делиться своими болями, усталостью и выгоранием, вываливающие все, что накопилось. Зачем работодателю уставший сотрудник, у которого все плохо?
Необходимые софт-скиллы — некоторые обязательные требования, предъявляемые к кандидатам, на которые никто не обращает внимания в описании вакансии. Например, «проактивность» — пишут все по шаблону, но на практике есть IT-работодатель, нанимающий только супер-активных инициативных ребят.
Нежелательные сигналы не ведут к немедленному отказу, это заметки HR, передаваемые на следующий этап, техническим специалистам и начальникам. А люди на следующем этапе, ознакомившись с заметками, могут решить не тратить свое время, если эти сигналы для них важны (или передвинуть кандидата в конец очереди).
Хотя сеньоры редко отсеиваются на HR-этапе, вот эти заметки никто не отменял, а значит, лучше все-таки оставить о себе приятное впечатление. Для этого надо хотя бы не считать собеседование чем-то вредным и ненужным. Кстати, этот этап часто преподносится HR-ом как «я вам просто расскажу о вакансии», не ведитесь на это: вас здесь все равно скринят, собирают информацию, готовят заметки для работодателя.
2. Технический этап
Основная сложность технического интервью для сеньора — понять, что именно проверяют: хард или софт-скиллы. Некоторые компании ждут технически точных решений, некоторые добавляют вопросы, где хотят видеть ход мысли кандидата, а решение отходит на второй план. Единственное, что бывает практически всегда — спрашивают больше, чем нужно, и не ждут, что кандидат сможет верно ответить на все вопросы и решить все задачи.
Тесты на софт-скиллы пришли от FAANG'a и стали популярны. Это те самые часто выбешивающие кандидатов задачки, не имеющие отношения к предстоящей работе или заведомо не соответствующие техническим знаниям собеседуемого.
Так делается специально — важно не решение, а рассуждение, поэтому надо размышлять вслух и не бояться задавать вопросы, уточнять, если что-то непонятно. Главное — не говорить «я не знаю»: интервьюеры и так в курсе, что не знаете, они хотят понять, что вы будете делать в реальной стрессовой ситуации.
Иногда кандидаты допускают ошибку, пытаясь показать, что они знают вообще все. Никто не знает вообще все, и если кандидат начинает убеждать в обратном, это воспринимается негативно. Понимание собственных слабых сторон и пробелов в навыках, напротив, ценится высоко.
Наконец, технический этап может подразумевать тестовое задание, лайвкодинг, парное программирование или что-то в этом духе. Если что-то из этого для вас неприемлемо (так, от больших тестовых заданий отказывается 80% кандидатов-сеньоров), лучше заранее договориться об альтернативе.
Практика показывает, что GitHub часто помогает. Есть вакансии, где тестовое задание обязательно в силу их специфики, с этим надо либо смириться, либо не тратить время. Кстати, оплачиваемые тестовые пока большая редкость, но ситуация понемногу меняется — компании начинают осознавать, что время сильного специалиста стоит денег, даже если он пока всего лишь кандидат.
3. Финальное собеседование с руководством и бизнесом
Этот этап — знакомство с будущими коллегами и руководством и последняя проверка софт-скиллов, в частности, принятия корпоративной культуры. По сути, здесь выясняют, как человек приживется в компании, будет ли ему и окружающим комфортно. Все это, разумеется, дико субъективно, но если софты кандидата и будущих коллег не стыкуются, это риск для компании.
Многие не любят всю тему с софт-скиллами и корпоративной культурой, считают это ненужной мелочью, но при этом сами же говорят на собеседованиях про важность командного взаимодействия.
В целом, чем больше компания обращает внимание на софт-скиллы, тем кандидату потом будет комфортнее в ней работать. Соответственно, если хочется попасть не в комфортную, а в конкретную компанию, надо заранее выяснить, какие человеческие качества в ней ценятся, и развивать их (или ловко симулировать).
И да, ситуация, когда кандидат отлично проходит технический этап, но не получает оффера из-за софт-скиллов — довольно распространенная.
Что делать
1. Практиковаться
Лучший способ научиться проходить собеседования — проходить их. Да, это отнимает время, зато дает неоценимый опыт, подсказывает направления, которые надо подтянуть, да и вообще зачастую развивает вас как специалиста. А еще помогает научиться спокойно воспринимать отказы, не впадая в недельную депрессию.
Если задача — попасть в условный FAANG, можно сосредоточиться на собеседованиях в компаниях пожиже, активно перенимающих фаанговские практики. Лучше получить личный опыт подобного рекрутинга, чем прочитать сотню отзывов отвергнутых кандидатов. А если вдруг поступит оффер — ну, может, стоит его и принять, дабы изучить ту самую корпоративную культуру изнутри.
2. Выявить проблемы с софт-скиллами
Проблема с отказами из-за софт-скиллов — в том, что вам никто эту причину не назовет. Если вы завалили технику — вы, скорее всего, и сами это поймете, да и фидбек в этом случае — довольно распространенное явление (кстати, наличие такого фидбека иногда намекает, что с софтами у вас все в порядке, и компания готова вас снова увидеть через годик). Если у вас непомерные ожидания по зарплате — опять же, вряд ли кто-то будет это от вас скрывать (но могут и скрывать, конечно). Но вот если вы не прошли по софт-скиллам — получите стандартную отписку в стиле «мы сейчас не готовы» или «сделали выбор в пользу другого кандидата».
Причина в том, что описание софтовых недостатков часто воспринимается как оскорбление, а то и дискриминация. Ну, представьте себе такой фидбек: «Извините, мы не готовы сделать вам предложение, потому что наш CTO счел вас унылым неадекватом с непомерным ЧСВ». Даже если формулировки будут более обтекаемыми, про «командный дух» и «слегка завышенную самооценку», вы же прочитаете именно так, как выше, правда? Вот поэтому фидбек по софт-скиллам везде находится под строгим запретом.
Если вы раз за разом не можете пробиться во второй этап или раз за разом получаете отписку про «сейчас не готовы» после успешно пройденного технического, возможно, стоит задуматься о визите к карьерному консультанту. У него таких табу нет, и он без проблем расскажет вам, как вас видит потенциальный работодатель, посоветует, что подкрутить.
Если же вы сами (или с помощью консультанта) понимаете, что проблемы с софт-скиллами появились из-за психологических проблем, то возможно стоит обратиться к специалисту. Даже здесь, на Хабре есть статья по этой теме. И это совершенно нормально, таковы уж ритм и плотность работы современного разработчика, что стрессы, выгорания, депрессии и прочие радости могут случиться в любой момент.
3. Искать работу под свои сильные стороны (не только технические)
Обычно сеньора нанимают под конкретную задачу. Если заранее выяснить, в чем именно эта задача состоит, то можно понять, стоит туда соваться или нет — или какие софт-скиллы демонстрировать в первую очередь.
Например, если надо исправить процессы разработки — нужны лидерские качества, если есть горящая проблема — самостоятельность в поиске решения и способность донести это решение до руководства. Ну а если нужен просто сеньор, который будет хорошо делать свой фронт работ — значит, надо быть эдакой высококвалифицированной «рабочей лошадкой».
4. Следить за карьерой и знать проблемные места своего CV
Резюме тоже может содержать красные флаги, ведущие ко всяким лишним вопросам. Например, если вы меняете работу каждый год, к вам могут относиться настороженно. Обратный пример — если вы сидите на одной позиции 5+ лет: заподозрят в отсутствии инициативы и стремления к развитию, а также узости профессиональных знаний.
Принято считать оптимальным сроком работы в одном проекте три года — за это время происходит самое активное развитие как специалиста. Если после этого нет повышения или какого-то перемещения по проектам внутри компании, стоит искать что-то новое.
Эти флаги ни в коем случае не означают вечный бан на приличную работу — просто надо их учитывать и заранее готовить хорошие ответы на неизбежные вопросы.
5. Не жаловаться на предыдущих работодателей!
Снова эта базовая и, казалось бы, всем очевидная вещь, но ее надо еще раз проговорить, потому что об нее постоянно спотыкаются. Из практики: кандидат, часто меняющий работу, к тому же с мелкими косяками в техническом задании, все-таки получает оффер, потому что про все предыдущие проекты рассказывает увлеченно и позитивно.
И, напротив, кандидат нормально проходит этап с HR, после чего чуть расслабляется на техническом, плохо отзывается про предыдущую работу — и получает отказ, несмотря на то, что с техникой вроде все было в порядке.
Впрочем, здесь есть исключение: если вы расстались с предыдущим работодателем из-за какой-то конкретной практики, с которой вы ни в коем случае не хотите столкнуться в будущем, это упоминать можно и нужно. Но надо очень точно обозначить эту практику и причину, по которой она для вас неприемлема.
Например, вы не хотите иметь отношения к попилу госбюджета, или вас бесит чрезмерная бюрократия в рабочих процессах: далеко не всегда подобное очевидно из описания вакансии или из собеседований, но люди с той стороны в курсе, поэтому вы мирно разойдетесь, сэкономив друг другу время и нервы.
Заключение
Надеюсь этот пост был вам полезен, а соблюдение этих простых правил поможет вам сделать процесс трудоустройства более гладким и в отдельных случаях менее раздражающим. Если в вашей карьере были какие-то особенные случаи — призываю делиться ими в комментах.
Многие мои коллеги не ищут работу, наоборот — рекрутеры сами пишут им в личку и часто совсем с нерелевантными предложениями. Чтобы это изменить — мы с командой сделали настраиваемого под ваши запросы Telegram-бота Get Me It, который показывает только то, что вам подходит. Помимо этого бот позволяет следить за изменениями в оплате на схожей позиции, чтобы своевременно пересматривать свой оклад, а если повышение не устроит — рассмотреть новое предложение с ростом зарплаты единовременно на 40% и более процентов.
Комментарии (93)
bm13kk
26.11.2021 13:39+28нанимающий только супер-активных инициативных ребят
На рынке легко видеть, что компании хотят молодых парней, которые работают по 60-80 часов в неделю и платить им за 40.
victor_1212
26.11.2021 14:08+5>Что делать
6. Networking, попросту говоря поддержание профессиональных связей, по личному опыту min не менее важно, чем 1-5, чем ответственнее позиция тем важнее (относится к опыту вне россии)
kalombo
26.11.2021 14:22+18Ну, то что выявляется токсичность HR-ом, это прям прикольно, жаргонное слово, у которого нет четкого определения и которое появилось, ну года 4 назад, наверное.
- Почему не взяли?
-Ну он токсичный, душный и вообще зашквар
-А как надо?
А надо, чтобы был огонь, файный и сасный.
Ommonick
26.11.2021 18:00+14Пришлось гуглить "сасный", эхх.
PapaBubaDiop
26.11.2021 20:57+4лень гуглить - поделитесь
nicusor
26.11.2021 21:53+7Значение
жарг. привлекательный, милый; вызывающий вожделение ◆ Что за сасный мальчик на первом [фото]? «ВКонтакте», обсуждение ◆ Ае, сасный. «ВКонтакте», обсуждение ◆ Поц не очень, а тёлочка сасная. «ВКонтакте», обсуждение записи
жарг. красивый; приятный ◆ Админ очень старается выкладывать сасные сохры и топовую музыку. «ВКонтакте», запись
ru.wiktionary.org/wiki/%D1%81%D0%B0%D1%81%D0%BD%D1%8B%D0%B9
И чтобы два раза не вставать
Сохры — это разнообразные картинки, фотографии, мемчики, гифки со стен друзей из новостей, которые пользователь ВК сохраняет в своём профиле, а именно в альбоме «сохранённые фотографии».
de-dup-i-dipi
26.11.2021 14:47+52Другой красный флаг из резюме — работа на одной позиции 5+ лет.
Что-то меня триггернуло. На одном проекте есть самописный фреймворк. Когда новые проекты давались - использовали новые фреймворки. Там постгрес, тут кликхаус понадобился. Там фласк, тут fastapi подойдет и т.д. Бредовая позиция, что на одном месте если, то обязательно отстал на 5 лет.
vlreshet
26.11.2021 15:20+31Плюсую. В конце концов, «на одной позиции» не равно «на одном проекте». Я уже восьмой год в одной и той же компании, но разнообразных проектов повидал уйму — и разные фреймворки, и разные БД, типичные и нетипичные сферы бизнеса, и т. д. Ну глупость же, менять работу через 3 года, просто чтобы «красных флагов» не было
A-Z-0-9
27.11.2021 12:26+4А у меня более 5 лет и позиция таже (сеньор) и один проект все эти пять лет. Но быстрее чем в этом проекте я развивался только в самом начале карьеры. Тут получил опыт перехода в облако, поработал и с облаками Амазона и Ажуром, и разные архитектурные решения попробовал, и с базами разными поработал и с системами ивентов. Причем это реальные системы, которые приносят реальные деньги.
Так что если проект развивается, то и в одном проекте можно развиваться. И такой опыт может быть даже более полезен - ты знаешь не только как использовать какую-то технологию, но и видишь последствия ее использования в проекте, и плюсы и минусы.
DMGarikk
27.11.2021 14:40+1ну вот вы отработали 10 лет на этом проекте. решаешь идти дальше
приходишь в другое место, а там все кардинально по другому, вместо кубера — swarm, вместо удобной отладки — куча скриптов и makefile (в питоновском проекте), деплой наполовину вручную, мониторинг на неизвестной вам софтине и какихто странных для вас данных. нет под рукой удобной либы ф-ций которые вы 10 лет под себя пилили… но с собой взять ее нельзя и пилить надо по новой.
и… и вам надо это срочно учить или подстраиваться или пытаться поменять чужой проект.gorilych
29.11.2021 05:20+3замени 10 лет на 1 год. Что поменяется в последнем предложении?
DMGarikk
29.11.2021 12:37-11-3 года в отрасли не меняется ничего настолько кардинально
а вот 10 лет, вполне
я в 14 году 'вернулся в айти'… докер считался игрушкой для сумасшедших… а сегодня деплой и прод не в кубере/чемто-аналогичным считается уже чемто странным
далее, я в 10 году помню сел и решил что учить рельсы, яву, или питон? (в итоге решил яву)… с 15 года гдето три проекта встретил которые переходили я руби на питон… и все программеры хором шли его учить чтобы не уходить с проекта
а вот пошел бы рубистом в 10 году (капец как популярно было), попал бы на проект и сидел бы там лет 10… нет конечно с руби много работы и сейчас но верить в его светлое будущее уже сложновато… и пришлось бы или переключатся сейчас или сидеть в болотце
dakuan
26.11.2021 16:43Тут сильно от культуры зависит. Если в Штатах к частой смене работы относятся в целом положительно, то где-нибудь, скажем, в UK если вы за 5 лет пару раз меняли работу, то вас уже могут посчитать job hopper'ом.
ldss
26.11.2021 18:37+1да не шибко положительно в штатах к частой смене относятся
Наоборот, больше ценится лояльность компании
0xd34df00d
26.11.2021 23:58+3Я бы сказал, что на самом деле априори каких-то убеждений нет, и что длинные сроки работы на одном месте, что частые смены работы — просто повод эйчару про это немножко поговорить с вами.
ldss
29.11.2021 17:11+1Наверное от компании зависит. Мне все рекрутеры постоянно говорят, мол, оо, с лояльность проблем нет, мы видим, это хорошо. Хотя может польстить хотят, фиг их знает
pavelsc
26.11.2021 18:23+7Тоже триггернуло :) Во-первых во всяких епамах и так новые проекты дают. Во-вторых зачем менять если нет никаких проблем с повышением зп и коллективом? Чтоб внезапно узнать что на новой работе повышают зп на $50 раз в три года и путем чуть ли собеседования повторного? Может на протяжении 8 лет это и была работы мечты? В-третьих банально рост внутри компании за программерские позиции. Ну не стать архитектором за 3 года увы.
questor
30.11.2021 15:08Аналогично думаю. Сидел 10 лет в одной конторе, при этом и проекты кардинально менялись и технологии (переходили на тот же докер/куб) и успел язык программирования сменить. Это не обязательно красный флаг, ситуации разные бывают. И можно просто поговорить, но даже по резюме это видно - так что если вас на этом этапе зарубают - то и к лучшему, что вы даже не потратили на такую компанию время.
fougasse
26.11.2021 14:51+19Про 5 лет на одной позиции ничего не понял.
Почему сеньор должен менять позицию чаще? На какую? Почему именно так?
Не все молодые и горячие, которые меняют работы раз в год и готовы впахивать за идею. Как бы этого HR не желали.
novoselov
26.11.2021 15:21+76Меняет работу каждые 1-2 года - не надежный, быстро от нас сбежит
Меняет работу каждые 3-4 года - плохие софт-скиллы или токсичный, не сможет сработаться с командой
Не меняет работу дольше 5 лет - не хочет развиваться, потянет компанию вниз
Ну да, ну да пошел я нахер ... :)
DMGarikk
26.11.2021 17:50ну реально бывает ситуации когда сеньор врастает в позицию в конкретной этой конторе, а отсутствие дополнительного внешнего опыта делает его консервативным
я работал в одной конторе, где тимлид работал на этот момент уже около 8 лет… был категорически против любых «новых ненужных веяний» если они не совпадали с его точкой зрения «как должно быть (на уровне текущий год минус 8 лет)»
скорее это минус для тех кто с такими людьми сталкивался по работеfougasse
26.11.2021 19:53+3А реально бывают люди по 10+ лет на сеньорской/лид позиции, которые развиваются.
Не очень понимаю, что за внешний опыт такой и почему его не может быть без смены компании?
sim31r
27.11.2021 01:05+2А я не понимаю, как можно часто менять работу, если лет 5 нужно чтобы вникнуть в код и бизнес-логику сложного проекта. Даже понять как работает движок 3D игрушки нужно несколько лет.
Vilaine
27.11.2021 02:13реально бывает ситуации когда
Так нужно проверять, что человек думает и знает. Хоть сколько он проработал на текущем месте.
nikolayv81
27.11.2021 11:00Смотря что вы понимаете под "новыми веяниями" а то может он был прав и спас бизнес от ненужных трат, и такой человек может быть гораздо ценнее...
elektroschwein
26.11.2021 18:53Потому что нередко бывает так, что чем дольше работник работает в одном проекте на одной позиции, тем сильнее он становится пригоден только для этого проекта и для этой позиции.
Kiel
26.11.2021 15:17Соглашаюсь на собесы HR, только, чтобы узнать больше о компании. По опыту скажу, что обычно этот пункт присутствует либо в очень больших компаниях, вроде сбера и здесь всё понятно - им и правда пишут миллионы, даже интересно поговорить и послушать. Либо в компаниях в которые вообще никто не хочет идти
amarao
26.11.2021 16:48+19Какой FUD...
Тезисы, которые пропихивает компания, занимающаяся HR'ством:
Слишком долго сидеть на одной позиции плохо, бегом на рынок труда. Казалось бы, какой интерес у HR-компании звать людей постоянно менять места работы? Конфликт интересов? Нэт, дарагой, просто бызнес.
Утверждение о том, что софтскиллы важнее навыков. Тихой сапой подвливают приятную менеджерскую мантру с обесцениванием сложных знаний. При том, что софтскиллы важны для работы команды, кто-то должен понимать как "оно" работает. Если у всех софтскиллы и только, то ваш фундамент основан на софтскиллах и устойчивость у него соответствующая.
powerman
26.11.2021 17:09+2Всё это не отменяет того, что для прохождения этих фильтров стоит о них знать.
Нанимать сложно, никто толком не знает как это делать качественно, отсюда и всякая ересь про 5+ лет и т.п. - надо же на какие-то факторы ориентироваться, вот и придумывают эти самые факторы. HR-компании придумывают те факторы, которые понимают и с которыми умеют работать (т.е. которые им выгодны, да) - софт-скиллы и стаж они проверить могут, хард-скиллы нет. Первичную фильтрацию от HR-ов требуют, а делать они её могут только на основании того, что сами понимают. Отсюда и завышенный приоритет именно на этих факторах.
Идея, что негатив к 5+ лет основан на желании увеличить доход HR-компаний - по-моему это всё-таки перебор. При текущем состоянии рынка и так идёт непрерывный найм везде, вроде работы у HR-ов выше крыши и без таких манипуляций.
amarao
26.11.2021 17:13+9Начальник отдела, который HR-фильтром отфильтрует доступных на рынке интровертов-профи и останется с широким набором приятных в общении мидлов с невероятно развитыми софт-скиллами, сам себе злобный буратина.
HR, который мешает набору, ничем не лучше, чем, например, охранник на входе в здание, который не пускает собеседуемых. дурак и дурак, что с него взять. А вот его начальник - некомпетентен.
В целом, те разумные процессы, которые я видел, включали очень мягкое участие HR'а.
А две мои последние работы с точки зрения трудоустройства вообще не включали HR'ов, потому что "начальной фильтрации" не требовалось, работала репутация.
И хороший начальник отдела внимательно следит за "именными фигурами" для их приглашения, а не выкидывает неподъёмную задачу "найти толкового сеньёра" на HR'а, который сам, мягко говоря, даже не джуниор.
sshikov
26.11.2021 17:30+1Фильтровать интровертов — это вообще за гранью добра и зла. Интроверты — это душки просто, лапочки и все такое. Если кто-то не умеет их готовить — ему противопоказано в HR-ы ИТ компании, однозначно.
amarao
26.11.2021 17:32+2Вот откуда у вас "душки и лапочки" я не понял. У многих тяжёлый характер. Может быть, даже слегка токсичное поведение. И это сложное раздумие - стоит ли брать человека, который ас в технологии, но с которым некомфортно было говорить; а вовсе не непредодолимый "фильтр от HR'ов".
sshikov
26.11.2021 17:46+1>тяжёлый характер
Как это следует из «интроверт»? На мой взгляд — это разные вещи. Во всяком случае официальное определение вроде ничего такого не говорит.
sim31r
27.11.2021 01:09+2Экстраверт не может быть токсичным что ли? Интроверт будет сидеть тихо, а экстроверту будет не сложно каждому донести свою точку зрения по 3 раза на день )) HR обычно все экстраверты или притворяются ими, вот с ними интровертам общаться легко. Два интроверта или два экстраверта наверное уже сложнее будет, как 2 одинаковых заряда должны отталкиваться.
powerman
26.11.2021 17:34Мягкое участие HR-ов - это как конкретно? Если они вообще фильтровать не будут - от этого лучше не станет. Фильтровать качественно, с учётом хард-скиллов - они не в состоянии. Именных фигур на всех явно не хватит.
Ну т.е. я-то с Вами не спорю, проблема есть. Вопрос в том, есть ли решение?
amarao
26.11.2021 17:39+7Работа HR, это:
а) выяснение, работал ли человек хотя бы примерно в этой области (отсеить людей "прислал резюме на удачу"). В целом, это может быть просто по резюме или с помощью уточняющего вопроса.
б) Сопровождение процесса - согласование дат, сроков собеседований, выяснения, где живёт кандидат, готов ли к релокации/удалёнке и т.д.
в) Коммуникация при отправке тестового задания (мы присылаем тривиальное 10-минутное тестовое задание до первого технического собеседования, это отсеивает 90% мимо забежавших и даёт повод для конкретного разговора на собеседовании).
г) Предоставляет свои наблюдения по кандидату с точки зрения кооперации (HR представляет участников собеседования друг другу, молчит всё собеседование, в конце прощается и обеспечивает приятное завершение процесса), в ходе собеседования HR не слушает про MLPS с датаклассами, а слушает интонации, кто кого перебивает, как реагирует и т.д.
д) Ведёт дело собеседуемого (помнит про его существование, следит за процессом, имеет полный комплект данных в удобном для обсуждения виде)
е) Выполняет требования GDPR по персональным данным.
powerman
26.11.2021 18:45Ну т.е. по факту фильтрацией, с Вашей точки зрения, HR заниматься не должен вообще? Любой кандидат, который считает что "работал или точно смогу работать примерно в этой области" доходит до технического интервью (тестовое многие могут отказаться делать, скажут смотрите мой гитхаб, или даже сделают, но смотреть тестовое - это же тоже время, и это время тратит не HR)?
amarao
26.11.2021 18:48+2Любой кандидат, который сумел поддержать разговор с HR и подтвердил, что знает технологию, по которой ТЗ, получает ТЗ. В этот момент не тратятся ресурсы специалистов.
Дальше (практика показывает, что) 90% мимо забежавших отсеиваются, потому что надо иметь хоть какие-то знания, чтобы сделать ТЗ. Оставшиеся 10% уже можно рассматривать.
Если кандидат отказывается делать ТЗ и показывает на гитхаб, то это транслируется в техотдел и кто-то поверхностно смотрит, похож человек на знающего или нет. Для этого достаточно увидеть несколько коммитов в предметной области (не chore). Вообще, живой профиль на GH сильно облегчает первичную оценку кандидата, и времени на это надо даже меньше, чем на чтение решения ТЗ.
Задача HR'а тут отсеить неформатное (например, человек никогда не работал за компьютером, но уверен, что с лёгкостью обучится, или человек перестаёт отвечать), снять головную боль с людей по "трекингу" (кому что отвечали, кому нет) и дать фидбэк по своим наблюдениям.
HR не обладает компетенцией для оценки навыков от слова "совсем" и с этим стоит смириться. Те, кто пытаются с помощью HR'а, который не умеет программировать, найти программиста, найдут кандидатов, которые умеют программировать как HR.
powerman
26.11.2021 19:00+1В целом, звучит здраво. Если стратегия - посмотреть лично всех возможных кандидатов, чтобы случайно не упустить хорошего.
Но есть и обратная сторона - если позиция сеньорная или выше, или даже если нужен реально крепкий миддл, то большинство кандидатов обычно сильно до этого уровня не дотягивают. И "посмотреть лично всех" превращается в чёрную дыру, куда без какой-либо пользы утекает время, и это время тратит не миддл, а CTO или тимлид, чьё время довольно дорого. В результате чего появляются статьи, вроде Коллеги, вы меня огорчаете от @onokonem.
Ещё одна (небольшая, на самом деле) проблема описанного Вами подхода - работа HR превращается в тупую отработку по скрипту, и тогда это уже не совсем HR, а что-то ближе к "специалисту" первого уровня тех.поддержки, и, в целом, работа скорее для телеграм-бота, а не человека.
amarao
26.11.2021 19:05+1Именно тут срабатывает 10 минутное ТЗ, потому что без знаний в области его не сделать, а если сделал, то это уже миддл+, а различить миддла от сеньёра - совершенно нерешаемая косвенными методами задача, так что говорить со всеми подходящими.
powerman
26.11.2021 19:27+3Мне буквально пару недель назад прислали как раз такое "сделанное" ТЗ. И даже не 10-минутное, а заметно сложнее. И оно съело с полчаса моего времени - сначала на то, чтобы понять, может кандидат просто неправильно понял задание или решил проявить инициативу, а потом на то, чтобы таки найти откуда он это решение украл (что и объяснило почему решена совершенно другая задача, а не то, что просили в ТЗ).
Плюс очень многие, включая и меня самого, не любят бесплатно делать тестовое. У меня на гитхабе 143 репо, если их мало и работодатель всё-равно упирается и хочет тестовое - для меня это красный флаг и я его посылаю. Плюс тестовое, которое я могу сделать за 10 минут - мало что покажет. Ладно, не буду играть словами и смягчать выражения: ничего оно не покажет! Я не знаю, как в Вашей области у админов, но у разработчиков за 10 минут ничего показательного не сделаешь. Простое тестовое - это 2-3 часа работы (если хорошо знать, что делаешь, а иначе это превращается в пару дней), так что не удивительно, что делать это бесплатно желающих мало.
Ну и в целом, факт выполнения тестового - показывает только готовность делать тестовые и то, что кандидат считает, что понял постановку задачи в тестовом и умеет кое-как кодить. Как правило, этого и близко не достаточно, чтобы отсеять слабых кандидатов - как правило тестовые охотнее всего делают как раз джуны и слабые миддлы.
В общем, есть у меня подозрение, что разница в наших подходах вызвана разницей в особенностях найма разработчиков и админов.
amarao
26.11.2021 19:35Я бы сказал, что вам было трудно читать именно потому, что задание не 10-минутное.
10-минутное задание с одним-двумя-тремя разумными решениями хорошо тем, что человек либо применил разумное решение, либо нет. Если вместо 30-40 строк решения вам присылают ужас, то вы его сразу видите. Более того, чем компактнее задание, тем выше вероятность, что человек его сделает. Вместо необъятной работы он видит <s>интересную</s> задачку, которую можно решить за один короткий заход.
Вот пример такого задания (придумываю на ходу): Написать плейбуку для поднятия point-to-point туннеля между двумя серверами. У серверов есть белые IP. Туннель должен быть симметричным (без выделения сервера и клиента). Шифрование не обязательно. Туннелю не обязательно сохраняться после перезагруки. IP адреса внутри туннеля могут быть заданы в инвентори. На входе даются белые IP серверов (linux), с запущенным ssh, имя пользователя и приватный ключ для доступа к обоим. Тест для testinfra для группы tun_servers прилагается. Ожидаемый размер решения - 6-12 task'ок. Формат - плейбука ансибла плюс инвентори, роли не обязательны. Использование molecula для запуска теста - в плюс.
powerman
26.11.2021 20:17Я согласен, что хорошо подобранное тестовое - это важно. Но придумать хорошее тестовое - не так-то просто.
Что конкретно покажет Ваше тестовое, кроме того, что кандидат знаком с ансиблом и либо уже поднимал такие туннели ранее, либо умеет за 10 секунд нагуглить набор команд вроде https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Jump_Hosts#Passing_Through_a_Gateway_with_an_Ad_Hoc_VPN?
amarao
26.11.2021 21:44Написать это на ансибле можно несколькими методами, и то, как человек напишет, скажет мне о том, как это человек владеет ансиблом больше, чем на большом проекте.
Найденное за 10с точно не будет соответствовать определению "симметричного туннеля". В целом, если кто-то слепит два встречных ssh-клиента, технически это будет соответствовать задаче, но человеку будет трудно это интегрировать обратно. Два tap'а в бридже? Я вот с ходу не придумаю как с помощью ssh сделать два симметричных туннеля. В целом, опции ip link гуглятся за секунды, но только хорошо понимающий сеть на хосте человек оные опции поймёт.
Если кто-то пришлёт нашкрябанные два command для ssh в плейбуке, то мы попросим мягкого HR'а сказать, что туннель должен был быть симметричным (без деления на сервер и клиент). Дальше HR на себя берёт всех гневающихся, несогласных и т.д. Если человек вчитается и исправит, ок, если нет - ну на нет и суда нет.
powerman
26.11.2021 22:15Просто из любопытства - а это вот по ссылке выше, которую я реально нагуглил за 10 секунд (никогда раньше не знал, что на ssh можно такое делать, но я вроде понимаю смысл термина "симметричный", и из описания задания вроде бы следовало, что ssh такое умеет) - это разве не оно? Там как раз пара tun-интерфейсов через ssh связывается.
amarao
26.11.2021 23:05У вас два участника соединения. В 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, и как человек в этой ситуации бы поступил, было бы очень интересно увидеть.
powerman
26.11.2021 20:20Точнее, перефразирую вопрос. Не "что конкретно покажет Ваше тестовое" - показать оно может много чего, смотря что кандидат напишет в плейбуке, - а "как по факту выполнения тестового отличить джуна от сениора". Т.е. иными словами - даёт ли такое тестовое хоть что-нибудь, кроме уже упомянутого мной "кандидат готов делать тестовые и понял задание"?
amarao
26.11.2021 21:46Мне - скажет. Я способен увидеть по этим 6-10 таскам как человек пишет на ансибле, понимает ли он принципы хороших плейбук на ансибле, владеет ли он хостовой сетью в linux.
Этого достаточно, чтобы отсечь тех, кто не умеет или "кое-как нашкрябал".
Всё дальнейшее - на собеседовании, человек как минимум уже довольно хорошо знает по крайней мере две области.
myc
27.11.2021 14:03А если кандидат работал с asible, salt, puppet и chef, но сходу не сможет написать грамотный плейбук, вы ему откажите? Ведь у этих систем несколько отличается подход к описанию.
amarao
27.11.2021 15:49Зависит от степени ошибок. У всех четырёх, насколько я понимаю, ценится идемпотентность. У всех четырёх, видимо, ценится разумное именование переменных.
Но вот если человек начнёт делать странное по сути (например, притащит код, которого не должно быть, или сделает socks proxy, хотя в тексте фигурировали IP внутри туннеля), то задание будет не сделано.
victor_1212
26.11.2021 19:34>различить миддла от сеньёра - совершенно нерешаемая косвенными методами задача
ув. Георгий, позвольте с вами не согласиться, лично провел не менее 300 интервью принимая людей на работу, если интересуетесь могу поделиться (в личку конечно)
sshikov
26.11.2021 21:01+1Рассказывайте, рассказывайте. 300 интервью это вообще интересно, за какой период, кого набирали…
victor_1212
27.11.2021 00:49людей принимали по возможности сильных, примерно уровень физтеха, где образование получил смотрели, но не очень, обычно уровень виден в первые 10 минут разговора (но бывало, что и по два дня говорили), долгая история, работал project leader, sw manager, sw director, (все development) всего порядка 10 компаний, все связано с сетями, типа voip и пр., nda подписано достаточно, в общем не положено детали выкладывать, но на вопросы можно попробовать, все же предпочел бы в личку :)
ps
посмотрел типа что есть webzilla и пр., ничего близкого конечно, могу добавить что программированием занимаюсь порядка 50 лет, первую embedded на основе linux сделали примерно 21 год назад
sshikov
26.11.2021 20:59+1>Если стратегия — посмотреть лично всех возможных кандидатов, чтобы случайно не упустить хорошего.
Ну вот скажите честно, в вашей практике их сколько было, кандидатов? Я один раз общался с коллегами, которые провели 50 интервью, и никого не наняли. Это максимальное известное мне число кандидатов. Да, многовато, этож минимум 50 часов наверное.
Но я лично никогда и близко ничего не наблюдал. Если кандидатов бывает скажем 10 — это уже хорошо, при этом процентов 90 из них я легко сам отсеиваю по резюме (и очевидно, что как технический специалист технические же навыки кандидата я оцениваю лучше, чем HR, а еще и быстрее).powerman
26.11.2021 21:11Количество "лишних" кандидатов как раз и зависит от работы HR. И да, по часу на каждого - это минимум. На практике лично у меня получается ближе к 2 часам: полчаса-час уходит на посмотреть тестовое, минут 15 на общение с HR, минут 15 на подготовку к собесу, и час обычно на сам созвон-собес. При этом надо понимать, что если бы день целиком состоял из собесов - было бы проще и эффективнее, но когда приходится вытаскивать себя из кода, настраиваться на общение, аккуратно разговаривать (и да, я вообще-то тоже интроверт, и от меня это требует определённых усилий) чтобы обеспечить кандидату максимальный психологический комфорт насколько это вообще возможно на собесе, и потом снова возвращаться в код - на выйти из кода и вернуться обратно уходит ещё где-то час… и 2 часа легко превращаются в результате в практически 3 часа вычеркнутых из продуктивной работы. 2-3 собеса - минус рабочий день. 50 собесов - минус рабочий месяц. А это и компании довольно дорого обходится, и я тоже нанимался не только собесы проводить… отсюда и желание адекватной фильтрации кандидатов на уровне HR.
sshikov
26.11.2021 21:19+1Так я вроде начал с вопроса — сколько вы лично собеседовали, и откуда они взялись? Потому что у меня в практике это выглядит примерно так — сравнительно мелкие проекты в пределах 10 человек, нужны минимум миддлы, и я никогда не видел более 10 кандидатов в течение месяца. И я наблюдаю острый дефицит хороших специалистов, а вовсе не избыток кандидатов. В итоге мы набрали за два года двух синьоров, по знакомству в обоих случаях. Проведя два интервью :) А вот сейчас у меня есть две позиции — и пока за месяц строго ноль кандидатов.
Т.е. если в таких масштабах смотреть — затраты на кандидата в проекте вообще несуществены. Поэтому в моем окружении я бы предпочел увеличить число кандидатов, и уменьшить отсев.
Вот поэтому и интересно, ваши 50 штук — это реально месяц, или это происходило скажем в течение года? Каков размер команды? Откуда столько желающих, по какой причине их так много приходит?
powerman
26.11.2021 22:06Я не очень понял, к чему ведут Ваши вопросы, в чём их смысл. Поэтому ответ получился несколько сумбурный, и тоже без особого смысла - не считая "всё плохо".
Это зависит от проекта и HR-ов. Сколько лично я насобеседовал за 30+ лет работы - не знаю, никогда не приходило в голову посчитать. Я видел разное - и как все 10 человек в такую команду набирали очень быстро по знакомству без HR, и как уже 3.5 месяца не могут набрать пару джунов при активном содействии HR. Об этом-то и речь: при вполне рыночной и даже чуть выше рыночной зарплате кандидатов должно быть более чем достаточно, особенно джунов. А когда HR-компания за месяц находит 7 человек на три открытые позиции закрывающие, по сути, почти все основные уровни квалификации (пара джунов плюс сениор или хотя бы сильный миддл), и абсолютное большинство из них и близко не тянут заявленный уровень - это крайне печально.
Отвечая на Ваш вопрос, при моих темпах на текущем проекте в 7 человек в месяц - 50 наберётся за полгода где-то. Но какая разница, на какой период времени растянуто выкинутое впустую время, если в результате этого времени как раз месяц и наберётся?
И нет, я не считаю, что 7 кандидатов на 3 позиции в месяц - это много кандидатов и "откуда столько берётся". Я считаю, что учитывая качество этих кандидатов - это очень мало кандидатов. Если бы нашли 7 удовлетворяющих требованиям - был бы другой разговор, тогда да, это много. А когда реально имело смысл собеседовать 1 из 10, пусть даже он и не подошёл, но там хотя бы был шанс - это очень много лично моего времени потрачено впустую, и я не хочу, чтобы таких кандидатов находили в разы больше.
P.S. Если у кого-то возникло подозрение, что мы джунов не можем найти потому, что ищем миддлов с зарплатой джуна - это не так. Текущие требования к джуну на уровне "полгода/год опыта на Go плюс наличие интереса к программированию (а не очередное войтивайти) и желание активно учиться писать качественный код", и да, мы готовы активно обучать, никто не ждёт что от этих джунов будет реальная польза ближайшие месяцы.
sshikov
26.11.2021 22:36>Я не очень понял, к чему ведут Ваши вопросы, в чём их смысл.
Смысл? Ну я просто пытаюсь понять, 50 собеседований или 7 в месяц — это какой масштаб проекта? Потому что даже если команда крупная — зачем их собеседовать всех одному? Если в команде есть синьоры или тимлиды — почему не разделить собеседования и не отдать кандидатов лидам? Ведь тем более, если вы джунов ищете — их же кто-то будет учить потом? Вот пусть эти люди их понемногу и собеседовали бы? Я понимаю, что общие затраты при этом все равно будут велики — но по крайней мере, это не будет ложиться на одного человека.
powerman
26.11.2021 23:32Я и буду учить, по крайней мере - поначалу. Если важен результат, то чем раньше получится исправить неправильные привычки, сформировать правильное отношение к работе, дать недостающие базовые знания - тем лучше. А вот когда эта база есть - тогда появляется смысл немного ослабить контроль и передать "шефство" другому разработчику, это им обоим на пользу пойдёт. Так что для меня важно, кого брать, и пропускать эти собесы - мне может дорого обойтись потом.
Ну и в более традиционном случае Ваше предложение всё-равно звучит странно. Собес обычно проводит не миддл, и даже не сениор - обычно это тимлид или CTO. Так что чьи бы это ни были часы, мои или не мои, это будут довольно дорогие часы. Найм вообще дело очень дорогое, и меня временами поражает, насколько компании эту цену недооценивают, когда умудряются из-за мелочей терять хороших разработчиков.
sshikov
27.11.2021 08:58>Собес обычно проводит не миддл, и даже не сениор — обычно это тимлид или CTO.
Ну миддла я и не предлагал.
Да, стоимость этого времени все равно достаточно велика, не спорю. И это важно.
ignat99
01.12.2021 15:43Старших специалистов CEO лучше выбирать лично. Потому что от них зависит результат приложенных усилий и вложенных средств. IMHO
AlexeySanko
26.11.2021 17:02+3Думаю автор писал про 5 лет на той же позиции с той же ответственностью (технической и софт-скилами). Надо через CV и на интервью показать что вы развивались в компании, а не тупо сидели на месте.
Повышение? - отдельной графой и периодом в резюме в той же компании. Это сложно, учитывая что ответственность не меняется резко с повышением. Но надо попытаться разделить.
Новый большой проект? - отдельной графой и периодом в резюме в той же компании. И новыми техническими решениями и тулами.
AlexeySanko
26.11.2021 17:08+16 лет забивал гвозди (от мебельных до рельсовых костылей)
VS
2 года забивал мебельные гвозди
2 года - десятки
2 года - рельсовые костыли
Прогресс на лицо :)
sshikov
26.11.2021 17:07+85. Не жаловаться на предыдущих работодателей!
Типичный взгляд HR, прямо скажем. Как технический специалист, проводящий технические интервью, я бы как раз охотно послушал бы жалобы на предыдущих работодателей. И сам бы пожаловался бы. Не вижу в этом ровно никаких проблем вообще. Даже интересно, что именно человек расскажет. Вот в зависимости от того, что расскажет — выводы могут быть разными.
Никакой работодатель не идеален, у них у всех могут быть недостатки, тем более что я бы лично жаловался бы на проекты и руководителей, а не на работодателя как компанию — потому что проблемы в жизни именно с ними, а не с компанией.
rtemchenko
26.11.2021 20:28+1Такие жалобы нередко выглядят как "Я д'Артяньян, все п-сы.". Норм указывать несоответствие желаний и реальности как причину ухода. Но это не должно звучать как "все зае-ло".
sshikov
26.11.2021 20:55>Такие жалобы нередко выглядят как
Могут, да.
Но я поэтому и говорю, что в зависимости от претензий выводы могут быть разные. Но как член команды, я предпочел бы сам с кандидатом поговорить на эту тему, если он захочет, а не оставлять HR такие решения. Почему? А почему должно быть наоборот? Ну вот с чего бы мне априори считать, что HR опытнее меня и лучше разбирается в людях, тем более, если с этим человеком работать именно мне?
Ну и опять же — я такие вещи выслушаю, но не буду на них настаивать. Если человек не хочет про такое рассказывать — он нем это тоже кое-что да говорит.
Stas911
27.11.2021 04:54+2Плюсую, правильно поданный рассказ про проблемы на предыдущих местах работы с соответсвующими выводами и lessons learned может смотреться весьма выигрышно.
HellWalk
26.11.2021 17:09+13Чтобы такого не происходило, стоит минимизировать рассказ о проблемах на прошлой работе
Вначале вы не рассказываете о проблемах на прошлой работе.
Потом не рассказываете о проблемах на текущем проекте.
А потом мы получаем компании, где все плохо, но все делают вид, что все хорошо.
У меня всегда вопрос людям, которые советуют что-то врать и недоговаривать - почему честно отрабатывая свои 40 часов в неделю я должен что-то врать и чего-то стесняться? Что за бред?
sshikov
26.11.2021 17:24>Вначале вы не рассказываете о проблемах на прошлой работе.
А почему вы решили сменить работу, если на прошлой все было настолько зашибись, что вы не хотите нам рассказать ни об одной проблеме?
BobArctor
26.11.2021 17:30+5Пункт №6
Без сожаления дропать конторы которым "софт скилы", "важно покопаться в себе даже если вы правы" и прочий социальный карго-культ важнее чем работать работу.
Вы одни - контор вокруг много. Стучите и вам откроют.
amarao
26.11.2021 17:41+2На любой экстремизм есть офферы, от которых трудно отказываться. Возможно, кому-то важен карго-культ и дресс-коды, но и зарплата существенно выше рынка. Каждый решает для себя сам.
Sam86
26.11.2021 18:17+4Имеет смысл подкачать софт-скилы в любом случае.
В конце концов ITшники люди в основном умные и способны понять на что идет плохая реакция, а на что нормальная. В итоге адаптировать своё поведение. Другое дело, что большинство ITшников просто не хочет это делать. Типа я пришел работать сюда, а не с людьми контактирвоать. Такое тоже имеет право на существование, но если вы хотите рост зарплат и карьеры - софт-скилы весьма полезны.
sunki
27.11.2021 01:15+2Тут какое-то странное и ограниченное понимание софт-скиллов. Коммуникация между разрабами к этому тоже относится. Если человек не умеет воспринимать критику или наоборот не умеет конструктивно критиковать или рассуждает по принципу "я художник, я так вижу" – это все тоже про софт скиллы.
ldss
26.11.2021 19:13+8про 5 лет на одном месте
Я, когда в Канаду попал, и начал работать, на одном корпоративе одной конторы прям в осадок выпал, когда руководство начало поздравлять работников - кто-то 13 лет уже работает, а кто-то и больше 20ти
Можно, конечно, рассматривать их как тормозных старперов - а можно как редких профессионалов в своей области. Никто почему-то не упрекает, скажем, профессоров физики в том, что они не меняют направление на биологию/астрономию/химию каждые 5 лет
Почему в девелопменте софта должно быть по-другому? Или работы настолько рутинны и однообразны, что сидеть там 5 лет просто потеря времени?Ну и давайте не будем забывать, что в крупных компаниях есть еще и движение по горизонтали, зачастую с радикальной сменой поля деятельности
centroid
26.11.2021 21:50+1потому что профессор/доктор физики решает нерешенную проблему физики. а разраб получает готовую технологию и смотрит как ею пользоваться и пользуется, как футболист просто оттачивая свое мастерство с уже готовым мячем
Daddy_Cool
27.11.2021 00:18+2В физике в этом смысле есть проблемы — скажем я специалист в достаточно узкой области, и на весь мир наберется ну максимум десяток мест где я мог бы работать сходу. Другой вопрос, что научные работники постоянно осваивают что-то новое. Периодически участвую в других проектах — если рядом есть человек который может объяснить базу, никаких проблем не испытывал.
gen_dalf
27.11.2021 01:50Решает не с нуля, а используя знания и опыт накопленный за сотни/тысячи лет. Не все разрабы занимаются копипастой со stackoverflow и то это касается только технологической части разработки, при решении бизнес задач обычно никакого фреймворка не существует.
vkni
27.11.2021 04:57Ну, положим, большую часть времени профессор занимается ну совершеннейшей рутиной — обучает студентов. Причём если обучает бакалавров, то эта рутина вообще уже лет 25 как не меняется. :-)
ldss
29.11.2021 09:16за грантами он будет бегать, а не нерешенные проблемы решать:)) Ну если не профессор в канаде или в европе, там профессором стал - и уже можно начинать ковырять в носу
что до готовых технологий девам которые они одинаково везде используют - это от профиля работы зависит. Понятно, что если работа сводится к перекладыванию jsonов из таблички в табличку(ц), то лучше там не задерживаться, но не все ж работы такие
nktkz
27.11.2021 00:14+1эйчары, пожалуйста, начните уже понастоящему учиться. вы уже задолбали
не слишком токсично?
Daddy_Cool
27.11.2021 00:19+2Кстати, а как долго HRу позволяется работать на одном месте, чтобы это не было флагом?
— Все как-то сложно. Надо как у Паркинсона.
«идеальное объявление привлечет одного человека, и того именно, кто нужен. Начнем с предельного случая: «Требуется акробат, который может пройти по проволоке на высоте 200 метров над бушующим пламенем. Ходить придется дважды в день, по субботам — трижды. Плата — 25 фунтов в неделю. Ни пенсии, ни компенсации за увечье не будет. Явиться лично в цирк „Дикий Кот“ от 9:00 до 10:00».
Быть может, слог и не очень хорош, но цель ясна: нужно так уравновесить риском денежную выгоду, чтобы не явилось больше одного соискателя. О мелочах тут спрашивать не придется.
Тех, кто не очень ловко ходит по проволоке, объявление не привлечет. Незачем указывать, что претендент должен быть здоровым, непьющим и не подверженным головокружению. Это поймут без слов. Незачем и говорить, что не годятся люди, страдающие высотобоязнью. Они и так не придут. Искусство тут в том, чтобы плата соответствовала опасности.
1000 фунтов в неделю может приманить человек десять, 15 фунтов не приманят никого. Где-то посередине — нужная сумма, которая и привлечет того, кто годится. Если придут двое, это значит, что мы завысили цифру».
sim31r
27.11.2021 01:24Поделюсь своим опытом. Тема очень узкая, SAP программистов наверное 0.1% от общего количетсва и число их думаю только снижается, так как Java, Python заметно веселее и порог вхождения ниже, при том что часто вопросы решаются те же самые (бизнес логика поверх Oracle БД). По некоторым модулям все разработчики страны чуть ли не лично знакомы. Собеседования прохожу периодически, собеседование ведут профессионалы и фанаты своего дела, типично минут 40 собеседования пролетают как 5 минут, делимся своим опытом, переходе на On Memory Database, какими-то наработками по взаимодействию с MS Office, SQL запросами. Собеседующему нет цели валить или брать кого попало, у меня тоже нет цели устраиваться любой ценой (везде свои плюсы и минусы), поэтому собеседование протекает как дружеская беседа. Чтобы упростить собеседование сразу упоминаю вопросы на которых "завалился" на предыдущих собеседовениях, где кончается порог компетенции. Собеседующий тоже может сказать что зарплаты у них невысокие, фирма консалтинговая (галера?), параллельно много задач и может потребоваться работа в выходные, типа вы подумайте, подойдет ли вам такой режим работы.
Проверка на софт скилы действительно важна, хочется все же работать в дружеском коллективе, а не токсичном. Я именно в такие и попадаю, или HR прекрасно работают или везет просто.
Vilaine
27.11.2021 02:25+2Другой красный флаг из резюме — работа на одной позиции 5+ лет.…
Классно, если пересидели, то попробуйте обратно в миддлы.
Что с этим делать? ..., временно снизить свои запросы и попробовать зайти на сеньорскую позицию через мидла...Обратный пример — если вы сидите на одной позиции 5+ лет: заподозрят в отсутствии инициативы и стремления к развитию, а также узости профессиональных знаний.
Человек с сильной инициативой и стремлением к развитию не задерживается на одном месте? Какая вообще связь? Особенно, если мы говорим о продуктовой компании, которая все эти годы идёт вперёд, а не сидит на поддержке, например.При этом лучше трезво оценивать свои софт-скилы. Если с ними беда, может, не стоит пытаться выдать себя за кого-то другого? На рынке по-прежнему достаточно сеньорских вакансий «рабочих лошадок», требующих в первую очередь глубоких технических знаний, а не навыков «проблем-солвинга», где будет комфортно и вам, и работодателю.
Как будто навыки «проблем-солвинга» и проверяемые софт-скиллы однозначно совпадают.Если вы раз за разом не можете пробиться во второй этап или раз за разом получаете отписку про «сейчас не готовы» после успешно пройденного технического, возможно, стоит задуматься о визите к карьерному консультанту
Это довольно рациональный подход для кандидата, но не свидетельствует ли о проблемах в HR такая необходимость подготовки к собеседованиям на софт-скиллы у профессионала по подготовке к интервью? Как бы софт-скиллы — это основная область ответственности и проверки выделенных специалистов HR.
Politura
27.11.2021 08:18+1Другой красный флаг из резюме — работа на одной позиции 5+ лет. Некоторые собеседующие понимают это как то, что человек в принципе не хочет узнавать что-то новое и развиваться за пределами рабочих обязанностей, его все устраивает. Не самый годный перк для сеньора, и на собеседовании это обязательно проверят.
Что с этим делать? Кроме очевидного «всегда учиться и развиваться», можно также признать наличие проблемы, временно снизить свои запросы и попробовать зайти на сеньорскую позицию через мидла или искать компанию с более низкими требованиями.
Переходить на мидла - бред. Достаточно рассказать про проекты которые были эти самые 5+ лет, наверняка они были не один и разные.
Проработал в одной и то-же организации около 15-и лет, когда решил все-таки менять работу, прокачал профиль линкедина, расписал там про свои проекты в этой организации за последние лет 10 и пошли приглашения на собеседования т.ч. и от ФААНГов, а также предложения от контор поменьше на позиции Staff, или Principal.
Mike-M
29.11.2021 00:05Другой красный флаг из резюме — работа на одной позиции 5+ лет.
Но при этом работодатели хотят, чтобы сотрудник работал на них чуть ли не до пенсии.
Что-то здесь не сходится.Проблема с отказами из-за софт-скиллов — в том, что вам никто эту причину не назовет.
Но при этом рекрутеры часто отказывают именно из-за soft skills, а потом постоянно жалуются на недостаток достойных кандидатов. Так откуда взяться достойным кандидатам, если никто не говорит в каком направлении им нужно работать над собой?
Опять не сходится.Даже если формулировки будут более обтекаемыми, про «командный дух» и «слегка завышенную самооценку», вы же прочитаете именно так, как выше, правда? Вот поэтому фидбек по софт-скиллам везде находится под строгим запретом.
Здесь наконец-то сошлось.
Если несколько рекрутеров говорят кандидату об одном и том же, но он не хочет меняться, то проблема матчинга (match) в кандидате.
Но рекрутеры ничего не говорят кандидату. Поэтому проблема матчинга — в рекрутерах.
Так что, уважаемые HR'ы, не жалуйтесь, а лучше не жалейте времени на предоставление кандидатам развернутой обратной связи. В конечном счете от этого выиграют все. И вам меньше работы будет.
sonepotam
29.11.2021 01:58-1Задушевно, особенно хорош пассаж о необходимости умерить аппетиты и пойти на мидловую позицию. Сейчас нехватка IT специалистов во всех сферах, поэтому ребята ситуация другая: Вам придется заплатить. И скоро вы будете платить за то, что к вам пришли на собеседование и тратят свое время на беседу с hr.
Во время поиска работы я столкнулся с тем, что люди в принципе не понимают, разницы между ответами юниора, мидла и сеньора. Например от сеньора ждут что он все время с утра до ночи кодирует и на вопрос об оптимизации запроса отвечает, что самое главное это cost запроса.
ThePaleEmperor
Что? Предложение о работе мечты?
alruk
На Яндексе, навигаторе линия трафика не меняется по мере приближения авто к цели. На МТС в мобильной версии нет доступа к настройкам автоответчика HR нашли человека,хзвала HR, он не справляется, это проблема вашей фирмы Да, я злой..