Comments 20
Крайне полезно.
Предлагаю тему для следующего поста:
Как поддерживать заинтересованность члена команды в проекте.
Правильные и дельные советы, но есть парочка замечаний
Разделение на PO и аналитика опоправдано
Что такое РО?
как минимум прочитал её описание и имеет представление, с чем нужно будет работать. Ведь мы работаем с финтех-продуктами. Наконец, в-четвёртых, собеседующему стало понятно, какие вопросы могут раскрыть сильные стороны кандидата на базе его прошлого опыта, а на какие он, скорее всего, не ответит, поэтому не стоит тратить на них время.
То есть, кандидату надо прочитать о фирме и вакансии, а интервьюеру западло пробежать глазами даже первую страницу резюме кандидата про его прошлый опыт? Ох уж, эти пальчики веером...
Пример хорошего ответа: хочу подключиться на новый проект на стартовом этапе, так как сильно устал от legacy за последние годы, всегда приятнее стоять у истоков чего-то большого и перспективного, ещё вижу в этом возможность занять в перспективе lelead-позицию.
А вы видели хоть раз, чтобы кандидат хотел на старый проект фиксить древние баги, особенно на такой, который через год-два заменят "новым перспективным"? Really?
В остальном норм.
Все сильно зависит от качества самого резюме. Хорошее резюме это повод обсудить весь релеватный опыт, а не только по последний.
И да, видел и не раз, что кандидаты с большим стажем неохотно рассматривают новые проекты, где будет больше творческого хаоса, и где процессы только предстоит наладить. Им по вкусу включиться в уже слаженную команду и действующий проект. Таких кандидатов не большинство, но и не ничтожно мало :)
PO == Product Owner
Есть некоторая однобокость в утверждениях, хотя во многом они и верны:
> Непонимание своей миссии
Это разработчик непонимает свою миссию или её не смогли объяснить? Во многих компаниях есть своё понимание процессов и роли человека в них, которые неочевидны со стороны, из грубых примеров: в случае "тормозов" со стороны базы надо идти к специально обученному человеку в чатик, он подскажет или заводить на него задачу или разбираться самому? В случае неочевидной постановки задачи надо переводить на постановщика с уточнением/идти к тимлиду/потому что он знает, а постановщик - важная шишка и дёргать его не стоит, что делать при "красном" пайпдайне - чинить/тегать того, кто сломал/посмотреть, что сломал не ты и забить? Кто пишет интеграционные тесты и пишутся ли они вообще? Что представляет собой написание документации: докстринги и доктесты/странички в конфлюенсе/файлики readme.md/кукбуки/факи/траблшутинги? И т.д.
> хочу подключиться на новый проект на стартовом этапе, так как сильно устал от legacy за последние годы, всегда приятнее стоять у истоков чего-то большого и перспективного, ещё вижу в этом возможность занять в перспективе lead-позицию.
Звучит на самом деле тоже не слишком специфично, то есть понятно, что человека на поддержку легаси ставить не стоит, но вот переписывание этого легаси на чём-то другом - уже достаточно новый проект или ещё нет? А если новый проект делается в зарегулированной сфере, где выбор поставщиков технологий сделан регуляторами, да и все алгоритмы/обработка данных написана в пункте 4 статьи 8 параграфа 32 вон того пыльного кодекса? Через сколько спринтов проект, на который нанимают человека тоже станет легаси и он пойдёт искать новый?
Ну и стоит учитывать, что работа тоже зачастую шаблонна, поэтому не стоит удивляться, что мотивация такая же, в конце концов такая ли большая разница между перекладыванием json с помощью асинхронного брокера сообщений с сферическими данными банка и этим же занятием с помощью кафки/БД и сферическими данными интернет-магазина? Кажется, в 80% случаев - не особо.
Пример ответа на вопрос (далее цитаты из статьи на wiki): REST — архитектурный стиль взаимодействия компонентов распределённого приложения в сети... REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиасистемы…
Такая лексика в устной речи наводит на мысль, что ответ был заучен или читается с той самой статьи на экране. Более того, термин «гипермедиасистема» так и просится, чтобы в разговорной речи убрать пресловутую «гипермедиа».
Задавая вопрос, как на экзамене, есть риск получить ответ как на экзамене, возможно, лучше попросить кандидата спроектировать архитектуру какой-то системы/сервиса, так гораздо проще понять практический опыт и понимание реальных ограничений, а не рассуждать о сферических entity бороздящих просторы stateless серверов.
В целом же согласен, особенно насчёт неискренности, я бы ещё добавил от себя, что помимо искренности, хорошо, чтобы все стороны процессов могли поставить себя на место другой стороны и понимать какие данные нужно передать/какая боль у этого человека/что можно сделать, чтобы её облегчить.
Полностью избежать истории вопросов как на экзамене не всегда удается. А вот ответ на такой вопрос уже может стать предметом разговора о конкретной архитектуре решения на текущей работе кандидата, согласен. В целом, нет единого мнения на тему, нужно ли ставить задачи на собеседованиях, которые в кандидат должен в live-режиме решать. На мой взгляд, для архитектора только если в качестве тестового задания, т.к. нормальная архитектура не рисуется за 15 минут в стресс-режиме. Но есть и такие практики в некоторых компаниях.
Поставить себя на место другого человека в режиме собеседования очень непростая задача, т.к. вы видите человека впервые, о его ситуации можете судить только с его слов, но вот боль понять действительно можно, если кандидат искренен. Тогда есть шанс ее облегчить тем, что не предлагать проект, где потенциально его может ожидать то же самое :)
Полностью избежать истории вопросов как на экзамене не всегда удается.
Я всё же не говорил про избегание таких вопросов, а от реакции на их ответ. Если часто ответ не нравится, возможно, вопрос стоит переформулировать или вообще от него избавиться. Хорошую архитектуру за 15 минут не построишь, конечно, но цель и не построить архитектуру, а понять, с чем человек успел поработать, какие ограничения видит и как вообще думает.
С собеседованиями вообще сложно, особенно, если в них добавляются эмоции, там и кандидат может уйти в себя и обидеться и ответа из него уже не вытянешь, или собеседующий может принять решение через 5 минут разговора и всё остальное собеседование занимается имитацией. В общем нелегко это.
"1. Нет ответа на конкретный вопрос"
А нужно ли все таки четко отвечать на поставленный вопрос? Ведь все вопросы в первую очередь направлены на проверку опыта и знаний кандидата. Если кандидат может ответить Зачем? и как применяли на своих проектах, то это довольно таки неплохой плюс, если есть необходимость покопать глубже, то можно продолжить задавать направляющие вопросы по теме.
Согласен с вами. Здесь цель узнать не только опыт и знания, оценить и т.н. софты, в которые входят коммуникативные навыки. И вот тут отсутствие четкого ответа на вопрос играет не пользу кандидата, особенно если в силу специфики работы, ему нужно будет общаться не только со своей командой, которая сможет наверняка подстроиться, но и с бизнес-заказчиком, поддержкой, смежными командами и.т.п.
Думаю, эта статья будет полезна как компаниям, так и будущим сотрудникам. Первым она поможет правильно проанализировать подготовку работника к собеседованию, а вторым - повысить свои шансы на успешное получение работы.
На мой взгляд, 10й пункт самый важный, т.к. взаимопонимание - наше всё.
Не раз был в ситуации, когда собеседующий поднимал темы(сложные и важные для эффективной работы), в которых сам не очень, и в итоге взаимопонимание устремлялось к нулю, а вместе с ним и взаимный интерес к продолжению общения.
Проводишь бесконечные вечера за изучением языков, баз данных, фреймворков, паттернов, алгоритмов, читаешь книги, а потом тебя не берут из-за фразы:
люблю интересные задачи, хочу профессионально расти, работать в сплочённой и дружной команде
Есть лёгкое ощущение, что пункты 5 и 10 противоречат друг другу.
Может так сложиться, да. Но на самом деле нет. Я бы добавил здесь то, что к проектному интервью лучше приходить психологически нейтральным или даже позитивно настроенным.
Разумеется, бывают случаи, когда уход из предыдущей компании не был хорошим и остались негативные эмоции. Чтобы не портить впечатление на интервью в новом месте, их лучше заранее проработать, чтобы иметь силы рассказать о них спокойно и только то, что считаете уместным и важным. Негативный опыт тоже опыт, главное не переборщить :)
Спасибо за полезный материал. У каждого HR свои заморочки, но все равно пригодится ваша подборка.
P. S. Пошел гуглить правильный красивый ответ на вопрос «для каких классов задач, на ваш взгляд, стоит применять асинхронные коммуникации и message-брокеры?» :)
Толковая статья: достаточно полно и кратко в то же время! Но напрашивается от сообщества запрос на "обратную" статью, с советами интервьюерам со стороны работодателей. Даже по своему опыту могу сказать, что далеко не все сотрудники нанимающей стороны дают точные и искренние ответы!
10 типичных «софтовых» ошибок на собеседовании