Ни ответа ни привета. Почему рекрутеры не отвечают после интервью и как это исправить

За 6 лет опыта в рекрутменте я расширила сеть контактов в LinkedIn до 10 000+. Сегодня лента новостей — это способ держать руку на пульсе рынка кандидатов. Периодически встречаю такие посты, которые собирают много реакций и комментариев:

«Давно не ходила на собеседования. И вот за последний месяц побывала на нескольких. Все компании разные. Но все без исключения HR этих компаний состоят в одной секте „отсутствия обратной связи кандидату“. Это многое говорит об уровне компании, скажу я вам».

Причин тому несколько:

  • На трудовом рынке Украины условия все еще диктуют работодатели, а не кандидаты. Сравните два подхода: «Мы предлагаем людям работу» и «Важно, чтобы лучшие специалисты выбирали нас». Кандидаты до сих пор борются за внимание работодателя. Наверное, единственное исключение — Middle и Senior инженеры в IT.
  • Влияет постсоветский менталитет отношения к сотруднику как к трудовой единице, а не как к человеку. Специалисты воспринимаются как объекты для достижения бизнес-целей, а не субъекты взаимодействия в бизнесе.
  • Жесткие KPI по найму фокусируют внимание рекрутера на кандидатах, которые могут принести бонус. Но в долгосрочной перспективе специалисты, что не подошли сейчас, могут стать целевыми через несколько лет. Вот только они уже не будут рассматривать вашу компанию.
  • Отсутствие процессов рекрутменту приводит к тому, что рекрутеры теряются в потоке заявок, нанимающие руководители не предоставляют конкретный фидбек и кандидаты рискуют не получить ответ после собеседования.
  • Неправильное распределение времени команды заставляет кандидатов ждать собеседование с директором по 2-3 недели.

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

Candidate Experience Journey

Рассмотрим вопрос с точки зрения Candidate Experience Journey. Стартом будет наличие у кандидата потребности в работе и активный анализ предложений. На схеме я отметила основные точки взаимодействия работодателя с кандидатом. В основном это письма или формы обратной связи, которые может настроить любой сотрудник без особых навыков в программировании.

Секрет успеха кроется в трех ключевых составляющих: это вовлеченность команды в создание наилучшего кандидатского опыта, service level agreement (SLA) и автоматизации. Давайте рассмотрим, как эти факторы работают на разных этапах пути кандидата в вашу компанию.

Включенность команды

В Railsware сложный процесс отбора, который состоит из 4-6 этапов и занимает до 3 недель.

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

Люди — движущая сила любого бизнеса. Самые яркие таланты обычно получают сразу несколько оферов. И когда приходит время выбирать между предложениями с одинаковыми обязанностями и зарплатой, специалисты оценивают команду, с которой предстоит работать. Потому помните, что отбор проходит не только кандидат, но и компания. К тому же мы проводим на работе треть времени. Хотелось бы вам работать по 8 часов в среде без обратной связи и ощущения своей ценности для команды?

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

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

Если же нанимающие руководители и рекрутеры привыкли работать по KPI / SLA / еще каким-то метрикам, определите четкие критерии. Мы договорились так: даем обратную связь по всем входящим заявкам в течение 24 часов для приоритетных вакансий и до 5 рабочих дней для позиций с большим потоком кандидатов. Четкие сроки определите сами в зависимости от особенностей вашей организации. Мы посчитали среднее количество заявок и время на обработку каждой и пришли к таким SLA. Следовать им не так трудно. Если же вашей команде не хватает рабочего времени на выполнение этих показателей, привлекайте больше людей или меняйте свой процесс.

А теперь подробно о каждом этапе взаимодействия с кандидатом.

Описание вакансии

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

Решение № 1. Собирайте все заявки в одном месте и перенаправляйте туда кандидатов. В этом вопросе мне нравятся DOU.ua, Robota.ua и LinkedIn — тут возможно автоматически перенаправлять кандидатов на свою форму по ссылке.

Если же на job-платформе нет такой функции, пишите в описаниях вакансий, где подать заявку, чтобы команда быстрее рассмотрела ее. Я добавляю ссылку в тексте вакансии минимум 4 раза, но некоторые кандидаты все равно отправляют заявку не туда. Поэтому не забывайте настраивать auto-reply на платформе (если такая функция есть в наличии).

Финальной точкой может быть простая Google-форма или форма обратной связи на сайте.

Подача заявки

Наш следующий touchpoint — форма для подачи заявки. Дилемма: сделать ее максимально быстрой или максимально детальной?

Ответ: максимально детальной. Думаем шире: помимо обработки заявки рекрутером, вы захотите добавлять данные в ATS (applicants tracking system), фильтровать контакты по локации, позиции, отправлять email-рассылки пулу кандидатов и так далее. Потому лучше сразу разделить поля.

Решение № 2. Настройте форму для подачи заявки и интеграцию с ATS. Если нет ATS — заведите ATS. Иначе вы рискуете потерять кандидатов в процессе отбора, историю коммуникации с ними, а также возможность взращивать аудитории, которые уже знакомы с брендом.

Мы интегрировали Typeform с Pipedrive с помощью Zapier. Typeform создает хорошее первое впечатление за счет дизайна, удобной мобильной версии и возможностей кастомизации. Вы можете добавить фото или видео в начале формы и показать свою команду, офис, культуру.

Pipedrive сохраняет email-переписки с кандидатами и легко интегрируется с разными приложениями через Zapier. Мы описали преимущества использования Pipedrive для рекрутмента в этой статье. Связка Google Form + GSheets тоже подойдет для трекинга статуса кандидатов.

Автоматический ответ после отклика

Как только кандидат отправил заявку, начинается напряженное ожидание ответа. Используйте это время в пользу своего бренда.

Решение № 3. Настройте auto-reply и расскажите кандидату еще больше о предстоящем процессе, а также об уникальном опыте работы в компании. Автоматические ответы помогают формировать ожидания от процесса отбора.

С помощью Zapier мы подключили SendGrid и отправляем такое приветственное письмо каждому кандидату. С одной стороны, оно достаточно объемное. С другой — мы отвечаем на частые вопросы о том, когда ждать ответа, о структуре и длительности отбора, а также почему сотрудники работают в Railsware в среднем по 5 лет.

Оценка резюме

Заметьте, активная роль рекрутера начинается только на этом этапе. С помощью автоматизации мы сохраняем время внутренней команды и хорошее впечатление о компании.

На этапе оценки резюме вступает в силу внутренний SLA обработки заявок. Мы договорились давать ответ кандидатам на приоритетные вакансии в течение 24 часов. Для позиций с большим потоком — до 5 рабочих дней (тут собирается до 150 входящих заявок на рекрутера в месяц). Для упрощения работы рекрутмент-команды смотрите решения № 4 и № 5.

Решение № 4. Подготовьте стандартные ответы — отказы или приглашения на следующие этапы отбора. Вы можете либо автоматизировать ответ через CRM или Zapier, либо подготовить шаблоны в Gmail. Я предпочитаю второй вариант, так как в каждое письмо могу вручную добавить строчку с объяснением причин отказа или дополнительными вопросами кандидату перед отправкой. Люди ценят обратную связь с рекомендациями.

Решение № 5. Настройте автоматические напоминания о том, что нужно дать ответ кандидату. В Pipedrive мы подключили Rotting feature — теперь система подсвечивает просроченные сделки на разных этапах воронки. Вы также можете автоматически добавлять задачи в календарь для трекинга заявок.

Напоминаю, что все эти инструменты не требуют навыков написания кода. Интеграции могут быть настроены «уверенным пользователем ПК». Большинство из этих программ бесплатны.

Этапы отбора

Первый этап после подачи заявки в Railsware — тестовое задание. Мы разработали наборы тестовых для каждой позиции, на которую нанимаем. Задание занимает от 3 до 8 часов. Это отличный фильтр для кандидатов, которые ищут легких путей: на следующий этап проходят только 16,58%. Тестовое выполняют до конца далеко не все остальные. Многие перестают отвечать нам :) Но это и неплохо, так как наша цель — нанимать только самых сильных специалистов, которые любят решать комплексные задачи. В благодарность мы предлагаем нетривиальные проекты. На всех последующих этапах кандидат работает в паре с одним из наших сотрудников.

Решение № 6. В процессе появляются новые игроки — нанимающая команда. Начиная с тестового задания и на всех последующих этапах отбора, участники готовят чек-листы для оценки каждого задания. Фидбек в формате «что было сделано хорошо и что стоит улучшить в следующий раз» тоже подойдет. Все пункты записываем на бумаге, но лучше в онлайн-отчете. Так рекрутер предоставит детальную обратную связь каждому, кто выполнил задание.

С этого момента каждый ответ должен быть кастомизирован. Чем бы не закончилось общение с кандидатом, этот человек уже попал в 16,58% лучших по вашим базовым фильтрам. Важно сохранить хорошие отношения. Тут сложно придерживаться конкретных сроков, но мы стараемся держать кандидатов в курсе процесса и когда стоит ожидать ответ.

О том, как подготовить команду к оценке и найму, следует написать отдельную статью. Но в рамках нашей темы рекомендую подход под названием «Обратная связь высокого качества» (или «метод бутерброда»). Фидбек важно привязывать к действиям человека (а не к личности) и говорить об уже состоявшихся событиях (а не обобщать и делать проекции в будущее). Делитесь обратной связью с целью помочь кандидату расти и развиваться, а не подмечать просчеты.

Схема ОСВК: 70% что было сделано хорошо + 20% что стоит изменить / улучшить в следующий раз + 10% что еще было неплохо.

Пример: в ходе нашей коллаборации ты отлично справился с заданиями 2 и 3. Мы увидели, что ты владеешь необходимыми подходами и инструментами и можешь применить их на практике в анализе данных. Также ты быстро изучил контекст, задавал достаточно много вопросов и записывал, а после использовал новую информацию в решении задач.

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

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

Job offer

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

Некоторые компании любят выбирать. На финальном этапе отбора могут находиться одновременно 2-3 участника. И часто рекрутеры забывают предупредить первого из них, когда ждать ответа.

Также некоторые склонны поторговаться, но не на этапе первичных интервью, когда кандидат заявляет о своих ожиданиях, а уже на этапе предложения о работе. С одной стороны, кандидату неприятно, что этот вопрос возник только сейчас. С другой — ты уже инвестировал/а столько времени и сил в процесс, что отказаться не так уж просто.

Решение 7. Информируйте кандидатов о сроках принятия решения после каждого этапа. Если это неделя — сообщите об этом. Если процесс затягивается — отправьте еще одно письмо.

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

Но бывают и кейсы, когда навыки кандидата соответствуют его зарплатным ожиданиям вплоть до финального этапа отбора. И тут вдруг проявляются проблемы, из-за которых мы вынуждены снизить предложение. В этом случае помогают детальный фидбек и факты. Проведите с кандидатом ретроспективу финального этапа (в Railsware это полный рабочий день вместе) и объясните свое решение.

Подготовка к выходу на работу

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

Решение 8. Информируйте будущих сотрудников о предстоящем старте: когда и куда приходить, кого звать на помощь, чего ожидать. Убедитесь, что нанимающая команда подготовила план онбординга сотрудника и он/она не будет сидеть без дела первые 2-3 дня. Отсутствие информации со стороны компании после принятия офера — не то, с чем хотелось бы ассоциировать начало сотрудничества.

Онбординг и испытательный срок

Некоторые компании считают вакансию закрытой, когда человек успешно прошел испытательный срок. И это не безосновательно. За 3 месяца совместной работы появляется намного больше фактов о продуктивности и навыках сотрудника, чем за 10-20 часов отбора.

Решение 9. Со стороны компании важно выполнить четыре пункта:

  1. Предоставить всю необходимую информацию, доступы, контакты для того, чтобы новичок становился самостоятельным.
  2. Составить план на испытательный срок и озвучить цели новому сотруднику. Это может быть список проектов, которые нужно завершить за первые три месяца. По каждому проекту опишите критерии успеха (по SMART).
  3. В течении испытательного срока проводите регулярные фидбек сессии. Новичок еще не знает особенностей работы организации, ему/ей нужно больше подсказок с вашей стороны. Закладывайте правильные принципы с первого дня на работе.
  4. Обязательно подведите итоги испытательного срока согласно поставленным целям. «Само собой разумеется, что ты прошел» не работает. Сотрудник на испытательном сроке остается в состоянии волнения и неопределенности, как на экзамене. Чтобы снять напряжение и перейти в рабочий режим, официально подведите итоги и подтвердите прохождение ИС.

Заключение

Бренд работодателя — такой же бренд, как и любой другой. Тут применимы все лучшие практики маркетинга. Опыт кандидатов (=ваших клиентов) строится на взаимодействии с представителями компании в процессе отбора. Не ухудшайте положение простыми ошибками. Уделите одну рабочую неделю настройке процесса, инструментов автоматизации, подготовке писем и тренировке рекрутмент-команды. Положительный эффект не заставит ждать. Буду рада ответить на вопросы. Давайте дружить в Facebook и LinkedIn.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному6
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Первый этап после подачи заявки в Railsware — тестовое задание

Один раз в житті я таки виконав тестове завдання про що одразу ж пошкодував. На думку перевіряльника там була помилка, а на мою думку перевіряльник був просто тупий чи може плюси бачив вдруге в житті. Втім, доводити, ясно, нічого не став, не вистачало ще працювати під таким керівництвом. Відчуття — розвели як лоха на вихідний день.

З того часу всіх з тестовим відкладаю в кінець списку обіцяючи собі обов’язково спробувати, якщо вакансія цікава й альтернативи будуть такі собі — ще жодного разу до кінця того списку не дійшов.

Это отличный фильтр для кандидатов, которые ищут легких путей

Нє, це гарний фільтр для кандидатів, яких чомусь не встигли вихопити з ринку перед вами.

В благодарность мы предлагаем нетривиальные проекты.

«Не вірю» ©

тот момент, когда на собеседования в гугл/амазон/майкрософт тратишь в совокупности по 5 часов, а какая-то очередная ноунейм контора хочет чтобы ты потратил 8 часов на их тестовое задание (после которого еще приедет собеседование на часик-другой)

Первый этап после подачи заявки в Railsware — тестовое задание. Мы разработали наборы тестовых для каждой позиции, на которую нанимаем. Задание занимает от 3 до 8 часов. Это отличный фильтр для кандидатов, которые ищут легких путей: на следующий этап проходят только 16,58%. Тестовое выполняют до конца далеко не все остальные. Многие перестают отвечать нам :)

Взагалі про тестові можна довго вести дискусію, але в любому випадку я б до цього не ставився як до «чудового фільтру». Це «чудовий фільтр», якщо ви хочете відфільтрувати кандидатів, які не хочуть виконувати тестове завдання, бо цінують свій час та є варіанти інших роботодавців, які не вимагають виконання тестових.

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

Це погано, тому що сильні кандидати часто проходять повз тестові, бо в них завжди є вибір серед багатьох компаній — ви самі про це сказали на початку:

Кандидаты до сих пор борются за внимание работодателя. Наверное, единственное исключение — Middle и Senior инженеры в IT.

P.S.
У мене є досвід найму людей на різні позиції в свою команду без допомоги рекрутерів і це хороший досвід, бо в такому випадку маю змогу оцінити всі переваги кандидата напряму. Наприклад, була позиція на розробника вже з певним досвідом в розробці (Middle рівня, грубо кажучи). Першим етапом йшов скрінінг на 30 хв по телефону кандидатів, які зацікавили мене та ліда. Другим етапом була технічна співбесіда на годину-півтори з лідом, на якій присутні я та ще один досвідчений розробник. Нажаль, після певного часу не знаходились спеціалісти, які відповідали б за знаннями та кваліфікацією. Але резюме одного студента 3-го курсу мене зацікавило: хоч в нього й не було відповідного досвіду, тим не менш в резюме було вказано про участь в олімпіадах по математиці та хакатонах. Після технічного інтерв’ю лід та інший розробник сказали, що цей кандидат був кращий за всіх попередніх, хоч трохи і не дотягнув до бажаного рівня. В результаті ми найняли сильного молодого розробника, який за декілька місяців показав, що може чудово реалізовувати завдання. При цьому вигралі всі: компанія найняла робітника з меншими витратами, ніж закладувались на позицію; кандидату дали трохи більшу зп, ніж він просив; команда найняла здібного спеціаліста і чудового колегу. Це все відбулось без тестових, звісно ж.

Чи найняли би ми цього розробника, якби ми наймали по вашій схемі? Чи взагалі його б пропустив рекрутер і дав би йому шанс, звернувши увагу на сильні сторони у вигляді мат олімпіад та хакатонів? Я задавався цими питаннями і ми робили невеликий эксперимент, в якому два рекрутери надіслали з своєї сторони тих кандидатів, яких би вибрали вони. Результат їхніх «фільтрів» був досить сумним, бо вони не помічали багатьох важливих деталей, по яким я чи лід відсіяли б більшість їх кандидатів за десять секунд перегляду резюме. Два рекрутера не репрезентативний показник, звісно, але співпрацювати з більшою кількістю в мене не було нагоди.

P.P.S.
Майже всім кандидатам я надавав відповідь по їх кандидатурі. Можливо, не надав зворотній відгук декільком кандидатам з поміж 70-80 розглянутих.

честно говоря мне пофиг дадут фидбек или нет. если я активно ищу работу, я отправляю CV оптом в 10 компаний. кто первый даст собеседование и после него интересный оффер, туда и иду. конторы с тестовыми заданиями рассматриваю в последнюю очередь. для трейни с пустым CV тестовое наверное норм

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

308 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Анастасія, дякую за гарну статтю.

Какая-то странная статья. Да и 6 этапов отбора смущает. Это же не Amazon или Google. Если кандидата не смогли оценить за 2 технических этапа, то и 6 этапов тоже не помогут

Останім часом роблю тестові, якщо:
а) немає активних інтерв’ю без тестового;
б) на виконання завдання потрібно не більше 3-4 годин;
в) завдання не виглядає як частина проекту;
г) чітко сформульвана задача і критерії оцінки;
д) в компанії немає шквалу негативних відгуків;

Но это и неплохо, так как наша цель — нанимать только самых сильных специалистов, которые любят решать комплексные задачи.
Write an algorithm that takes an array and moves all of the zeros to the end, preserving the order of the other elements

Хлопці, гайда до них на борт, комплексні складні задачі!

То не подходит, что много этапов отбора, то «почему всего одна простая задача?»:) Оценка — это комплекс задач. Есть простые, есть сложные. Выполнив одни и не выполнив другие, Вы показываете свой профиль с разных сторон. Но задач очевидно несколько (особенно в нашем-то многоэтапном процессе отбора). Потому давайте смотреть на картину целиком, а не вырывать фразы из контекста.

Суть мого коменту не про те що задача проста та одна (покрутити аррай може бути досить складно якщо давно такого не робити), а в тому що такі задачі ніяк не релевантні актуальній роботі та проектним завданням.

Потому давайте смотреть на картину целиком, а не вырывать фразы из контекста.

Давайте дивитися. Ваш директор написав приклад завдання, інакшого приклада я не побачив.
Нижче ваш співробітник пише про 1.5 години на вирішення «абстрактної задачі». Я роблю припущення що це буде така сама маячня з циклами рекурсіями та перебираннями масивів, просто ще складніша, що аж півтори години треба сидіти, та водночас не має жодного стосунку до бізнес задач які потім треба буде вирішувати.

День парного програмування це ± ок, але чомусь у статті ви про це не згадали, а це між іншим один з ключових моментів.

Коротше кажучи як завжди, написали шопопало, купа корпоративного булшиту, фокус не на тому що цікаво кандидату, отримали відповідний негатив у коментах а потім виправдовуєтесь увесь тред бо вас не так зрозуміли, понасмикали цитат із контексту та взагалі у вас не просто шлюпка а цілий корабель з місією та продуктами по 500 000 користувачів.

На всех последующих этапах кандидат работает в паре с одним из наших сотрудников.

ну да, в статье про это ни слова:) и в auto-reply letter тоже:)

Я це зрозумів так що до кандидата прикріпляється ваш кабан і далі комунікація ведеться з ним а не так що тіп приходить до вас в офіс і вони сидять разом щось роблять.

Як інші це зрозуміли (якщо взагалі звернули увагу)—можете здогадатися самі з коментів.

>какая-то ноунейм-контора
>6 этапов отбора в течении 3 недель

Конечно же мы не можем тягаться с «Укренерго»

Безусловно. «Укренерго» наш основной конкурент.

На трудовом рынке Украины условия все еще диктуют работодатели, а не кандидаты. Сравните два подхода: «Мы предлагаем людям работу» и «Важно, чтобы лучшие специалисты выбирали нас». Кандидаты до сих пор борются за внимание работодателя. Наверное, единственное исключение — Middle и Senior инженеры в IT.

Ох, не соглашусь. Все зависит от того, кого компании ищут. Это только на словах все лучше из лучших, а если на деле, то все намного иначе. В любом случае, любая уважающая себя и свои деньги компания будет давать фидбек, потому что это:
а) человеческое отношение, которые тебе вернется бумерангом и банальное уважение к кандидату;
б) бренд, хорошее впечатление, лояльность;
в) экономия средств компании на ненужную рекламу, лишних рекрутеров и самое важное — время работы инженеров, которым приходится собеседовать не лучших, а кого рекрутерам удается притянуть на собеседование.

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

Остальные причины в точку.

Еще немного комментариев по тестовым заданиям:
— Тестовые задания обязательная часть процесса для каждой позиции
— Все кандидаты в рамках оной позиции выполняют одно и то же задание

— Мы не зарабатываем на тест тасках. Кто найдет способ как заработать на решении задачи Write an algorithm that takes an array and moves all of the zeros to the end, preserving the order of the other elements, того мы с удовольствием возьмем к себе в команду

— Кандидаты, которые проходят сложный процесс найма, понимают, что они будут работать с людьми, у которых можно будет многому научится. И для них это ценно

— Касательно «все компании одинаковые». Если интересно, то можно почитать о нашей модели в этой статье более детально dou.ua/...​a/columns/product-studio. Кроме сервисного бизнеса мы активно развиваем собственные продукты, общее количество пользователей которых превышает 500,000 и среди них очень много именитых компаний

Всем спасибо за комментарии и хороших выходных!

Write an algorithm that takes an array and moves all of the zeros to the end, preserving the order of the other elements

В чем смысл с таких задач? За 2 минуты можно найти решение в гугле. Одно дело спрашивать лично, а другое давать кому-то в качестве теста на дом.

Мы доверяем тем, кого нанимаем. Ищи в гуглуе и мы это поймем на следующем этапе.

Вы поймете, только вот зачем этот дополнительный шаг? Это разве что отсеять полных идиотов, которые не могут в гугле найти решение 100-ни подобных задач. Аля Leetcode, только вот если Вы даете подобные задачи они долны содержать уникальный контент, а не обычную копипасту из 100-ни подобных задач с одинаковым условием. Тот же Amazon хотя бы пишет какой-то текст другой в условиях задачи, чтобы запутать человека и не дать возможность тупого поиска по условию, но по сути всё равно одно и тоже.

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

Просто удивился насколько простое задание и зачем его вообще такое давать. Думал какой-то уникальный контент или задача, который можно давать на дом.

Большенство апликантов честно пытаются решить задачи

Слово честность здесь лишние. Допустим есть задача где нужно знать как применить алгоритм dijkstra algorithm. Я не Дейкстра и сам его врятли за 20 минут придумаю. Даже сам Дейкстра его за 20 минут не придумал и крутился в этой теме долгое время прежде чем выдать алгоритм, который применяют 100-тни тысяч программ. Но я знаю в чем суть алгоритма и всегда могу понять какая задача его требует. Мне не нужно его всегда помнить в супер деталях и доказательствах, но я могу его напомнить себе на wiki, если мне нужно. По-вашему это не честно, а по-моему я не ДЕЙКСТРА и никуда им не стану.

Допустим есть задача где нужно знать как применить алгоритм dijkstra algorithm. Я не Дейкстра и сам его врятли за 20 минут придумаю.

A* (алгоритм Дійкстри його окремий випадок) це базовий інструмент Справжній інженер його знає і пам’ятає навіть уві сні (що там пам’ятати? черга, купа та допустима евристика).

Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.

А что доказывает эта фраза? Только то что в Google не возьмут без знания алгоритмов. Для тех, кто не в контексте это сообщение написал создатель Homebrew twitter.com/...​status/608682016205344768

Справедливости ради, этот чувак достаточно странный. Просто почитайте его твиты или ответы в PromiseKit репо

Ну зачем впадать в крайности? Мы не требуем писать алгоритмы, которые требуют часы на обдумывания. Любой хороший инженер решает наши задачки за минут 20-30 без помощи Google.

Даже интересно стало, а вы примите решение типа:
— создать пустой массив Х
— пройти по исходному массиву в цикле и при этом ненулевые элементы скопировать в массив Х, а нулевые посчитать
— приписать к массиву Х полученное число нулей в конец
— вернуть массив Х?
Или тут кандидат предполагается, что должен повозиться с перестановками в самом массиве

само собой ожидается in-place с минимальным числом перестановок. иначе нет смысла такое задавать.

Вот это «само собой» всегда нужно озвучивать в тестовом. Для вас само собой это оптимизации, для других само собой отсутствие преждевременных оптимизаций. Для кого-то SOLID какой-нибудь важный критерий, для кого-то YAGNI...

Вариант (в зависимости от ЯП) — создать пустой массив нужного размера, который будет изначально заполнен нулями по дефолту (еще раз напомню — зависит от ЯП). Записать туда ненулевые значения за 1 проход.

Ну это та же схема, только массив создается фиксированного размера изначально. Временная сложность того же порядка, что и у оптимального решения О(n). Но они хотят решение с перестановками в цикле, я эту задачу решал когда-то просто уже, до оптимального решения додумался через 2 часа, при том, что очевидное решение выше приходит в голову примерно за 3 сек.

Я предположил, что подобная задача может быть еще и на знание платформы/языка. В случае решения в лоб, разница между фиксированным размером и динамическим может состоять в том, что фиксированный, например, выделяется на стеке, а динамический на куче.

А вариант с перестановкой в голову сходу такой пришел:
    int position = 0;
    for (int i = 0; i < count; i++) {
        if (i != 0) {
            int temp = array[position];
            array[position] = array[i];
            array[i] = temp;
            position++;
        }
    }
Оно или есть изящнее решение? Можно дополнительно проверять на i == position и не делать перестановку в этом случае, а просто инкрементировать позицию

Сори, не понял идею здесь вообще, пусть X = [1, 0, 1], тогда по итерациям:
1) pos = 0, i = 0, пропустили тело ифа — continue
2) pos = 0, i = 1, зачем-то поменяли 1й и 2й элементы, массив Х -> [0, 1, 1]
3) pos = 1, i = 2, зачем-то поменяли 2й и 3й элементы, массив Х -> [0, 1, 1]
В любом случае — зачем сравнивать с 0 счетчик цикла, а не элемент массива?
Хотя может у меня виртуальный отладчик поломался просто

i = 0, pos = 0 + 1, [1, 0, 1]
не нулевое значение, попадаем в иф
элемент на нулевой позиции меняется сам с собой, не оптимально, но пережить можно. отслеживаемая позиция инкрементируется
i = 1, pos = 1, [1, 0, 1]
нулевое значение, пропускаем иф
i = 2, pos = 1+1, [1, 1, 0]
не нулевое, меняем элемент с индексом 2 на элемент с индексом 1, 0 отправляется в конец.

Решение которое где-то за 2 минуты в голове сформировалось, думаю что есть варианты лучше.

Собственно, код по-идее должен компилироваться — можно проверить в обычном отладчике.

repl.it/...​s/ShortPointlessBloatware — надеюсь ссылка работает

так

if (i != 0) {

сбило, по ссылке правильно
if array[i] != 0 { 
если убрать холостые перестановки — оно, хотя реализация чуть другая (мне даже эта больше понравилась).

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

Блин, проглядел и когда набирал, и когда отвечал. конечно там должен быть array[i].

Извиняюсь, что сбил с толку.

Write an algorithm that takes an array and moves all of the zeros to the end, preserving the order of the other elements, того мы с удовольствием возьмем к себе в команду

а вы даете такую задачу в виде именно тестового задания на дом (и если да — то на какую позицию если не секрет)? решение таких задач мне кажется как раз лучше наблюдать в реальном времени?

Write an algorithm that takes an array and moves all of the zeros to the end, preserving the order of the other elements

Я вже почав думати що у вас там адекватний підхід, але тут ви мене серйозно розчарували.

Бутікове продуктове агенство з рейтами по 200 баксів за годину не спромоглося придумати нормального завдання...

1. тестовое задание это первый этап процесса. тест таск не должен быть сложным/длинным, но в тоже время должен иметь возможность отфильтровать кандидатов
2. вы ведь понимаете, что Сергей привёл абстрактный пример ?

если вам интересно, мы можем выслать вам тест таск, а вы можете его пройти в любое удобное для вас время. это несколько относительно простых задач, которые нужно решить на платформе www.qualified.io. в среднем прохождение занимает около 2х часов.

после тест таска мы проводим два основных этапа интервью:
1. сессия парного программирования на 1.5 часа, во время которой мы пишем решение одной абстрактной задачи
2. FullDay — полный рабочий день в одном из наших офисов. вместе с нашим инженером кандидат реализует настоящую задачу с одного из продуктов. FullDay проводится в обычном рабочем режиме, что позволяет кандидату посмотреть на процесс работы изнутри, а нам лучше понять, сможем ли мы сработаться с кандидатом в дальнейшем. Как и в вашем примере с Basecamp — это большая инвестиция времени с двух сторон, поэтому этот этап проводится последним.

Если у вас будет время и желание, мы с удовольствием проведем с вами все эти этапы интервью.

Кто найдет способ как заработать на решении задачи Write an algorithm that takes an array and moves all of the zeros to the end, preserving the order of the other elements, того мы с удовольствием возьмем к себе в команду

берите миня ни искал в гугле! ))

карочи идём по массиву находим 0 на его место записываем следующий не 0 и получаем 2 индекса to и from и просто двигаем их дальше по мере того как 0 соотв. пропускаем и двигается только from просто переходит на следующий а если не 0 то соотв. переписываем из from в to и сдвигаем как from так и to когда from доходит до конца массива место от to до конца массива заполняем нулями в принципе чисто теоретически можно попробовать ещё заполнять его прямо по мере продвижения from но это не точно но если подумать то может наоборот как раз нужно делая вместо copy swap но тут надо смотреть имеет ли вообще разумный смысл swap на 0

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

т.е. я к тому веду что в качестве тестового для нулевого уровня оно наверное подходит и даже годно но для какого-нибудь синьора уже сомнительно как вы считаете?

Хорошая схема на основе пузырька, 0 постепенно всплывают в конец, но надо каждый раз забегать вперед и искать следующий не 0 после перестановки,
и если 0 мало — всплывать они будут долго (много перестановок), поэтому менять 0 нужно не со следующим не 0, а с последним не 0 в массиве, тогда он сразу будет на своем месте.

И вот требовать именно уже самое оптимальное решение в реальном времени как проверку просто ненулевого уровня — ну это уже чуть сомнительно, мне кажется, не у всех мозг оптимизирован для быстрого решения задач такого типа, и не у всех синьоров в том числе (они то как раз задачи др типа обычно решают).
10-12 лет назад с 0 коммерческого опыта мне такие задачи давались значительно легче чем сейчас, мозг по другому работал

не получится потому что перестановок вам не избежать потому что на самом деле это не «ноль всплывает» это «остальные элементы тонут» ))

как я сперва написал на ноли вообще можно забить и потом просто «добить остаток нолями» просто потому что уже не важно что там было но всё что не ноли придётся таки «утопить» иначе ему в начало массива ну никак не попасть селяви

и дальше фактическая «оптимальность» сводится к пониманиям «проходимости» массива т.е. скажем считать отдельный проход по заполнению нулями за отдельный проход или нет или скажем основной алгоритм нет смысла начинать совсем пока не найден первый ноль но это считать за проход или нет?

т.е. скажем 0 на 5-м месте соотв. добежали до 0 ок это проход? дальше добежали до конца последовательно «топя» элементы при этом можно не делать swap просто потому что возможно так будет даже эффективнее просто потому что незачем 0 записывать мы и так знаем что это 0 это пусть будет «основной проход» и дальше взяли то место где был последний «утопленный» элемент в данном случае 10-е место и просто записали туда 0 это считать за «проход» или нет?

или скажем то что мы используем 2 индекса это 1 «проход» или 2? ))

проход там будет фактически 1 несмотря на 2 индекса, просто эти 2 индекса встретятся внутри массива и процесс прекратится, схематично

int i = 0;
int j = array.size() - 1;
while (i < j) {
  while (i < j && array[j] == 0) j--;
  if (array[i] == 0) {
    swap(array[i], array[j]);
  }
  i++;
}

выше в коментах еще был неоптимизированный пример этой же схемы только в др сторону: repl.it/...​s/ShortPointlessBloatware

ЗЫ решение не мое, я сам решал пузырьком, вернее обратным пузырьком, где элементы действительно тонут

preserving the order of the other elements

не сдал приходи на следующий год

ЗЫ: ок чуваки признаю силу вашей задачи в качестве рабочего входного фильтра ))

ЗЫ: впрочем я тут между делом пхп балуюсь и «подчищаю всякое за веб девелоперами» так что в вашей бизнесе видимо бывает я проверял ))

эх, таки проглядел(((

там ещё хорошее дополнение

Minimize the total number of operations.

к.м.к. стратегия swap только создаёт «видимость однопроходности» но на самом деле будет постоянно перезаписывать ноли туда сюда

но и опять же ж следуя уже это доп требованию интересно было бы б подумать об «единовременном перемещении сразу на своё место» скажем хотя бы б «скипать» целые «пролёты» нулей сразу за 1 раз

но и опять же ж следуя уже это доп требованию интересно было бы б подумать об «единовременном перемещении сразу на своё место» скажем хотя бы б «скипать» целые «пролёты» нулей сразу за 1 раз

чёт я туплю в «базовом алгоритме» они и так фактически «скипаются» просто потому что «ноли не тонут»

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

ЗЫ: ок чуваки признаю силу вашей задачи в качестве рабочего входного фильтра ))

ЗЫ: впрочем я тут между делом пхп балуюсь и «подчищаю всякое за веб девелоперами» так что в вашей бизнесе видимо бывает я проверял ))

вон один уже не прошёл ))

задача несложная и абстрактная

В реальному житті така задача виникає час від часу, але там і обмеження можуть бути типу «без додаткової пам’яті», або «за один прохід».

Задача насправді непогана: спочатку перевірити чи може кандидат писати код взагалі і наскільки цей код легко читати. А потім вже можна додавати умови і обговорювати потрібні модифікації та обмеження.

Задача насправді непогана: спочатку перевірити чи може кандидат писати код взагалі і наскільки цей код легко читати. А потім вже можна додавати умови і обговорювати потрібні модифікації та обмеження.

я для себя начал рассматривать 3 уровня программистов

№ 1 синьор это который может писать код «от начала и до конца» здесь читай ещё и проведя его от задачи в джире через код ревью и qa до финального мержа в мастер

№ 2 лид это который может писать код сообща с другими лидами в т.ч. координировать синьоров в писании кода сообща уже синьорами

ЗЫ: тут к моему удивлению оказалась интересная ачивка но люди вообще не представляют себе «как делать сообще» и вообще даже «а что так тоже можно было?»

№ 3 эксперт это который может решать задачи уже технического плана «не просто код» и «код который не просто»

причём эта классификация прекрасно соотносится и к не программистским целям и работает вообще я уже проверял ))

Достаточно забавно, на самом деле, только сегодня решал задачу на кодварсе именно вот эту, только условия были чуток сложнее. 4-й уровень, за один проход решать не все умеют, но я совсем изворотился от скуки (хобби такое, щито поделать).

Наслаждайтесь, мое собственно тоже найдете там, единственное в своем роде, конечно.
P.S. ответ даст, дежае www.codewars.com/...​058f/solutions/javascript.

const interpolate = (literals, ...expressions) => {   let lits = JSON.stringify(literals)   let string = ``;   let result = [];   let zeros = [];   for (const [i, value] of expressions.entries()) {         for (const [i, val] of value.entries()) {           if (val !== 0 && val !== '0') {             result[result.length] = val;           } else {             zeros[zeros.length] = val;           }       }     }   return [...result, ...zeros] } const removeZeros = (arr) => interpolate`${arr}`; // P.S. цикла написано хоть и два, но два их будет  // только в если вызывать как показано в // следующем блоке кода

Отдельно для читающих, которым покажется через чур — тут есть небольшая хитрость и только из-за нее сделал необычно, но кстати, по скорости если убрать лишний JSON.stringify — быстрее не отработает, просто прокиньте в консоль код сверху без дебильного последнего конста, который нужен для кодварса и сделайте так

const initial = [7, 2, 3, 0, 4, 6, 0, 0, 13, 0, 78, 0, 0, 19, 14]; const initial2 = [72, 0, 1, 0, 4, 6, 0, 0, 13, 23, 78, 0, 0, 19, 14]; const initial3 = [0, 2, 3, 0, 4, 6, 0, 0, 13, 0, 78, 0, 0, 19, 0]; interpolate`${initial}${initial2}${initial3}` // P.S. Ща будет магия

Оптимально? Нет. но за-то как красиво. Ненавижу циклы, а в задаче (по крайней мере этой) — условие такое же как на которое вы поставили, но не использовать методы массивов и объектов. Настолько ненавижу что написал внедрение в процесс интерполяции строк (да, тоже цикл, но этот быстрый :)).

Хочешь нормальное — вот. Если интересно нормальное решение за О(n) будет что-то около такого

const initial = [7, 2, 3, 0, 4, 6, 0, 0, 13, 0, 78, 0, 0, 19, 14]; const zeroesArray = []; const removeZeroes = (arr) =>   arr.reduce((p, c, i, array) =>     ((i === array.length - 1) && [...p, c, ...zeroesArray]) ||     ((+c && c !== 0) ?       [...p, c] :       (zeroesArray.push(0) &&     p)   ), []); removeZeroes(initial)

А теперь на тему тестовых — принципиально не делаю, не потому что не хочу в свободное время заниматься чем-то связанным с программированием, а потому что не хочу заниматься неинтересными, одинаковыми задачами в свободное время. Кто просит сделать тестовое — кидаю ссылку на мой сендбокс, там весит прикольный показательный во многих местах код, а делать тудушки — максимум джуны будут. Да что таить то? Я и сам джуном был сделал 1-2, просто руку набить, полезный опыт.

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

Как итог — не думаю что вы видели такой подход. И он неоправданно сложный, но иначе совсем скучно. И не увидели бы, ведь на тестовое я бы сразу сказал что мне лениво...

Если прочтете — напишите, пожалуйста, считаете ли вы все еще что тестовое оправданно для любой позиции?

Тим часом Basecamp дають тестове завдання як один з етапів найму.

m.signalvnoise.com/...​rs-with-a-take-home-test

Втім, до тестового завдання доходять не всі, а лише невеликий відсоток фіналістів. Перед тим оцінюється їх супровідний лист та CV. Впевнений що тут ніхто ніколи не писав cover letter тому що навіщо?

But for programmers, we don’t need a project that large to get a good indication of someone’s programming skills or thought process. With both of the last two openings, we used assignment that were estimated to take 3-5 hours to complete.

That’s still a very substantial commitment! I wouldn’t ask anyone to submit such unpaid work without believing they were clearly in the running for the position. But when you look at our numbers, we usually don’t end up asking more than 1-3% of our applicants for such a commitment.

Раніше Basecamp винаймав людей з open-source спільноти, тобто якщо ви були активним контриб’ютором в Rails, то у вас були б хороші шанси. Проте зараз вони вважають що оцінювати людей тільки за наявністю опенсорс проектів, або вкладу в існуючі невірно, але і без перевірки того як людина програмує жити не годиться. Цим і мотивоване тестове завдання.

Щодо вашої контори, то проблема людей нижче по треду полягає в тому, що вони вважають, що ви замахнулися на священне—намагаєтесь ставити себе вище звичайного в Україні аутсорсу або аутстаффу.

Бачите, більшість з них ніколи не вийде з лав галерного програмування (хоча їм дуже хотілось би), відповідно в Україні нема і не буде ніяких компаній які змінюватимуть світ або робитимуть рокет саєнс. В очах пересічного гребця ви нічим не відрізняєтесь від звичайної вебстудії яка робить все що попадається під руку. А раз ви звичайна веб-студія, то як ви насмілились декларувати свої правила гри? Хто вам дозволив? Як краби, які не тямлять що з відра не можна вибратися, якщо тягнути своїх братів назад, вони тягнуть вас назад на дно українського аутсорсу і кажуть: «сиди і не рипайся! Бач, бутікове продуктове агентсво! Що надумали собі! А ну назад, на дно, де гребці не підіймають очей до неба та бачать поток проектів за які ще треба конкурувати з індусами». Відповідно ніякої «культури» у вас немає і бути не може, ваші «рейти» нічого не значать для кінцевого розробника, якому, як і його брату з єпаму, дістаються лише крихти. Проекти у вас нічим не кращі та не гірші за ті що клепаються командою джунів з-під одного апворк акаунту в трикімнатній квартирі на оболоні (тру сторі). У вас така сама потогонка як і усюди, такі самі умови а відповідно щоб потратити до вас на роботу, ви самі повині гребця запросити і ще обслужити.

Бач, тестові завдання надумали!

Цікаво, що було би, якби такий самий матеріал написали Grammarly. Адже в них теж є тестове, і купа етапів на одному з яких гребця просять дати контакти одного зі своїх попередніх менеджерів і потім телефонують. Мені телефонували і я мав розмову щодо свого колишнього колеги, в якого я був менеджером. Отакий секуріті-та-факт-чекінг, що вони собі дозволяють! Втім, думаю що на Grammarly би тут ніхто не наїхав, крім вже зовсім фрікуватих товаришів.

Беру деякі слова назад, якщо ваші завдання всі по типу

Write an algorithm that takes an array and moves all of the zeros to the end, preserving the order of the other elements

то ви якісь скажені каргокультисти які думають що вони фаанг. Дізлайк відписка.

Насколько важно фоллоу-апить рекрутера? С одной стороны есть негласное правило, что отсутствие ответа равно отрицательному ответу, с другой стороны всё равно рекомендуют напоминать о себе: убедиться что ваше дело не потерялось и проявить настойчивость.

Спасибо за вопрос.
Я думаю, что это нормальная практика профоллоу-апить рекрутера.
Мы стараемся избегать таких ситуаций и апдейтить кандидатов про их статус (механика описана в статье:), но не исключаю ситуаций когда рекрутеру нужно напомнить о себе.
Рекрутеру часто приходиться фоллоу-апить кандидатов и это нормальная практика.
Типичные ситуации:
— прочитал сообщение и не ответил (забыл, не захотел)
— не прислал тестовое задание в указанный дедлайн, забыл сообщить об этом
— не захотел дальше двигаться по процессу, стало лень сообщать об этом
— забыл сообщить, что принял оффер другой компании и так далее
Фоллоу-ап применим к обеим сторонам, человеческий фактор никто не отменял. Другое дело, когда не отвечают после двух фоллоу-апов, тогда это может указывать на то, что ответ отрицательный и лень отвечать. Кстати, это частое явление для обеих сторон.

У вас процесс на высоте :) Чаще же бывает, как автор и написала, никакой обратной связи. И это явление международное и касается всех индустрий. На реддите, например, популярно мнение, что молчание — это отказ by default, и нет смысла переспрашивать, такие правила. А рекрутеры наоборот советуют напоминать. Статистику по тому насколько это успешная практика я не видела, интересно будет если кто-нибудь напишет.
А кандидатов я с какого-то момента перестала фоллоу-апить. Если ты не ответил или не сделал что обещал, значит ты не сильно заинтересован, и мы наверное друг другу не подходим ¯\_(ツ)_/¯

Знаєте, ваші схеми з тестовими завданнями на 4-8 годин неоплачуваного часу кандидата чимось мені дуже нагадують сумнозвісні «нігерійські» листи... чи навіть СМСки з «виграшами» 400 тис. грн. )))
Ставте лойс коли теж бачите спільні риси.

Там опечатка.
People’s Team Lead — народный тимлид Украины, это следующая лычка после заслуженного — Merited Team Lead.

А потом уже идет звание Герой труда ?

Никогда не давал тестового кандидатам на позицию мидл+, как собеседующий. Вообще не понимаю, каким должно быть задание, чтобы понять, что человек именно синьор, а не, скажем, мидл.
Специально проходил собеседования и делал задания на позиции синьора, лида. И, несмотря на то что компания считает свои задания интересными и сложными, они все (задания на 2-3 часа) были на уровне того, чтобы отделить мидлов от джунов, или джунов от совсем не умеющих ничего людей.
Для себя я решил просто: если интересный проект и есть время, то я могу сделать тестовое, но, обычно, при активном поиске работы, предложений столько, что времени делать тестовые просто нет.

К сожалению грешил этим когда-то.
Потом плавно перешел к варианту с парным кодингом на месте и общением в процессе. Потом вообще ушел от этого подхода.

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

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

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

В обоих случаях, тестовые частично покрывали мою некомпетентность как интервьювера.

А мені подобається робити тестове. По перше вважаю що — покажи свій код, найкращий спосіб познайомитись з програмістом. По друге — з тестового можна зрозуміти що за компанія. Наскільки завдання заточене на те, щоб кандидат показав вміння чи це якась фігня для галочки. Якої якості рев’ю. Допомагає прийняти рішення чи взагалі варто мати справу з ними. Були випадки коли щасливий біг від них радіючи що не попав працювати з тими дятлами. Думаю були випадки коли і рев’ювер радів, що не прийдеться зі мною працювати.

Спочатку писав це як відповідь на коментар Артуру Терменжи, але вирішив винести на верх для загального обговорення.

Полтора часа обычно недостаточно,

Ніт, півтори години це золотий стандарт аби одна-дві досвідчені людини розпізнали наявність/відсутність релевантного досвіду у кандидата для їх задач.

Ваш підхід навіває мені дві думки:
1. Ви і ваші інженери не вміють проводити адекватні змістовні співбесіди. Це нормально щось не вміти, головне, це визнати це, хоча б самому собі. Проведення адекватних змістовних інтерв’ю це також скілл, який можна здобути прочитавши теорію + практика.
2. Ви від початку шукаєте більш морально гнучких людей, яких можна прогнути під ваші умови і які, у випадку проблем або конфліктів, не будуть стояти на своєму, а приймуть ваші умови. Це також нормально. На заході для цього проводять Cultural Fit Interview, там відкрито декларують, що шукають не тільки кваліфікацію, а це й певний min set, певну систему цінностей і поглядів яка збігається з поглядами компанії або конкретного менеджера і команди.
До речі саме через цей пункт, на інтерв’ю, я завжди прошу описати ідеального кандидата на цю позицію, з якими скілами та якими поглядами і системою цінностей вони шукають.

Нажаль, чесність все ще чужда українському ІТ ринку, як компаніям так і кандидатам, тому ми бачимо подібні статті, коли компанія має якісь цілі і прагнення, як я описав вище, абсолютно нормальні і зрозумілі, але замість того аби бути чесними і відкрито декларувати свої наміри і свою політику, ми бачимо як прикриваються «процесами».

"

прошу описати ідеального кандидата на цю позицію, з якими скілами та якими поглядами і системою цінностей вони шукають.

" деякі у нас вміють шукати ідеальних — має знати все і вся, прогинатись під систему, бути готовий овераймити і все це за мінімум грошей

Відповідь на це питання дає дуже багато інформації, як про самих інтерв’юєрів так і про компанію загалом.

Жарти в стилі того, що написали ви це теж відповідь, адже, як відомо, в кожному жарті лише доля жарту і якщо відповідь буде така, значить і вектор розвитку в компанії буде такий.

Как и любой бизнес, если контора на плаву — значит стратегия жизнеспособна и указывать со стороны их неправильность или аморальность бессмысленно. Это не хотелки HR. Значит находится достаточно людей принимающих такие правила игры.

Без проблем, ринок досить широкий, просто хтось вміє вчитись і виростає до рівнів Єдинорогів або аутсорсерів рівня DXC, а хтось лишається містячковим інтернет-агенством на 30 людей.

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

Важно уточнить, что мы не пытаемся нанять максимум сотрудников. Рост нацелен скорее на качество, а не на количество.
Если бы у нас была цель вырастить штат инженеров до трех сотен в течении года — скорее всего мы бы сократили процесс до одного интервью в полтора часа. Однако такой цели нет.

2. В нашем процессе интервью также присутствует этап Culture Fit, однако это не способ кого-либо «прогнуть», либо навязать чуждые ценности.
В одной из других статей мы описывали как работаем и каких кандидатов ищем — dou.ua/...​icles/product-engineering

Это же детальнее рассказываем и на Culture Fit, а также отправляем ссылки на первых этапах знакомства.
Это достаточно прозрачный подход, более того, он как раз нацелен на проактивных кандидатов, способных защитить свою точку зрения.

буду рад понять, как вы увидели здесь отсутствие честности.

Интересно, есть такие компании, которые предлагают выполнить не оплачиваемое тестовое часов так на восемь, и после согласия кандидата, сразу ему отказывают, аргументируя это тем, что человек: не дорожит потраченным временем, в отчаянии и готов хвататься за все подряд(значит будет непродуктивно расходовать время), его не взяли другие компании и он поэтому согласился, готов работать бесплатно со всеми вытекающими.

Конечно нет, но ему предлагают з.п. меньше, чем тем кто тестовое не выполнил

Скажу за фидбек. Если фидбек формальный, в духе не подходит кандидат просто потому что, или видно что рекрутеру не потрудились уточнить, или ей просто лень. Это тоже чувствуется, и лучше в таком случае уже промолчите

Лучше уж формальный фидбэк, чем его отсутствие.

Ого, тут всі так ополчилися на тестові. Не хочете? Не робіть! От вже розвели драму. Так само як компанії з тестовими не будуть мати одних хороших кандидатів, ви не будете працювати в хороших компаніях з тестовими.

Є багато по-мудацьки вимогливих та безглуздих тестових, несмак видно здалека, легше виявити стрьомну компанію. Трапляються хороші, годні, які несоромно вирішити, і не заберуть більше 1-2 години часу перед тим подумавши.

Хаха, жартую! Тестове — марна трата часу, існує безліч інших варіантів як відфільтрувати хороших кандидатів. Он стільки всього альтернативного придумали. Вирішуйте все по інтерв’ю, у вас же є люди і гроші на це, беріть на роботу а там розберемося, для чого ці всі бар’єри? Втрачаєте стільки талантів!

lh3.googleusercontent.com/...​CWGb3WY4×2hwzis4rtUW2-ovc

Как всё перекрутил. Самое страшное оружие — это надежда.
А вдруг там где тестовые, самые лучшие конторы?

Те конторы что без тестовых пускают, они настолько плохи, уже

у відчаї

Прошу зауважити що я не писав що всі компанії з годними тестовими — хороші для роботи. Треба завжди зважувати свої рішення залежно від ситуації.

А конкретно в цьому топіку складається враження що «тестове — зло», і найоптимальніший шлях це йти в компанію де процес найму займає найменше часу. Кек.

«тестове — зло», і найоптимальніший шлях це йти в компанію де процес найму займає найменше часу. Кек.

Именно так, тестовые задания проверяют будешь ли ты послушен

Бачте, є люди, які роблять тестові, курсові, дипломні за плату. Вважаю, що кожен з интерв’юерів стикався з цим явищем. Й є такі люди, які можуть захистити тестове, яке вони не робили, як кожен з нас може розібратись з чужим кодом й підтримувати його.

Бар’єр лишається бар’єром, у випадку з «тестовим за гроші» бар’єр буде подоланий ціною витрати грошей і вдвічі більшої кількості часу (написати одному і розібратися іншому), з шаленим ризиком спалитися. Намахати можна в будь-якому випадку, але цей випадок має подвійне пенальті, якщо спалився — вигонять сцяними ганчірками, і не є чимось «робочим».
Хіба це велика контора яка може дозволити собі дармоїдів.

А якшо продовжити логіку : чому б тим людям, які роблять тестові за гроші, по дивному збігу обставин та не працювати на півставки в тій же хвірмі, куди намагається влаштуватись кандидат ?
Ви думаєте це фантастика? А от і ні.
Невеликі контори зазвичай запрошують для проведення технічної стадії інтерв’ю сторонніх спеціалістів, які за дивним збігом обставин є викладачами всіляких там курсів з програмування...
А тепер складіть два рази по два.

А чому б не кинути старе через хвилину після отримання файлу? А потім вже для себе зробити на тому ж стеку.
Мені було б цікаво подивитися на реакцію.

Ну, это фидбек комьюнити на идею тестовых.
Будет ли к нему прислушиваться менеджмент компаний или нет — дело менеджмента

И все же после статьи и тонны комментариев я до сих пор не понимаю зачем нужно заморачиваться и идти в вашу аутсорсинговую компанию если можно без такого напряга пойти в любую другую из топ-20 ?

Смотря что для тебя топ-20. Многие кандидаты выбирали нас из-за того, что устали от плохих процессов, низкого качества кода, заказчиков, которые не могут понять чего хотят, а ты все переписываешь и переписываешь. Многие еще устали от бессмысленных продуктов. Некоторые отмечают интересность задач, которые мы предлагаем в процессе отбора, чему-то учатся. Все проекты указаны в описании вакансии — можно посмотреть, интересно тебе такое или нет. Увидеть команду (возможно, ты некоторых знаешь и хотел бы с ними работать). Я могу продолжить список, но все зависит от того, решаешь ли ты на основе «зарплата+легкий процесс» или мыслишь глубже.

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

Як ті 90% кандидатів, що ви набираєте зовнішньо, дізнаються про цікаві проєкти, хороші процеси,
адекватний менеджмент ДО того як влаштуватись до вас? Більшість кандидатів загуглять інфу про компанію, почитають відгуки на доу, додадуть враження від перших співбесід і зроблять для себе висновок, чи підходить їм компанія.

Кроме тестового задания, есть еще несколько этапов интервью, во время которых можно задать эти вопросы, а мы с удовольствием расскажем.

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

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

У вас інтерв’ю проходить після тестового — де взяти мотивацію проходити тестове? Ви дійсно не бачите логічної помилки чи це справа принципу стояти на своїй позиції?

Я справді намагаюсь зрозуміти чим ваш процес кращий. Поки що видно, що ваш процес генерить чудову статистику відбору: ’1 з 70 кандидатів проходить’, ’тільки 16.58% проходять перший етап відбору’ — звучить красиво і круто при поясненні рейта в 85 баксів/год для чергово кастомера, але по факту це не показові цифри.

Андрей, добрый вечер! Что касается технических позиций, есть два варианта:
— если кандидат был найден рекрутером и после первого письма/сообщения заинтересовался позицией, мы отвечаем на все его вопросы, и также рассказываем о процессе отбора. В таком случае, для кандидата не является сюрпризом наличие тестового и, если он не желает его выполнять — он может отказаться. Кроме того, есть опция пойти на интро колл с Managing Director, чтобы иметь возможность узнать о компании больше. Здесь особой статистики нет — есть кандидаты, которым важно сначала пообщаться вживую с представителем компании, есть и те, кто сразу готов переходить к тестовому. Насчет мотивации — она появляется, если человек, услышав ответы на свои вопросы и узнав инфу о компании понимает, что ему это подходит.
— если кандидат сам подался на вакансию, во-первых, как было уже описано в статье, ему приходит авто-ответ с описанием этапов отбора, и, опять же, этап тестового для него снова не новость. в комментариях ниже моя коллега уже упоминала, что в данном случае мы предполагаем, что человек уже что-то о нас узнал, его заинтересовала позиция и в этом случае у него точно так же есть мотивация сделать тестовое :) Кроме того, если у него есть вопросы — он их задает и получает ответ.

але по факту це не показові цифри

Возможно. Более показательным, наверное, будет то, что в среднем ребята остаются работать в компании 6+ лет, и у них нет нужды сменить компанию через несколько месяцев или год, потому что ожидания не совпали с реальностью. Это оправдывает более энергозатратный процесс отбора. Для компании он оправдывается тем, что из нанятых сотрудников 95+ % проходят испытательный срок.

Если у Вас есть какие-либо еще вопросы — будем рады ответить :)

Денис, статья и не была нацелена на то, чтобы убедить кого-либо в том, чтобы идти в нашу компанию (мы, кстати, НЕ аутсорс:)). Как было написано в самой статье:

Это отличный фильтр для кандидатов, которые ищут легких путей

Ребята, которые у нас работают, готовы были заморочиться, потому что наши ценности, процессы и подходы перекликались с их ценностями :)

Точно, не аутсорс) prnt.sc/ska5o9 «Фабрика решений для клиента ?», «Бизнес партнер который решает проблемы ?» В последнее время все чаще сталкиваюсь с такими рассылками, где аутсорсинговые компании придумывают новые абстракции для своей деятельности, но суть все та же.

тот момент, когда на собеседования в гугл/амазон/майкрософт тратишь в совокупности по 5 часов, а какая-то очередная ноунейм контора хочет чтобы ты потратил 8 часов на их тестовое задание (после которого еще приедет собеседование на часик-другой)

там не 5 часов, 5 часов это после online coding на 2 часа (считай что тестовое) и после телефоного с HR.

у амазона онлайн кодинг у меня занял 20 минут, максимум там кажется полтора часа дают плюс 4 интервью по 55 минут — итого 4 часа ну плюс еще созвоны с эйчарами.
майкрософт — онлайн кодинг занял минут 30, плюс 4 интервью по 55 минут — итого 4 часа 10 минут и созвоны с эйчарами.
гугл — телефонное интервью на 45 минут плюс 5 интервью по 45 минут — 4 часа 30 минут и созвоны с эйчарами.

Итого в худшем случае без учета бесед с эйчарами (а я говорил только за тестовое плюс собес) — 5 часов.

Online coding за 20 минут на 2 задачи? Наверное что-то совсем простое или просто копи-паста готового кода «из кубышки». Первая задача простая и действительно можно сделать за минут 10, если рука набита. Вторая задача сложнее и вникнуть в условие занимает больше времени и код написать тоже не 5 строчек. Хотя Amazon сильно упростил всё последнее время и попасть туда на низкие уровни (все что ниже L6) не очень сложно, но зарплата будет не высокая.

да, были достаточно простые — медиумы с литкода и я подобные решал, но в худшем даже случае, если использовать все полтора часа — это около 5 часов на техническую часть в сумме.

у амазона

в остальных фаангах очевидцы рассказывают иногда о днях

а откуда дни берутся в множественном числе? Это в смысле, что сегодня у меня один час собеседований, завтра 4 и в сумме получается два дня?

тут на dou был чей-то рассказ
больше одного дня онсайт

сорри, ИМХО ты что-то путаешь, в крайнем случае это было растянуто на два дня, как я сказал.
Максимум о чем я слышал — 6 собеседований меньше часа каждое, что никак не суммируется в 8 или больше

при чем тут что во что суммируется, человек на несколько дней полностью выпадает из жизни, плюс дорога туда/обратно

*facepalm* любопытно, как абсолютное большинство однодневных собесов превратились в

несколько дней полностью выпадает из жизни, плюс дорога туда/обратно

«Выпадает» один день, в худшем случае, если офис на другом континенте еще выпадают два на дорогу.

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

Я бы сказал что проблема скорее в другом. Мне кидали тестовое на синьорские позиции и я вежливо слал нахер. Его может реально сделать за 2-3 часа как написано, но только тестить будет некогда, дизайна будет ноль, а код не будет показательным. Я как-то делал тудушку обычную (сам захотел прости господи, даже работу не искал), так часов 10 ушло на то чтобы именно круто получилось, (при том что дизайном я вообще не парился, минут за 15 сделал весь с материалом). Собственно просят тестовое — кидаю ее до сих пор и говорю либо так, либо никак. Все равно даже два часа жалко тратить на горе любителей сэкономить и отсеять.

люди, которые тратят на гугл/амазон/майкрософт в совокупности по 5 часов, как правило туда не попадают

в смысле? Учитывать подготовку? Здесь же речь непосредственно о собеседованиях, а не о получении скилла, достаточного для прохождения в оный

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

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

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

Время, затраченное на интервью мы оптимизируем только когда первая задача решена. Мы не пытаемся нанять максимум людей в сжатые сроки.

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

И? Львиной доле компаний для этого не нужно тестовое на 8 часов.

Время, затраченное на интервью мы оптимизируем только когда первая задача решена. Мы не пытаемся нанять максимум людей в сжатые сроки.

А можно расшифровать эту цитату? Я вот ничего не понял из того, что было сказано. Что значит «Оптимизация времени, затраченного на интервью»? «Когда первая задача решена» — означает, что вы можете откинуть кандидата после первой задачи? Ну так это и в ФААНГах есть.

Смысл в том, что у не-джунов дофига собеседований, когда они выходят на рынок. В последний раз у меня было восемь за две недели и то, я откинул то, что мне совсем не подходило. Мне страшно представить что бы было, если бы каждый следовал этому принципу, что на компанию надо было выкинуть около десятка часов. И чтобы получать лучших, вы должны предлагать что-то такое, что не предлагают другие, что вас выделяет. Что предлагают FAANGи, Jane Street, Palantir и прочие я понимаю, что предлагают компании вроде вашей, я не понимаю.

что предлагают компании вроде вашей, я не понимаю

Они действуют из предположения, что если человек сам им прислал резюме, то он уже сознательно заинтересован попасть именно к ним. Естественно, это не так — на рынке полно кандидатов, которые рассылают резюме куда только руки дотянутся. Но, они своим процессом отбора отсеивают таких на ранних этапах. И, что сцуко характерно — это вполне рабочий подход, если не стоит задача «нанять максимум людей в короткие сроки». Если бизнес-модель Railsware позволяет такое — ну чо, респект ребятам.

А если сами хантят, то выше упоминали, что рассказывают кандидатам о своих преимуществах, прежде чем выдавать тестовое.

спасибо за уточнение.
именно так — насколько мы заинтересованы в кандидате, настолько и у кандитата должны быть причины попасть именно в Railsware. процесс настроен на двустороннее сотрудничество.
конечно, он не подойдет для тех, кто ищут работу по принципу «кто первый ответит».

Определенно ребята не метят в «лучших», просто в послушный «среднячок». Собственно как и айтишники не метят в топчик из-за конкуренции и локации. Это сравнимо упреку что не у каждого жена твердая 10, когда по факту 3-7.

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

Не робив й не збираюсь робити тестові завдання. Це можна вимагати від джуна, щоб подивитись, чи він дійсно встиг всмоктати якісь знання. Але примушувати інженера із досвідом витрачати на вас свій вільний час, якого й так завжди не вистачає — це неповага до нього.

Гірше всього, коли компанія не каже з самого початку про тестове завдання, ти витрачаєш час на перше інтервью, потім на технічне, а потім тобі кажуть, що ви нам підходите, але ще ось тестове завдання зробіть. Доводиться відмовляти таким компаніям, але декілька годин твого життя вони вже забрали (включно із дорогою до їх офісу).

Тож, HR, будь ласка, благаю: кажіть про обов’язкове тестове завдання ОДРАЗУ! Не витрачайте свій час та час кандидатів даремно.

Слова,як бальзам на душу. Обіймаю твої думки,друже!!!

Почему не поинтересоваться о всех этапах самому?

включно із дорогою до їх офісу

Тому вважаю що краще перші кілька етапів інтерв’ю проводити віддалено в Zoom.
Взагалі ще до коронавірусу не розумів компаній де потрібно було пертися в їхній офіс.
Ми ж не просто живемо в часи повального Інтернету й мобільного зв’язку, а ше й працюємо не деінде, а в айті індустрії, на секундочку... Поїздку в офіс має сенс планувати лише на заключному етапі, коли офер вже в кишені (чи майже).

В залежності від кількості етапів. Часто цікаво як там з дорогою до офісу, що навколо і який офіс всередині.

тобто якшо любите подорожувати в часи карантину.

Гірше всього, коли компанія не каже з самого початку про тестове завдання, ти витрачаєш час на перше інтервью, потім на технічне, а потім тобі кажуть, що ви нам підходите, але ще ось тестове завдання зробіть.

Я всегда спрашиваю перед началом процесса о наличии тестового и количестве этапов.
И еще у меня есть ряд предварительных вопросов.

Мені тестові зустрічаються доволі рідко, тож важко завжди пам’ятати про таке питання :)
Я б сказав, що це зовсім не стандартна опція процедури хайрінгу, тому саме компанії краще сповіщати кандидата про цю особливість.

Згоден з тим, що порядок проведення інтерв«ю повинен бути прозорий і спланований від згоди проходити аж до найму (тест => interview => customer interview etc... => offer). Ніхто не любить сюрпризи у вигляді «а давай ще перевіримо чи він вміє код писати», особливо, якщо після тех інтерв"ю.

Щодо тестових завдань — маю трішки іншу думку (особиста, тому — суб"єктивна). Тестові завдання робити — це ок — навіть дуже. Якщо хочеш взяти на роботу людину, яка має бажання працювати, та розвиватися — то для неї не складе труднощів витратити час на тестове завдання. Задум — відсіяти людей, що невмотивовані вкладатися в роботу, а просто шукають де би посидіти з зарплатою на 500$ більше.

Але ніхто не застрахований від наступного... Бувають ситуації, що вас тестують просто тому, що так модно ... рекрутери і менеджери начиталися хайпових книжок чи статей і роблять дикий відбір тестами які знайшли в інтернеті ... а по факту, в роботі, завдання будуть — міняти текст на Thymeleaf чи фіксати jQuery scripts, а ви робили Java 14, Rx, Netty, Spring...

Тестові завдання — нормально, якщо з розумом.

Цікаво почути досвід людей які пішли по другому флову.

Вибачте, але я на не згодна з таким негативним відношенням до тестових завдань.
Якщо ви кажете про не вміння HR комунікувати нявність тестового завдання на якомусь з епів, то так, я згодна, це важливо попередити кандидата про його наявність і взагалі як буде виглядати процесс інтервю.

За своі 10+ років в індустріі я працювала лише в 4х компаніях(не так багато, але я маю теплі спогати про кожну компанію та коллег). Перша компанія(DBBest) була в Харкові, а далі штати. Усі моі амеріканські інтервью процеси займали 1+ місяць.
The World Bank — 3 місяці, 1 місяць інтервью-перемовин з Харкова і ще 2 місяця оплачуваного прототипування(тестового завдання) у Вашингтоні. Тільки після цього оффер.
bizy.com стартап у Вашинтоні — 1.5 місяця. Мені була запропонована лід-позиція, у команді де не було технічного фаундера, але вже було декілька девелоперів. Десь 3 тижні ми спілкувалися телефоном і зустрілися 1 раз в кафе, а потім домовились що я попрацю тиждень, ми познайомимся краще, я з командою, а вони зі мною, а потім вирішемо хочему ми працювати разом або ніт. Позиціі у стартапах це завжди великий ризик як для девелопера, так і для засновників. Дуже важливо знати на що ти підписуєшся.
Amazon & Palantir — інтервью процеси по 2 місяці — телефон, тестове завдання, інтерв’ю в офісі на 6-9 годин. Я отримала оффер Principal Engineer від Amazon і там було не тільки тестове завдання, але і сочіненіє не тєму який я гарний лідер, на 3 сторіки! Palantir після onsite інтервью вирішив оффер не надсилати.

Я дійсно вважаю що насправді хороші позиціі та спеціалісти за годину один одного не знаходять, це дуже важливо знати і розуміти компанію до того, як прийняти оффер, а тестове завдання один з індикаторів того, що на мене чекає після офферу.

ще 2 місяця оплачуваного прототипування(тестового завдання)

Оплачуваного.

я попрацю тиждень

«Попрацюю». Тобто з оплатою випробувального періоду.

Amazon — це FAANG. П’ятірка світових лідерів можуть собі дозволити давати тестові завдання. Саме тому, що це їм дозволяє їх статус.

Але навіть вони не дають ТЗ на 8-10-20 годин. А ось одна немаленька американська контора якось дала таке завдання, годин на 20. Інша ізраїльска контора намагалась нав’язати ТЗ на годин 6-10 в залежності від якості виконання. При тому, що обидві контори самі мене знаходили й пропонували на них працювати. Я не розумію такого ставлення до мого вільного часу.

Я розумію Ваше розчарування, є компаніі які переступают межу. І для вас це є теж індікатор з ким ви маєте справу, і це є добрий привід припинити інтервю з Вашого боку. Я просто вважаю що краще це зрозуміти ще до того як прийняти офер... Мій поінт у тому що зло то не самі тех тестові завдання, а поодинокі випадки компаній які не вміють іх комунікувати.

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

честно говоря мне пофиг дадут фидбек или нет. если я активно ищу работу, я отправляю CV оптом в 10 компаний. кто первый даст собеседование и после него интересный оффер, туда и иду. конторы с тестовыми заданиями рассматриваю в последнюю очередь. для трейни с пустым CV тестовое наверное норм

для трейни с пустым CV тестовое наверное норм

+1 какого именно «фидбека» ожидать для синьора и выше и какой именно «фидбек» ему вообще давать? зачем конкретно этот «фидбек» конкретному синьору не вообще? как он конкретно синьор сможет этот «фидбек» конкретно применить?

честно единственные варианты которые я видел это а) «узнавать правильные вопросы на собеседовании» б) узнавать вообще вопросы на собеседованиях вообще

т.е. в первом случае человек реально применяет тактику «так тут задали конкретный вопрос я узнаю на него конкретный ответ и в следующий раз отвечу конкретно на этот конкретный вопрос» причём по моим данным такая «тактика» таки реально работает ))

т.е. если брать в глобальном масштабе вы реально ожидаете от синьора что он не может из собеседования сам сделать выводы и сам потом разобраться с вопросами которые у него возникли на собеседовании? а что за «синьор» вообще в таком случае такой? как вы ожидаете что он будучи таки принятым на работу будет таки дальше уже по работе «разбираться с вопросами»? будет непрерывно спрашивать у других и требовать фидбек? таки да таких тоже есть причём видимо достаточно значимое количество от общего но тут интересно таки каких именно ожидаете вы? (здесь «вы» обобщение)

Ну, например, если честно скажут overqualified — чем это плохо?

тем что на самом деле это не так потому что сам кандидат этого понять не смог?

Тобто сеньйор повинен володіти ще й телепатичними скілами?
Є таке когнітивне викривлення у зв’язку з проекцією, коли ви впевнені шо геть усі навколо поділяють вашу думку, яка у вас щойно виникла в голові, тому що вона ж така очевидна. Але якшо запитати фідбек у оточуючих, то ви будете дещо неприємно вражені, а може й навіть розчаровані. Власне для того й потрібні фідбеки, бо це є натурна перевірка ваших гіпотез.

Тобто сеньйор повинен володіти ще й телепатичними скілами?

— How’s he doing?
— He asked us to call him Captain Blondebeard.
— Well technically Mars would be under maritime...
— Yeah I know. He explained it to us.
(к)

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

статья не только о найме инженеров. инженерные тесты реально выполнить меньше, чем за 2 часа, на практике выходит 3-4. и это таски со специализированных платформ (у нас Qualified.io). В остальных случаях тестовое тоже можно выполнить быстрее при наличии всех нужных навыков, но на практике часто выходит 8 часов.

Ну а скажем, если специалист уже проходил тест на

Qualified.io

в другой конторе, это как-то можно приложить?

Тоесть, должны быть shortcut, например, у меня есть аккаунт на TopTal, значит я прошёл их отбор.

в таком случае задачи займут у вас 1.5-2 часа, не больше. мы старались подобрать одновременно и интересные и не сложные в решении.

цікава арифметика. вона чимось реально підкріплена, чи так, та стелі ті цифери побачили?
самі пробували розв’язувати? скільки часу витратили? а через місяць ту ж саму задачу?

среднее время прохождения тест таска от всех кандидатов (инженеров) за последние пару лет

з секундомером міряли?

самі пробували розв’язувати? скільки часу витратили? а через місяць ту ж саму задачу?

инженерный тест таск — это несколько коротких задач на www.qualified.io. сервис показывает время прохождения.
сами пробовали, да, 1.5 — 2 часа.

Саме так, особливо коли ті 8 годин можна витратити з більшою користю для себе ніж розробляти нашарка комусь рішення для їх бізнесу з примарною перспективою працевлаштування. А вони потім зберуть ті тестові, виберуть кращі моменти, зліплять у купу та й матимуть профіт. Такий собі мозковий штурм на етапі проектування... силами волонтерів.

здається це був той випадок, коли статтю було б краще не публікувати тут. Зайдіть зі сторони кандидати де оцінювання компанії буде по логіці, де перший етап — оплата кандидату за його час, потрачений на ваші тестові завдання. оплати немає, тому компанія не варта уваги.
Рекрутери забувають що не вони вибирають, а процес двосторонній, тому згадуйте, що кандидат теж обирає, і його інтереси, пріоритети та логіку обирання компанії для роботи — варто враховувати вже з перших етапів спілкування.

оплати немає, тому компанія не варта уваги.

Интересно, сколько Вы пропустили интересных компаний и проектов, следуя этому принципу.

Рекрутери забувають що не вони вибирають, а процес двосторонній, тому згадуйте, що кандидат теж обирає, і його інтереси, пріоритети та логіку обирання компанії для роботи — варто враховувати вже з перших етапів спілкування.

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

Ще раз повторю, щі сторони кандидата гляньте — ви впевнені, що у нього є достатньо знань про вашу компанію, шоб обрати вас чи потратити час на виконання ваших завдань?

Вы читали наши описания вакансий с конкретными примерами проектов, над которыми предстоит работать, и списком статей, описывающих наши подходы к работе railsware.com/...​full-stack-ruby-engineer или статьи о нашей бизнес модели dou.ua/...​s/sergeykorolev/articles или тот же auto-reply с описанием процесса? мы собрали основные вопросы кандидатов, которые возникают в разговорах, и разместили ответы на них в публичном доступе. При отправке заявки вы сталкиваетесь со всеми этими материалами (если их читать). И если остались вопросы — у вас на связи рекрутер (а иногда и один из наших лидов) для общения.

працювати треба з людьми в першу чергу — жоден опис чи статті не покажуть цього. і взагалі — чому ви так активно виправдовуєтесь — не впевненні у тому, що компанія та ваша стаття чудова? ))

вы задаете вопросы — я отвечаю. не нужны ответы — не задавайте:) комментарии для дискуссий

Обыкновенная работа, в люксофте такая же

или статьи о нашей бизнес модели

 По ссылке нет ни слова о вашей бизнес модели и почему она была выбрана. Было бы интересно услышать как видите БМ Вы (HR) например.

бизнес модель описана в статьях, если их открыть:) а именно тут dou.ua/...​mns/software-consultancy и тут dou.ua/...​a/columns/product-studio .

Если вкратце:
— целимся в первую очередь на топ качество в создании любых продуктов -> позволяет повысить клиентский рейт и получить больше вовлечения + улучшаем свои собственные продукты
— гибридная модель (продукты и сервисы) -> позволяет легче переживать кризисы (одна часть страхует другую) + получать доход от обеих
— учимся делать продукты лучше на базе продуктовой модели, изучаем рынок на базе сервисной модели -> все наработки применяем в обеих частях бизнеса и они растут.

Вам, как HR, такой ответ простителен.

Такой же ответ вам дадут и представители других ролей в компании :) однако, если вы хотите узнать больше деталей — не стесняйтесь спрашивать.

Интересно, сколько Вы пропустили интересных компаний и проектов, следуя этому принципу.

Мамзель, интересно бабло. Трата времени на тестовое задание есть трата бабла! Ведь время -деньги. А что вы ощутимо выше платите, чем десять других контор без тестового вовсе не факт

Время затраченное на проверку тестового задания кандидатом другими участниками (сотрудниками компании) им в зп/компенсациях ежемесячно приходит) Или в вашей компании задействование в собеседованиях процесс добровольных овертаймов?)

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

Вот именно так и есть

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

 — именно так! 2 реальные, ежедневные ситуции:
1) идем на базар за клубникой
— трещим с бабулькой, пробуем, и думаем берем или нет(условно выполнение тестового задания — тк продавец дал клиенту покушать бесплатно), но когда клубничка красиво выложена пирамидкой в приличном лотке — тетка помоложе бабульки обычки кричит — «проба только через весы»: разбираем — качественная сортовая большая и красивая клубника стоит бабла (ситуация «джуниор вс опытный специалист» на лицо) — итого, для того чтоб купить клубнику во втором случае мы можем помимо того что посмотреть на красоту клубники еще спросить откуда она и тп вещи — но узнать развела ли тетка на водяную клубнику уже можно исключительно после того как ее купим. в 99% эта новомодная наливная клубника будет стоить > той что можно бесплатно попробовать у бабушки.
2) компания разработчик софта хочет втащить свой софт новому клиенту — можно вести долго переговоры и тп — но расширенную версию, а порой даже просто полностью рабочию в отличие от демо (которое работает на 10%) клиент получит только после внесения определенной суммы.

Так что именно так и просходит. Еще скажите, что когда при покупке всякого барахла в инстаграмчике не перечисляете предоплату за «пересылку» новой почтой...а товар то может и не подойти когда за ним придете. Или замерщики всяких окон бесплатно приходят.

андидат заинтересован в получении работы.

Здається ви знову забули що:

процес двосторонній

Якась у вас систематична амнезія щоразу трафляється.
Чи може ви не так вже й зацікавлені в наймі кваліфікованих кадрів насправді?

С точки зрения компании, мы тратим время и деньги на кандидата.

«Ми» — це хто?
Безпосередній власник компанії, інвестор чи акціонер витрачає гроші й він насамперед має бути зацікавлений, а ви є лише наймані працівники й отримуєте зарплатню, в якій ви нічого не втратите незалежно від того наймете класного спеціаліста чи ні.
Тобтоще раз: ви особисто нічого не втрачаєте, тоді як кандидат даремно витрачає свій особистий час з досить примарною перспективою працевлаштуватися до вас. Очевидно, він міг би цей час витратити з багато більшою користю для себе, навіть не маючи роботи й знаходячись в скрутному фінансовому становищі.

Год назад писал тестовое в данную конторку, после потраченного времени никто никакого фидбека не прислал. Осадочек остался.

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

возможно. потому и создали этот процесс

Спасибо что честно это признали

І ложек нема, й осад лишився. ;-)

омг, давно не читал такого ада

Интересный подход с тестовым заданием в самом начале, сталкивался с таким. С одной стороны, хорошо, что тестовое задание не даётся тем, кто хочет больше денег, чем компания готова платить. С другой, со стороны кандидата это выглядит немного странным: я еще ничего не знаю про компанию, хочу ли я в ней работать или нет (а на это как раз очень сильно влияют люди, с которыми я общаюсь на собеседовании), а мне уже надо показывать свой commitment на 3-8 часов. Думаю здесь есть несколько альтернатив:

— перед тестовым заданием провести интервью с тим-лидом команды, поговорить про опыт кандидата и дать возможность ему ответить на вопросы кандидата. Дальше уже в зависимости от результата или кандидат уходит/не соответствует ожиданиям от своего же резюме, либо дальше выполняет тестовое задание с уже примерным представлением того, что за компания

— тестовое задание дается после технических интервью и оно оплачивается. Минут этого подхода в том, что очень часто тестовое задание является предметом общения на технических интервью.

— вместо тестового задания кандидат приходит на работу и работает один день с командой над реальными или приближенными к реальным задачам.

В общем если говорить об опытных специалистах то использовать тестовое задание в качестве первоначального фильтра — это немного опрометчиво. Хотя тоже может быть много оговорок — возможно тестовое задание настолько интересное и нетривиальное, что само по себе заинтересует кандидата.

>

С другой, со стороны кандидата это выглядит немного странным: я еще ничего не знаю про компанию, хочу ли я в ней работать или нет (а на это как раз очень сильно влияют люди, с которыми я общаюсь на собеседовании), а мне уже надо показывать свой commitment на 3-8 часов. Думаю здесь есть несколько альтернатив:

Уточню, странным со стороны кандидата это выглядит если не вы сами нашли вакансию и подали резюме (то есть у вас уже есть первоначальные причины, почему вы хотите работать в компании), а если вас нашли где-нибудь на LinkedIn и предложили пообщаться о вакансии, и в конце общения дали то самое задание на 3-8 часов.

Если кандидата нашли мы — обычно назначаем звонок для знакомства и рассказа о компании. Если же кандидат сам отправил заявку — мы предполагаем, что он прочитал наши статьи о работе и будущих проектах в описании вакансии (вот пример railsware.com/...​full-stack-ruby-engineer ), а также встречался с нашими спикерами на конференциях, читал о нашей бизнес модели dou.ua/...​s/sergeykorolev/articles . После подачи заявки кандидат также получает автоматический ответ с еще большим количеством материалов о формате работы . И всегда есть контакт рекрутера (он/а отправляет тестовое) для дополнительных вопросов. А после первого тестового все последующие этапы — это парная работе с одним из наших сотрудников.

Если же кандидат сам отправил заявку — мы предполагаем, что он прочитал наши статьи о работе и будущих проектах в описании вакансии

БУГАГА. Да просто шлёшь резюме тупо везде. Где предложат больше, там и хорошо

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

є ще цікавість технологій та самого проекту,

Этого ты не узнаешь до собеседования, скорее всего и на нем не узнаешь. Ты ж видишь какие пиздобоолы тут собрались:чтобы продраться сквозь их софистику нужно постоянно думать да гадать где они тебя хотят обмануть

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

Если кандидата нашли мы — обычно назначаем звонок для знакомства и рассказа о компании. Если же кандидат сам отправил заявку — мы предполагаем, что он прочитал наши статьи о работе и будущих проектах в описании вакансии (вот пример railsware.com/...​full-stack-ruby-engineer ), а также встречался с нашими спикерами на конференциях, читал о нашей бизнес модели dou.ua/...​s/sergeykorolev/articles

Человек, который написал вам сам, более низкого сорта? Почему вы к ним относитесь не одинаково?

Возможно, потому что если человек написал сам, то за него бонус никто не получит?

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

Они хотят выбирать мотивированных работать именно в их компании. В целом, имеют право. Да, при этом их стратегия отбора направлена сильно «против шерсти» тенденций украинского рынка труда, но. Если их бизнес-модель не требует срочного закрытия позиций, а позволяет неспешно и вдумчиво отбирать самых мотивированных — то пуркуа бы и не па.

Вопрос не в сортах, а в том, есть у человека вопросы или нет, знает ли он достаточно о Railsware чтобы подать свою заявку. Есть кандидаты из outreach, которые уже о нас знают и отказываются от Intro звонка, просят сразу дать им тестовое. Звонок проводим позже.

Если же у кандидата (не важно, из outreach или inbound) есть вопросы, мы на них отвечаем перед тестовым (письменно или голосом). Но если человек подался сам и не задаёт вопросы — да, предполагаем, что он прочитал достаточно статей о нас и о предстоящей работе.

Интересно, что, по нашей статистике, кандидаты из outreach чаще выбирают сразу отправить резюме и делать тестовое, чем Intro звонок с нашим управляющим директором или с лидом :) в письмах мы добавляем ссылку на звонок, и через Calendly можно сразу выбрать удобный для себя слот в их календаре. Но большинство из заинтересованных пока что выбирает тестовое:)

Спасибо за ответ!
Если честно, удивлена, что у вас Intro звонками занимаются управляющий директор или Лид. Или это шутка была, которую я не поняла? :)

Не шутка. мы даже QR-коды и ссылки на эти звонки на стендах печатаем — вот пример с конференции RubyC на 350+ человек (ссылку не четко видно — rw.rw/30mincall ) : monosnap.com/...​nSNo2XVmRXGNJKj52wpnYiWMB

Интересный подход :)

Интересно. Скажите, вот эти подходы, о которых вы здесь пишете, они действуют только для киевского отделения компании? В других городах (в Кракове, в Дубаи или в Данбери) подход такой же, как описан здесь, или чем-то отличается?

Для всех кандидатов условия одинаковые

Хорошая статья, Анастасия! Если бы искал в работу в Украине, с удовольствием бы подал свое резюме :)

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

Ответ ниже прямо в статью стоит вынести:

Работа — это о взаимодействии двух сторон: сотрудника и компании. И мы ищем win-win решение. А покупать кота в мешке на основе нескольких бесед и оценки кода, который скорее всего писали всей командой, — не наш вариант. Мы не оправдаем ожидания наших клиентов по качеству сервисов и ожидания сотрудников по их команде (многие отмечают, что ценят Railsware именно за сильную команду). К тому же, проходя отбор, кандидат тоже изучает компанию и будущие задачи. Не провести с потенциальным работодателем хоть какое-то время — это как жениться без свиданий. Вы готовы к такому?

спасибо, рада слышать:)

Чувак, вот ответь мне на один вопрос: нафига тратить время на то, чтобы сделать конторе красиво если у тебя назначено ещё 10(!!!) собеседований?

Владимир, если следовать Вашей логике, получается, что HR-у тоже незачем тратить время на то, чтобы отправить фидбек кандидату, ведь у него тоже может быть в процессе еще 10 :)))

Совершенно верно. Не хочешь — не трать время. Мне вот сотни раз, наверное, не отправляли обратной связи и что? Я просто ищу дальше, всегда

У всех свои подходы. Не все кидают 10 резюме в рандомные компании, скрестив пальцы «авось пройду куда-нибудь». Если я, например, уже таки подаюсь в компанию, то я смотрю чем она занимается, будет ли мне там интересно, пишу сопроводительное письмо и отсылаю резюме уже будучи уверен, что я подхожу компании, а она мне. Я рассчитываю пройти все собесы и тестовые. И в таком случае мне не жалко терять время на них, ведь я хочу попасть в компанию, а не просто бросаю удочку и жду пока 1 из 10 собесов я проскочу.

Какая разница как называется контора где ты работаешь

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

Правильно, если взять меня на работу я же заражу мозгами всех остальных

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

Точно так же кандидату сложно за полтора часа понять, захочет ли он с нами надолго остаться.

Оба пункта важны, т.к. мы не хайрим под проект / клиента и не держим людей на бенче. Лучше потратить несколько дополнительных часов на этапе интервью, чем не оправдать ожидания в первые месяцы.

Если бы искал в работу в Украине, с удовольствием бы подал свое резюме
прогнивший менталитет украинских разработчиков

Не могу понять почему наши уехавшие соотечественники так часто кричат про «менталитет, г***но и б**дло». Вы то наверное кристально чистые в Эстонии переродились, без нашего «прогнившего» менталитета ?

Перед тамтейшими не дуже виходить пови***ватись, доводиться ходити розповідати які всі на відміну від не д’Артаньяни на форуми з батьківщини.

все без исключения HR этих компаний состоят в одной секте «отсутствия обратной связи кандидату»

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

Відповідь на заголовок статті — почати відписувати. І все. Однак ж не може бути все так просто, треба ж виправдовувати свою зарплату? Щодо тестових = то вибачайте, але це трата часу і кандидата і девелопера. Можна ж попросити Github, показати куски поточного коду... Я певен що за години 1.5 розмови з кодом і тп можна скласти певне враження про людину і її якості. А оця вся схема.. вона мабуть добра коли треба найти за низьку ціну виконавців роботів.

Можна ж попросити Github, показати куски поточного коду...

Те кто выкладывают код в компании где работают, даже если это и куски — нарушают закон, если это не open source.

малося на увазі що в Github лежить власний код — якісь тестові, спроби, уроки.. будь що по темі. Поточний код — скріншер вирваного з контекст проекту, і виключно якщо кандидат захоче. Не захоче — можна тоді щось інше придумати — наприклад прям наживо щось пописати (але варіанту з поточним кодом не було і за відмову кандидатів слід поважати ІМХО).

Тестове завдання маст хев + опціонально лайв кодінг опісля. Гарне тестове покаже вміння кандидата побудувати власноруч проект (хоч і в маленькому масштабі), організацію кода, вміння написати тести і т.д. Справа не в тому, щоб «зробити тестове правильно», а показати роботодавцю що ти вмієш. На лайв кодінгу можна оцінити як кандидат думає і як він орієнтується в написанні коду.

Схема якраз таки стандарт серед великих компаній, щоби упевнитися, що ти наймаєш гарного спеціаліста, а не того, хто язиком добре теліпає на співбесіді. Тому і витрачається багато часу на процес найму і перевірки. Без тестового і лайв кодінга важко оцінити точно рівень кандидата, за виключенням якщо це якийсь відомий суперстар з FAANG, є великий риск наняти хтозна кого, якщо опиратися тільки на якийсь там гітхаб і годинну розмову.

Звісно, розумний кандидат побачить, де тестове завдання дійсно тестове, а де його просять зробити справжню роботу не платячи зарплату :)

Давайте полємізувати ©. Тестові доцільні коли треба людину без досвіду, або з мінімумом. У решті випадків — це даремна трата часу. «якийсь там гітхаб» — це показник чим кандидат цікавився, що пробував (можливо там навіть є якісь старі тестові!). Тестове — може так само зробити хтось за кандидата. Ризик найняти аби кого є тільки тоді коли рекрутер і інтервюери або самі хтозна хто, або треба найняти гвинтик в велику організацію. Тому і будують такі схеми, щоб прикрити себе.

озвученные вами риски имеют место быть, именно поэтому:
* тестовое — это небольшой набор абстрактных задач, которые можно сделать за 1.5-2 часа. большинству было интересно их решить, независимо от опыта
* после тестового мы проводим дополнительные этапы — лайв кодинг сессии, общение с менеджментом и возможность задать любые вопросы о компании.

Первый этап после подачи заявки в Railsware — тестовое задание

Тестовое задание это не панацея. В целом когда-то у нас практиковали следущий подход по поводу тестового задания:

Предлагаем кандидату сделать тестовое задание.
1.1) Кандидат отказывается его делать, но имеет хорошое CV. Приглашаем на собеседование без тестового задания.
1.2) Кандидат отказывается его делать, но имеет плохое CV или плохо подходит под вакансию. Кандидату явно про этого говорят и если он хочет всё равно попасть на собеседование, он должен сделать тестовое задание.

После собеседования есть сомнения и для того, чтобы их развеять предлагается сделать дополнительное задание:
1.1) Кандидат отказывается его делать. Ок, берем другого.
1.2) Кандидат делает его. Получает офер.
1.3) Несколько кандидатов на выбор, выбираем того, кто сделал тестовое задание или сделал его лучше чем другие.

Как-то так, но опять же nothing is set in stone и могут быть разные ситуации — насколько важный/долгосрочный проект, новый ли проект, старый ли проект и тд.

P.S. У меня один раз был собеседование на 12 этапов, не было тестового, но реально пришлось общаться с разными людьми, летать на онсайт. Это не проще, чем просто сделать тестовое за пару часов.

Первый этап после подачи заявки в Railsware — тестовое задание

Один раз в житті я таки виконав тестове завдання про що одразу ж пошкодував. На думку перевіряльника там була помилка, а на мою думку перевіряльник був просто тупий чи може плюси бачив вдруге в житті. Втім, доводити, ясно, нічого не став, не вистачало ще працювати під таким керівництвом. Відчуття — розвели як лоха на вихідний день.

З того часу всіх з тестовим відкладаю в кінець списку обіцяючи собі обов’язково спробувати, якщо вакансія цікава й альтернативи будуть такі собі — ще жодного разу до кінця того списку не дійшов.

Это отличный фильтр для кандидатов, которые ищут легких путей

Нє, це гарний фільтр для кандидатів, яких чомусь не встигли вихопити з ринку перед вами.

В благодарность мы предлагаем нетривиальные проекты.

«Не вірю» ©

Повторюсь — статья не продает наш процесс отбора. Статья о фидбеке, с которым бывают проблемы. Не хотите делать тестовые — Ваш выбор:) Многие кандидаты стремятся попасть к нам, несмотря на сложный процесс, и потом работают по 5-13 лет.

«Не вірю» ©

Никто не заставляет, пока не попробуете:)

«Работать в нашей компании — большая честь!» ©

Єдиний раз, коли все ж отримував фідбек по тестовому, це була лише фраза: «я там краєм ока глянув і не дуже зрозумів; я це тестове робив якось не так».

Коментар порушує правила спільноти і видалений модераторами.

Хоспаді, який ужос.
Судячи з усіх пунктів, це як раз і є типовий кейс «Мы предлагаем людям работу» [!!!!!!!!!!!!!!1111]

Это отличный фильтр для кандидатов, которые ищут легких путей

Ви Гугл? Може Амазон? Ні? Тоді це відмінний фільтр для компаній, які шукають тєрпіл у відчаї; та для компаній, які заздалегіть готують кипу приводів поторгуватися.

Ну й відгуки стосовно вашого ж тестового ВЖЕ натякають:

Do not waste your time doing their test tasks. Company would use you to solve their business issues for free.
я трачу целый выходной день на то, чтобы поучить продукт и нормально сделать тестовое задание, и получаю комментарии «почему здесь строчка лишняя?»

Далі...

Мы запрашиваем ожидания еще в заявке на вакансию

І що тоді робите, коли отримуєте діапазон значень? А я знаю! Намагаєтеся просадити рейт по нижній межі, не розуміючи, що діапазон не береться не звідки, а на ціноформування часто впливає стек, специфіка процесів, та ще багато чого, що з тексту вакансій в принципі очевидно трохи рідше, ніж ніколи.
Дофіга людей з рідістю займатимуться фронтендом на гнучкому графіку без скрам-хороводів за Х, в той же час за фуллстек із мікроменеджментом візьмуться не менш як за Х*1.5 Але куди вам це зрозуміти? З позиції ж погонщиків, саме їх проект достойний влізти по нижній межі зарплатних очікувань будь-якого розробника )

Онбординг и испытательный срок

Випробувальний? А у вас, вибачаюсь, співробітники, чи таки контрактори?
Ну і взагалі, я коли чую, що хтось НАСТІЛЬКИ заморочується хай навіть формальним «випробувальним періодом», одразу прощаюсь, бо всі ці «бла-бла-бла плани» це вірна ознака того, що, по-перше, йде спроба зазіхнути на мій вільний час та розкорячити в позі показушної «лояльності», а по-друге, через три місяці намагатимуться зробити те, що не вийшло при наймі — просадити, або хоча б надовго зафіксувати рейт.

В этом комментарии вся суть эгоистичных и инфантильных недо-программистов («copy-paste developer»), которые не видят дальше своего носа, и не имеют думать с других перспектив кроме своей.
---
В статье главный посыл идет к компаниям, и в нем говорится о том как важно в процессе найма относиться к кандидату уважительно, в первую очередь всегда сообщая фидбэк, а не молчать даже после N-го этапа собесов.
А твое сверхценное мнение никому не интересно — особенно если оно написано в такой хамской форме.

Может ты не в курсе со своего тепленького и уютненького рабочего места, но те кто были сокращены в недавнее время — очень часто с этим игнором сталкивались. И уж поверь, что это действительно создает проблемы при поиске работы в нынешних условиях.

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

Выглядит как какой-то стокгольмский синдром от

тєрпіл у відчаї

А я взагалі завис в роздумах, якою з двох картинок на таке відповісти.
gif.cmtt.space/...​/02/a9/4fa6d7a9b76418.jpg
чи
hippiefreak69.files.wordpress.com/2016/08/troll.jpg

Если бы у нас работали «тєрпіли у відчаї», не думаю, что клиенты сотрудничали бы с нами по таким высоким рейтам и так долго — ринок переполнен аутсорсами, которые окажутся явно дешевле. Но почему-то выбирают нас (видимо за качество, судя по отзывам клиентов). Сотрудники не исключение — те, кто успешно прошел отбор, отмечают плюсы интересного процесса, опять же свидетельствующего о качестве. Больше деталей о том, как это работает, тут: dou.ua/...​mns/software-consultancy

я трачу целый выходной день на то, чтобы поучить продукт и нормально сделать тестовое задание, и получаю комментарии «почему здесь строчка лишняя?»

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

Ожидания по зарплате нужны для сравнения с вилкой перед тем, как двигаться дальше. И да, они помогают нам с обзором рынка зарплат (это один из факторов пересмотра вилок). Дальше каждая компания индивидуально решает, что с этой информацией можно сделать. Мы изучаем рынок и движемся вперед с теми, кто попал в нашу вилку. Если человек не хочет понижать свои ожидания — желаем удачи с другой компанией до каких-либо тестовых и собеседований. Жаль, что у Вас так плохо складывалось с работой и выросли такие стереотипы и обобщения. Но далеко не все компании стремятся занизить ваш рейт.

по-перше, йде спроба зазіхнути на мій вільний час та розкорячити в позі показушної «лояльності»,

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

Якщо там на картинці за посиланням — середні рейти аутсорсу (в уявленні вашого МенеджінгДиректора, зовнішні, як я зрозумів), то можу розчарувати, більш ніж певен, що ваші так звані «високі рейти» — суцільне бахвальство, а спроби порівнювати себе із пересічними

аутсорсами, которые окажутся явно дешевле

враховуючи, що у нас все ще цвітуть і пахнуть домушні «студії», і саме вони займають левову долю ринку (за кількістю компаній, а не задіяних контракторів та виконаних проектів) — то взагалі якесь привселюдне обмазування лояльністю та корпоративними цінностями.

Ожидания по зарплате нужны для сравнения с вилкой перед тем, как двигаться дальше.

Ок, ловіть: 3.5 — 5.5
Які висновки зробите? Як примірятимете на свою умовно біля4Кшну «вилку»? Чи кандидат заздалегіть усвідомлюватиме, що називає місячну «хотьолку», як от виявилося, в контексті роботи з погодинною оплатою? Як з цих значень вираховуватимете вартість години (банально, скільки на вашу думку в місяці робочих годин)?

Овертаймы оплачиваются
раз вся работа только о деньгах

Ой всьо (тм) ?

Шедевральна позиція. Дякую, я в курсі, як там що у таких як ви «оплачується», коли довкола кипа наївних джуно-міддло-ноулайферів, яким не впадлу поовертаймити й за просто так, адже їх обирали із числа «духовних та ідейних», а не з рядів такого примітивного бидла як я ))

Це як із Необмеженими Відпустками (тм)
Всі вже давно прекрасно розуміють мету тієї уловки.

переубеждать не буду

Та й не варто ) Всім, кому треба, ваш креатив і так вже розповів про компанію більш ніж достатньо, хоча б в каментах вже на закопуйтеся ще глибше.

Вы делаете много выводов на основе своих же комментариев, однако попробую ответить хотя бы про овертайм и часы.

С часами все просто — месячная зарплата, поделенная на кол-во рабочих часов в месяц из расчета 8 часов в день, 5 дней в неделю. К примеру, в мае 21 рабочий день, это 168 часов. То есть отработав 168 часов в мае, вы получите ровно 100% месячной зарплаты. При этом любой дополнительный час оплачивается по такому же расчету.

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

Буду рад ответить на другие вопросы :)

не думаю, что клиенты сотрудничали бы с нами по таким высоким рейтам и так долго

вопрос о том, сколько из этого «очень высокого рейта» достается рядовому гребцу, который я задал вашему управляющему партнёру, так и остался неотвеченным.

Но почему-то выбирают нас

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

пайплайн проектов больше того, что вы можете переварить

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

Тут бы послушать в деталях про микс продуктового и сервисного бизнеса (но кто ж расскажет), потому что чисто сервисный бизнес растёт исключительно на объёмах, а для этого нужно нанимать, как раз, быстро и много.

У них всё просто. Можно посмотреть сайт и понять, кто основные клиенты. Основные клиенты это новомодные стартапы в основном из Bay Area, которые подняли 2-3 ляма и хотят быстро запилить что-то руками офшера, но чтобы было красиво и качественно, но дешевле чем в Bay Area. Вот как-то так я понимаю ихних клиентов. Если они известные в этом, то вполне могут выбирать среди желающих таких entrepreneur-ов.

Первый этап после подачи заявки в Railsware — тестовое задание. Мы разработали наборы тестовых для каждой позиции, на которую нанимаем. Задание занимает от 3 до 8 часов. Это отличный фильтр для кандидатов, которые ищут легких путей: на следующий этап проходят только 16,58%. Тестовое выполняют до конца далеко не все остальные. Многие перестают отвечать нам :)

Взагалі про тестові можна довго вести дискусію, але в любому випадку я б до цього не ставився як до «чудового фільтру». Це «чудовий фільтр», якщо ви хочете відфільтрувати кандидатів, які не хочуть виконувати тестове завдання, бо цінують свій час та є варіанти інших роботодавців, які не вимагають виконання тестових.

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

Це погано, тому що сильні кандидати часто проходять повз тестові, бо в них завжди є вибір серед багатьох компаній — ви самі про це сказали на початку:

Кандидаты до сих пор борются за внимание работодателя. Наверное, единственное исключение — Middle и Senior инженеры в IT.

P.S.
У мене є досвід найму людей на різні позиції в свою команду без допомоги рекрутерів і це хороший досвід, бо в такому випадку маю змогу оцінити всі переваги кандидата напряму. Наприклад, була позиція на розробника вже з певним досвідом в розробці (Middle рівня, грубо кажучи). Першим етапом йшов скрінінг на 30 хв по телефону кандидатів, які зацікавили мене та ліда. Другим етапом була технічна співбесіда на годину-півтори з лідом, на якій присутні я та ще один досвідчений розробник. Нажаль, після певного часу не знаходились спеціалісти, які відповідали б за знаннями та кваліфікацією. Але резюме одного студента 3-го курсу мене зацікавило: хоч в нього й не було відповідного досвіду, тим не менш в резюме було вказано про участь в олімпіадах по математиці та хакатонах. Після технічного інтерв’ю лід та інший розробник сказали, що цей кандидат був кращий за всіх попередніх, хоч трохи і не дотягнув до бажаного рівня. В результаті ми найняли сильного молодого розробника, який за декілька місяців показав, що може чудово реалізовувати завдання. При цьому вигралі всі: компанія найняла робітника з меншими витратами, ніж закладувались на позицію; кандидату дали трохи більшу зп, ніж він просив; команда найняла здібного спеціаліста і чудового колегу. Це все відбулось без тестових, звісно ж.

Чи найняли би ми цього розробника, якби ми наймали по вашій схемі? Чи взагалі його б пропустив рекрутер і дав би йому шанс, звернувши увагу на сильні сторони у вигляді мат олімпіад та хакатонів? Я задавався цими питаннями і ми робили невеликий эксперимент, в якому два рекрутери надіслали з своєї сторони тих кандидатів, яких би вибрали вони. Результат їхніх «фільтрів» був досить сумним, бо вони не помічали багатьох важливих деталей, по яким я чи лід відсіяли б більшість їх кандидатів за десять секунд перегляду резюме. Два рекрутера не репрезентативний показник, звісно, але співпрацювати з більшою кількістю в мене не було нагоди.

P.P.S.
Майже всім кандидатам я надавав відповідь по їх кандидатурі. Можливо, не надав зворотній відгук декільком кандидатам з поміж 70-80 розглянутих.

Це вам був потрібен працівник шоб проблеми вирішувати, а їм треба людей продавати і маржу з того мати. Добре шо фільтрують і не забирають час адекватних спеціалістів.

Почитайте комментарий c ответами (снизу). Из моего опыта, «адекватным» специалистам хочется работать с другими «адекватными» специалистами, а еще работать в «адекватных» компаниях. Как вы поймете, что компания и команда подходят, не проведя с ними достаточно времени? Не понимаю Вашей логической цепочки.

Адекватних чОму?

Как вы поймете, что компания и команда подходят, не проведя с ними достаточно времени?

Ну уж точно не шляхом покірного виконання 8-годинних тестових мовчки скинутих ХРом замість «здрасьтє».
А потім приходиш такий на тех. інтерв’ю із параллельним розбором виконаного тестового та розумієш, який перед тобою, вибачаюсь, м***к. І ніби й пройти співбесіду — не проблема, але чи варто?...
Так, ота ситуація, описана нижче Артемом — доволі розповсюджена.

На думку перевіряльника там була помилка, а на мою думку перевіряльник був просто тупий чи може плюси бачив вдруге в житті.

Статистика показывает, что к нам проходит 1 из 70 подавшихся инженеров. Если бы речь шла про маржу то можно было бы просто брать всех подряд.

Статистика показывает, что к нам проходит 1 из 70 подавшихся инженеров.

По вашій статистиці, 58 з 70 відсіюються вже на першому етапі, коли кандидатів просять пройти тестове, тому це красива цифра, але не коректна до приведення прикладу

Это отличный фильтр для кандидатов, которые ищут легких путей: на следующий этап проходят только 16,58%.
Если бы речь шла про маржу то можно было бы просто брать всех подряд.

При рейті для замовника в 75$\год (dou.ua/...​umns/software-consultancy) маржа таки дає про себе знати (: Просто з такими розцінками брати всіх підряд дійсно не вийде, тут з вами погоджуюсь

А чем этот рейт отличается от условных EPAM, Luxoft-ов? Ты думаешь у них меньше рейты чем Railsware? Очень сомневаюсь.

Тем что он у них средний рейт совсем не $75. Он гораздо ниже. Отдельные позиции могут иметь стоимость и $100 но основной доход идет от джуниоров мидлов котрых много и идут по низкому рейту.

Финансовые отчеты EPAM читали? Компания заработала в первом квартале 651 миллионов. Колличество человек 36700. Считаем 4*651000000/36700 = $70953 в год на человека. Опять же, мы говорим про большую компанию, в которой кроме программистов куча другого персонала, директоров, маркетологов, а так же работают 1000-чи жуниоров по всей компании. Вы ж $85 не за билите за джуниоров. В итоге у ЕПАМ может быть каждый billable человек приносит вполне 100к+ в год и в среднем не ниже чем Railsware. В целом средний епамовец может быть технически слабее среднего Railsware emp, no doubts, но за счёт своего бренда, величины компании они могут иметь цены не ниже чем Вы и НЕ искать top 5 на рынке.

Забилите и по 85 если есть клиент согласный на такой рейт :) Все зависит от контекста. Там дальше очень много всяких NDA, но все совсем не так как вам может показаться.

У епама офисы и аутсорсинг бизнес по всему миру. Очевидно, что консультанты в штатах могут стоить и $150. Ссылаясь на отчеты епама ты до конца не знаешь кого в этих отчетах называют сотрудниками, так как с легальной точки зрения СПД это не сотрудники а сабконтракторы. Говоря про рейт мы говорим про рейт который клиенты платят за команды в восточной Европе. Я очень давно в этом бизнесе и у меня достаточно информации включая топ менеджмент епама, чтобы утверждать, что не платят епаму рейт $85 за инженеров.

По всему миру, но в США до 1000-чи человек (не больше) и погоду не играют. Они считают СПД-шников тоже, иначе бы 36700 никак не набралась. В основном у них персонал это РБ, УК, РФ, по мелочи во всяких Касахстанах и Армениях. То есть можно утверждать, что 80% их сотрудников сидят в СНГ.

Мне другое интересно, за счет чего Railsware может продавать людей по $85 и кому? Понятно, что можете сказать, что у Вас экспертиза в Ruby и Вы лучшие в этом. Допустим, есть у Вас 5-10 человек, которые работают в компании ооочень долго и можно сказать, что имеют экспертизу за которую стоит платить такие деньги. Но если посмотреть на team page, то видно что большинство работников молоды и о какой-то супер глубой экспертизе говорить не приходится, ну то есть я на месте бы заказчика не поверил бы, если бы мне толкали синьоров по $85 супер экспертов в области и при этом возрастом до 30 и работающих в Вашей компании пару лет. Я бы на месте заказчика бы согласился бы возможно платить $85, тем кто работает долго у Вас же, но это исключение чем правило. Возможно какие-то модные Калифорнийские стартапы на это ведутся (пока есть деньги у них), но так большой бизнес НЕ построишь.

в возрасте 30 многие уже имеют 10 лет рабочего опыта, этого более чем достаточно для построения экспертизы.

конечно, больше времени в индустрии или компании часто будут равны более глубокой экспертизе и скиллам. мы решаем это за счет активного knowledge sharing (как внутреннего, так и на конференция, статьях), аллокаций, учитывающих опыт и специфику и продуктов, а также постоянного feedback процесса.

И, конечно же, хайринг — тема статьи. Чтобы не продавать джуниоров по 85, нужно быть уверенным в кандидатах, которым отправляется оффер.

Сколько из этих 70-ти выполнило тестовое, прошло остальные интервью и на этом этапе хочет с вами работать?

Другим етапом була технічна співбесіда на годину-півтори з лідом, на якій присутні я та ще один досвідчений розробник.

Боюсь, я неполно раскрыла понятие тестовых заданий для инженеров. Для первого скрининга мы используем задачи от www.qualified.io . Следующим этапом идет работа в паре с одним из наших инженеров, которая похожа на Ваше техническое собеседование. Начиная с этого этапа, все задания выполняются в паре с нашими инженерами. Тоесть тестовое, которое кандидат решает самостоятельно, всего одно. Так же и для других позиций — сначала тестовое, потом только парная работа.

Взагалі про тестові можна довго вести дискусію, але в любому випадку я б до цього не ставився як до «чудового фільтру». Це «чудовий фільтр», якщо ви хочете відфільтрувати кандидатів, які не хочуть виконувати тестове завдання, бо цінують свій час та є варіанти інших роботодавців, які не вимагають виконання тестових.

Согласна, отпадут те, кто не хочет делать тестовое. Но другого пути качественной оценки кандидатов за 15 лет мы не нашли. К тому же, наша нанимающая команда тратит на оценку тестовых и работу в паре с кандидатом столько же времени, сколько кандидат на их выполнение.
Работа — это о взаимодействии двух сторон: сотрудника и компании. И мы ищем win-win решение. А покупать кота в мешке на основе нескольких бесед и оценки кода, который скорее всего писали всей командой, — не наш вариант. Мы не оправдаем ожидания наших клиентов по качеству сервисов и ожидания сотрудников по их команде (многие отмечают, что ценят Railsware именно за сильную команду). К тому же, проходя отбор, кандидат тоже изучает компанию и будущие задачи. Не провести с потенциальным работодателем хоть какое-то время — это как жениться без свиданий. Вы готовы к такому?
Ну а замотивировать лучших кандидатов потратить время и пройти процесс — это уже задача employer brand и рекрутеров. Тут мы работаем совместно:)

Але резюме одного студента 3-го курсу мене зацікавило: хоч в нього й не було відповідного досвіду, тим не менш в резюме було вказано про участь в олімпіадах по математиці та хакатонах. Після технічного інтерв’ю лід та інший розробник сказали, що цей кандидат був кращий за всіх попередніх, хоч трохи і не дотягнув до бажаного рівня. В результаті ми найняли сильного молодого розробника, який за декілька місяців показав, що може чудово реалізовувати завдання.

Это отличный кейс и лишний повод расширить свой поиск. Мы так же рассматриваем более junior специалистов. У нас были успешные кейсы и мы находили людей с отличным потенциалом для роста.

оценки кода, который скорее всего писали всей командой

Это что за код такой — open source?

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

Ваш спосіб грає сам проти себе:
а) Відсіюєте багатьох хороших кандидатів на першому етапі;
б) Витрачаєте багато часу кандидата і своєї команди на перевірку тестових.

Далі, кандидат буде проходити тестові тільки якщо в нього буде мотивація це робити. Але якщо він подає резюме в 10 компаній і в 9 з них не буде на першому етапі тестового, то яка ймовірність, того, що він обере саме вашу, в якій пропонують витратити свій час на задачі вже на першому етапі? Не хочу образити ні вас ні кандидатів, які проходять у вас тестові і приймаються вами, але ви ж не ФААНГ, щоб диктувати ринку свої умови гри.

Не провести с потенциальным работодателем хоть какое-то время — это как жениться без свиданий. Вы готовы к такому?

Як в моєму випадку, так і у вашому, розглядається технічна сторона кандидата. Але у нас це йде на другому етапі під час тех інтерв’ю і витрачаємо в купі 1-1.5год, замість вашого першого етапу з витрачанням 3-8 год кандидата + певна кількість часу ваших колег на перевірку тестового. Чому ви вирішили, що ваша стратегія відбору краща, ніж в моєму випадку чи в той же умовний ЕПАМ\Люксофт\Циклум етк, де нема тестового на першому етапі? Якщо ви опираєтесь на якісь дослідження в цих питаннях, то дуже цікаво було б побільше дізнатись про це.

але ви ж не ФААНГ, щоб диктувати ринку свої умови гри.

Мы диктуем свои условия игры только себе и тем, кто в нас заинтересован:) Статья о своевременном фидбеке и коммуникации с кандидатом, а не о продаже нашего подхода к отбору. Но! Наш подход достаточно сложный и принимается далеко не всеми кандидатами. Тем не менее, мы нанимаем достаточно сотрудников, которые соответствуют нашим требованиям и проходят отбор (90% вакансий компании закрываются из входящего потока, а не через outreach). Это лишний раз подчеркивает, что наш подход к обратной связи работает даже в комплексе с насколько сложным процессом.

Як в моєму випадку, так і у вашому, розглядається технічна сторона кандидата. Але у нас це йде на другому етапі під час тех інтерв’ю і витрачаємо в купі 1-1.5год, замість вашого першого етапу з витрачанням 3-8 год кандидата + певна кількість часу ваших колег на перевірку тестового. Чому ви вирішили, що ваша стратегія відбору краща, ніж в той же умовний ЕПАМ\Люксофт\Циклум етк, де нема тестового на першому етапі? Якщо ви опираєтесь на якісь дослідження в цих питаннях, то дуже цікаво було б побільше дізнатись про це.

Посчитайте сколько времени тратят ваши кандидаты и рекрутеры+нанимающая команда на initial interview и тех собеседования. Умножьте на количество заявок Также посчитайте, какова конверсия между разными этапами отбора и сколько вы тратите времени, чтобы понять, что кандидаты не подходят. Получится больше, чем в нашем процессе (как со стороны кандидата, так и со стороны команды).

Я бы не делала вывод, что в аусорсах/аутсафах легче и эффективнее найм. В основном, крупные аутсорсы/аутсафы пляшут от прихотей заказчика, часто процесс найма на конкретный проект зависит от того, чего хочет заказчик. Процесс может включать и тестовые задания и несколько интервью, может даже доходить до поездки в страну заказчика для финального интервью и займет это не 3-8, а гораздо больше часов.
В этом случае рекрутеры вообще никак не могут повлиять на процесс, так как заказчик всегда прав:)
Конечно, есть кейсы, когда нанимают с одного интервью, но есть и обратная сторона такого подхода. Как результат в крупных аутсорсах большая текучка, даже если человека берут с первого интервью, очень часто на долго он в компании не задерживается. Причин может быть несколько: попал на бенч, не интересный проект, легаси проект и так далее.
Вопрос что лучше или хуже ну очень спорный, есть риски которые вы как нанимающая сторона принимаете или нет:)

хоч в нього й не було відповідного досвіду, тим не менш в резюме було вказано про участь в олімпіадах

А в чем противоречие? Тест таски которые мы готовим рассчитаны на УМ а не на годы опыта. В нашем процессе мы бы увидели этот ум после тест таска и первого парного интервью. Некоторые позиции, включая инженерные, мы вообще не отсеиваем по резюме.

В нашем процессе мы бы увидели этот ум после тест таска

... якби кандидат погодився витратити свій час на тестове

А разве на собеседование он его не тратит? А что если кандидат не пытается пройти собеседование в 10 компаниях, что если мы входим в топ 3 его предпочтений и он хочет именно к нам?

если мы входим в топ 3 его предпочтений и он хочет именно к нам?

То он наивный, внушаемый лопушок. Украинские конторы одна от другой отличаются только названием

А разве на собеседование он его не тратит?

У вашому випадку, на тестове йде більше часу

А что если кандидат не пытается пройти собеседование в 10 компаниях, что если мы входим в топ 3 его предпочтений и он хочет именно к нам?

Тоді виходить, що вам потрібні хороші спеціалісти, які завідомо знають, що Railsware дуже класна компанія.

Якраз і виникає припущення, що багато хороших спеціалістів проходять повз не знаючи цього, хоча могли б успішно у вас працювати, отримувати топову зп, а ви б могли скоріше закривати вакансії та отримувати більший вибір серед хороших кандидатів.

Первый этап после подачи заявки в Railsware — тестовое задание. Мы разработали наборы тестовых для каждой позиции, на которую нанимаем. Задание занимает от 3 до 8 часов. Это отличный фильтр для кандидатов, которые ищут легких путей

Боюсь, это отличный способ отсеять опытных специалисто

А деякі компанії зовсім і не про найм

опытных специалистов

Головне щоб маржа побільше була, ну й замовники не дуже швидко розбігалися, а на яких там костилях триматимуться їх проекти... та кого це хвилює? :)

Как тогда оценить уровень знаний человека? По разговорам? По коду, который писали всей командой? Нам не хочется покупать кота в мешке. Увы, чисто ГОДЫ опыта не гарантируют качество кода и результатов.

Как тогда оценить уровень знаний человека? По разговорам?

Да, такое вполне возможно. Есть множество вопросов, позволяющих отличить дилетанта от специалиста.
А вот с тестовым заданием человеку много кто может «помочь» :-)

Это правда риск, но он отпадает на следующем этапе, когда кандидат работает в паре с одним из наших инженеров / продактов / маркетологов (в зависимости от позиции). Вопросы действительно помогают с базовым скринингом, но, увы, не помогают с оценкой качества, скорости работы, глубины знаний. Работая в паре над задачами это оценить куда проще. Есть люди, которые отлично разбираются в терминологии и продают себя, но на практике не могут справится с базовыми заданиями.

Работая в паре над задачами это оценить куда проще.

Розповідати що там кому простіше оцінити... Уявляю ваші процеси.
Встаньте дєті, встаньтє в круг, візьміться за ручки, бо дядя менеджер, який за фахом взагалі історик-логопед в якійсь трешовій книжечці прочитав, що так ефективність зросте до 300% і стоятиме як при Сталіні!

Есть люди, которые отлично разбираются в терминологии и продают себя, но на практике не могут справится с базовыми заданиями.

От тут люто плюсую, якщо ви розумієте про що я ;)

Частично помогут. Но когда начнется общение по его же коду и он начнет плавать — то тут сразу станет понятно — кто делал задание, имхо

Как тогда оценить уровень знаний человека?

Что такое качество?

Нам не хочется покупать кота в мешке

А мне не хочется работать бесплатно.

Что такое качество?

У каждой компании свое понимание качества. У нас есть конкретный список критериев качества, которые мы оцениваем.

А мне не хочется работать бесплатно.

Справедливо. Но компания тоже вкладывает свое время в оценку и парную работу с кандидатом (и таких далеко не один). К тому же кандидат в это же время оценивает компанию для себя. В краткосрочной перспективе да, вы тратите время, в долгосрочной — избегаете неинтересных проектов, неподходящих менеджеров и коллег, которые будут тянуть Вас назад в развитии (или того хуже — приведут к выгоранию).

долгосрочной — избегаете неинтересных проектов

Я за деньги гавно буду вёдрами носить.

неинтересных проектов, неподходящих менеджеров и коллег,

Это которых? Если человек платит и вежлив с ним работать можно

у Вас все просто. можете тестовые не делать:)

Я и не делаю. Лбди приходят ко мне по отзывам

избегаете неинтересных проектов

А как у вас формируется команда на неинтересные проекты?

мы не берем неинтересные проекты. мы выбираем, с кем из заказчиков работать, а с кем нет.

А интересные, это какие? Вот что то мне кажется, интересно = много денег

А если денюх одинаково, то по каким критериям выбираешь проект?

Я беру два и работаю на пол рабочего дня

Да, ты можешь себе это позволить :)

У вас нет проектов на поддержке? Тогда возникает следующий вопрос — кто занимается поддержкой проектов, которые были успешно завершены вашими командами?

С другой стороны, поддержка — это далеко не всегда унылое разгребание говнокода.

Если проект изначально писался профессионалами, и писался хорошо (а если компания выбирает из заказчиков, которые готовы платить $85 в час — то, скорее всего, её заказчики — не нищеброды, которым надо сделать из говна и палок, но лишь бы за три копейки) — то поддержка не сильно будет отличаться от просто дальнейшей разработки.

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

У меня был проект, который писался топ US фрилансером по рейту 150 в час.
Был проект, который достался в наследство (заказчик не скупой) после скитаний и по украинцам, и по индусам.

Ни заказчик, ни рейт — не показатели качества кода. Совершенно внезапно 150 баксов/час разработчик из US от 80 баксов/час разработчик из Индии отличаются софт скиллами, таймзоной и еще парой гуманитарных плюшек. Потом помыкавшись по подрядчикам, проекты оседают в том числе и в Украине, и чем меньше этапов этих скитаний — тем лучше код.

В общем, основная мысль в том, что удобство поддержки проекта меньше упирается в рейт и больше упирается в кол-во подрядчиков, которые работали с этим проектом.

Как вообще как так можно сравнивать? Какие там были условия, кто первый писал, какой time pressure? Может US фрилансер написал первый в спешке и без ТЗ, а Вам таким умным достался готовый код на поддержку, то конечно можно критиковать и рассказывать про качество. В США разработчики больше на бизнес ориентированы в основном, а не написания красивого кода.

В Украине программисты (даже с лычками senior) любят работать по приниципу — бизнес не шарю, код могу писать по спекам и по тикетам с красивым описаниями, зато красиво. В США это немного не так работает в основном — тестеров нету, нянек нету, аналитиков нету, менеджеру вообще не до тебя. У тебе есть high level task, например, сделай поддержку канадского доллара в debit card процесинге или же сделай поддержку proxy voting. Всё. Это всё. Дальше сам. В Украине с такими заданиями программисты тебя н*р посылают, но зато рассказывают про КОД и как там кто-то красиво или не красиво пишет. Красиво или не красиво — бизнесу по*р, главное чтобы стабильно работало и сделано было в бюджет. В Украине же нужно нанять 5-нянек в ввиде QA, manager, tester, чтобы сделать точно такую же задачу.

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

Не нужно ничего умножать, если нормально сделано — слово нормально это слишком обьемное понятие и не все программисты далекие от бизнеса понимают это. Для них нормально это по ООП, красивый код (в ихнем понятии) или что-то ещё с этим связанное. А для бизнеса это может быть другое — рассширяемость, стабильность, scalability. Некоторые проекты не приносят столько денег, чтобы в них вкладываться сильно и они соотвествывали понятию «не с говна и палок» в широком смысле этого слова.

Там были другие проблемы. Например у топ-юс фрилансера был везде его кривой фреймворк, надерганный из гитхаба (просто куски кода украдены без ссылок и референсов).

Есть и интервью с этим чуваком, где он прямо говорит, что основное его конкурентное преимущество — таймзона и умение в североамериканскую социализацию, что выгодно его выделяет среди конкурентов и позволяет брать такой рейт (что вполне логично).

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

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

а как вы определяете неинтересные проекты?
вот пришел заказчик Х с проектом Y, платит хорошо, репутация отличная, в каком например случае проект Y может быть для вас неинтересен?

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

У нас на одном из этапов просим небольшой проект сделать шаря экран. Хорошо сделать можно минут за 40, максимум даем полтора часа (недавно увеличили, раньше был час), в это время собеседующий в основном смотрит, может подсказать, можно гуглить, брать код из прошлых проектов, главное уложиться во время, получить работающий результат и показать задел на расширение и умение применять общепринятые практики.
Был сначала скептически настроен, потому что задание совсем игрушечное, но удивился как хорошо иногда выявляет сильные и слабые места кандидатов.

Есть испытательный срок.
На нем все будет видно.

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

Это гипотеза, которая на практике работает совершенно иначе. По-настоящему опытные специалисты наоборот заинтересованы в сложном процессе отбора.

Ну да, ну да. Вот есть у меня десять вакансий. На одной из них нужно пройти десять кругов ада + сделать тестовое. По зарплате никто ничего не обещал. Что мне делать? Правильно! Я задвину контору с тестовым в самый конец списка, зачем мне тратить время?

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

Який зв’язок між «не бігати 5-10 років», «крутою продуктовою компанією» та «10 співбесідами»? Десять співбесід — це швидше про бюрократію, а не крутість, і якщо контора настільки геморойна вже на вході, можна собі уявити, який квест видадуть після спроби попросити підвищення.

если ты хочешь работать в крутой продуктовой компании где берут не на проект, а в компанию, тогда это другой отбор там и люди готовы пройти 10 собеседований, чтобы потом 5-10 лет никуда не бегать.

А зачем мне это?

в крутой продуктовой компании

Продуктовых компаний десятки тысяч.
Тут наверное главное слово «крутой», чем «продуктовой».
Под которым надо понимать, либо быть фанатом продукта, давним пользователем.
Либо сама контора ну очень на слуху.
Каждый человек фанатеет, конечно от своего, но врядли у каждого личный список таких контор больше 30 штук.

В том и дело, что большинство разработчиков в Украине не имеют свою нишу и могут писать всё-всё. На Западе люди часто могут иметь нишу в которой специализируются и я сейчас не говорю про языки программирования. А про отрасли, ниши в отраслях. Например, тебя не возьмут главным разработчиков Google Search Engine, ну вот никак, потому что ты всю жизнь писал что-то другое. А вот человека, которые работал в Yahoo Search, возьмут и будет у него зарплата намного выше чем у типичного разработчика, который может делать все. Продуктовые компании — это возможность получить нишу, получить имя. А если ты бешаешь в аутсорсе с проекта на проект — ниши у тебя нету и твою работу знают 100500 других таких же на рынке.

Крутые продуктовые это те, которые на слуху у людей и ими пользуются много людей в мире или много компаний в мире.

Ну вот я имею нишу. Ты думаешь, я стану делать тестовое?

Те кто известный в своей нише им и собеседование не нужно.

Ну вот, получается меня-бы они отсеяли.

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

К чему это всё.

if (есть ниша) -> тестовое не надо
if (фанатеешь) -> делаешь тестовое, есть оно или нет
if (много денег) -> делаешь тестовое, есть оно или нет
else -> посылаешь к чертям

Ну вот, смотри.
1. Им нужно тестовое, ДО собеседования
2. Я фанат украинской конторы? Да брось!
3. Много денег? До собеседования это никак не узнать
Вывод: пусть идут лесом, согласен?

3. Много денег? До собеседования это никак не узнать

а в чем проблема утончить? Я всегда спрашиваю. Ибо в самом начале пути было пару раз — прошел собеседование, ты им очень нравишься и они тебе. А потом наступает неловкий момент — ой, а мы может позволить только X денег, а вы просите 2-3Х. Так что если мне говорят — зп по результатам собеседования и при этом даже вилку не озвучивают — то просто прощаюсь с такими людьми. Вот где по настоящему пустая трата времени

в чем проблема утончить?

Проблема в том, что я никогда не говорю сумму первым. Вдруг у них больше есть

Поэтому и спрашивается вилка/бюджет на данную вакансию, как минимум. Если нет вилки — давай, до свидания. Была пара компаний где я называл зп 6-7к и при этом глаза у HR/рекрутера не вылазили на лоб. А ответ простой — если пройдете собеседование — не вопрос.

Вариант с +500 самый адекватный.

95% у них его нет
4% он есть
1% что реально выбить +1000

Понимаешь, я — штучный товар. Цены могут отличаться на порядок

Нет.
Тестовое — огромная трата времени. Если человек работает — то еще и во вне рабочее время.

Оптимально — рассматривать вакансии без тестового в первую очередь.

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

Главная проблема тестового задания абсолютно такая же, как и у всего процесса найма, а именно отсутствие обратной связи. Если компания не готова выделить 30 минут на качественное код-ревью тестового, глупо ожидать, что кандидат сможет выделить несколько часов на его подготовку, не правда ли? И угадайте, что говорят 100% компаний, которые не дают feedback? «Мы всегда даем feedback».

а в FAANGи есть тестовое разве?

Есть, только в форме live coding, а не когда тебе на дом дают что-то делать

а, ну так это на час от силы и та же алгоритмическая задачка

Не помню. В гугл вроде может быть до нескольких этапов собеседований по 1-3 часа
Плюс для части собесов возможно придется он-сайт ехать
+ телефонный скриннинг само собой

В последний раз когда мне писали, это получалось что нужно ехать в другую страну на несколько дней (4-5) в случае прохождения телефонного скриннинга.

Всяко больше временных затрат чем тестовое, с одной стороны.
С другой стороны — это Гугл, и там зп/плюшки заметно выше рынка.

единственное исключение — Middle и Senior инженеры в IT

Тоесть исключением является большинство?)

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

ну да, ну да, стоит очередь толковых продактов и вы лениво перебираете кому дать поработать за 500 баксоф :D

Мы запрашиваем ожидания еще в заявке на вакансию

Всегда была интересна статистика отклика на такие вакансии vs вакансии с указанием суммы / вилки

Мы сейчас начали экспериментировать с указанием вилок зарплат, но пока данных мало. Не скажу, что вопрос о зарплате кандидата негативно влияет на желание отправить резюме — у нас количество входящих заявок на все вакансии (даже инженерные) с каждым годом увеличивается. Да и почти все позиции закрываем из входящего потока. Только Full Stack Ruby инженеров дополнительно ищем сами.

Поручал делать такой анализ. Увеличивает поток в 5-7 раз в зависимости от позиции.

Підписатись на коментарі