Тезис: вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода.
Более того, вы сами это прекрасно знаете, сознательно или подсознательно, однако корпоративная этика мешает заявить прямо о своих сомнениях.
Для привлечения внимания покажем картинку и продолжим.
Зачастую на собеседовании люди смотрят на сам процесс интервью достаточно однобоко. Однако большинство опытных соискателей проводили хоть раз собеседования или же интересовались ими совсем недавно (чтобы облегчить жизнь самому). Однако с другой стороны стола сидит человек (не всегда, однако очень часто), который пришел на встречу в середине рабочего дня, в его голове всё еще крутится проект. Отсюда и получаем, что на одни и те же вопросы и ответы, соискатель и работодатель смотрят по-разному.
Как я уже сказал выше, вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода, в ином случае вы просто будете проводить собеседования крайне неэффективно, будете попадаться на стандартные ловушки и манипуляции. И в итоге наймете совсем не того, кто вам нужен. Однако корпоративная этика всё-таки заставит вас рапортовать, что "всё сделано правильно, команда стала больше, теперь точно всё успеем".
Я нашёл как минимум три стандартные темы, которые помешают нам нанять грамотного человека. Всех их объединяет одно — если следовать совету из тезиса, вы сами четко поймете, почему они только сбивают вас при разговоре с будущим членом вашей команды. Однако важно помнить, что у тезиса есть и обратная сторона: если вы знаете, что плохо проводите интервью, однако абсолютно не хотите ничего улучшать, вы не хотите нанимать грамотных людей — вы найдете сотни причин того, почему вам не стоит тратить время на своё хождение по собеседованиям.
Все темы являются компиляцией интервью на должность программиста (в том числе своих и по рассказам обеих сторон).
Глупая тема #1 — разговоры о философии
Итак, вы пришли наниматься в компанию. Вы хороший пахарь в своей области, у вас есть опыт работы. Вы не сверхгений, не нобелевский лауреат. Вы обыкновенный высококвалифицированный специалист.
С другой стороны сидит team leader (или начальник проекта, или менеджер среднего звена, который может быть когда-то даже программировал). У него горит проект, он вообще не знает, кто тут пришёл с ним говорить. Единственное, что он помнит — "ну вроде программист, ну вроде работал с .Net Core". И после этого задается вопрос: "А расскажите о принципах SOLID?".
Вопрос о подобной теме кажется очень красивым. Он должен подчеркивать опыт соискателя, он должен показывать разницу между зеленым новичком и бывалым воякой. Есть только одно но — ответ на этот вопрос не показывает абсолютно ничего. Если человек сходу расшифрует все пять букв, то это означает лишь то, что он недавно прочел статью об этом. Причем недавно — это в пределах пары недель. Более того, если человек вообще не вспомнит, что обозначают буквы, то это всё так же ничего не означает. Вы ведь берете на работу инженера, не философа, не ученого, а инженера. Он будет писать код, исправлять ваши же баги, а не рассуждать о высоком. Он будет разбираться с тем, почему Oracle сделала так странно интерфейс, а не с тем, почему программа "не канонична, ибо не соответствует формальным 200 правилам".
Однако если вы услышали подобный вопрос на собеседовании, то есть несколько вариантов, кто перед нами. Наиболее вероятные — или менеджер среднего звена, который иногда смотрит код. Или же практикующий инженер, который просто решил начать диалог с хоть какого-то вопроса. А потому правильный ответ соискателя будет содержать еще и свой вопрос: "Раз уж мы заговорили о принципах SOLID — а как вы бы сделали сервис авторизации полностью по этим принципам? Мы с Вами знаем, что сервис должен отвечать за уйму важных вещей, однако давайте он будет делать только три вещи: проверять логин/пароль, выдавать токен, а заодно и проверять этот самый token".
Вопрос выше хорош тем, что вы быстро (и с большой долей вероятности) поймете, с кем имеете дело.
- Технический специалист быстро даст заднюю передачу и признается, что всё это философия, она нужна чтобы начать разговор, однако всё это неважно. И вы продолжите общение.
- Менеджер среднего звена ответит на философский вопрос что-то в стиле "необходимо использовать неблокирующую очередь и IoC контейнер, использующий свой Class Loader" (я намеренно преувеличил ответ, чтобы была понятна суть). Это звучит для не-программистов очень умно, а значит даже похоже на небрежный такой ответ, из которого любой поймет дальнейшее решение. Однако мы говорим о роли разработчика ПО, потому вы сразу догадаетесь, что на другом конце стола — не технический специалист, а потому вы сможете выбирать ответы так, чтобы именно понравиться ему.
Небольшая ремарка — как вести диалог с не-специалистом, который считает, что он специалист
Чаще всего такой человек вырастает из программиста, однако последний раз он делал сам что-то серьезное лет пять назад. Однако наш партнер всё равно считает, что он в тренде, а потому с гордостью говорит о технических подробностях. На это и будет давить.
Если сказать разработчику баз данных, что Oracle/MS SQl сами умные, а потому им не требуется отдельный тюнинг, то специалист сразу отправит вас домой. А заодно разозлится, приведет кучу аргументов и примеров из жизни, когда это не так. Однако, когда мы говорим с менеджером, мы запросто можем выдать фразу вида "в разработке баз данных есть самое главное правило — все запросы должны быть простыми. Любой тюнинг и ускорение запросов (то есть добавление hint-ов) затратит время работы команды, усложнит решения, а выхлоп будет минимальный". Подобная фраза будет как бальзам на душу человеку, который не знаком с базами данных на практике, однако знает теорию и философию. А еще его достали объяснения коллег, почему нельзя сделать задачу быстро, так, как он предполагал в своих обещаниях начальству.
Есть и другая схема давления на философа-менеджера (который пытается казаться и технически грамотным, это очень важно). Зачастую они живут технологиями своей бурной молодости разработчика, а потому полезно будет сказать, что вы противник внедрения самых последних, еще не проверенных временем решений. Поставьте себя на место управленца — он привык к C-подобному синтаксису, а народ собирается кодить на Kotlin/Swift/Scala. И тут приходит человек, который полностью готов (и всеми руками за) использовать старые, понятные менеджеру, технологии, где наш любимый управленец всегда сможет подсказать. Ну как тут можно устоять?
Disclaimer
Советы выше полезны только для манипуляции менеджером, который плохо умеет управлять, а потому часто лезет с техническими советами (а не с помощью). Подобные рекомендации никак не помогут (и навредят) при разговорах с:
- Грамотными управленцами. Они просто пропустят технические фразы. Им важно, чтобы работало стабильно и предсказуемо, чтобы в решении было много полезного и удобного функционала. Они хорошие и умные, манипуляцию они почуют сразу.
- Начальниками проекта, которые сами не забывают программировать (а не просто иногда смотрят код). Эти люди быстро выведут вас на чистую воду.
Вывод о философских рассуждениях
Не задавайте вопросы о философии. Вы только себя подставите, да и заодно заставите соискателя лишний раз волноваться и ошибаться. В реальности вам абсолютно не важно, как сотрудники теоретизируют о программах.
Однако к разговорам о философии не относятся следующие темы:
- Идеи того, как и почему базовые структуры устроены тем или иным образом. Это просто вопросы о дискретной математике, практически каждый опытный сотрудник видел неправильное применение структур (хоть и редко).
- Как можно улучшить класс XXX. Это вполне практический вопрос, да вы и сами часто отвечаете на него, глядя в код.
Глупая тема #2 — разговоры, не относящиеся к работе
Клише — о преданности делу
Очень важная ремарка: чтобы стать токсичными, все эти вопросы ну никак не должны относиться к хотя бы половине сотрудников. Или по-другому: сами сотрудники могут ответить на них "неправильно", и это будет считаться абсолютно нормальным.
Клише старое, однако используется: а кем вы видите себя в нашей компании через пять лет? Более того, чаще всего такой вопрос задают или те, которые в компании всего пару лет, или те, которые сидят на одном и том же месте в компании лет 15.
Однако вопросы выше мутировали. Например, один из трендов 2018 года: Если у вас есть год свободного времени, вам платят зарплату и так далее. Вопрос: а чем вы будете заниматься? Я, к сожалению, не знаю ответ на этот вопрос, который удовлетворил бы хотя бы 80% работодателей. Этот вопрос только вредит собеседованию, так как:
- Соискатель сразу видит перед собой идиота, у которого закончились вопросы по делу, однако крайне не хочется возвращаться к работе. В голове у работодателя может быть совершенно иное, однако именно так он выглядит со стороны — идиот.
- На этот вопрос никогда не дадут правдивый и искренний ответ. Просто потому что все хотят казаться в глазах других людей человеком, который не бросит в беде, Матерью Терезой современности. Так не принято делать, однако очень хочется казаться. А потому соискатель с большой долей вероятности преувеличит практически всё, что только можно.
- На этот вопрос уже есть абсолютно искренний, верифицируемый и известный ответ. У 40-летнего программиста было порядка 20 лет работы за свою жизнь, то есть около 20 месяцев отпуска, 2 000 выходных. Плюс еще есть немало вечеров, праздников и т.д. Получаем важное следствие — всё то, что человек мог сделать за теоретический год, он уже сделал за свою жизнь. Более того — в резюме и так описаны самые вкусные подробности, все Open Source проекты, все достижения. Всё уже есть.
- И самая главная причина того, что вопрос вредный: нам не нравится правда о сотруднике, мы просим его лгать и фантазировать, чтобы убедить самих себя, что он нужен.
Разговоры о полезности свободного времени
Еще один пример того, как запутать самих себя на собеседовании. Это вопросы в стиле: "а как вы проводите свободное время?" И опять эта фраза кажется ну очень умной, хотя и является вредной по факту.
В чем же минус этого вопроса? Ведь мы просим человека еще рассказать о том, какой он умный и хороший, как легко он освоит новые знания (всё то, что выделено курсивом — обман и лукавство). Однако по факту:
- Если человек серьезно работает по 10-12 часов, он зачастую изучает достаточно на самой работе. Он смотрит презентации коллег, он читает профильные статьи, он анализирует многое из того, что непосредственно связано с его работой. В итоге, если человек действительно профессионал, то он не сможет честно и красиво ответить про свободное время.
- Если же наш соискатель тонкий манипулятор, то он мигом сможет понять, что его уже практически взяли, раз задают подобные вопросы. Ну разве стал бы работодатель задавать вопросы не о профессии, если уже решил не брать собеседника? А потому грамотный переговорщик ответит что-то в духе: "Мы говорили о технологиях .Net на Windows. Я дома сейчас читаю статьи о .Net Core на Linux (ну или на Mac, можно на iOS/Android, главное — чтобы тема была смежная, а не совпадала). Я считаю, что это будущее отрасли, а потому стараюсь тщательнее относится к новым решениям, потому что нам скоро с ними работать". Я неоднократно слышал такой ответ, однако всякий раз соискатель быстро уходил с технического описания на теорию. Однако шаблон ответа по своему прост и гениален. Ведь новый сотрудник делает пассаж в сторону технологии, с которой имеет дело собеседник. Потому он приводит парочку правдивых (хоть и общеизвестных) фактов. И в завершении переводит тему туда, где можно лукавить и откровенно врать, так как проверить работодателю будет сложно (он-то сам вряд ли это изучал).
- И самое важное следствие: как бы не ответил соискатель, всё это не важно. Вы сами можете проверить в компании, что ответ про свободное время никак не будет коррелировать с качеством работы.
Вывод о разговорах, не относящихся к работе
Не задавайте таких вопросов. Все компании более менее одинаковые, нет смысла просить кандидата признаться в преданности. Нет смысла спрашивать то, что даже проверить сложно — вы просто возьмете лгуна, а выгоните честного работягу.
Не задавайте вопросов, на которые даже члены вашей команды ответят неправильно.
Глупая тема #3 — разговор о редко встречающихся проблемах
Клише — я недавно узнал, давайте поговорим об этом
Пример токсичного вопроса: "Мы делаем сервисы на Java, недавно мы обновились на Spring Boot 2 и заметили интересную особенность сериализации XML — в ряде случаев сервер не может обработать XML сообщение. Вам приходилось с таким сталкиваться?"
Что ожидает услышать работодатель: новый класс Jaxb2XmlDecoder не переопределяет метод decodeToMono, который объявлен в AbstractDecoder (как вы понимаете, Jaxb2XmlDecoder наследует AbstractDecoder). Реализация decodeToMono по умолчанию — бросок исключения, что приводит к тому, что нельзя ни принять XML, ни отправить.
Тезис статьи — вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода. Как соискатель, вы уже видите жесткую проблему в этом вопросе. А как собеседующий — не факт.
Итак, чем же этот вопрос плох:
- Мы спрашиваем об очень частной вещи. Ошибка ведь не проявляется в JSON сериализации, то есть если у соискателя в проекте использовался JSON, то он просто не мог узнать о такой подставе.
- Мы спрашиваем об очень свежей вещи. Ведь Spring Boot 2 не так давно и вышел, а потому соискатель запросто мог работать в проекте, где еще не начали обновление.
- Решив эту задачу, мы сами забудем про это. Однако нам так понравилось найденное решение (или сам факт нахождения), что оно прямо зудит в мозгах, а заодно и требует рассмотрения на собеседовании.
- Самое важное следствие: скорее всего через год мы сами не сможем ответить на этот вопрос. А значит, задавая его, мы с высокой долей вероятности просто выгоним грамотного разработчика
Клише — хоть у нас этого не происходит, но давайте поговорим
Пример токсичного вопроса: "Хоть у нас и нет больших объемов данных, однако как бы вы хранили 100 Пб данных, с возможностью быстрого доступа к ним?"
Я слышал такие вопросы и от коллег, с которыми я собеседовал, и от потенциальных работодателей. Во всех случаях я задавал себе вопрос: "ну зачем это спрашивать? У нас нет таких задач, мы не профессионалы в этой области. Да и соискатель пришёл к нам с другими навыками. Ну зачем спрашивать то, что мы даже приблизительно не сможем проверить?".
Этот вопрос очень перекликается с философским, однако выглядит вполне конкретным, реалистичным, а главное — говорит о масштабах компании.
И он тоже очень и очень проблемный, так как:
- Мы не сможем проверить ответ человека. Это как с философией о правильном ПО — человек ответит, однако это не даст нам никаких данных о том, что он реально может сделать.
- Задача поставлена очень абстрактно. Не сказан ни размер объектов, ни частота записи, нет требований даже о надежности системы. Тут грамотный специалист может просто отмахнуться ответом вида "возьму одно из эффективных распределенных систем хранения". Или он может испугаться своего незнания, а потому даст сбивчивый непонятный ответ.
- Зачастую на такой вопрос даже ваши коллеги не смогут дать четкого и правильного ответа (и это не плохо, это нормально; окулист может просто не знать, какими препаратами лечат редкую форму рака).
- Мы приходим с тому же следствию: этот вопрос лишь увеличит погрешность в оценке кандидата. Этим вопросом мы узнаем не то, насколько человек поможет нашей команде, а то, насколько хорошо человек решит задачу другого отдела (или же другой фирмы)
Вывод о попытках фантазировать про редкие проблемы
Не говорите о задачах, которые вы не решаете. Вы опять возьмете не того, кто вам поможет, а того, кто будет фантазировать, как помочь другим.
Общий вывод о глупых вопросах
Как вы уже увидели — есть множество глупейших вопросов, которые только мешают собеседованию. Они даже не нейтральные — они именно вредные. Однако, понять то, что вопрос токсичный, бывает очень сложно. И есть простое и понятное решение: вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода.
Ведь это простое, понятное и верифицируемое правило, которое избавит нас:
- От глупых и ненужных вопросов кандидату
- От громадного эго, налета гениальности и собственной переоцененности
А заодно вы пообщаетесь с умными людьми, плюс найдете вопросы, которые таки стоило бы задать.
Комментарии (74)
m03r
22.04.2018 23:18+1У меня сложилось впечатление, что автор не разделяет методику проведения интервью, и круг выясняемых на нём компетенций. Знания и умения, разумеется, меняются от вакансии к вакансии, от отрасли к отрасли, от года к году с появлением новых технологий. Но методика — то есть умение так задавать вопросы, чтобы получить как можно более точное представление о компетенциях соискателя — практически не меняется.
Все «глупые темы», перечисленные в статье, представляют собой методические ошибки — темы, которые ничего не скажут о соискателе вне зависимости от вакансии, отрасли ни в 2008 году, ни в 2018. При этом в статье утверждается, что методика интервьюирования магическим образом выправляется (на полгода) посещением трёх собеседований в качестве соискателя.
Очень, очень грубая аналогия:
«Вам не следует выступать на концертах, если вы за последние полгода не посетили три концерта в качестве слушателя». Конечно, посещая концерты, можно кое-чему научиться. Но для выступления гораздо важнее уметь играть (или петь), чем слушать больше или меньше музыки.
imanushin
23.04.2018 02:10-1Очень, очень грубая аналогия:
В концертах вы видите обратную связь сразу же. А после интервью вы увидите результат через несколько месяцев. Потому аналогия не совсем корректна.
представляют собой методические ошибки
Да, всё верно. И эти ошибки даже можно попытаться исправить, если вы не будете с другой стороны баррикад. Однако их увидеть намного легче, если воспользоваться идеей выше.
lair
23.04.2018 11:25+2Заметим в скобках, что вот как раз для выступающих ваша аналогия неверна. Музыкант должен слушать не меньше музыки, чем он производит сам (а, на самом деле, больше), иначе он (практически всегда) вырождается.
Roman_Kh
23.04.2018 11:36+2Концертирующий музыкант порой за 1 день прослушивает 3 концерта, причем не только для своего инструмента. Таким образом, узнают не только о том, ЧТО играют другие, но и, самое главное, КАК играют.
JC_IIB
23.04.2018 00:15+1У 40-летнего программиста было порядка 20 лет работы за свою жизнь, то есть около 20 месяцев отпуска, 2 000 выходных. Плюс еще есть немало вечеров, праздников и т.д. Получаем важное следствие — всё то, что человек мог сделать за теоретический год, он уже сделал за свою жизнь.
Это были его отпуска и выходные, которые он проводил с семьей и друзьями, чтобы отдохнуть от написания кода. А вот если у него появится оплачиваемый год — он вполне может продолжить тратить выходные на семью, а освободившиеся рабочие дни — на организацию собственного бизнеса, например.
Статья очень спорная, к тому же переполненная жирным шрифтом. Субъективное мнение подается как факт.roscomtheend
23.04.2018 11:47-2На хабре есть мнение что отпуска и выходные программист должен проводить изучая фреймворки и участвуя в опенсорс, семья и хобби для непрофессионалов.
aknew
23.04.2018 12:05Даже если это было бы правдой, очень сомневаюсь что месяц участия в опенсурсе по выходным (итого 8 дней) выйдет таким же продуктивным как 5 будней подряд. А на более мелких отрезках (по часу после работы) все еще хуже.
imanushin
24.04.2018 10:06Это были его отпуска и выходные, которые он проводил с семьей и друзьями, чтобы отдохнуть от написания кода. А вот если у него появится оплачиваемый год — он вполне может продолжить тратить выходные на семью, а освободившиеся рабочие дни — на организацию собственного бизнеса, например.
Вы полностью правы. Я и говорю, что этот вопрос — абсолютно некорректен, так как не несет никакого смысла. Мы услышим всегда фантазию. А правда в том, что:
- Из ваших коллег часть делает Open Source или стартапы, а часть — нет
- Корреляции между пользой компании и занятиями программированием в свободное время нет (а точнее — она ниже погрешности оценки)
- >>> тут вывод, однако я не выделю его жирным шрифтом >>> Стоит ли задавать такой вопрос, если на него ответит неправильно даже часть ваших успешных коллег?
TheShock
23.04.2018 01:36+1Более того — в резюме и так описаны самые вкусные подробности, все Open Source проекты, все достижения. Всё уже есть.
Резюме — это краткий список ненужной информации. Почему? Потому что любой пункт вполне может оказаться ложью?
Написано «Senior JS Developer» — просто на фирме, на которой он работал был только он и им было все-равно, как его должность называется. Корочку дать — не деньги платить. А чувак просто примеры на jQuery со СтекОверфлоу копировал.
Написано «Знаю паттерны проектирования» — ну да, когда-то читал статью про синглтон.
Написано «занимался highload проектами» — «я не занимался, просто все так пишут, вот и я написал».
Это все реальные примеры с собеседований. Конечно, большинство людей пишут в основном правду в резюме, но пока не поговоришь лично — не поймешь.
k0nst
23.04.2018 11:47Так а что делать то? Автор рамышляет как этот процесс улучшить и как реагировать в «типовых» ситуациях. Предложите вариант как все же определить кто перед вами, если смотреть с обеих сторон: соискателя и того, кто проводит собеседование? Предложить что-то написать «по-быстрому»? Не каждый просто с точки зрения обстановки может на ходу что-то сбацать. Серьезные спецы вообще могу ухмельнуться, встать и уйти. Вопрос остается открытый
ohmytribe
23.04.2018 15:15Просто пообщайтесь с человеком, поймите, комфортно ли вам будет с ним работать, говорит ли он какие-то адекватные вещи, говорит ли он о том, что он делал в прошлом или о том, чем может помочь именно вам.
Имхо, самая большая проблема, что проекты ищут людей на должности, не людей для решения определённых задач/проблем.
Пример 1 (отрицательный): «Мы ищем программиста высокого уровня. Вы знаете, что такое SOLID?»
Пример 2 (положительный): «Мы заметили, что у нас есть определённые проблемы с быстрой реализацией MVP фич, кроме того, мы хотели бы реализовать полнотекстовый поиск.»
Если человек способен решить ваши текущие проблемы/задачи, то, в абсолютном большинстве случаев, он будет способен решать и проблемы/задачи в будущем.
Собеседование — это беседа двух людей и их попытка выяснить, будет ли им интересно работать вместе и получать ли они пользу от этой работы. Мне кажется, какой-то план собеседования работает только в случае, если у вас конвейер и команда из 30 программистов. Если у вас, скажем, 5 программистов на команду, то каждый член команды может прикрывать определённую область. Кто-то быстрый и энергичный, кто-то медленный и дотошный, кто-то хорошо умеет разбираться с запутанными багами и т.п. Поэтому ищете вы чаще всего не столько компетенцию, сколько компетенцию, психологические особенности и т.п.Areso
24.04.2018 13:24У меня как-то было с одним человеком парное программирование: я писал фичи, а он их за мной переписывал. Так и работали, lol.
lair
23.04.2018 01:38+1И где же тогда найти людей, которые будут проводить собеседования? И как сделать так, чтобы люди, которым с собеседуемым взаимодействовать (например, потенциальный начальник), таки смогли проводить собеседования?
dmsav
23.04.2018 08:23+1Мне кажется, главное на собеседовании, чтобы соискатель не чувствовал дискомфорт, и после собеседования не почувствовал себя говном. Некоторые, особенно технические специалисты-руководители среднего звена очень любят задавать тупые вопросы на уровне детского сада, и ты не знаешь как им ответить тактично. Ещё есть те, кто любят на собеседовании давить морально вопросами, чтобы показать, что он может себе это позволить.
А так, если вопросы уместны, но они могут быть любыми. Например, вопрос о том, как соискатель проводит личное время, может быть увязан с хобби. А про вопросы типа «каким вы видите себя через год» актуальны, если он хочет остаться в компании, которая ему нравится.
Dr_XaoS
23.04.2018 08:28+1правильный ответ соискателя
…
выбирать ответы так, чтобы именно понравиться ему
…
схема давления
…
для манипуляции менеджером
…
никогда не дадут правдивый и искренний ответ
и т.д.
вам точно не стоит заниматься подбором персонала, если вы считаете, что все вокруг пытаются вас обмануть. Это приведет только к тому, что в вашей компании соберутся люди, которые обожают хитрить и манипулировать.
Да, не многие люди могут общаться честно и открыто на собеседовании, особенно походив по другим компаниям, у которых на входе с ними «играют в покер», но оно того стоит.Fid
23.04.2018 11:47Как раз ему стоит т.к. он понимает что не надо задавать эту хрень про «кем вы видете себя через 5 лет».
Dr_XaoS
23.04.2018 12:51Если вы про автора статьи, то я не в курсе, стоит ему или нет, потому что лично не знаком и не склонен делать далеко идущие выводы.
А насчет вопроса про 5 лет, все зависит от контекста. Иногда вопрос сам напрашивается из размышлений кандидата, иногда кандидаты спрашивают то же самое про компанию, и мы отвечаем :)
imanushin
24.04.2018 10:09Это приведет только к тому, что в вашей компании соберутся люди, которые обожают хитрить и манипулировать.
Если вы по-умолчанию считаете, что вам говорят правду, то это не значит, что вас не обманут.
Dr_XaoS
24.04.2018 10:23Конечно. Я считаю, что вообще не стоит заранее решать, будет ли кандидат говорить правду или нет (это позволяет избежать эффекта якоря). Вместо этого лучше выстраивать процесс найма так, чтобы люди могли проявить себя с разных сторон.
imanushin
24.04.2018 10:35лучше выстраивать процесс найма так, чтобы люди могли проявить себя с разных сторон
Ну это понятно, так все говорят. Мир во всем мире и всё такое.
Если не сложно — а можно пример того, когда вы задаете вопрос:
- На который человек может солгать (и вы это не проверите, а также не проверяете прямо или косвенно)
- Однако сам ответ вы должны учитывать
Dr_XaoS
24.04.2018 11:50На самом деле сложно, потому что ответы на те вопросы, которые нас касаются, мы в конечном итоге узнаем, а те, которые нас не касаются, мы не задаем. К тому же каждый вопрос можно дополнительно обсудить, как минимум спросить почему такой ответ (в этом плане все тестирования и анкетирования кандидатов очень сильно проигрывают).
Из практики был случай, когда на первой встрече на вопрос о достаточной зп на испытательный срок кандидат назвал очень скромную сумму. Через пару дней предложили ему оплачиваемое тестовое задание с почасовой оплатой на основе той суммы, и оказалось что на такое он не готов. В плане отбора персонала это было даже хорошо — удалось увидеть, как кандидат ведет себя в конфликтной ситуации.
Из подобных соображений я задаю иногда глупые вопросы или даю задачки на написание кода на листочке. В них не важен ответ. Главное — увидеть взаимодействие человека с задачей и с другими людьми вокруг этой задачи. Очень помогает понять, сходятся принципы работы нашей компании с кандидатом или нет.roscomtheend
25.04.2018 09:30Тоже задания на листочке давал. Результат, конечно, важен, но если человек не помнит название функции сортировки или порядок параметров — да и фиг с ним, есть справка, важнее как он подойдёт к решению простой задачи. Простой, чтобы пяток можно было уместить в полчаса, задачи близкие к области — нет смысла спрашивать про обход графа или к-ч деревья у того, кто будет делать SQL-запросы, а делать джойн из не скольких таблиц тому, кто будет писать прошивки МК. Будет плюсом, но это не обязательное требование.
reinvent
25.04.2018 14:38Если вы по умолчанию подозреваете человека в обмане, он не обманет ваши ожидания.
TheShock
25.04.2018 14:46Это заявление не имеет логического обоснования.
Neikist
25.04.2018 15:00На самом деле подвести логическое обоснование под нее можно, другое дело что оно будет оперировать вероятностями, личным опытом, личными представлениями о психологии и подобным. Но в каких то случаях может оказаться верным.
TheShock
25.04.2018 15:05Ну ведь там нету слова иногда: «он иногда не обманет ваши ожидания»
reinvent
25.04.2018 15:15Еще пример
Жан Франсуа Зобрис часто цитирует похожие дискуссии с работниками и новыми сотрудниками FAVI, чтобы объяснить им причины перехода на самоуправление. Однажды он решил записать оба набора установок, чтобы использовать формулировки для обучения новых сотрудников.
«Анализ нашей организационной структуры в 1980 х гг. [когда FAVI управлялось, как любой другой завод] показал, что составившие ее исходили из того, что сотрудники и сотрудницы:
• воры, поскольку все нужное было заперто на складах;
• лентяи, поскольку их рабочее время контролировалось и за каждое опоздание назначал наказание кто то… кто даже не давал себе труда выяснить причины опоздания;
• ненадежны, поскольку вся выпущенная ими продукция контролировалась кем то еще, кто, однако, тоже был не слишком надежен, поскольку время от времени… назначались и выборочные проверки;
• неумны, поскольку думал за них инженерно технический отдел».
Зобрис с коллегами сформулировали три новых подхода, которые вскоре стали на предприятии чем то вроде мантр.
• Мы считаем каждого человека хорошим.
(Надежным, целеустремленным, достойным доверия, умным.)
• Там, где нет счастья, нет и эффективности.
(Чтобы быть счастливыми, нужна мотивация. Чтобы иметь мотивацию, надо уметь нести ответственность. Чтобы нести ответственность, надо понимать, почему и для кого мы работаем, и обладать свободой, чтобы решить, как нам работать.)
• Самое ценное создается в цеху.
(Рабочие у станков производят продукцию. CEO и сотрудники центрального офиса в лучшем случае помогают им в этом, в худшем становятся дорогостоящими помехами{47}.)
Neikist
25.04.2018 15:18Хоть я обычно на противоположной стороне, но выскажу такое мнение (повторюсь, не мое): в комментариях к подобного рода статьям не все и не всегда руководствуются только формальной логикой при чтении комментариев и статей. Довольно много подразумевается «между строк», квантор всеобщности не абсолютен, и т.д. и т.п.
reinvent
25.04.2018 15:14Да, не имеет. И тем не менее, работает.
Когда AES приобретает новую электростанцию, Деннис Бакке часто начинает объяснение сути нового подхода к управлению с того, что интересуется, какими владельцы и менеджеры типичного предприятия предположительно видят работников. Согласно его данным, рабочие следующим образом описывают, что, по их предположению, думает руководство.
• Работники ленивы. Если за ними не следить, они не будут прилежными и старательными.
• Работники работают прежде всего ради денег. Они делают то, что нужно, чтобы заработать как можно больше.
• Работники ставят свои интересы выше интересов организации. Они эгоисты.
• Работники показывают наилучшую производительность и эффективность, когда им надо просто выполнять повторяющиеся несложные задания.
• Работники не способны принимать правильные решения по важным вопросам, затрагивающим экономические показатели компании. Такие решения способны принимать только боссы.
• Работники не хотят нести ответственность за свои действия или за решения, влияющие на эффективность организации.
• Работники нуждаются в присмотре и защите, как дети в присмотре и защите родителей.
• Работников надо держать на почасовой оплате или оплачивать определенное количество произведенных образцов продукции. Боссы должны получать стабильную зарплату и, возможно, бонусы и опционы.
• Работники – взаимозаменяемые части машины. Один хороший работник похож на другого хорошего работника.
• Работникам надо говорить, что делать, когда делать и как делать. Они должны чувствовать свою ответственность перед боссами{45}.
Эти установки, если их выразить буквально, звучат очень грубо. Однако именно они лежат в основе структур и методов работы современных организаций. Если такие взгляды на сотрудников верны, то использование системы контроля, наказаний и поощрений со стороны лидеров вполне разумно. Только дурак доверит сотрудникам принимать решения, используя внутреннее консультирование.
Поскольку упомянутые выше установки часто существуют неявно или даже не осознаются, Бакке счел необходимым выразить их открыто, а затем выдвинул совершенно иной набор предпосылок.
Сотрудники AES
• Творческие, думающие, достойные доверия взрослые люди, способные принимать серьезные решения;
• отдают себе и другим отчет и несут ответственность за принятые ими решения и действия;
• совершают ошибки, как и все мы совершаем ошибки, иногда намеренно;
• уникальны; и, самое главное,
• хотят использовать свои умения и таланты, чтобы внести полезный вклад в деятельность своей организации и помочь миру в целом{46}.
С таким набором установок самоуправление и внутреннее консультирование обретают смысл, а контрольные механизмы и традиционная иерархия становятся не нужны, поскольку деморализуют и отвлекают от работы.
TheShock
25.04.2018 15:23Ваш пример о другом.
Работники ленивы
Это категоричное заявление.
А про человека, который приходит на собеседование заявление не «этот человек врет», а «этот человек может врать». То есть вы впадаете в крайности.
А все эти вещи рассказывает своим сотрудникам почти любой менеджер любой компании. И правда, в большинстве компаний изначально стараются строить на доверии. Но на 10 честных человек найдется 11-й, который будет воровать тонер из из-за которого приходится запирать кладовку.
В IT фирмах это не так выражено (у нас 50 человек в офисе и кладовка открыта) и такую атмосферу доверия создает как-раз фильтр с подозрением во время собеседования.reinvent
25.04.2018 15:28Но на 10 честных человек найдется 11-й, который будет воровать тонер из из-за которого приходится запирать кладовку.
Таким образом все 11 попадают в разряд подозреваемых.
Доверие к сотрудникам в FAVI простирается гораздо дальше продолжительности рабочего времени и норм выработки. Ключи от машин компании свободно висят на стойке у секретаря. Любой рабочий может выйти из цеха, взять машину и отправиться к поставщику или клиенту, никакого специального разрешения не требуется (однако существует обычай оповещать о поездке коллег, вдруг кто то захочет присоединиться). Раньше на заводе был склад, и кладовщик выдавал инструменты и расходные материалы только по письменному запросу начальника смены. Выходя куда либо, кладовщик склад запирал. Сейчас склад всегда открыт, и каждый рабочий может взять, что нужно. Ему только надо сделать запись в журнале для заказов. Однажды со склада была украдена дрель. Зобрис повесил на складе объявление: «Украдена дрель. Вы знаете, что, в принципе, мы увольням даже за украденную туалетную бумагу. Поэтому красть дрель было очень глупо. Особенно если учесть, что никому и никогда не запрещали взять инструмент на вечер или на выходные». Этого оказалось достаточно: краж больше не было. Опыт показывает, что подобное злоупотребление доверием в FAVI случается исключительно редко, как, впрочем, и в других организациях, выбравших путь самоуправления.
retran
23.04.2018 10:16-1Технический специалист быстро даст заднюю передачу и признается, что всё это философия, она нужна чтобы начать разговор, однако всё это неважно. И вы продолжите общение.
Пожалуй, дальше можно не читать.
Alesh
23.04.2018 10:30Очень интересная статья, много адекватных советов и утверждений.
Не согласен только с основной мыслью) про «вам не следует проводить собеседования, если вы не ходили хотя бы на три ...». Если речь идем о менеджере, то возможно это и правильно, а если о техническом специалисте, то у меня есть масса доводов против. Ну как минимум, что один раз он может уйти на такое собеседование и не вернуться))ganqqwerty
24.04.2018 17:49ну тут мы сталкиваемся с тем, что вы должны работать в здоровой компании. Если бабла платят адекватно, на работе сплошь друзья и хорошая атмосфера, а тимлид и все над ним нормально исполняют свои функции — то можно ходить на сколько угодно собеседований и все равно не хотеть сменить место работы.
Alesh
25.04.2018 13:50Иногда люди выбирают новое место не потому что тимлид плохой и атмосфера нездоровая. Иногда уходят даже на меньшее бабло, но рядом с домом например. Иногда тупо обещают золотые горы, лишь бы сманить, и чел уходит, и часто жалеет потом. Понятно что рыба ищет, где глубже… Но если походы по собеседованиям вводятся как обязаловка, то вариант что рыба уплывет возрастает на порядок. Я уже не говорю, что технического специалиста берут на работу в основном не, что бы он хантил.
Ruins
23.04.2018 11:47Если у вас есть год свободного времени, вам платят зарплату и так далее. Вопрос: а чем вы будете заниматься?
— сделаю минет своему работодателю. Думаю подобный ответ не только удовлетворит маразм большинства работодателей, но и увеличит шанс на отпуск.
Viktor_Ilukhin
23.04.2018 11:48Главное перед собеседованием понимать:
1) хочешь ли ты работать в этой компании;
2) сколько ты готов работать в этой компании за оговоренный оклад;
3) нравится ли тебе люди, с которыми ты общаешься на собеседовании — с ними тебе придется работать.
А тупые вопросы, кто перед тобой, что он спрашивает — это все вторично. Главное самим понимать — с этим человеком вам придется работать. И это относится как к тому кто проводит собеседование, так и к тому кто его проходит.
На моей практике собеседования проводили те у кого было свободное время, т.к. при том темпе, который был, этого времени не было даже на собеседования.
В этом случае хорошо помогало изначальное понимание того, кто нужен на данную позицию. И отсюда уже вытекали идущие вопросы к соискателю.
ohmytribe
23.04.2018 15:01Я писал пост о собеседованиях сюда лет 6 назад. Сейчас пост удалил, т.к. мне он кажется откровенно глупым. А собеседования у меня теперь проходят в свободном стиле — рассказываю о компании, рассказываю, какие у нас есть проблемы, которые пытаемся новой позицией решить и т.п. Далее человек рассказывает о себе и уже в контексте наших проблем рассказывает о своём опыте и о своих «набросках» к решению этих проблем (это получается само собой, я даже не задаю этих вопросов).
И чем свободнее собеседование, тем меньше вероятность, что наймёшь кого-то, кто не впишется в команду. После собеседования просто даём небольшое тестовое задание для работы «на дому», это тестовое я разбираю всегда с кем-то, кого считаю более компетентным на данный момент (я уже пару лет не пишу код и компетенцию в этой сфере потерял). Если вдруг внутри команды такой компетенции нет (абсолютно новая должность, например), то не стыдно и компетентных друзей/товарищей попросить посмотреть.
А вот эти все каверзные вопросы — это для викторин, а не для _СО_беседований.
el_gato
23.04.2018 15:17-1Мне тут тем летом пришлось заниматься техническими собеседованиями на должность джуна на стандартный LAMP стек. Я до этого никогда таким не занимался, да и сам последний раз был на собеседовании 5 лет назад, но помню эту шнягу про нарушенный контракт equals в джаве и прочие убогие вещи, типа нарисуй fizz-bazz на коленке, решил не заниматься подобным, а сделал следующее.
соискатель получает ноут с текстовым документом на рабочем столе с именем/паролем и ссылкой на наш местечковый гитлаб. На ноуте уже установлено все что нужно GIT/PHP и т.д.
Короткие инструкции: склонировать репу, создать новую ветку, успешно запустить приложение, после чего закоммитить сделанные изменения и запушить ветку обратно. Вот и все. После этого я ради приличия задавал пару вопросов опционально, если к примеру на первом собеседовании у интервьюера он отвечал на вопрос «оцените свои знания MySQL по шкале от 1 до 10» — 10, а такие были, то какой нибудь каверзный вопрос по мускулу и т.д.
В общем после того как кандидат клонировал репу и запускал проект на встроенном пхпшном сервере, для того чтобы увидеть заветные слова «WELL DONE» ему нужно было:
• Добавить отсутствующую зависимость в composer.json
• Поправить автозагрузку локальных классов в том же композере
• Исправить пару функций чтобы не сыпались юнит тесты
• Написать самому пару тестов чтобы не проект не ругался на недостаточное покрытие тестами.
• Исправить логическую ошибку в запросе к бд чтобы возвращались корректные данные.
• Что-то еще было, но уже лень искать смотреть.
Вот и все, разрешалось гуглить, не разрешалась «помощь друга». По итогам взяли двух. Одного — который справился плохо, но был другом брата свата шефа, и еще одного, котрый вообще не был пхпшником, но, тем не менее, справился хорошо. Он сейчас показывает весьма хорошие результаты в работе.
stoune
23.04.2018 17:46Очередное подтверждение того что не все кто пишет не хабре имеют что сказать дельного. Полно спорных и даже глупых утверждений которые выдаются за истину в последней инстанции. И автор не сказал главного, а что же тогда спрашивать?
Единственное из полезного, да не стоит спрашивать о какой то специфической проблеме, но вопросы об организации большого хранилища данных это как раз хороший вопрос. Он открытый не имеет одного правильного ответа и хорошо показывает уровень понимание дизайна систем, если конечно кандидат претендует на должность Senior+.
Danik-ik
24.04.2018 08:33Очень много на Хабре комментариев, что автор выдаёт своё мнение за истину в последней инстанции. Может, Вы не так читаете? Автор выдаёт своё мнение. Просто выдаёт мнение. Вас смущает, что он не пишет "могу быть не прав"? Для меня, как читателя, это умолчание. Да, критическое отношение к написанному НЕ ТРЕБУЕТ ритуальных фраз от автора. И сразу никаких иллюзий о якобы "истине".
Читайте правильно, и бу вам ща.
Всё вышесказанное может оказаться неправдой
imanushin
24.04.2018 10:19И автор не сказал главного, а что же тогда спрашивать?
Вы же технически грамотный человек, а потому сразу поняли, что раз ответ не общеизвестен, то он как минимум сложный, а скорее всего правильного ответа вообще пока не нашли.
Идея доказательства: если у нас есть публичная методика идеального собеседования (прям со списком вопросов), то по сути мы сделали подсчет KPI для всех поступающих в компанию. Более того, если раз в год просить внешнюю компанию еще раз собеседовать наших сотрудников, то мы получили еще и внутренний KPI. А так как до сих пор компании еще не нашли эффективного способа подсчета KPI для разработчиков, то и исходное предположение (оно было — "у нас есть публичная методика идеального собеседования") ложно. Доказательство было "от противного" (точнее — идея доказательства).
В статье я показывал:
- Ряд вопросов, которые не стоит задавать на собеседованиях, так как они бессмысленные. И привел обоснование.
- Привел методику (очевидно, одну из) которая позволит собеседующему избежать как минимум вопросов из пункта "1", а вообще-то — позволит самому быстро понимать, что не следует задавать (или по-другому — повысить эффективность собеседований, убрав заведомо известные проблемы)
vsb
23.04.2018 20:53+1А как работодатели отнесутся к честным ответам? Терпеть не могу врать. «Если у вас есть год свободного времени, вам платят зарплату и так далее. Вопрос: а чем вы будете заниматься?» — «Скорее всего буду 50% времени играть в World of Warcraft, 40% времени сидеть на хабре, 9% времени читать технические или околотехнические статьи, 1% времени что-нибудь программировать для души (аддоны для World of Warcraft, ага).» «а как вы проводите свободное время?» — «Делаю работу по дому, гуляю, занимаюсь сексом, играю в World of Warcraft». «Кем вы видите себя в нашей фирме через 5 лет?» — «Через 5 лет я себя вижу в другой фирме». «Назовите свои недостатки» — «Лень, рассеянность, асоциальность, проблемы со здоровьем, патологический перфекционизм». Или это такай игра «ответь мне то, что я хочу услышать»?
imanushin
24.04.2018 10:21Вы правы, это именно игра в «ответь мне то, что я хочу услышать». И для эффективных собеседований от неё следует отказываться.
Я чуть детальнее описал в комментарии ниже — https://habrahabr.ru/post/354054/#comment_10771768
roscomtheend
25.04.2018 09:38Вы приняты. Особенно про «через 5 лет». Интересно, те люди, которые (на хабре в т.ч.) заявляют что «надо менять работу раз в 1-2-3-5 лет» когда их сотрудник заявляет что засиделся и хочет нового, как реагируют? «Мы его на помойке наши, воспитали, а он вам фигвамы рисует». Или даже со старта скажет «да я тут на пару лет, потом дальше» они его будут рассматривать (не на временный проект, а на многолетний)?
sshikov
23.04.2018 21:31>Поставьте себя на место управленца — он привык к C-подобному синтаксису, а народ собирается кодить на Kotlin/Swift/Scala
А давно ли у котлина не C-подобный синтаксис? А многие пожалуй согласятся, что и у Swift/Scala он по большому счету такой же. Уж точно все эти языки — не лисп.imanushin
24.04.2018 09:55на место управленца
Мы же не про инженера говорим, и не про практикующего тимлида. Они-то разберутся. Мы говорим про человека, который давно не кодил, но хочет думать, что он в тренде.
Сравните программы (Java vs Kotlin):
public int conditionalSum(int a, int b) { if(a > b) return a + b; return a; }
fun conditionalSum(a: Int, b: Int) = if(a > b) { a + b } else { a }sshikov
24.04.2018 20:30И что я должен был тут увидеть? Это ровно то, что называют С-подобным синтаксисом. А другой синтаксис — это например все паскали/Ада/PL/SQL и им подобные, где вместо скобок ключевые слова. И в этом смысле котлин ничем не отличается от Java.
Arris
23.04.2018 21:37Если у вас есть год свободного времени, вам платят зарплату и так далее. Вопрос: а чем вы будете заниматься?
Ну, никто же не говорит, что я должен за это протирать штаны в офисе.
Я бы ответил честно, но непрактично: поеду в кругосветное путешествие. За год управлюсь.
Как вы проводите свободное время?
«Отдыхаю.»
Самый честный и правильный ответ.
Заставляю тело и разум отдыхать от работы, которую делаю в рабочее время.
P.S. К сожалению, дать такой ответ легко, а вот заставить себя отдыхать — трудно. Не все это умеют правильно.imanushin
24.04.2018 09:50Вы полностью правы. И ваш ответ полностью правильный (для меня), к тому же он правдивый.
Суть неправильности вопроса в том, что зачастую даже ваши коллеги ответят сильно по-разному. А потому, если есть правильные и неправильные ответы, то какой смысл задавать вопрос, на который не ответят уже работающие в компании?
Ведь проект пишется, жалоб нет.
Danik-ik
24.04.2018 08:57+1Чтобы следовать заветам данной статьи, большой начальник должен правильно мотивировать собеседующих. Чтобы почаще ходили на собеседования. Снижение зарплаты, думаю, подойдёт. Сразу двойная выгода!
kypexin
24.04.2018 10:40Интересная ремарка. Вы считаете, что для хождения на собеседования нужна только «отрицательная» мотивация (то есть, только когда человек активно начинает искать новую работу)? Почему? Просто любопытно.
Neikist
24.04.2018 12:32Ну, логично что если человека все устраивает то об уходе он не будет думать.
kypexin
24.04.2018 12:35Это так, но вместе с тем «думать об уходе» и «ходить по собеседованиям» это вещи зачастую вообще между собой не связанные (лично для меня по крайней мере).
Neikist
24.04.2018 12:56В таком случае получается вы вводите в заблуждение того к кому на собеседование идете, поскольку не планируете уходить с текущего места.
kypexin
24.04.2018 13:18Думаю, это только если сам подаёшься на открытую позицию. Но часто работодатель как раз сам проявляет интерес и приглашает, в этом случае ничему не вредит честный ответ в духе «Я не нахожусь в активном поиске работы, но с удовольствием приду пообщаться». По моему мнению, хождение на собеседования даёт исключительно полезный опыт, независимо от того, ищешь работу или нет.
roscomtheend
25.04.2018 09:44(Хоть и не автор исходного тезиса) Потому что я проводил слбеседование и для меня это тоже нагрузка, а не развлечение (как и хождение на собеседования). И я представляю как кандидат, прошедший собеседование, внезапно заявляет, та-да!, а я к вам и не собирался. Не будьте как кандидат.
ganqqwerty
24.04.2018 17:45Прекрасная статья, особенно про то, что надо самому ходит на собесы. Сходил разиков пять, посмотрел, какие дебильные вопросы задают — и сразу порефлексировал, а не делаешь ли ты того же самого.
K0JIXO3HuK
25.04.2018 12:59Я всегда полагал, что программисты — люди творческие. Художники, пишущие не краской, но цыфрами. Поэты машинного кода, так сказать. Мне кажется, в вашей отрасли нужно оценивать математические, логические и творческие способности человека.
aikus
25.04.2018 12:59Вот тут написано про «токсичные» вопросы. И даже предположить не постарались, что эти вопросы для чего то задаются. Может вопрос для отвлечения внимания, чтоб проверить концентрацию? Может действительно им вот сейчас надо 20 Пб из одного цода в другой перегнать (и у них пока лучшая идея сделать это на грузовике)? Может опыт команды говорит, что следуя принципам SOLID действительно код получается лучше?
В статье сразу делается предположения, что (1) вопросы глупые и (2) задавать их не нужно. Если эти предположения поставить под сомнения, то и выводы получатся не такие.
В целом, смотреть, как там собеседуют в чужом болоте, конечно полезно. Но если это делать вот с такими установками, то ни чего хорошего из этого не выйдет. Скорее всего вывод будет — я один тут Д'Артаньян.
vics001
Во всех статьях про собеседования упускается момент, что собеседование всегда было и будет оставаться субъективным процессом, люди нанимают на работу других людей. Чем более разносторонняя работа, тем более разносторонние вопросы могут и будут задаваться.
А кому их тогда проводить? Может нанять человека, который будет проводить?Чтобы не разводить холивар, надо просто согласиться, что как в проверке теорий бывают ошибки 2-х родов: ошибка первого рода — взяли, не того кого нужно, или он сам ушел, ошибка второго рода — не взяли, а вот если бы взяли то, он точно бы подошел. И как всегда уменьшая ошибку первого рода, увеличивается ошибка второго рода и наоборот.
Я пожалуй соглашусь, что сейчас большинство компаний оптимизируют именно ошибку первого рода. По моим наблюдениям более 90% успешно прошедших собеседование кандидатов работают более года. Ошибка 10% — отличный результат для такой сложной и трудноинтвервьюируемой индустрии.
Areso
из которых от 3 до 6 месяцев въезжают в проект, в инфраструктуру, получают доступы через СБ, и так далее и тому подобное, знакомятся и притираются в новом для себе коллективе. Ах да, через год (полтора или два) заодно будет видно, как в компании обстоят дела с индексацией зарплат (не засобирается ли человек в другое место только лишь потому, что захотел увеличить свою зарплату до актуального рыночного значения, пока в компании будут что-то неловко бубнить про KPI и достижения общих целей по всей компании).
Если поправить, скажем, на два-два с половиной года, то звучит уже много лучше. Но можно ли поправить, сохранив тот же процент?
vics001
Ой, так через 20 лет уже жизнь программиста пройдет :) Если людям действительно не нравится, то уходят через 1-3 месяца, я помню ушел через 6 месяцев, правда там условия поменялись резко в еще худшую сторону.
Вообще, надо проводить опрос по индустрии и смотреть, такую информацию могут представить либо крупные компании, либо HR-агенства.
ohmytribe
2-2.5 года для программиста — это очень много. Если у вас 90% программистов работает по 2-2.5 года, это говорит не о успешности собеседований, а о определённом ментальности программистов, которых вы принимаете на работу. Для молодых программистов, скажем, 2-2.5 года на одном месте — для меня даже странно.
musicriffstudio
да
TheShock
А как с ним провести собеседование?
musicriffstudio
по-старинке
Color
Пусть сам себе и проводит, это будет еще и тестовым заданием