Чи надмірна інженерія є попереджувальним знаком? [зачинено]

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

Тепер моє запитання: це попереджувальний знак?

EDIT: Досить багато дискусій базується на хибному тесті - що є справедливим моментом. Як я описав у коментарі, основна передумова тесту полягає в тому, щоб показати, як ви можете читати дані з файлу розумним чином (і ви будете вражені різноманітністю підходів, які ми бачимо), і як відповідати елементів, перш ніж обчислити затримку між оновленнями. Тепер для цього потрібно зробити певні припущення щодо даних, і ми шукаємо ці припущення, а також чітко заявляємо, що ми хочемо бачити підхід, який ви приймаєте (включаючи підхід OO тощо). Все це за дві години період часу.

ІМХО, коли я брав інтерв'ю, це була найповніша вправа, на яку я зіткнувся.

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

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

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

Я б сказав, що це чіткий попереджувальний знак, але необов'язково дискваліфікація кандидата.

Існують дві окремі проблеми, які, здається, мають кандидати:

1. Пропущений пункт вправи - Це досить тривожно. Усі навички програмування у світі не дадуть хорошого результату, якщо хтось не в змозі кинути проблему, яку він вирішує належним чином. Я виявив, що найпродуктивнішими інженерами є ті, хто здатний визначити справжню проблему, яку потрібно вирішити, навіть якщо це не зовсім поставлена ​​проблема. Наявність здатності критично розмірковувати над питанням, яке задається, і, можливо, переформулювати його в щось більш просте для вирішення, є критичним вмінням. Відсутній момент, коли проблема чітко заявлена, повинен бути великий червоний прапор.
2. Перевірка рішення рішення - Це вторинне питання і часто є результатом першого випуску. Існує пара різних патологій, які можуть мати такий результат. По-перше, неправильне розуміння проблеми або занадто широке викладення її може призвести до занадто складного рішення. Це чітко пов’язано з першим пунктом вище. По-друге, намагатися "показати себе", продумуючи майбутні сценарії, які насправді можуть не бути актуальними. Це може бути проблематично, оскільки це вказує на те, що кандидат не зрозумів значення простоти в рішеннях та відстрочення складності, поки це справді не потрібно. Це те, що можна виправити за допомогою хороших вказівок, але це уважність, коли хтось входить в організацію.

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

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

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

Ось кілька речей, які, напевно, не згадували ваші вимоги:

• Стандарти кодування

• Коментарі

• Обробка винятків

• Описові назви змінних, класи, методи

• Після ідіоматичного використання мови

• Правильний об’єктно-орієнтований дизайн

• Увага до можливих проблем одночасності

• Написання тестових випадків для коду

Ви звернули увагу на одну з цих речей, не чітко про це заявляючи? Як кандидат міг би знати, хто з них вас хвилює, а який - ні?

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

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

ИМХО відповідь явно да , це попереджувальний знак, якщо

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

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

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

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

Можливо.

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

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

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

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

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

Можливо, але врахуйте наступне:

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

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

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

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

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

Багато цього можна пояснити тим, як ви формулюєте питання і як ви ставили все інтерв'ю в перспективу.

Це як: "Давайте подивимося, наскільки ти креативний. Що таке 2 + 2?" Четверо? Все, що ви могли придумати, - це найпростіша, очевидна і точна відповідь? Молоді розробники початкового рівня, які так хочуть справити враження під час інтерв'ю, приймуть «Ми хочемо перевірити ваші навички кодування або побачити, наскільки ви хороший програміст». означати "зробити щось дуже складне". Нам усім подобається вважати простим найкраще, за винятком випадків, коли це ускладнює справи.

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

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

Це залежить, але взагалі ні.

Дизайн взагалі - це навичка, засвоєна досвідом. Опис Aaronaught прогресію, пов'язану Мар'яном, як правило, хороший.

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

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

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

Також: Яку посаду рівня ви наймаєте? Занадто велика інженерія для кандидата на вступний чи проміжний рівень є менш проблемою, ніж надмірна інженерна робота у кандидата на старший рівень.

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

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

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