⌘142. Перевірка тестових завдань

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

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

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

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

Отже, ось три мої прості кроки:

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

Перший та другий етап зазвичай зрізає 60% кандидатів, ще 20% може зрізати третій етап.

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

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

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

Отже, процес такий:

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

Підписатися у Telegram

Надіслати
 4   21 д   Sad But True   менеджмент