Comments 29
Бизнес-кейсы однозначно лучше, но они также собирают тот же негатив: соискатель стрессует, интервьюер давит, не может толком донести суть и реальность бизнес-кейса, погрузить соискателя в контекст и так далее.
О да, чем лучше кандидат отвечает на теорию, тем хуже он на самом деле умеет работать. Прямо как антипаттерн на собесах можно использовать.
Предлагаю кандидату выстроить работу команды. Для утрирования ситуации обычно рассматриваем вариант, когда в команду к сильному разработчику (кандидату) нанимают 5 джуниор-разработчиков.
Так вам все-таки нужен сильный разработчик или человек-комбайн, который кроме собственно разработки занимается и построением процессов и обучением джунов?
Надеюсь, это хотя бы нормально описано в требованиях к вакансии, потому что требования вообще ни разу не стандартные и ближе к обязанностям тимлида. Ну и часто реально сильные разработчики не особо горят желанием заниматься обучением новичков, но это не говорит о том, что такие разработчики не нужны.
ближе к обязанностям тимлида
Это нормальный процесс девальвации зарплаты через повышение уровня обязанностей на грейд выше. Конкуренция растёт, кто бы что там ни пел про кадровый голод. В США уже лет 5 как в обязанности синьйору вменяется няньчинье с джунами. Но хотя бы прямо в вакансиях это пишется.
не скажу за европейские страны и СНГ, но в западных фирмах практически везде сениор-разработчик - это целая команда в лице одного человека. среднестатистические требования к сениору:
хард-скиллы по всем фронтам - от разработки (благо в веб-ориентированой работе осталось еще разделение на фронт- и бекенд работу, то настоящий фулл-стек не требуют)
деплой - настройка и поддержка CI/CD, разворачивание окружений
тестирование на всех уровнях - ответственность и за тесты в коде, и за процессы тестирования, и за CI/CD, и за метрики-мониторинг, и собственно саппорт - on-call и прочее взаимодействие с пользователями
менторинг, хайринг
лидерство команды и проектов - от продажи идеи менеджменту до планирования и распределения работы, лидинга всех процессов разработки и ответственность за таймлайны-дедлайны
при этом человек должен сам отвечать за свой карьерный рост - планировать его и исполнять план, чтобы не застаиваться в позиции
при этом команда может состоять из 5 и более сениоров - тогда вот это вот все выглядит очень забавно, когда каждый должен лидить что-то (и других и проекты)
Мы ищем программных инженеров)
Но спасибо за комментарий! Мы действительно стараемся максимально подробно расписать требования к вакансии. Все, что не входит в требования, как правило, не является причиной отказа кандидату. Однако, мне очень полезно на этом этапе узнать дополнительные возможности/желания кандидатов, чтобы потом успешно применять это в рабочем процессе
Что касается блока про 5 джуниор-разработчиков, то в первую очередь мы все-таки обсуждаем автоматизацию, построение гитфлоу и различные другие процессы в духе кодревью. Обучение новичков обычно не входит в прямые обязанности разработчика и остается на его усмотрение
Конечно же нужен и швец и жнец на одной ставке. Не даром было подчёркнуто, что ценятся такие ios разработчики, которые готовы написать ещё и бэкенд.
У меня, конечно, не особо большая выборка, но из тех разрабов, кого я знаю, именно те, кто горят желанием (ну или, как минимум, не против) учить джунов и помнят, каково им было, когда они начинали, являются самыми крутыми, продуктивными и полезными для бизнеса. У них, как минимум, вкачена эмпатия и способность слышать бизнесовых ребят и снисходительно относиться к тому, что они, зачастую, сами не знают, чего хотят. А вот их антиподы, наоборот, начинают душить, что требований нет, "это не баг, а фича", все тлен, работать не буду и т.д. и т.п. Грубо говоря с гибкостью не очень. Не готов поручиться, что так везде и у всех, ибо все люди разные, но конкретно на моем опыте дела обстоят как-то так.
Звучит очень здравомыслеще.
Однозначно, лучше классического собеседования.
Мой самый «любимый» ответ — «попрошу доступы к коду и напишу все сам».
Кавычки у слова "любимый" подразумевают, что это плохой ответ? Если так, то почему? =)
Тоже интересно.
Единственная гипотеза: автор предполагает что надо просить нанять команду.
Как правило в этом кейсе я хочу услышать о различных способах оптимизации именно на стороне мобильного приложения (кеширование, предзагрузка, лоадеры и любые другие решения).
Сам по себе факт того, что человек может написать код и в мобильном приложении,и на бэкенде, не является плохим. Но мы в первую очередь собеседуем мобильных разработчиков, поэтому, если есть решение, которое можно применить на стороне приложения, я бы хотел его услышать
Может быть не очень корректно писать 2 комментария подряд, но, имхо, они разные, поэтому разделил.
Лично я считаю такой подход хорошим и даже стало интересно самому провести такой собес. Наверное, лучше всего предлагать кандидатам ситуации, которые реально случались на проекте, тогда решение кандидата можно будет сравнить с тем, как эта проблема уже когда-то решилась в реальности. И вот тут может оказаться несколько вариантов:
1. кандидат не додумается ни до какого решения, либо придумает что-то очень плохое вообще не туда;
2. кандидат будет мыслить в верном направлении и либо придет к тому же, - идеальный кандидат, либо ему чего-то не хватит, что тоже его делает отличным кандидатом, у которого еще всё впереди;
3. кандидат придумает решение еще круче.
В третьем варианте возможен даже сценарий, когда придется сказать кандидату: "круто, но наша команда не справилась бы с вашей идеей - вы слишком хороши для нас". Могу как совет предложить сделать чуть больше акцента в статье на том, что цель, наверное, даже любого собеса найти не лучшего, а наиболее подходящего.
а после успешного собеса выходишь на работу и там опять JSONы перекладывать
Радует, что процесс проведения собеседований непрерывно улучшается. Печалит, что медленно) В реальности, если у человека за плечами не один год работы iOS разработчиком над разными приложениями, о чем его спрашивать, хоть технически, хоть по бизнесу? Разве что за жизнь поговорить, а там как пойдет)
Удивительно, конечно, как можно погрузить кандидата во что-то мало-мальски реальное за 15 минут и сделать из этого какой-то вывод. Думаю, не во всех областях сможет прижиться такая практика.
Благодарю, что поделились опытом.
Подготовка бизнес кейсов к конкретной вакансии с учётом внутренней специфики фирмы и требований, которые они предъявляют к соискателю, дело серьёзное и требует опыта и креативности от
Хоть в каких-то компаниях есть здравомыслящие лиды, можно только порадоваться за эти компании. Чаще попадаются упоротые синьоры с красными глазами от бессонных ночей, т.к. работают за всю команду "ибо все надо переделывать после этих криворуких". И собесы они проводят в стиле "академик принимает экзамен у выпускника курсов для начинающих по языку ххх".
При таком подходе действительно больше шансов взять на работу реального практика, который будет регулярно коммитить полезный уникальный код в ваш репозиторий. В противовес бесконечным теоретическим интервью и уже решенным задачам, сделанным под теоретиков-олимпиадников, которые будут бодро выдавать вам заученные наизусть типовые ответы, а на работе потом тупо копировать чужой код или чужие идеи, как например в Яндексе
так и на вероятность того, что кандидат, повысив свой уровень, попробует пройти собеседование снова
Пробовать снова? А разве работодателю это нужно?
Немного в сторону с вашего позволения.
Я откликнулся на какую-то вакансию, отклик сколько-то провисел в "просмотрено", затем получил отказ — все по-классике. Тем временем я продолжал искать и фильтровать вакансии, отправлять отклики, как вдруг я получил интересный ответ на какой-то очередной свой отклик. Текст ответа гласил (цитата копипастом):
я же вам отказала на той неделе зачем вы опять суетесь???
"Сначала я не понял, а потом ка-а-ак понял" ©
Я посмотрел историю своих откликов — да, действительно, с разницей примерно в неделю я отозвался на две вакансии с одинаковым содержанием от одного и того же работодателя. То есть он нагенерил их несколько штук одинаковых, но ждал при этом уникальных откликов... А с моей стороны кнопка "вы уже отликнулись" в этом случае не срабатывает — id вакансии в системе уже другой.
Скриншот с вашего позволения не цепляю — компания известная на всю страну, все ее знают.
Если у интервьюера на руках список вопросов и он занимается тем, что сравнивает ответ кандидата с ожидаемым шаблоном (видимо такой тип собеседований вызывает бурления у общественности), то в моем представлении это говорит только о непригодности интервьюера и, видимо, недостаточной зрелости и осознанности компании.
И это не лечится заменой опросника на разбор кейсов. К слову, автор в комментариях сам же и пишет «как правило в этом кейсе я хочу услышать...». Если разбор кейса сводится к получению желаемого результата, то чем это концептуально отличается от стандартных вопросов?
Уверен, что если бы автор проводил собесы в формате: живое знакомство с беседой о прошлой работе, вопросы и задачки на проверку хардов, ответы на вопросы кандидата, то он бы мог делать точно такие же выводы о кандидате, что и сейчас.
В общем, в статье понравилось целеполагание (узнать кандидата со всех сторон, понизить уровень стресса), но причинно-следственные связи описаны неверно. Из-за чего решать проблему предлагается заменой опросника, а не повышением уровня интервьюера, компании, и просвещением соискателей. Что в свою очередь продолжает плодить срачи и нытье в комментариях на тему ненужности тех или иных вопросов на интервью и их форматов.
Забавно, что через умение анализировать причины краша приложений у пользователей вы в том числе оцениваете эмоциональный интеллект соискателя)
Интересный подход. Интересно, можно ли подобный разработать для вопросов от кандидата к работодателю. Особенно интересуют отзывы настоящих сотрудников компании и честные ответы команды без каких либо "молодой активный креативный коллектив и интересные задачи". То есть самый интересный вопрос это "Какие новые скилы ты развил в рамках проекта?" или "Сколько проектов было успешно реализовано на твоей памяти?".
Хорошая статья, спасибо автору! Интересный подход, необычный.. Собеседование - это всегда реал-тайм реагирование на ситуацию. Сколько раз было, что заранее подготовленный флоу собеса приходится менять прямо по ходу проведения. Иметь в запасе такой вариант собеседования - однозначно "+". Заменить им полностью собеседование типа: "вопрос"-"ответ" - скорее нет, чем да..
Теорию могут заучить почти все. Применять эту теорию на практике могут немногие.
а как вы это делаете? Я не совсем понял.
Вот есть вроде намек на "дополнительные вопросы", но вы сказали что они задаются "если ответ не нравится", значит у вас какие то ожидания от кандидата есть, технические, что если например вы ждете от кандидата, что он вам расскажет про барьеры в очередях, а он знает лучшее решение в организации цепочек запросов в сеть с помощью Promise? Вроде дичь, вот уже Combine есть, но в конкретной задаче Combine хуже справится, и как оценить тогда такой ответ?
Еще есть кейс, что после одного из ваши собесов сольют в сеть "правильные ответы" и будут появляться кандидаты, которым не нужно вообще задавать вопросов, потому что они чешут от зубка, как опытные синьеры. Как с этим боритесь?
Вы очень крутую вещь подсказали в статье: "иногда я меняю условия" вот это реально помогает определить софты, а вот про отсев нежелательных личностей, можете пояснить? Как он происходит? Как вы определяете не подходящего для вашей команды человека?
Идеальное собеседование. Мой опыт тимлида, как нанимать с помощью бизнес-кейсов