• Как мы переделали структуру собеседований, и что из этого вышло
    0
    У нас 5 продуктовых и 5 платформенных кластеров. Описанный в статье процесс используется только в одном из них (С2С). И то это скорее фреймворк, а не строгий процесс. Команды его использующие могут менять структуру вопросов и задачи в рамках секций. Могут добавлять свои секции. В общем адаптируют фреймворк, оставляя общую структуру и идею каждого блока.
    В моем кластере (Verticals) похожая но не точно такая же схема. У нас тоже есть скрининг по телефону/скайпу, делают его инженеры и мы стараемся уложиться в 30 минут на все (знакомство + наши вопросы + вопросы кандидата). Потом техническое интервью, 2 часа с похожим набором секций. И финал HR + менеджер для проверки soft-skills и прояснения оставшихся вопросов 1.5 часа.
    В общем набор секций примерно одинаковый у всех, но каждый кластер адаптирует все под себя и внутри кластера команды еще могут тоже что-то менять. Так что наш процесс ближе к микросервисам, чем монолиту :)

    Про метрики на которые смотрели ребята не отвечу, возможно у StanYurk есть детали.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Я не проверял с линейкой, мне удобно сидеть этого достаточно. Если вам это важно, попросите после интервью показать ваше рабочее место и проверьте удобство. Я знаю кандидатов которые так делали и вроде все довольны остались.
  • Как мы переделали структуру собеседований, и что из этого вышло
    +1
    В этом случае все тратят свое время зря, в том числе компания. Но время которое мы тратим на интервью сильно меньше чем время которое мы потратим на адаптацию человека. В случае если он уйдет мы опять должны будем потратить время на поиск и адаптацию нового разработчика. Получается в случае вашего увольнения по время испытательного срока, компания несет двойные потери в отличие от вас. Поэтому и появляются все эти этапы. Кажется что времени тратиться много, но если сравнить с возможными потерями, то не так уж и много.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Есть планы по редизайну в этом году :)
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Вы наверное имели ввиду этап с задачками, потому что тестовые задания (то что надо делать дома) мы не практикуем на позиции разработчиков.

    В любом случае, мы такой подход не практикуем и ссылки на свои проекты на github кандидаты нам присылают не так часто как хотелось бы. По моим ощущениям это 1-2 кандидата из 10-ти. Но мы подумаем над такой опцией.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    У нас все рабочие места соответствуют стандартам. Не только по размерам, но и по освещенности и электробезопасности. По последним двум пунктам регулярные замеры и проверки делаются.
    Ну и как человек сидящий за одним из таких столов как на фоточке, могу сказать что они не маленькие и не узкие. Хватает места и для ног под столом и на столе для рюкзака и для одного двух дополнительных мониторов.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Задачки это только одна часть. Можно научиться решать задачки но завалится на вопросах по архитектуре. На этой секции мы даем какие-то интересные задачки на проектирование какого-то сервиса или продукта. Например фронтенд или мобильных разработчиков можем попросить спроектировать мессенджер. Бэкэндеров попросить спроектировать сервис типа твитера или высоконагруженный сервис.
    Ну и по резюме и на последней секции интервью видно какой реально опыт был у кандидата.
  • Как мы переделали структуру собеседований, и что из этого вышло
    +1
    По программированию обычно нет. Но по архитектурным вопросам да. И на общий технический кругозор тоже смотрим.
    Правда тут есть исключения. На некоторых менеджерских позициях может быть секция по программированию если для команды важно чтобы их начальник писал код на равне с ними, иначе они могут его не принять.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Да, звучит классно. А как быть если показать код нельзя?
  • Как мы переделали структуру собеседований, и что из этого вышло
    +1
    Если это никак не сказывается на его работе, то подходит. Но тут речь не про любовь к Авито, а к тому чем ты занимаешься, к программированию и созданию крутых вещей. Если человек может писать прекрасный качественный код, не токсичен к команде, постоянно приходит с интересными идеями по улучшению продукта, но при этом в душе ненавидит Авито, то мы наверное никогда про это не узнаем и будем рады видеть его в своей команде :)
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Формулировка не очень удачная. Резюме это опорная точка от которой строиться диалог. Вместо абстрактных вопросов «как бы вы поступили в ситуации Х», мы смотрим на то какой опыт был у кандидата на предыдущих местах работы. С какими ситуациями он сталкивался, как их решал. На вопросы про предыдущий опыт проще отвечать, и они лучше раскрывают кандидата.
  • Как мы переделали структуру собеседований, и что из этого вышло
    +1
    Вы нашли фотографию рабочего места ребят из команды it-support. Они выдают людям ноубуки, мониторы, мышки и поддерживают всю it инфрастуктуру офиса :) Вот пример рабочих мест разработчиков.

    А проблему шума неплохо решают стеклянные шумо-поглащающие перегородки между несколькими рядами. Если присмотреться их видно на этом фото.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Ни с каких, я ровно об этом и говорю. Хорошая зарплата это минимальная база, но мы хотим чтобы кандидат кроме своей зарплаты любил и свою работу. Бывают люди которым всеравно что они делают, лишь бы деньги платили. Бывают те кому важно над чем они работают не меньше чем зарплата которую они получают. А еще бывают такие которым вообще не важно сколько денег, лишь бы делать то что им нравится.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    И их тоже ищем :) Еще и хотим чтобы они умели не только UI, но и UX
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    i360u а как в вашей компании проводятся интервью? Как вы проверяете hard-skills кандидата? Я в своей практике ничего лучше практических задачек пока не видел и не придумал.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Да именно про это StanYurk и говорит. Мы не меняем горящие глаза на маленькую зарплату. Мы даем достойную зарплату на рынке, но в дополнении к ней хотим чтобы кандидат разделял наши подходы к работе, в частности Agile и Scrum. Смысл этого довольно прагматичный, если человеку будет не комфортно с нами и он будет себя заставлять сидеть на работе за хорошую зарплату, то он очень быстро перегорит и уйдет от нас. А мы как компания уже потратили много времени на его поиск и адаптацию и будем вынуждены потратить это время снова.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    Последний этап интервью с HR и руководителем, это как раз про soft-skills. Разговор строится на основе предыдущего опыта кандидата. Спрашиваем над какими проектами и главное как работал, какая была команда, какая у него было роль в команде, что нравилось, чего хочется от нового места и т.п.
  • Как мы переделали структуру собеседований, и что из этого вышло
    0
    На техническом интервью мы смотрим на hard-skills, на интервью с HR и руководителем на soft-skills. Почему эта секция в конце? Во-первых, потому что отсев по hard-skills гораздо выше. Во-вторых, потому что требования по hard-skills у нас примерно одинаковые во всей компании, а по soft-skills кандидат может не подойти в конкретную команду, или кандидату самому не понравится то чем придется заниматься. Тогда если есть открытые вакансии в других командах, мы можем предложить ему что-то еще.
  • Как мы переделали структуру собеседований, и что из этого вышло
    +2
    Вы как то не так трактуете то что StanYurk написал. Мы как раз таки ищем сантехников которые умеют спроектировать и собрать коллекторный узел. Но в дополнение к этому хотим что бы сантехник любил свою работу и делал ее хорошо, чтобы он смотрел что делают другие сантехники и вместо устаревших железных труб собирал нам коллектор из сшитого полипропилена и меди с правильным набором редукторов, фильтров, кранов и гребенок.
    Как правило люди которые только «сидят в офисе от смски до смски с зачислением зп» не интересуются ничем вокруг, у них очень узкий кругозор. Поэтому любовь к смскам с ЗП, это для нас это обязательна (а кто их не любит? :) ) но не достаточно для того чтобы мы приняли положительное решение.
  • Фантастические тимлиды и где они обитают
    +1
    То что вы описываете больше похоже на путь разработчика, чем руководителя. Принципы управления программистами меняются не так быстро и сейчас все еще актуальны книжки написанные в 70-е годы. Например тот же Брукс и его Мифический человеко-месяц.
    Ну и тимлид это не обязательно лучший разработчик в команде. Если есть желание быть тимлидом, то не надо в него расти качая знания в новых технологиях. Там нужны совсем другие навыки.
  • Фантастические тимлиды и где они обитают
    0
    Почему вы не создаете удаленные команды? Возможно было бы проще найти сотрудников.

    Для новых офисов в других городах мы еще не достаточно большие, нам проще помогать кандидатам с релокацией в Москву.
    А для полностью распределенных команд мы пока морально не готовы. С ними нужно работать по другому, а у нас все процессы заточены сейчас на то что со всеми нужными людьми ты либо сидишь рядом, либо можешь пообщаться лично.
    Ну и 3-4 месяца для поиска руководителя это не так много, мне кажется. Я сомневаюсь что в распределенную команду мы бы нашли человека быстрее.
  • Фантастические тимлиды и где они обитают
    +1
    зачем для этого отдельный человек для всех направлений сразу (и как ещё всё это успевать), когда очевидно что специализирующиеся на чём-то одном люди сделают это лучше

    Потому что у нас кроссфункциональные команды, которые помогают нам быстрее и лучше разрабатывать продукт. Я про это отдельно писал в статье.
    Да у нас требования к TULам более высокие, чем к обычным функциональным тимлидам. Но такая структура имеет свои плюсы по сравнению с функциональным делением.
  • Фантастические тимлиды и где они обитают
    +1
    Я спрашивал, потому что Продукт Менеджер у нас как раз есть и это отдельный человек и роль. В статье есть картинка со структурой команды. Эта позиция у нас называется Unit Leader и он как раз отвечает за продуктовую составляющую, сбор болей и потребностей пользователей, за наполнение бэклога нужными инициативами чтобы бизнес достигал своих целей, за постановку квартальных и годовых целей и т.п. А задача Technical Unit Leader чтобы команда разработки качественно и в срок доставляла задачи из бэклога до пользователей.
    А Проектные Менеджеры обычно бывают в компаниях где разработчики поделены на функции (бэк, фронт, qa и т.п.) и для разработки какой-то фичи нужно собрать из них команду и управлять разработкой проекта. Обычная матричная структура вобщем. Но в таких компаниях другие процессы и конечно будут другие требования к тимлидам.
  • Фантастические тимлиды и где они обитают
    +1
    как у вас получилось найти столько кандидатов, чтобы их можно было отсеивать по критериям «не написал в резюме про то, как управлял коммандой»?

    На самом деле мы очень много людей без нужных скиллов звали на очное интервью, в надежде что они не написали, но умеют. Но очное собеседовать отнимает очень много времени, поэтому если буду нанимать в следующий раз, то буду обязательно делать скрининг. За тот же час, можно поговорить с двумя — тремя людьми, а не одним.
    На обе позиции в сумме:
    — отсмотрел резюме больше сотни
    — на очное интервью звали человек 20-30
    — до кейса дошло человек 7
    — оферов соотвественно сделали 2

    И как вам удалось замотивировать кандидатов 2 недели делать тестовое задание?

    2 недели это «грязное» время. Реально люди же работают, занимаются своими делами, поэтому времени на подготовку уходит не так много. Кандидатов мы никак особо не мотивировали, все с пониманием относились к тестовому заданию. Мне кажется потому что все понимают, что позиция менеджерская, и цена ошибки при найме достаточно высока, поэтому с понимаем относятся.

    Сколько времени занял найм?

    Сейчас точно не скажу, но где-то 3-4 месяца на каждую позицию.
  • Фантастические тимлиды и где они обитают
    0
    Отсылка есть, второго смысла никакого нет. Если вы тимлид и вас это оскорбило, прошу прощения.
  • Фантастические тимлиды и где они обитают
    +2
    Если так, то это самое что ни на есть обычное руководство. Менеджмент. Тут нет ничего чтобы требовало специальных технических навыков

    Ну тимлид это и есть менеджер у технической команды. Если технической командой будет руководить человек без технического опыта, который не понимает что они делают, он не сможет ими нормально руководить. Не сможет заниматься их развитием, не сможет оценивать результаты их работы, не сможет оценить технические решения которые предлагает команда. Поэтому ему и нужны технические навыки.

    Вы зачем-то совмещаете должность архитектора, техлида, менеджера.

    Архитектора точно не совмещаем. А чем по вашему техлид отличается от менеджера?
  • Фантастические тимлиды и где они обитают
    +2
    «2 недели» это столько нам обычно называли сами кандидаты в среднем. Мы не ставили жестких сроков, хоть два месяца готовься, хоть 1 день.

    Про расчет бюджета в поставленных задачах ничего нет :) Только в описании текущей ситуации, чтобы у кандидатов было понимание про то на какую команду можно расчитывать.

    Остальные цифры про деньги нужны для того чтобы подготовить реалистичный план миграции. Например я ожидал что кандидат предложит какое-то техническое решение и напишет сколько ему надо под это серверов, поэтому сразу писал граничные условия по важным вещам.

    Вы хотите ПМа не тимлида.

    Нет, я не хочу ПМа :) Мне был нужен технический руководитель. Хороший технический руководитель не junior уровня, должен учитывать в своих планах расходы на сервера, людей и ПО. Не обязательно в деньгах, но в штуках точно.

    Если человек вам бюджет проекта сможет расчитать не ожидайте от него каких либо подвигов в коде.

    Да, согласен. Я об этом прямо не писал в статье, но для меня тимлид это в первую очередь человек который руководит командой, а не пишет код. Я не ожидаю от него подвигов, но хороший технический бэкграунд и кругозор обязательны.
  • Фантастические тимлиды и где они обитают
    0
    «планы на ближайшие 100 дней» — тут да, была не очень удачная формулировка. Мы просили сделать «роадмап» на квартал + хотели услышать что человек планировал лично, как менеджер, делать в первые месяцы работы.
  • Фантастические тимлиды и где они обитают
    0
    ПМ — это кто? Проектный Менеджер или Продуктовый Менеджер?
  • Фантастические тимлиды и где они обитают
    +2
    Отвечает — контролирует

    Это так, но вот дальше следствие из этого не совсем корректное. Как я писал выше, можно контролировать все лично, если есть экспертиза и время. А можно выстроить процесс так, что этим будет заниматься человек у которого есть нужная экспертиза. И тут много разных вариантов в зависимости от ситуации в компании и окружения.

    Другие команды — это неконтролируемая сфера. У них может быть релиз, авария и тд. и им не до ревью ваших фич. Плюс они вне контекста проекта, и оптимальность решений могут оценить только на уровне кода, но не на уровне взаимодействия с другими элементами проекта.

    Согласен, это очевидный минус такого решения :) Но бывают ситуации когда это работает.
  • Фантастические тимлиды и где они обитают
    0
    Да, над доставкой в 2017 году работали. А что не так? В статье вроде не говорится что Domofond был первопроходцем в миграции.
  • Фантастические тимлиды и где они обитают
    –1
    Отвечает != лично сам руками делает. В данном случае задача TULа позаботиться о том чтобы код был качественный, а способов это сделать может быть много, например: ревьюить самому если есть экспертиза, иметь в команде по сильному разработчику нужных функций которые отвечают за ревью, договориться с коллегами из смежных или платформенных команд о кросс-ревью и т.п.
    Для обеспечения безопасности тоже есть свои практики и инструменты, например практика Security Champions. В дополнение к этому есть отдельная команда со специалистами по безопастности которая может сделать аудит по запросу, но для этого TUL должен к ним прийти с этим запросом :)
  • 9 секретов онлайн-платежей. Часть 1: настройка 3-D Secure
    0
    Площадка имеет мало возможностей по выбору MCC. Обычно его просто выдает платежный шлюз или сам банк и если там не очень хорошо понимают специфику бизнеса, либо есть какие-то свои правила регулирующие выдачу, то коды могут выдавать очень разные.
  • 9 секретов онлайн-платежей. Часть 1: настройка 3-D Secure
    0
    В Америке проверяется насколько я знаю.
  • Антифрод. Быстро, дешево… отлично (часть 1)
    0
    Поле «имя на карте» помогает немного в защите от ботов, проверяющих список ворованных карт. Не все боты одинаково умные и многие подставляют в поле всякую фигню, которую легко распознать и блокировать платеж еще до отправки в платежную систему.
  • Как принимать платежи по кредитным картам — опыт Badoo
    0
    Если данные шифруются после заполнения формы в барузере и отправляются процессинговому центру, то через ваши сервера они не проходят. Значит вы их никак не обрабатываете, сертификацию проходить не надо.
    Пока транзакций мало, за тем что вы делаете с данными карточек никто особо следить не будет. Многое в этом бизнесе основано на доверии. Как только трафик начнет расти, к вам придет ваш собственный процессинговый центр и спросит про сертификат.
    Плюс подобное решение с шифрованием данных, не будут предлагать любому клиенту, толь проверенным компаниям, которым нет нужды заниматься мошейничеством с данными карт.
    И последняя дополнительная защита, это депозит, который процессинговый центр обычно просит внести при заключении контракта. Он должен покрыть все возможные издержки и компенсацию пользователям, если вы вдруг окажетесь не добросовестным клиентом.
  • Как принимать платежи по кредитным картам — опыт Badoo
    +1
    Да, совсем забыл про нее, спасибо за дополнение. Период через которой проводится авторизованная транзакция можно настраивать. Некоторые агрегаторы предлагают делать это в полностью ручном режиме. Тоесть если не послать запрос на отмену или подверждение списания, то через определенный период, транзакция будет автоматически отменена.
    По такому принципу например работает привязка новый карты в PayPal.
  • Как принимать платежи по кредитным картам — опыт Badoo
    +1
    А еще вопрос по процентам деклайнов от банков/шлюзов: вы не пробовали выстраивать каскады, когда если один шлюз отказывает, транзакция идёт на второй, третьий и т.д. пока какой-нибудь не заапрувит?

    Пробовали, работает :) Но надо быть очень аккуратным, чтобы не снять с пользователя деньги дважды или трижды.

    Кстати, меня всегда удивляло, почему PCI DSS позволяет хранить 10 цифр (в общем понять можно, чтобы отличать банки и идентифицировать карты), ведь учитывая, что последняя цифра это контрольная сумма, подобрать 6 оставшихся — секундное дело. (был опыт когда отказало 2 криптодевайса и пришлось востанавливать незавершённые транзашки)

    Нас при аудите просили зашифровать этих данных в базе. Чтобы получив к ней доступ нельзя было перебором подобрать номера.
  • Инвайт в подарок на день программиста!
    0
    1b1082086a708b21ab3b3f4e22b408df
  • Как принимать платежи по кредитным картам — опыт Badoo
    0
    Тогда я что-то не правильно понял из документации у вас на сайте :) Расскажите пожалуйста подробней как оно работает или дайте ссылку где почитать