Як навички, використовувані в типових питаннях інтерв'ю, застосовуються в реальній роботі? [зачинено]

Для завдань із розробки додатків SQL та C # інтерв'юери зазвичай задають питання щодо обходу дерев, графіків та пов'язаних списків за допомогою чистого C та покажчиків. За 3 роки, які я провів на роботі, насправді мені ніколи не довелося

знайти шлях до 1-го вузла праворуч від даного вузла, який є кратним даного вузла

наприклад

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

Прочитайте деякі відповіді Джоеля нижче.

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

В основному, якщо ви йдете до лікаря, ви б хотіли, щоб цей лікар вивчив анатомію. Незважаючи на те, що вона лише призначає вам якийсь антигістамінний препарат, у медичній школі лікар дізнався, що певні препарати погано діють для людей із «хронічним фрактазом діамадабади до нижньої стегнової кістки». Таке поглиблене знання ВСЯКОГО за цією спеціальністю іноді може змінити життя і смерть, а в інформаційних технологіях - життя і смерть продукту або роботу.

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

http://www.joelonsoftware.com/articles/fog0000000319.html

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

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

http://www.joelonsoftware.com/articles/CollegeAdvice.html

Їх немає. Багато інтерв'ю роблять люди, які не знають, як шукати вмілих розробників , і не знають, які питання вони повинні чи не повинні задавати.

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

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

Хороші (технічні) запитання, погані запитання

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

1. (Шкідливо) "Яка довжина в рядках найдовшої робочої програми, яку ви написали цією мовою?"

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

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

2. (Погано) "Хто такий Денніс Річі?"

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

3. (Добре) "Які нові функції .NET 4.5?"

   Це питання набагато цікавіше, ніж питання про Денніса Річі. Якщо кандидат не може говорити про нові функції в .NET 4.5, чому він називає себе розробником C #? Відсутність таких знань:

   • Показує, що людину може не цікавити ні мова програмування, ні спільнота .NET,

   • Вказує на те, що людині можуть не вистачати певних знань про особливості C # /. NET, інші розробники використовують, якщо не щодня, то хоча б часто.

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

4. (Середній) "Хто з них швидший, SSD або ОЗУ?"

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

5. (Середній) "Як реалізуються стек і черга?"

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

   Я б не відкидав кандидата, який не може відповісти на це запитання, але перевіряю більш ретельно, чи справді він знає речі, наприклад, задаючи відповідне, але менш теоретичне запитання:

6. (Добре) "Як можна пройтися по дереву, не використовуючи рекурсії?"

   Якщо кандидат відповідає на це запитання, розмовляючи про FILO / FIFO та про переваги та недоліки використання стека проти рекурсії для обходу дерев, то насправді не має значення, що він не зміг відповісти на попереднє питання.

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

Як задати хороші технічні питання?

коментар kojiro цікавий і заслуговує на більш довгу відповідь:

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

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

Ось три підказки, які можуть допомогти:

1. Знайдіть друга / колегу, якого ви вважаєте кваліфікованим, і попросіть його зробити відгуки. Це вимагає великої довіри, але може принести велику користь вашій компанії.

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

3. Введіть "запитання щодо інтерв'ю" в Google. Це працює досить добре, і зазвичай пояснюють можливі відповіді. Приклад:

   • Пітон : ці десять питань здаються досить непоганими. Вони, можливо, трохи базові, але допоможуть фільтрувати 95% кандидатів, яких ви все одно не бажаєте наймати.

   • SQL від Дейва Піналя, відмінний, як завжди.

   • C # : трохи занадто просто, але знову ж таки, вони фільтрують 95% кандидатів,

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

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

^{¹ Є деякі розробники, які не зможуть пояснити, що таке B-дерево (окрім того, що це "деяка структура даних"), але все ще вміють правильно розвиватися.}

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

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

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

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

Які хороші питання програмування?

Ті відомі питання "Чи можете ви написати коротку програму" мають величезну проблему, що більшість програмістів не можуть написати єдиний рядок коду, не допомагаючи їм IDE. Але це в повсякденних робочих ситуаціях взагалі не проблема, оскільки програміст завжди допомагає йому IDE. Отже, запитуючи такі речі, як "Знайти помилку", "Написати 50 рядків коду, які роблять ..." або навіть прості запитання, потрібно враховувати, що заявник не має своїх інструментів (IDE, Google).

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

Однак, гарне питання програмування не повинно зосереджуватись на знанні API чи спеціальних навичок кодування, якщо це не є абсолютною вимогою для роботи. Знання можна отримати, тому краще з’ясувати, наскільки хороша людина в отриманні знань, ніж запитувати те, що вона / вона вже знає.

Хороше запитання до завдання програмування повинно бути коротким, простим, здатним кодувати на кожній мові лише кількома рядками коду, і це - особливо - повинно якомога більше розповісти про те, як людина працює і знаходить відповіді. Приклад:

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

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

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

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

Що таке хороші загальні знання?

На хороші запитання легко відповісти, давати широкий обсяг відповідей (так звані "відкриті запитання") і дозволяти дізнатися якомога більше про заявника, як можна за короткий час.

Приклади:

(Запитуючи програміста на C ++): "Які ще мови крім C ++ ви знаєте?"

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

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

(Далі після цього, скажемо, що він знає Java): Які три найкращі відмінності між C ++ та Java на ваш погляд? "

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

Це просте запитання, яке перевіряє багато глибоких знань про різні мови програмування. Наскільки насправді знання цих тем насправді? З цих відповідей ви можете багато чого розповісти про знання та власне розуміння основної механіки мов програмування. Скільки ця людина витратила з брудними деталями або якщо вона / вона просто хтось, хто пов'язує різні функції API, не маючи реального поняття, що відбувається під ними.

Ця концепція питань початкового рівня, що супроводжуються простими глибокими питаннями знання, може бути використана і для більшості інших тем. Завжди в цій схемі: питання про відшкодування, питання про перевірку, поглиблене запитання. Інший приклад (з інтерв'ю Java):

1. "Як би ви оцінили свій досвід розвитку багатопотокової розробки?"
2. "Назвіть, будь ласка, те, що, на вашу думку, є першими трьома найважливішими речами, які слід враховувати при розробці багатопотокової програми."
3. "Будь ласка, назвіть три класи Java API, які допоможуть вам розробити ці програми та дайте короткий опис того, для чого вони використовуються."

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

Тож наступного разу, коли хтось задасть вам 20 питань кодування підряд, ви знаєте, що він або вона в основному не мають уявлення про те, як правильно опитати когось. ;)

Попередження: це написано як (свого роду) коментар до відповіді @ MainMa, але 1) це занадто довго, щоб вмістити коментар, і 2) Я думаю, що це додає дещо іншого погляду на конструктивні питання, тому це сама реальна відповідь .

У своїй відповіді @MainMa класифікує "Які нові функції .NET 4.5?" як "гарне" питання.

Дозволю собі не погодитися. Як він це висловив, я б сказав, що це в кращому випадку досить посереднє питання. Хороше запитання було б більше подібне: "Чи відрізняється код, який ви пишете сьогодні, від коду, який ви написали N років тому?" (для деякого значення на N менше, ніж років досвіду, зазначеного в резюме, бажано приблизно від 3 до 5).

Як він це висловив, питання стосується запам'ятовування. Чи повністю запам'ятав цей кандидат список списків? За правами переможцем повинен стати той, хто найточніше цитує список Microsoft.

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

Просто вміння сказати "LINQ" не говорить вам практично нічого корисного щодо кандидата. Будучи в змозі сказати: "LINQ допоміг зробити мій код набагато більш компактним і читабельним, тому що я можу виражати поняття X, Y і Z чисто і прямо, де раніше я повинен був перестрибувати наступні палаючі обручі, щоб зробити це." (чи щось подібне) багато розповідає про кандидата, про який код він пише, його судження, гнучкість тощо. Це також дає вам набагато більше можливостей для подальших запитань щодо того, як ця людина думає про проблеми, пише код, думає про код тощо. Нарешті, це дає вам набагато краще уявлення, чи це кандидат, який насправді має N років досвіду, чи хтось, хто має один рік досвіду, повторений N разів.

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

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

Скажімо, у вашій компанії є відкрита позиція, і ви зараз опитуєте людей. У вас вже 20-30 розробників у черзі. То як би ви обрали найкращого кандидата на цю посаду? Скажімо, найскладніше завдання, яке вони повинні виконати в цій роботі, - це відкрити файл з файлової системи, прочитати дані рядки за рядком, трохи змінити його і повернути в початковий файл.

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

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

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

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

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

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

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

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

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

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

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

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