Як взяти співбесіду з кандидатом у систему сидміна? [зачинено]

Які б питання ви задавали і які сценарії ви описували б, які відповіді ви шукали б?

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

Я задаю питання в 3 категоріях:

• Технічні знання - Я хочу переконатися, що кандидат знає, що він / вона повинен знати. Наприклад, скажіть мені різницю між RAID 0, RAID 1, RAID 5, RAID 1 + 0 і RAID 0 + 1. Якщо адміністратор Служб каталогів AD, розкажіть мені про роль FSMO лісу та домену та що вони роблять. Крім того, тут я запитую, яка технологія їх цікавить. Чи будують вони роботів на боці? Добре! Вони програмують зазначених роботів? Дійсно? Тому у мене є хтось, хто може трохи кодувати і знає болі усунення несправностей. Видатний! Такі речі.
• Особистість - я задаю питання про те, як вони впораються з різними сценаріями. Ситуації на кшталт "Прем'єр-міністр розуміє, що в графіку була допущена помилка. Ви знаєте, що помилка - це помилка прем'єр-міністра. Ця помилка призведе до того, що ви працюєте два вихідні назад до спини. Як ви впораєтеся?" В основному питання, які розкривають, як думає кандидат і чи вони знають, що робити, щоб бути частиною команди. Це не відмовить людей, які знають правильні відповіді і не роблять їх, але це відлучить людей, які не мають уявлення, як гарно грати з іншими. Я також задаю питання щодо участі громади.
• Попередній досвід - я зазвичай прошу кандидата дати мені ситуацію чи проект у минулому, які добре склалися там, де вони були головною частиною. Я хочу знати, з якими викликами вони стикалися і як вони вирішували їх. Я також прошу дати мені ситуацію, коли справи йшли не так добре. Які уроки здобув кандидат? Що міг би зробити кандидат, думаючи заднім числом, щоб, можливо, розвернути ситуацію (а якщо кандидат не зміг, чи визнає кандидат це).

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

Чудове запитання, яке мені одного разу задали:

Уявіть, я зареєстрував вас тут на машині і підвів термінал. Ви вводите wget http://www.google.com/. Що сталося?

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

"Ну, це почалося з переривання клавіатури ..."

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

Але ось моє найважливіше питання -

Перше моє інтерв'ю з "справжньою" ІТ-фірмою закінчилося, коли я потрапив на технічне запитання, на яке я відповів: "Не знаю".

Відповідь була: "Чудово, коли можна починати?"

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

Я часто опитую людей на посадах початкового рівня, тобто я не можу обговорювати істотну історію роботи. Я зазвичай обговорюю особисті проекти, але два питання, які я завжди задаю, - "Чи можете ви описати мені свою домашню мережу?" та "Як створити резервну копію домашніх машин?" Дійсно зацікавлена ​​людина може постояти біля дошки 30 хвилин, обговорюючи це, потрапляючи в IP-адреси, бездротову безпеку тощо. Бідний кандидат знизає плечима і скаже вам, що його брат налаштував.

Не задайте "дрібниці" питань - запитання з однозначною, дуже конкретною відповіддю. Люди можуть забути таку річ, коли перебувають під стресом. Якщо їхня робота вимагає, щоб вони знали, який штифт в інтерфейсі V.35 використовується для передачі даних, вони можуть шукати це, коли вони мають роботу. Загальні запитання допомагають зрозуміти більше про кандидатів, ніж дрібниці ... Ми також не любимо дражнилки мозку.

Практика системного та мережевого адміністрування

Задавайте різні типи питань, які допоможуть вам дізнатися про кандидата. І як вони впишуться у вашу робочу групу. У давні часи. Більшість SA були фізиками, астрономами, математиками та інженерами. Чому? Можливо, тому, що мав відмінні навички стрільби та брав дуже хороші ноти.

Кілька запитань:

Технічні

• Опишіть мені, ніби я нічого не знаю, як працює мережа TCP / IP.
• Опишіть мені, ніби я нічого не знаю, як працює комп’ютер (основний пристрій Фон-Ноймана)
• Намалюйте мені просту мережну схему: у вас 20 систем, 1 маршрутизатор, 5 комутаторів, 2 сервери та невеликий блок IP. Іди.
• Виходячи з роботи, що ви очікуєте робити тут?
• Опишіть мені, що ви сподіваєтеся досягти тут.
• Який найкращий спосіб оновлювати документацію?
• Який найгірший випадок аварійного відновлення, у якому ви коли-небудь були причетні? Скажи мені, що ти зробив.
• Чому вам подобається бути SA?
• Як би ви оцінили себе як СА?

Бізнес

• Чи вірите ви, що ІТ стимулює бізнес чи бізнес керує ІТ?
• Що ви думаєте про нашу сьогоднішню модель бізнесу?
• Що ви могли зробити, щоб зробити нас вигіднішими?
• Як ІТ-інтерфейс з нашою компанією?

Особисті

• Який ваш улюблений жарт?
• Яку книгу я повинен прочитати завтра? Чому? (потім перейдіть до бібліотеки і перегляньте її)
• Хто такий Томас Лімончеллі? (хе-хе, ГОТЧА!)

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

Наймання СА - дуже складне завдання. Навряд чи технічне інтерв'ю опише, кого ви наймаєте. Це не стільки те, що вони зараз знають. Це те, що вони готові навчитися, і як швидко вони навчаться і застосовуватимуть це.

Якби я був членом групи інтерв'ю для sysadmin в програмній компанії, де, як слід було б, вони підтримуватимуть програмне забезпечення компанії на своїх серверах, мені було б цікаво дізнатися, чого очікує кандидат від розробників. Як вони взаємодіють з розробниками - "ми проти них" або "всі разом з різними знаннями"? Чи є у них досвід ситуації, коли розвиток та ІТ (чи той, де називається відділ) закінчилися конфліктом, і як це було вирішено? Є чи вони зацікавлені в отриманні деякої обізнаності про технології та термінології , використовуваної розробниками, і вони готові допомогти навчити розробників в своїх областях знань, щоб кожен міг краще спілкуватися?

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

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

Питання "пустої дошки" - це ті, що справді відокремлюють овець від кіз. "Це межа мережі; це веб-додаток, який працює на IIS, це ваш SQL-сервер; це поле UNIX з іншою службою чорної скриньки на ньому. Як зробити це стійким до відмов, захищеним тощо?" "

Єдиною відповіддю, яку я отримав на це від одного кандидата, був олеяний "ти жартуєш, правда?"

Я наймаю адміністраторів Linux для запуску, тому мої питання такі, які повинні дратувати досвід із недосвідченості. Екран телефону:

1. Назвіть стільки каталогів вищого рівня в сучасній системі Linux (FHS), скільки можна (їх близько 20, ніхто не отримує більше 75%, навіть ті, хто цим займається щодня)?
2. Для чого використовується змінна середовища PATH?
3. Назвіть людину, відому своєю причетністю до програмного забезпечення з відкритим кодом / вільним програмним забезпеченням (крім Лінуса Торвальда) (найчастіша відповідь: Річард Сталлман)

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

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

Інакше це більш детально говорити про те, що вони очікують від робочого середовища, намагаючись з’ясувати, чи є вони 9-5er чи чи насправді цікавить те, що вони роблять --- відсутні інші фактори, типи Linux до уваги (хоча вони можуть смоктати), а мережеві інженери, як правило, 9-5ers (хто теж може смоктати) ... Просто мій досвід.

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

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

Після ретельного сортування резюме у мене ще було 20 кандидатів. 20 осіб із ~ 150 пройшли перший відбір, який дозволив мені витратити три-чотири години на опитування кожного з них. Основними критеріями відбору для мене були:

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

Щоб знати про їх вміння збирати та вирішувати проблему в нестандартній ситуації, мене запитали, наприклад: "Як зіпсувати Windows-систему, якщо у вас є фізичний доступ до комп'ютера, але у вас немає жодного паролі облікового запису? " і після цього я запитав їх про "Як виправити зіпсовану систему?". Я наводив декілька прикладів боротьби з вірусами і запитував, що вони роблять, щоб запобігти пошкодженню та повернути функціональність та втрачені дані з якомога меншим числом інструментів та більше питань щодо використання нестандартних інструментів. Одного разу я запитав кандидата: "Яке питання ви б задали , якби ви опитували мене, щоб знати, наскільки я хороший у нестандартних ситуаціях?" :-)

Щоб знати, наскільки вони хороші в пошуку оптимального підходу, я наділив їх невеликою практикою в налаштуванні веб-або поштового сервера або мережевого шлюзу для певних параметрів ("мені потрібно, щоб це був дуже швидкий веб-сервер для невеликої кількості підключених клієнтів" до цього, і так, я хочу, щоб на ньому була створена мова скриптів на стороні сервера, щоб показати мені певну статистику, що я повинен обрати і чому ти робиш те, що краще? Не могли б ви показати мені на нашому тестовому сервері, якщо у вас є залишилось 20 хвилин? ")

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

База знань - одна з моїх улюблених частин: Що таке OSI? Чому TCP / IP називається " стек протоколу "? Які герої інформатики ви знаєте? Що таке Windows-реєстр? А як щодо систем, схожих на Unix?

І дуже важлива річ - вони ОБОВ'ЯЗКОВО люблять свою роботу! "Чи читали ви деяких класичних авторів, таких як K&R?", "Як довго ви захоплюєтесь комп'ютерною технікою?", "Що ви почали вивчати комп'ютери?", "Чи є у вас тестові комп'ютери / маленька мережа вдома?" (якщо це правда, це дуже хороший знак!).

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

Мені подобається задавати питання, протилежні нормальній формі цього самого питання. Наприклад, у веб-розробці поширене питання "коли ви надсилаєте форму замість GET?" Але я запитую навпаки: "Коли ви використовуєте GET замість POST?" Це змушує людей замислюватися про недоліки замість переваг або розглянути, які компроміси вони роблять, приймаючи рішення.

Репрезентативне запитання щодо ІТ може включати два подібні технології вибору; можливо, питання типу "Коли ви вибрали робочу групу Windows замість домену?"

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

Трохи поза темою - але цікава історія з офіційного блогу Google:

Як я потрапив у Google (гл. 1)

Наші інженери, однак, прагнуть їхати за різними, а іноді і більш дивними, маршрутами. Деякі приймають на роботу поза школою, або друзями чи колишніми колегами. Інші просто надсилають своє резюме на jobs@google.com. Хоча для кількох інженерів шлях був цікавішим.

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

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

Кандидат не повинен просто говорити: "Я не знаю". Я шукаю відповідь детальніше за принципом "Я б хотів, щоб Google" або щось подібне до "Я є учасником [ACM | SAGE | LOPSA | Помилка сервера], і я би перевірив [архіви списку розсилки | веб-сайт ], щоб знайти допомогу у відповіді на це питання ".

Дізнатися, куди звернеться кандидат, коли він не знає відповіді на запитання - це хороший спосіб сформувати свої можливості.

Я брав інтерв'ю з людьми як як працівник великої компанії, так і як власник невеликої компанії. Якість номер один, яку я шукаю, - це врівноважена особистість між "прозорливим" та "тинкірним".

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

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

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

Крім цього, будь-який sysadmin в ролі * nix повинен бути в змозі описати, чому це смішно .

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

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