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

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

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

Це може бути будь-який файл, наприклад:

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

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

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

Отже, ось три моїх простих кроки.

Тест на сенс

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

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

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

Тест на форму

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

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

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

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

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

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

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

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

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

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

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

  • з’ясовувати відгуки з минулих місць роботи,
  • з’ясовувати, які цілі стояли перед кандидатом на минулих місцях роботи і як він із ними впорався.

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

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

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

Sad But True | Андрій Чумаченко (с)

Рейтинг
( Поки що оцінок немає )
Сподобалася стаття? Поділитися з друзями:
Роби Бізнес, Укр
Додати коментар

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: