«Є ризик втратити цікавого кандидата та уповільнити найм». Чи потрібні тестові в IT і якими вони мають бути

Єдиної думки про те, чи варто компаніям давати тестові завдання технічним спеціалістам, а кандидатам — виконувати їх, в IT-індустрії немає. Дехто вважає, що це непоганий спосіб відсіяти тих, хто ще не готовий до обов’язків, які доведеться виконувати. Інші ж кажуть, що це марнування часу, оскільки тестове не обовʼязково свідчить про здатність вчитися та виконувати робочі завдання в реальних умовах.

Немає і єдиної думки щодо того, якими тестові мають бути у 2023-му з погляду формату, оплати та фідбеку роботодавців. Щоби краще зрозуміти позиції сторін, DOU поспілкувався з айтівцями й компаніями на цю тему.

«Те, що в кандидата є відповідний досвід, тестове навряд чи покаже, особливо роздуми і вміння спеціаліста розвʼязувати проблеми»

Станіслав Кошель, Software Engineer

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

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

На мою думку, тестове має оплачуватися за таких умов:

  • якщо його виконує людина, що претендує на посаду middle та вище;
  • виконання тестового займає понад годину.

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

Тестове повинне щось комусь довести. Вочевидь те, що в кандидата є відповідний досвід, тестове навряд чи покаже, особливо процес роздумів і вміння спеціаліста розвʼязувати проблеми. Натомість live coding закриває цю потребу.

Якби я шукав у свою компанію спеціалістів рівня Junior, тоді тестові мали б сенс. Але для цього я б використав сервіс онлайн-тестування, де є питання і варіанти відповідей — це дозволить «поганяти» по теорії чи перевірити основні навички з програмування. Але важливо, щоб не було неадекватних питань, які в реальній практиці не трапляються. Після першого етапу з тестовим я б відбирав найкращих кандидатів і запрошував на технічне інтерв’ю, де їх чекатиме live coding.

Схожий досвід у мене був з BetterMe. Там потрібно було виконати тестове з двох частин, година на теорію і година на практичне завдання, все виконувалося в браузері. Потім мене разом з п’ятьма іншими кандидатами запросили на тестовий робочий день в офіс, але, на жаль, далі я не пройшов.

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

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

«Компанія не повинна писати розгорнутий відгук щодо кожного технічного спеціаліста»

Ігор, репетитор з математики, шукає роботу React-розробником (спікер зажадав залишитись анонімним)

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

Я React-розробник, знаю JS/React/TypeScript/CSS, тобто класика. Відгуків на таку вакансію приблизно безліч, а якщо точніше, то орієнтовно 400 за день.

Наведу два приклади тестових, з якими я стикався:

  • Завдання — написати інтернет-магазин, буквально. Термін — два дні. Його я не виконував, бо це надто безглуздо.
  • Другий приклад розмитий, оскільки це траплялося часто. Вакансії з jQuery, PHP тощо — всі трешові, буквально кожне тестове — написати сайт.

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

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

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

У таких випадках краще, на мою думку, дивитися на пет-проєкти. Потім має сенс дати тестове, що кине виклик знанням, але водночас його можна буде зробити за день. Тобто легкі завдання з LeetCode або ж створення інтернет-магазину — дурниця. Варто обирати щось середнє за складністю.

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

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

«Стрес і зовнішні чинники на тестове мають впливати не більше, ніж на звичайну роботу»

Сергій, Full Stack Developer (спікер зажадав залишитись анонімним)

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

Два ТЗ були у вигляді проєктів на GitHub з пропущеними методами (тобто @todo). В одному були чіткі коментарі, що має реалізовувати метод, з коментарями щодо аргументів/формату відповіді (були абстрактні класи). У другому — лише назви методів, потрібно було дописати чужий код. На виконання кожного виділили три години. Я погодився виконати завдання з умовою, що буде зворотний зв’язок. Але в результаті відгук довелося буквально випрошувати.

У третьому випадку я мав розібратися в API СРМ-системи, реалізувати логін/авторизацію/методи до основних ендпойнтів СРМ. Дедлайн — до трьох днів. Фідбек був «нас влаштовує, ось офер» (це засмутило, хотілося б отримати розгорнуту відповідь, незалежно від наявності оферу, але мені тільки сказали, що все добре).

Якщо на виконання тестового потрібно до трьох годин і йдеться про посади рівня Junior і Middle, я вважаю, що оплачувати його з боку компанії не потрібно. Якщо це Strong Middle, Senior і вище — тоді так, оплата має бути в разі, якщо тестове працює. Компенсація — у розмірі погодинної оплати згідно із зарплатною вилкою, на яку претендує кандидат. Якщо компанія не хоче оплачувати, тоді має бути live coding на технічній частині інтерв’ю. Це набагато стресовіше, зате швидше за часом і допомагає краще зрозуміти стиль мислення кандидата.

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

Розгорнутий фідбек неабияк важливий, оскільки допомагає зрозуміти причину відмови й виконати роботу над помилками. А можливо — і пояснити роботодавцю, чому тестове виконане саме так, а не інакше. Якщо кандидат не завершив завдання на 100%, справедливо залишити питання надання фідбеку на розсуд компанії, оскільки очевидно, що він не відповідає вимогам вакансії (свої сили можна було оцінити ще до початку виконання тестового).

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

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

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

GlobalLogic

Тестові завдання ми даємо у двох випадках:

  1. Коли це є додатковою умовою під час пошуку і підбору спеціаліста. Тоді рекрутер дає кандидату тестове завдання, рішення якого надсилають на розгляд технічній команді разом з резюме та іншими деталями. На основі цього команда ухвалює рішення, чи запрошувати людину на співбесіду.
  2. Якщо після технічної співбесіди залишилися уточнення або питання щодо досвіду спеціаліста і відповідності вимог проєкту до досвіду кандидата. Попередні приклади робіт, викладені на репозиторіях, не завжди висвітлюють потрібний досвід для певного проєкту/ролі. Завдання пишуть індивідуально і під певну роль, а рішення дає змогу роздивитися саме потрібний досвід і логіку у виконанні тестового.

Щодо формату і часу на тестові — наразі нічого не змінилося. Зазвичай рішення потрібно записати в текстовий документ. Тестове завдання має займати не більше як 30–60 хвилин. Строки на виконання обговорюємо, а рекрутер контролює цей момент.

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

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

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

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

Intetics

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

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

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

У деяких випадках тестове завдання оплачуємо. Сума винагороди залежить від рівня вакансії та приблизного часу на виконання цього завдання й відповідає середньому рейту для рівня кандидата.

Intellias

Тестові завдання не є обов’язковими в Intellias. При відборі кандидатів на більшість позицій їх немає. І лише іноді клієнтське інтерв’ю має нескладні тестові завдання. Виконання тестових ми не оплачуємо.

За підготовку технічних завдань відповідає наш технічний експерт або клієнт Intellias.

Кандидат отримує фідбек за кожен етап, що передбачені у процесі інтерв’ю, зокрема й за тестове, якщо воно є.

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

Avenga

У 2023-му нічого в частині тестових завдань у компанії не змінилося. На більшість вакансій ми проводимо лише технічне інтерв’ю.

Тестове — це радше виняток, ніж правило, й воно обумовлене вимогами конкретного проєкту чи клієнта. Також інколи тестове завдання є в рекрутинговому процесі для більш «творчих» позицій, наприклад SMM Specialist, Graphic Designer тощо. Воно допомагає розкрити потенціал і досвід кандидатів і співвіднести його з вимогами вакансії.

Наразі ми не практикуємо оплату тестових завдань, проте формуємо їх таким чином, щоб кандидати витрачали мінімум часу. Завдання для технічних позицій розробляє Engineering Director і технічні спеціалісти з урахуванням особливостей проєкту та вимог вакансії. Перевіряють теж спеціалісти, що залучені в рекрутинговий процес на конкретну вакансію. Вони ознайомлюються з кожним тестовим. Зі свого боку ми стараємося надати розгорнутий відгук, де виділяємо сильні сторони й зони зростання, щоб виконання завдання принесло користь і самому кандидату.

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

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



57 коментарів

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

Коли набирав людей в команду(джун, мідл) довгий час все починалось з тестового завдання. Доволі просте, по реакту. Дуже добре допомагало відсіяти людей з фіктивними CV. Інформація яку люди подавали в портфоліо, частіше не мала жодного сенсу, все одне і те саме. Ті хто проходив тестове і приходили на технічне інтерв’ю іноді складали враження, що вони це завдання навіть не виконували, а просто скопіпастили. Але потім від тестового відмовились тому що багато стали відмовлятись, а ті що і робили були недостатнього рівня.
А саме дивне — один із найсильніших розробників якого найняли, зробив тестове завдання на низькому рівні, що я ще думав чи варто його звати на тех інтерв’ю.

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

У третьому випадку я мав розібратися в API СРМ-системи, реалізувати логін/авторизацію/методи до основних ендпойнтів СРМ. Дедлайн — до трьох днів. Фідбек був «нас влаштовує, ось офер» (це засмутило, хотілося б отримати розгорнуту відповідь, незалежно від наявності оферу, але мені тільки сказали, що все добре).

Вибачте, що не надали тоді фідбек. Надаємо зараз. Ви чудово розібрались в API СРМ-системи. Ви чудово зрозуміли, які є запити, які з них GET, а які POST. Хочу додатково відзначити, що ви не полінилися прочитати 2 сторінки документації, де це все описано, це однозначно плюс. Логін було виконано безперечно: у відповідь ви отримали токен, та зберегли його в зміннй. Нам дуже подобається такий підхід, ми використовуємо схожий в своїй команді. Ви здогадались використати отриманий токен для авторизації. Ви великий молодець, тому що в документації написано «використовуючи token», але ви здогадались, використати саме відповідь із запита логіна! Методи до основних ендпойнтів ви виконали за допомогою HTTP запитів, хоча теоретично це можна було би зробити і через TCP.

Мав різний досвід із проходженням співбесід, і скажу, що досвід із тестовим завданням був ненайгіршим із всіх.
Компанія просила зробити тестове завдання, для цього я мав часу, скільки хотів. Хоча по суті це зайняло може один робочий день. Завдання сама дуже поверхове, типу зроби отакий сервіс, я був вільний в тому, як робити, як дизайнити, як представляти це рішення потім і тд.
Вже сама співбесіда була вже не як декілька технічних інтерв"ю із розв"язуванням літкодів, а по суті моє представлення мого ж проєкта, обговорення дизайну, підходу, технічних моментів і тд.
Додатково було тільки поведінкова співбесіда.
Тому вважаю такий підхід абсолютно добрим.
З.І.: визначати чи хороший спеціаліст, чи ні тільки по резюме, чи портфоліо, це невдячна справа. Бодішопи, особливо індуські, поставили цей процес на конвеєр. Там всі мега супер пупер круті спеціалісти по резюме. Допоки не проведеш співбесіду з ним. Хоча є таланти, які і співбесіди якимось чином добре проходять. Але от коли доходить до роботи, тут вже не так весело.
Тому отаке.

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

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

Мабуть самий яскравий компроміс, це було тестове за донат на ВСУ! Я навіть не був зацікавлений у посаді, але звісно виконав тестове!

А как проверить, что донат был произведен?

Чек оплаты, плюс меня попросили дать реквизиты куда именно донат. Все прозоро...

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

Тестові завдання мають право на життя. Але при умовах

  1. Кандидат погодився його виконувати
  2. Завдання не складне
  3. Воно може навчити чомусь новому кандидата
  4. Обов’язково проведена сесія обговорення рішення
  5. Рівень кандидата середній та нижче
Особливо шкідливі тестові завдання для спеціалістів, чий рівень вище середнього. Тому що при перевірці буде виявлено не знання кандидата, а співпадіння світоглядів того, кого перевіряють та того, хто перевіряє.

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

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

Не погоджуся з умовами 2 та 5.

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

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

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

воно не відфільтровує гарних кандидатів

Задача не відфільтрувати, задача — знайти кандидата.

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

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

А може і ні. Чувак поставить 4 пробіли — а ти полюбляєш табуляції, або 2 пробіли, чи запустить ІDE «не тієї марки» — співбесіда закінчена. При цьому у реальному проекті, написано скажімо «code style — Google, 2 пробіли» — і або так, або Sonar завалить білд на CI, та розмова вичерпана — нема про що холіварити. За великим рахунком інстинктивно в нас одна претензія до людей — він такий як я (як усі) — або не такий як я. Так от — на роботу треба робітник чи робітниця які зможуть її робити в достатній якості за існуючий бюджет, а не ще один ви.

Локальний ринок:
Якщо стажероджун — робиш тестове і взагалі що завгодно, шоб отримати роботу.
Якщо мідл+ — ігноруєш, роботу знайдеш і так
Глобальний ринок:
Фаанги — літкод, проходиш — молодець
НеФаанги — читай локальний ринок

Согласно статистике на 1 вакансию откликаются 67 кандидатов. Скорее всего на вакансии с тестовыми заданиями меньше, но упростив шанс, что вас наймут 1,5%. Есть ли смысл в таком случае тратить 3 дня на тестовое задание?
В тестовом задании просят выполнить его за 3-6 часа. Но я опросил кучу народа и в лучшем случае его делают 3 дня. Один раз я сделал тестовое задание за 4 часа (при том что скопировал огромную часть кода с пет проектов) как просили и мне ответили что я как-то мало сделал, вон другой кандидат целую cms систему за 4 часа написал. Поэтому если вы не готовы тратить 3 дня на тестовое, можно даже не пытаться.
У рекрутеров есть минимальное количество человек, которых они должны затащить на собеседование по конкретной вакансии. Поэтому они всеми правдами и неправдами будут уговаривать сделать тестовое, могут соврать с вилкой зарплат, да даже с используемыми технологиями. Т.е. даже если рекрутер будет видеть, что вы не подходите на эту вакансию, вас все равно попросят дать резюме и сделать тестовое, чисто чтобы нагнать клиенту людей.

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

Потім такі компанії які платять вище ринку і немає тестових першими й закриваються в кризу з зрозумілих причин.

Жодного разу з цим не зістикався. Працюють як має бути

Кризи происходят раз в 8 лет. Поэтому отказываться посреди цикла от крутых денег?

Коли ходив по співбесідах і шукав свою першу роботу, то тестові завдання дуже допомагали прокачуватись. Кожне виконане тестове це був +1 маленький pet-проєкт, який потім показував на наступних інтерв’ю. Так як роботи у мене тоді не було, то мав багато вільного часу, щоб цим займатись. Але потім, коли через кілька років вирішив змінити компанію, то від тестових вже відмовлявся, бо не мав часу та запасу енергії їх виконувати.

Інформація неправдива. Навіщо взагалі писати неправду, незрозуміло? у компанії Intellias тестові завдання є обов`язковими і не надають переваги тим хто їх зробив. тестові завдання — це неефективний варіант відбору для спеціалистів класа Middle+ і вище і потім — проблема для подальшого спілкування із синьорними спецами на ринку. Автор Anna Belovolchenko, будь ласка, перевіряйте інформацію. 2 людини пишуть, що отримали тестове та його виконали, і по 2 людям зрозуміло, що не працюють у цій компанії, це ж нескладно подивитися на цьому ж сайті: jobs.dou.ua/...​panies/intellias/reviews

Вітаю! Євгене, дякую за коментар. Про всяк випадок уточню: компанія надала офіційні відповіді на мій запит. У статті ви бачите коментар Intellias, а не мою вигадку. У цьому ж коментарі йдеться, що тестові у компанії дають, не завжди, але дають. Тож не зовсім розумію, чому ви звинувачуєте мене у поданні неправдивої інформації.

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

не є обов’язковими

неправдива, але це не відповідає дійсності.

Це неправда, ТЗ не є обов’язковими.
Двічі наймався в компанію, ні в мене і в колег кого питав не було ТЗ, тому твоє твердження неправда.
На який саме стек і проект співбесідувався?

так я ж показав вище лінк. там можно подивитися — Oleksandra Korotkova і Олександр Кваско
пишуть що обов`язковим. виходить за логікою, якщо у мене і ціх 2 людей було тестове, а у тебе — не було, то у Інтеліас тестове завдання завжди це відмова. доречі я можу довести, у мене залишилася переписка, 2 людині по відгукам по компанії пишуть що було ТЗ. так хто писав неправду Деніс? :)

Может отказ был не из-за тестового? ;)

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

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

не хотел в Украине заказчик работать с людьми

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

Друже, я прямо зараз сиджу в офісі Інтеліасу і запитав колег, ні в кого небуло ТЗ, лише технічна співбесіда. Запитав девелоперів, Qa і одного девопса.

Деніс

Господи, так огидно перекручувала моє ім’я тільки покійна тітка з села.
Я прямо флешбеки зловив. Хороша була тітка, шкода, що від ковіду померла.

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

Global PR Specialist

не допомогло ні вам ні

Oleksandra Korotkova

ні замовнику у пошуку.

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

При відборі кандидатів на більшість позицій їх немає.

— потрібно змінювати. Те що Ви працювали раніше у цій компанії, НЕ доводить те що компанія Не доносить неправдиву або неповну інформацію. і ще: я цитую з статті, Ви як людина яка не представляє компанію і не можете змінити процеси навіщо себе цитуєте?? :)

Це неправда, ТЗ не є обов’язковими.

Що саме «це»? Те що в контору Х неможливо потрапити без виконання ДЗ? Таке твердження скоріше за все буде таки неправдою, бо в більшості випадків буде існувати хоча б 1 випадок, коли ТЗ не будуть вимагати :)
А от те що в конкретному процесі найма, на певні позиції або іноді навіть конкретним кандидатам можуть озвучити, що «ДЗ є обов’язковим» — це вже інша історія.

Особисто проводив кілька технічних інтерв’ю в Інтеліасі і вимог щодо тестових не отримував. Та й при моєму наймі його не було

За от вже 15 років в ІТ прийшов до того, що зазвичай тестове завдання, це спосіб відмовити. Особливо коли його дають таке, що його 5-6 днів виконувати. Англійці, наприклад, його дають не відкрито, так би мовити випробуваний термін і щось справжнє — якесь відносно просте завдання, та дивляться як людина чи команда його виконує. Наші, зазвичай таким чином кажуть: «Дякую що завітали, нажаль ви нам не підходите».

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

В Intetics здебільшого намагаються обходитися без технічних завдань.

Чи вирішили Intetics проблеми з тестовим завданням?

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

Это вы знаете, что вы хороший кандидат. Компания X хочет это проверить, а компания Y не хочет. Но если «хороший» — это ваше субьективное о себе мнение, а по факту это не так — она вас уволит на испытательном сроке, бесполезно потратив ваше и свое время.

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

А Вы сколько собеседований провели в качестве интервьюера? Какой % одобренных вами кандидатов продолжили работу в компании спустя 12 месяцев?

Когда ответить нечего — начинаются плоские шутки. Ну ок.

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

А не це питання «ти хороший спеціаліст ?» нема відповіді. По американських треба сказати — ТАК! Я найкращій вибір серед усіх можливих, краще мене не знайти ! Купляйте тільки в нас! По нашому то навпаки треба бути скромним, щоб не бути хвальком. От щоправда деякі маркетологи, які адаптують американьскої підходи під нас — пропонують надавати перелік досягнень, які підтверджують — що ви в своїй роботі надаєте вискоку вергогідність відтворення позитивного результату — тобто професіоналізм. Відповідно відповідаєте критерію — «добрий спеціаліст». Єдине питання — а які критерії результату вас цікавлять щоб надати їх у якості досягнень ??? Комусь треба — портфоліо, попередніх робіт та рекомендації. Комусь високій рівень знань фреймверків, алгоритмів. Комусь якісь сертифікати із підвищення чи встановлення кваліфікації. І т.п. Коротше кажучи — що для одних хороший, то для інших поганий і навпаки.

не понял, на какой из моих 2 вопросов Вы ответили вопросом на вопрос :) значит, публично не можете ответить на

Виктор, а вот Вы хороший специалист? цените свое время?

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

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

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

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

Вот представьте приходит в службу безопасности наниматься телохранитель. Ему говорят — ты классно все рассказал, красиво, но вот тебе пистолет, вот мишень, стреляй. А он в ответ — та нет, ребята, заплатите мне 100 баксов, что я просто так напрягаться буду. И если поверят ему на слово, возьмут в шатат, приставят к вам, он облажается (потому что теория и практика это вещи то разные), то вы первый же им предъявите — «кого вы набираете, почему не проверили»?

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

Тут слово «полінився» не вірно. Якщо ти реально спеціалист з рівням мідла та вище, то вірне слово — «зробив безкоштовно». Це має 3 негативних наслідки: для тебе — ти не знайшов того работодавця, який далі запропонує більше гроші, для інших на ринку — від них теж теперь очікують це робити нашару, і 3 — для роботодавця, тому що теперь кращі гравці з ринку не будуть до цієї компанії йти. А навіщо, якщо після декілька раундів результат неповаги до себе- пропонування менше грошей?? :)

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

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

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

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

Бывает что хорошему кандидату нравится компания Х и он где-то, когда то, планировал при возможности посотрудничать с этой компанией, но так совпало, что они захотели выполнение тестового ))

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