Я усвідомлюю, що про цю річ було багато дискусій, і вони часто перетворюються на догми навколо того, чи задаєте ви питанням "100 логічних піратів" чи ви змушуєте їх писати "fizz buzz".
Мене цікавить, які методи та питання були ефективними для вас під час опитування потенційних розробників для роботи.
Одна техніка на відповідь, щоб ми могли проголосувати за них, будь ласка.
Відповіді:
Окрім реальних технічних питань, і, як правило, наприкінці інтерв'ю, я намагаюся зрозуміти рівень їх зацікавленості в галузі та культурі з такими питаннями:
Ви бачили щось недавно, пов’язане з програмуванням, яке вам було цікавим і хотіли б рекомендувати іншим програмістам? Нова мова, інструмент, платформа, техніка, веб-сайт?
Чи можете ви назвати будь-яку відому людину в нашій галузі, чия робота вам подобається, або яка надихає і чому? (розробник, засновник веб-сайту, автор, доповідач тощо)
Що ти зараз читаєш чи яка остання прочитана книга, пов’язана із програмним забезпеченням?
Які сайти, пов’язані з програмуванням, ви часто відвідуєте?
Хоча відмова відповісти на ці запитання взагалі (на жаль, це трапляється дуже часто) не означає для мене «не наймання», вони багато говорять про те, як людина підходить до професії розробки програмного забезпечення.
Змусити їх написати код, реальний код.
Інтерв'юер може дозволити вам вибрати мову програмування, яка вам найбільше подобається, будь то C ++, Java, C # або що завгодно, і попросити вирішити просту проблему, наприклад, виконати якусь роботу зі струною або подвійно пов'язаним списком чи будь-яким іншим. Якщо у вас є проблеми з використанням вашої кращої мови для вирішення простої проблеми, то є проблема. Будь ласка, ознайомтеся з повідомленням у блозі Стіва Єгге та особливо у розділі "Психічна підготовка".
Нехай кілька людей з вашої команди опитують їх самостійно. Діліться своїми думками після цього, не розмовляйте між ними, перш ніж опитати їх. Якщо говорити між ними, то буде залежати ваше судження, і ви не матимете незалежних суджень.
Для технічних людей, які опитують їх, змушують їх писати код. Що стосується нетехнічних, не намагайтеся запитати те, чого ви не відчуваєте. Переконайтесь, що у вас є хоча б деякі технічні люди, які беруть інтерв'ю.
Інтерв'ю не повинні проводити лише керівники, це має бути надзвичайно важливим для кожного працівника, з яким вони працюватимуть у майбутньому.
Мені подобається співбесідник, який пояснює свої попередні проекти та те, що вони робили. З цієї відповіді у мене можуть виникнути подальші запитання: чому вони робили щось певним чином, як вони вирішували певну проблему, якщо згадували про неї, але найголовніше, що було метою проекту та які бізнес-проблеми вирішили.
Я роблю це, щоб побачити, чи можуть вони сформулювати так, щоб змусити мене зрозуміти, що вони робили, і побачити, чи зрозуміли вони, що роблять.
Дивно, що останнє питання про мету проекту та бізнес-проблему вирішило, що подорожує багато людей. Вони поняття не мають, Чому взагалі робився проект, над яким працювали. Якщо ви не знаєте, чому ваш проект існує в першу чергу, мене змушує задуматися, чи сприяєте ви рішенням, чи просто так, як вам кажуть.
(Зрозуміло, я кидаю цю туди, оскільки всі інші відповіді, як правило, є технічними. Я хочу, щоб люди знали, чому вони вирішують і ті проблеми, які вони вирішують, інакше вони, як правило, вирішують неправильні проблеми, які не має кінцевий користувач " т байдуже :)
Попросіть їх прийняти важливе архітектурне рішення
Наприклад. Ось програма x, яка виконує y кількість підзадач одночасно. Яку б ви обрали, багатопроцесову або нарізну структуру.
Які переваги / недоліки обох. Наскільки вони б добре працювали і як їх можна використовувати для використання багатоядерної багатопроцесорної платформи, які ваші особисті переваги? Особисті упередження можуть допомогти визначити, чи доводилося їм коли-небудь реально застосовувати знання та надавати їм точку стрибка, щоб поділитися своїм досвідом?
Є багато питань, з якими інтерв'юер міг би поставити такі:
Більшість із цих тем - це типи, які передбачають інтимне знання про те, як / чому комп'ютерна система працює так, як це робиться. Всі вони - питання / рішення проблем, на які немає однозначної відповіді, тому вони дають уявлення про те, наскільки добре ця людина здатна адаптуватися або подолати проблеми, що стоять перед ними. Не той тип понять, який можна легко підібрати без деякого практичного досвіду.
Примітка: Якщо заявник написати якийсь песудо-код, теж обов'язково, але ця відповідь вже прийнята.
Просто дайте їм базовий код, який потрібно зробити на дошці - наприклад, виконання пов'язаного списку, сортування чи щось подібне.
Ви можете судити про те, наскільки вони комфортні з їхньою мовою без допомоги компілятора, і ви можете судити про їх розумовий процес (особливо якщо вони ніколи такого не реалізовували - більшість "нових" програмістів ніколи не робили).
Поговоріть, дозвольте їй просуватися і вигулюватись по технічному та професійному маршруту та шукайте проникливі чи дурні коментарі по дорозі. Це дає вам 3/4 того, що вам потрібно від співбесіди, оцінки: навичок та особистості людей, загального інтелекту та грубої оцінки технічних навичок.
Використовуйте свої "інтерв'ю" для інтерв'ю як початкових тем та для того, щоб підтримувати розмову у відповідності до технічних тем - можливо, вам буде потрібно час від часу скидати бесіду (наприклад, виконувати вправу кодування), щоб адекватно досліджувати сфери, які викликають занепокоєння / інтерес.
Справжня хитрість цієї техніки полягає в тому, щоб переконатися, що вони все говорять, інакше ви ризикуєте сприятливо оцінити, оскільки вони змусили вас почувати себе розумними, слухаючи / погоджуючись з усім, що ви сказали.