Иногда не всегда сразу ясно, подходит ли кандидат в компанию. Не частый кейс, но бывает. Может быть несколько вакансий в разных отделах, и если кандидат не подошел для одной позиции, может быть отличным выбором для другой.
Также важен этикет. Если кандидат уж пришёл к нам, мы уважаем его время. Ответить на его вопросы — это наш способ показать уважение. Это создаёт win-win ситуацию: даже если "сделка" не состоится, положительное впечатление может привести к рекомендациям от кандидата.
Историй, когда уже точно все решено, а мы кандидата удерживаем, чтобы потратить время на бесполезные рассказы - мы стараемся не допускать и ценить время друг друга.
Я хотел показать, что иногда кандидаты приходят на собеседования без особого энтузиазма, без огня в глазах, будто их заставили – просто чтобы поставить галочку. Поэтому и выбрал изображение спящего кандидата, чтобы подчеркнуть эту идею.
Хороший вопрос! На самом деле, рассказ о вакансии в конце собеседования – это как финальный аккорд общения. :)
Весь процесс поиска новых коллег довольно сложен, чтобы уместить его в одну статью.
Сначала мы выкладываем вакансию, чтобы люди увидели, что у нас есть интересное предложение. Если кто-то откликается или мы находим кого-то через другие каналы, HR рассказывает подробнее о проекте и условиях. И если после всех этих этапов кандидат всё ещё заинтересован, на собеседовании мы уже делаем все, чтобы убедить его присоединиться к нашей команде. Вот почему детальный рассказ о вакансии часто бывает в конце – это своего рода подведение итогов всему разговору.
Большое спасибо за интересную статью! Есть несколько вопросов - поделитесь опытом, пожалуйста:
Про поддержку. По пути к светлому будущему у вас наверняка было 2 больших направления - разработка нового решения и поддержка старого зоопарка. Как с этим справлялись? Какие подходы? Это делала одна команда - и поддержку, и развитие платформы? Или разные?
Про ресурсоемкость Из статьи вижу порядка 2000 сервисов, срок прихода к светлому будущему - 2 года. Полагаю, что языки разработки/флоу - тоже имеют небольшую вариативность. А какой размер команды это все делал (платформу и поддержку)? Хотя бы ориентир - 2-3, 5-7, 10+ ?
Про backstage - а чем обсуловлен выбор собственного решения? Так исторически сложилось или есть какие то грабли/нюансы с backstage? Судя по тому, что вы там храните - возможно backstage не покрывал ваши запросы? Я тоже стою перед backstage и думаю с какой стороны к нему подступится.
Про метрики - тоже инетересно. В конце указано TTM, и это вполне логично (субъективно), что автоматизации и быстрый CI/CD явно быстрее ручных вариантов, но как замерялось влияние именно инфраструктуры на TTM (объективно)? Создание нового сервиса - да, померить можно - вначале ручками через кучу заявков создавали 3 дня, а через автоматику за 5 минут. Но замерлся ли остальной процесс - linter/unit/тесты, доставки кода по контурам, автоматические релизы? Именно в контексте метрики TTM. Если да - было бы круто узнать чуть больше деталей.
Если смотреть на вопрос шире - причин несколько.
Иногда не всегда сразу ясно, подходит ли кандидат в компанию. Не частый кейс, но бывает. Может быть несколько вакансий в разных отделах, и если кандидат не подошел для одной позиции, может быть отличным выбором для другой.
Также важен этикет. Если кандидат уж пришёл к нам, мы уважаем его время. Ответить на его вопросы — это наш способ показать уважение. Это создаёт win-win ситуацию: даже если "сделка" не состоится, положительное впечатление может привести к рекомендациям от кандидата.
Историй, когда уже точно все решено, а мы кандидата удерживаем, чтобы потратить время на бесполезные рассказы - мы стараемся не допускать и ценить время друг друга.
Неожиданная трактовка картинки :)
Я хотел показать, что иногда кандидаты приходят на собеседования без особого энтузиазма, без огня в глазах, будто их заставили – просто чтобы поставить галочку. Поэтому и выбрал изображение спящего кандидата, чтобы подчеркнуть эту идею.
Хороший вопрос! На самом деле, рассказ о вакансии в конце собеседования – это как финальный аккорд общения. :)
Весь процесс поиска новых коллег довольно сложен, чтобы уместить его в одну статью.
Сначала мы выкладываем вакансию, чтобы люди увидели, что у нас есть интересное предложение. Если кто-то откликается или мы находим кого-то через другие каналы, HR рассказывает подробнее о проекте и условиях. И если после всех этих этапов кандидат всё ещё заинтересован, на собеседовании мы уже делаем все, чтобы убедить его присоединиться к нашей команде. Вот почему детальный рассказ о вакансии часто бывает в конце – это своего рода подведение итогов всему разговору.
Большое спасибо за интересную статью!
Есть несколько вопросов - поделитесь опытом, пожалуйста:
Про поддержку.
По пути к светлому будущему у вас наверняка было 2 больших направления - разработка нового решения и поддержка старого зоопарка. Как с этим справлялись? Какие подходы? Это делала одна команда - и поддержку, и развитие платформы? Или разные?
Про ресурсоемкость
Из статьи вижу порядка 2000 сервисов, срок прихода к светлому будущему - 2 года. Полагаю, что языки разработки/флоу - тоже имеют небольшую вариативность.
А какой размер команды это все делал (платформу и поддержку)? Хотя бы ориентир - 2-3, 5-7, 10+ ?
Про backstage - а чем обсуловлен выбор собственного решения? Так исторически сложилось или есть какие то грабли/нюансы с backstage?
Судя по тому, что вы там храните - возможно backstage не покрывал ваши запросы?
Я тоже стою перед backstage и думаю с какой стороны к нему подступится.
Про метрики - тоже инетересно. В конце указано TTM, и это вполне логично (субъективно), что автоматизации и быстрый CI/CD явно быстрее ручных вариантов, но как замерялось влияние именно инфраструктуры на TTM (объективно)? Создание нового сервиса - да, померить можно - вначале ручками через кучу заявков создавали 3 дня, а через автоматику за 5 минут. Но замерлся ли остальной процесс - linter/unit/тесты, доставки кода по контурам, автоматические релизы? Именно в контексте метрики TTM. Если да - было бы круто узнать чуть больше деталей.