Чому інженерні інтерв'ю SW непропорційно складні (порівняно з дослідницькими інтерв'ю)? [зачинено]

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

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

Ось типовий цикл інтерв'ю для дослідника:

• Інтерв'ю по телефону, щоб дізнатись, чи відповідає моє дослідження дослідженню лабораторії
• Особисто: викладіть презентацію про моє нещодавнє дослідження за одну годину (що, можливо, коштує 9 місяців роботи) та дайте відповіді на запитання аудиторії
• Інтерв'ю особистого інтерв'ю з близько 5 дослідниками, де вони задають мені дуже розумні запитання щодо моєї роботи / публікацій / патентів, включаючи: технічні питання, де моя робота вписується в суміжну роботу і як я можу поширити свою роботу на нові області

Ось типовий цикл інтерв'ю для інженера SW:

• Інтерв'ю по телефону, де мені задають питання щодо алгоритму і, можливо, я кодую. Досить стандартний.
• Інтерв'ю особистості на дошці, де вони висвердлюють F *** у вас на езотеричних C ++ дрібницях (наприклад, як працює поліморфна віртуальна функція виклику), алгоритми (змушуйте алгоритм "усі пари" із найкоротшим шляхом працювати для вершин 1B) , проектування системи (проектування балансира завантаження бази даних) тощо. Це триває протягом шести-семи інтерв'ю. Смішно.

Чому хтось буде готовий миритися з цим? Який сенс запитати про дрібниці C ++ або писати код, щоб довести себе? Чому б не зробити інтерв'ю SE більше схожим на інтерв'ю дослідника, де ви говорите про те, що зробили?

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

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

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

Виходив сюди на кінцівку.

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

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

Подумайте про це на мить.

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

Мої запитання такі: "Чому так важко отримати докторську ступінь?" І "навіщо мені потрібен доктор наук, щоб бути дослідником CS?" "Чому так багато бар'єрів і перешкод?"

Чому хтось буде готовий миритися з цим?

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

Навіщо покладатися на аспірантури та видання для створення облікових даних? Чому б не зробити інтерв'ю для дослідження більше подібним до інтерв'ю SE, де все залежить від того, про що ви можете згадати зараз під час інтерв'ю?

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

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

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

Натомість нам все одно, адже нам потрібно знати, наскільки швидко ви можете дізнатися основні речі. Ви претендуєте на X-річний досвід роботи? Гаразд, ми поставимо складні запитання, щоб дізнатися, чи володієте ви ґрунтовними знаннями.

Ви не знаєте, як здійснюється виклик віртуальної функції під кришкою, але ви знаєте все про профілювання та оптимізацію? Чудово, ми, швидше за все, наймемо вас - ви здобули ґрунтовні знання в одній галузі, і тому ви неодмінно отримаєте ґрунтовні знання в іншій.

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

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

Побічне зауваження: Мені приємно, що ніхто не опублікував посилання на нарис FizzBuzz .

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

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

• Стартапів, як правило, турбує знання того, що ви можете почати писати код прямо зараз і може працювати з швидким темпом середовища. Як таке, вони, як правило, переймаються тим, скільки ви знаєте вгорі голови, оскільки вони, схоже, не хочуть бачити, щоб ви витратили багато часу на пошук того, що вони вважають "основними" знаннями. Якщо визнати, що ви не знаєте чогось, це може бути не такою хорошою справою в цьому середовищі, якщо це те, що вони очікують, що ви знаєте.
• Невеликі компанії, як правило, шукають те саме, що і стартапи, щодо того, наскільки ви знаєте, але вони не переймаються тим, наскільки добре ви поводитесь із швидкими темпами (залежно від роботи) та іншим з тими м'якими навичками принесіть і як добре ви впишетеся в кмітливість компанії.
• Великі компанії та внутрішні відділи ІТ, здається, більше стурбовані тим, що ти володієш заданим рівнем технічних знань, але вони не такі стурбовані, якщо ти не знаєш все вгорі голови, оскільки вони передбачають, що будуть якісь час, пов’язаний з тим, щоб ви пройшли навчання того, що очікує компанія. Таким чином, це середовище, коли визнання, що ти щось не знаєш, але готовий вчитися та вчитися, може сприйматись як користь.
• У дослідницькому середовищі (тобто підтримка розробки програмного забезпечення для вчених, на мій досвід) вони, як правило, переймаються питанням, якщо ви можете написати програмне забезпечення, але тим більше, якщо ви готові робити те, що потрібно для того, щоб ви могли дізнатися, що вони роблять так їм не потрібно тримати руку, поки ви намагаєтеся вирішити проблему. Оскільки це також дослідницьке середовище, вони також здаються зацікавленими у тому, наскільки ви зацікавлені у вивченні нових речей.

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

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

Знову ж таки, інтерв'ю з технікою є довільним і примхливим.

Існує велика різниця між гриль-людиною на деталях та побаченням, чи знає їх КС. Як я вже говорив вище, я маю понад десятиліття досвіду роботи з C ++, але я схильний бомбардувати питання щодо OOP / спадщини. Чому? Оскільки колись додано підтримку шаблонів, я використовував C ++ майже виключно для загального програмування .

Я взяв інтерв'ю з кількома компаніями BigHouseHoldNameTech у районі Бей та Сіетл, і одне з найкращих інтерв'ю стосувалось справжніх питань, з якими вони мали вирішити цю роботу, включаючи структури даних та алгоритми [тобто: у вас є 300 мільярдів точок даних що складається з XYZ. Як ви ефективно зберігаєте та шукаєте? ].

Це в значній мірі дозволяє вам знати, як кандидат міг би вступити та допомогти вирішити реальні проблеми, з якими ви стикаєтесь. Абсолютно гірше було і з іншою компанією BigHouseHoldNameTech, але вони задавали години, що стоять неймовірно затаємничих питань, на які вам справді слід було б просто переглянути в посібнику [ тобто описати основні відмінності між друкованою платою у Windows проти Linux - і це не було " t для положення рівня ядра ]

Хедж - фонди є химерними з їхнім наміром катувати ... очікувати 8 годин рішення ранця проблем типу на дошці.

Я розробник програмного забезпечення (c / c ++) з більш ніж 20 роками в цій галузі. Типи інтерв'ю, які ми зазвичай бачимо зараз (тизер мозку, реалізація структур даних, алгоритми пошуку тощо на дошці), раніше не було часто, окрім новинок. Якщо людина працювала в поважній компанії протягом розумної кількості часу, це вважалося доказом своєї здатності писати код. Зараз це стало дуже шкільним, і я не знаю чому. Дійсно, типові речі, які вони просять вас кодувати, МОЖЕ запам'ятовуватися, тому робити це на дошці насправді нічого не доводить. У робочому проекті ви користуєтесь Інтернетом, щоб щось досліджувати, і не писали бтрей або пов’язані списки з нуля.

Я думаю, що його чергова прихильність до управління - як і scrum - з цим, ймовірно, розпочали роботи Google, Amazon та Microsoft. Всі інші скопіювали так само, як це зробили з чином Джека Уелча та потягнули ... пам'ятаєте GE?

Якщо ви менеджер з найму, читаючи мої коментарі, то, про що ви МОЖЕТЕ запитати кандидатів, - ЯК вони б пішли на вирішення певних проблем. Замість того, щоб просити їх кодувати хеш-таблицю, задайте їм проблему, пов’язану з хеш-таблицею, і запитайте, як вони її вирішили.

Я також погоджуюся з розробником над цим постом, який сказав "дайте їм справжню світову проблему, яку довелося вирішити компанії"!

"але я схильний бити питаннями OOP / Inheritance. Чому? Тому що, як тільки була додана підтримка шаблонів, я використовував C ++ майже виключно для загального програмування."

Я також згоден з вищесказаним. Працюючи в компанії, ви пишете код ЇХ чином. Я все ще намагаюся іноді згадувати виклик C ++ за синтаксисом посилання вгорі голови, тому що старший архітектор компанії, в якій я працював 15 років, вважав за краще використовувати вказівники, а не посилання. Він був старим програмістом на С, який ви бачите. Так ось, що ми всі використали.