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

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

Відразу я планував перекинути його на Github, написати тестовий набір для нього, використовувати Travis-CI (безкоштовну безперервну інтеграцію для публічних сховищ Github) для запуску тестових наборів та за допомогою CMake для створення Linux-файлів для Travis-CI. Таким чином, не тільки я можу продемонструвати, що я розумію, як використовувати Git, CMake, Travis-CI та як писати тести, але я також можу просто посилатися на сторінку Travis-CI, щоб вони побачили результати тестів. Я подумав, що зробить це трохи зручнішим для інтерв'юера.

Оскільки я добре знаю ці технології, це не додало часу до призначення.

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

Як інтерв'ю я був би радий бачити знання процесу розробки програмного забезпечення, продемонстровані таким підходом; на відміну від просто написання коду.

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

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

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

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

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

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

Надмірна інженерія - це погане слово, коли ви створюєте AbstractFactoryManagerAdaptors, які підключаються до передачі BuzzManager та FizzManager лише для вирішення FizzBuzz.

Те, що ви робите, - це надмірна старанність, яка навіть не є річчю (хоча це недостатньо старанність).

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

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

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

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

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

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

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

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

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

Тестування має своє місце. Задайте собі наступні запитання щодо тесту та відповідайте відповідно.

1. Чи справедливий тест з урахуванням вашого поточного рівня кар'єри?
2. Чи є в тесті чітко визначена правильна відповідь?
3. Чи зацікавлений інтерв'юер у вашому потенціалі як людина, чи вони виявляють більший інтерес до результатів тестування (тобто наймані агентства для цього страшні).
4. Чи є тест тим видом роботи, який би вам подобалося виконувати, чи це неоднозначна перевірка навичок (тобто тест, якщо ви знаєте синтаксис Java).

Мені лише безпосередньо доручено виконати завдання та ввести код.

Ви щойно відповіли на власне запитання.

Відразу я планував перекинути його на Github, написати тестовий набір для нього, використовувати Travis-CI (безкоштовну безперервну інтеграцію для публічних сховищ Github) для запуску тестових наборів та за допомогою CMake для створення Linux-файлів для Travis-CI.

Ні, це не те, що вас просили зробити.

Таким чином, не тільки я можу продемонструвати, що я розумію, як використовувати Git, CMake, Travis-CI та як писати тести, але я також можу просто посилатися на сторінку Travis-CI, щоб вони побачили результати тестів. Я подумав, що зробить це трохи зручнішим для інтерв'юера.

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

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

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

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

Вони візьмуть ваш вихідний код і передадуть його по офісу. Люди будуть коментувати це, і те, що ви не хочете, щоб вони говорили, це "Він допустив цю помилку? Але витрачав час, використовуючи Git, CMake і Travis-CI. Який ідіот, коли пропустив цю помилку".

Це воно. Ви програли.

Вони хочуть знати, що ви можете кодувати, тому що вони не можуть вас цього навчити. Гіт, CMake і Travis-CI можна легко навчити.

Я думаю , що ваш підхід НЕ є ні хорошим , ні поганим самим по собі . Я б запитав інтерв'юера, чи нормально використовувати Github та інші інструменти. Як в коментарях зазначив @Izkata, ви оприлюднюєте своє рішення.

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

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