Яких стандартів можна очікувати від випускників / молодших інженерів? [зачинено]

Чи допустимі переливи буфера у випускника-розробника? Ми встановлюємо планку занадто високо? Які очікувані можливості випускників / молодших інженерів?

Контекст:

В даний час ми набираємо на посаду молодшого розробника, працюючи головним чином на C в Linux.

В рамках процесу ми вимагаємо від кандидатів скласти тест на код у вільний час у С.

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

[Редагувати]:

• Ми прямо просимо перевірити помилку, код якості продукції.
• Ми надаємо рамки для тестування та складання кандидатів

[Оновлення]:

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

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

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

Зокрема:

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

[Оновлення 2015-07-09]: Енді Девіс з Nujob написав цікаву та релевантну статтю про використання тестування коду з точки зору кандидата, і статтю варто переглянути. Знайдіть його тут .

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

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

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

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

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

День, коли ви довіряєте компетенції свого молодшого, це день, коли вас слід допитати, юніорів слід поводитись з великою кількістю наставництва та здоровою дозою "довіряйте, але перевіряйте". Я був молодшим колись, і всім, хто був там у той час: пробач. Пам’ятаєте жахливі речі, які ви робили в якості молодших? (Будь ласка, не кажіть мені, що це був лише я; ви дасте мені комплекс ..)

Я бачу тут кілька питань.

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

Друга - ваш дуже обмежений басейн. У нас також є кандидати, які роблять тест на програмування. Є п'ять окремих "програм", які вони мають написати. Вони роблять це вдома і надсилають код. Тести надзвичайно прості (немає бази даних, немає зовнішніх залежностей) і їх можна легко виконати за допомогою експрес-версії Visual Studio. Самі тести легко проходять старший хлопець приблизно за 30 хвилин. Зауважте, що ми зазвичай робимо це лише для недавніх випускників на трирічному досвіді, який можна перевірити.

Ми оцінили, що приблизно 70% тих, хто отримав тест, просто ніколи не повертаються до нас. Приблизно 15% речей, які не збираються, зазвичай через кричущі синтаксичні помилки (наприклад, відсутні ;). Ще 10% компілює, але не виконує необхідних дій.

Це залишає колосальних 5%. На даний момент ми навіть не розглядаємо такі умови, як введення альфа-символу як вхідного, коли потрібен числовий. Це суто з урахуванням дуже обмеженого набору X, оскільки вхід додаток робить відповідний вихід. Крім того, ці цифри походять приблизно від 500 кандидатів за останні чотири роки: ми вели статистику, бо хотіли знати.

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

Питання, звичайно, чому?

Чому дитина, яка здобула ступінь в цій галузі чотирирічного університету, не може виконати які прості завдання з програмування? Відповідь полягає в тому, що коледжі повністю не пов'язані з потребами бізнесу та відстають на багато років від того, що ми вважаємо сучасним. 10 років тому стандарти кодування були такими, що безпека - це те, що ви робили після факту; і одиничні тести ще не були в моді. В той час як сьогодні безпека краще бути в авангарді вашої думки з кожною функцією або додатком. Пам'ятайте лише: більшість професорів ніколи насправді не працювали в цій галузі, АБО не працювали в ній давно. Як тільки ви це знаєте, то починаєте розуміти, чому вони так відстають. Гірше, що деякі з цих професорів витрачають занадто багато часу на певну технологію ( Java , PHP), що б там не було) і не вдалося обговорити серйозні основоположні питання, такі як структура коду або прийнятні підходи (і ЧОМУ!).

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

Отже, що ми робимо?

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

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

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

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

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

Про мене:

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

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

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

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

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

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

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

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

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

• Чи здатна ваша організація залучити усіх, хто може написати робочий код?

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

• Чи здатні ви навчити свого роду програмістів, як бути програмістами, і чи готові ви витратити ці зусилля та почекати, можливо, кілька років і сподіваєтесь, що внутрішній талант кандидата здійсниться?