Пособеседуем ... "Сеньйора"

Додав трохи «жовтого-Alizar-style» в заголовок.

З подачі Макса Іщенка , термін «сеньйор» може незабаром знайти нове семантичне значення і стати широко відомим у вузьких кола, а також зайняти гідне місце серед таких загальних як Коте, Капітан Очевидність, Мопед , Гном і пр. І буде він означатиме не що інше, як «сеньйор 80 рівня в 23 роки» .

Але пост не про це. Нижче я б хотів поділитися з шановними читачами ДОП особистим досвідом проведення співбесід.

За свою кар'єру я встиг попрацювати у трьох містах (Донецьк, Харків, Київ) і в різних компаніях: бухгалтерське ПЗ, торгові та фінансові інструменти, ігрострой, аутсорс, авіа-симулятори, промислове 3D. Багато разів інтерв'ював і був співрозмовникам, бачив багато схем і різних підходів. І на поточний момент все це «сінергетіровалось» і «випала в сухий залишок» у формі наступного алгоритму роботи з шукачами (С).

Перший етап - очна чи заочне спілкування

(бажаний, але не обов'язковий етап)

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

Оцінка:

  1. Обсяг (рядки, кількість файлів)
  2. Структурна організація (папки, файли, іменування)
  3. Коментарі коду.
  4. Угоди по іменування.

Що дозволяє дізнатися/оцінити:

  1. Підходи С в частині командного взаємодії - занурення «стороннього» людини (інтерв'юера) в свій програмний код.
  2. «Стиль» програмування.
  3. Використовувані технології/фреймворки/бібліотеки/велосипеди.

Другий етап - очне спілкування

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

Оцінка:

  1. Злагодженість у русі думки, послідовність викладу.
  2. Вміння слухати і чути співрозмовника/опонента.

Що дозволяє дізнатися/оцінити:

  1. Рівень володіння UML, кількість типів діаграм в арсеналі С.
  2. Владение паттернами проектування.
  3. Здатність переміщатися по архітектурі вниз-вгору, вправо-вліво, вперед-назад, перехід від загального до конкретного і навпаки.
  4. Реакцію З критику з боку і як наслідок стадію «зіркової хвороби».

У процесі обговорення загострюю увагу на технічних деталях і промацують базу: «А чому тут спадкування, а не композиція?», «Тут не з'явиться зрізка?», «Чому не використали boost:: bind?» і пр.

Плюси:

  1. Ми розмовляємо про те, що претендент знає , а не про те що він не знає . Нехай 1 - універсум, який, Ви хочете перевірити q - це те, що С знає, n - то що, не знає. Як наслідок q + n = 1. Я завжди віддаю перевагу спілкуватися на тему q.
  2. Розмова йде «природним» шляхом, який підходить обом учасникам.
  3. «Симулятори/Емулятор» командної роботи.
  4. Можливість у будь-який момент поставити логічну крапку в співбесіді, без необхідності виконання «30 тестів за 1 годину».

Мінуси:

  1. Недостатній рівень формалізму. Для великих компаній кількість паперових артефактів повинно бути більше і вони повинні бути структуровані, так як вони можуть/будуть використовуватися для повторного інтерв'ювання та/або як вхідні дані для евалюейшенов.
  2. Даний підхід важко (але можна) адаптувати для інтерв'ювання Junior/Middle розробників, для яких важливим критерієм оцінки є все-таки саме «енциклопедичні знання».

Час:

Через 30 хвилин ясно який рівень С.

USP:

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

Опубліковано: 18/07/11 @ 04:05
Розділ Різне

Рекомендуємо:

Аутсорсинг і еволюція організації праці програмістів
$ 6000 від webeffector в конкурсі "Просування неминуче"
Квест по створенню ВП у Рязані
Інтерв'ю з Максимом Спиридоновим про його проект ШколаЖизни.ру
Золоті гори, найкращі фахівці або ми крутіші конкурентів