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

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

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

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

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

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

1. Тест на сенс

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

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

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

2. Тест на форму

Другий етап перевірки також є досить простим – я перевіряю документи на наявність структури.

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

Круто, коли автор дбає про свого читача і подає інформацію так, щоб підвищити шанс її прочитання та засвоєння. Наприклад, чудово виглядає подача інформації у форматі “питання-відповідь”.

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

3. Тест на якість

На перших двох етапах за 10-20 хвилин можна відсікти більшу частину кандидатів, адже перевірити суть і форму найпростіше.

А ось на третьому етапі доведеться більш вдумливо подивитися на подані документи:

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

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

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

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

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

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