Какие стандарты можно ожидать от выпускников / младших инженеров? [закрыто]

Допустимы ли переполнения буфера от дипломированного разработчика? Мы устанавливаем планку слишком высоко? Каковы ожидаемые возможности выпускников / младших инженеров?

Контекст:

В настоящее время мы набираем на должность младшего разработчика, работающего в основном в C на Linux.

В рамках этого процесса мы требуем, чтобы кандидаты проходили тестирование кода на досуге в C.

До сих пор мы отклонили двух кандидатов на основании того, что их код, хотя и читаемый и в одном случае довольно идиоматический, страдает от ошибок переполнения буфера из-за неограниченной записи в буфер.

[Редактировать]:

• Мы явно просим проверенный на ошибки код качества производства.
• Мы предоставляем тестирование и сборку для кандидатов

[Обновить]:

В результате этой цепочки и личных бесед с другими разработчиками мы меняем способ проведения тестов кода и на кого мы нацеливаемся при наборе персонала.

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

Однако мы приняли некоторые меры, чтобы сделать процесс набора персонала более продуктивным как для нас, так и для кандидатов.

Особенно:

• Мы делаем наши ожидания более четкими, с четким объяснением того, что мы подразумеваем под качеством продукции, и с предупреждением о том, что код должен быть надежным в отношении ввода и ошибок.
• Теперь мы связываем кандидатов с ресурсами по защитному программированию и стандартной библиотекой C в описании теста кода.
• Мы изменили нашу целевую аудиторию с младших разработчиков и выпускников на целевых людей с некоторым соответствующим опытом.
• В случае, если представленный код каким-либо образом дает сбой, но в противном случае будет принят, мы сейчас предоставляем минимальный тестовый пример, который вызывает условие ошибки и дает кандидатам возможность исправить свои ошибки (если код не отклонен по какой-либо другой причине). Мы также укажем проблемные линии / функции, если это необходимо.
• Цель самих тестов теперь немного изменилась: от входного фильтра появился шанс создать лучшую картину кандидата, в частности, это сообщит наше телефонное обсуждение. Тем не менее, мы по-прежнему готовы отказаться, основываясь исключительно на коде.

[Обновление 2015-07-09]: Энди Дэвис из Nujob написал интересную и актуальную статью об использовании теста кода с точки зрения кандидата, и эту статью стоит посмотреть. Найдите это здесь .

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

Я думаю, что тесты кода полезны для определения компетентности кандидата, но они не должны быть успешными. Вы должны использовать результаты теста кода, чтобы начать диалог с кандидатом.

Если вы видите ошибки, которые они совершили (особенно если они младшие разработчики), укажите на них и спросите, что они будут делать по-другому, или если они поймут, почему существует проблема.

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

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

В тот день, когда вы доверяете компетенции вашего младшего, вы должны подвергнуть сомнению ваши вопросы, к юношам следует относиться с большим наставничеством и здоровой дозой «доверяй, но проверяй». Однажды я был младшим, и всем тем, кто был там в то время: извините. Помните ужасные вещи, которые вы сделали, когда были младшими? (Пожалуйста, не говорите мне, что это был только я; вы дадите мне комплекс ..)

Я вижу несколько вопросов здесь.

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

Второй - ваш очень ограниченный бассейн. У нас также есть кандидаты на тестирование по программированию. Есть пять отдельных «программ», которые они должны написать. Они делают это дома и отправляют код. Тесты чрезвычайно просты (без базы данных, без внешних зависимостей) и могут быть легко выполнены с использованием Express-версии Visual Studio. Сами тесты легко выполняются старшим парнем примерно за 30 минут. Обратите внимание, что мы обычно делаем это только для недавних выпускников, имеющих опыт работы до трех лет.

Мы подсчитали, что около 70% из тех, кто прошел тест, просто никогда не возвращаются к нам. Примерно 15% включают вещи, которые не будут компилироваться, обычно из-за явных синтаксических ошибок (например, отсутствующих ;). Еще 10% компилируется, но не выполняет требуемые действия.

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

Если бы мы больше смотрели на структуру кода и методы защитного кодирования, такие как правильное распоряжение неуправляемыми ресурсами или использование try .. catchоператоров, то почти никто бы не прошел.

Вопрос, конечно, почему?

Почему ребенок со степенью в этой области из четырехлетнего университета не может выполнить простые задачи программирования? Ответ заключается в том, что колледжи совершенно не связаны с потребностями бизнеса и на много лет отстают от того, что мы считаем современным. 10 лет назад стандарты кодирования были такими, что безопасность была чем-то, что вы делали после свершившегося факта; и юнит-тесты еще даже не были в моде. Принимая во внимание, что сегодня безопасность должна быть на переднем плане с каждой функцией или улучшением. Просто помните: большинство профессоров либо никогда не работали в этой области, либо не работали в ней в течение длительного времени. Как только вы это знаете, вы начинаете понимать, почему они так далеко позади. Хуже того, некоторые из этих профессоров проводят слишком много времени на определенной технологии ( Java , PHPи так далее) и не могут обсуждать серьезные фундаментальные вопросы, такие как структура кода или приемлемые подходы (и ПОЧЕМУ!).

Просто побочный пример. Недавний выпускник рассказывал мне о своем опыте написания мобильной ОС для одного из своих классов, но он не мог объяснить, даже в основных терминах, как работает веб-сервер. Он просто не знал. 15 или 20 лет назад, наверное, было подходящее время для понимания того, как сделать ОС. Сегодня ... не так много. Тем не менее, это был обязательный класс, когда класс по защитному программированию был бы гораздо более полезным для них И для внешнего мира.

Так что же нам делать?

Из этих 5% мы проведем собеседование немного дальше, чтобы понять их индивидуальность и форму. Затем мы выбираем «лучших» с полным знанием того, что мы собираемся потратить около шести месяцев на «перепрограммирование» их, чтобы избавиться от дерьма, которым их профессора наполнили их.

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

Когда нанимать младшего разработчика: - Если есть излишняя легкая работа, которая будет пустой тратой времени для более старшего разработчика. - Если вы готовы наставлять и обучать этого человека в течение следующих нескольких лет. - Если вы пытаетесь вырастить компанию и хотите кого-то, кто останется надолго. Младший разработчик, который останется только на год, будет пустой тратой ресурсов компании, они мало что сделают для производства чего-либо, и большинство результатов будет в их личном росте. - Когда вам хочется тратить деньги на чей-то рост. Снова, большинство преимуществ будет тем, что они изучают.

Когда не нужно нанимать младшего разработчика. - Когда работа слишком сложная. В этом случае это просто вне их лиги. - Когда вы хотите сэкономить деньги. Старший разработчик должен выполнять те же задачи в кратчайшие сроки с лучшими качественными результатами, и, следовательно, всегда должен быть дешевле. - Когда работа является аутсорсинговой или ее недостаточно для того, чтобы работник был занят. В таких случаях было бы лучше переложить часть работы на частного подрядчика.

Последний важный момент. Не нанимайте младшего разработчика, потому что «это все, что мы можем себе позволить», или «это все, что мы готовы потратить», когда они не подходят для работы. В конце концов, все, что вы в конечном итоге будете делать - это сбрасывать деньги в унитаз Кроме того, как только они приобретут эти навыки, они все равно будут запрашивать большие деньги.

Обо мне:

• Степень в физике почти без формального обучения.
• Два года опыта работы. Так что я знаю, что такое учебный процесс.
• Начать разработку программного обеспечения. Я проделал очень сложную работу и видел разные уровни квалификации от разных людей. Многие из них не могут справиться с тем, что я делаю.

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

Учитывая это, я думаю, что правильным ответом будет поднятие проблемы в следующем возможном взаимодействии и спросить их, что они знают о переполнении буфера, чтобы проверить свои общие знания. После этого скажите им, что вы нашли такой код в готовом к работе коде. Это даст вам хорошее окно, чтобы судить, как они будут реагировать на исправления и инструкции.

Разве распространенная мысль, что младший разработчик, который знает меньше, но хочет и способен учиться и совершенствоваться, более ценен, чем младший разработчик, который знает больше, но не может или не будет совершенствоваться?

При этом в одном из ваших комментариев вы упомянули, что передали им тесты, которые указали бы на переполнение буфера в их коде, если бы они их использовали. Поэтому, возможно, главный вопрос заключается в том, почему они не запускали тесты (если они это сделали, то почему они превратили код с ошибками)?

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

Однако в искусственном тесте кода в свободной форме я был бы легок в нарушении, подобном sprintf. Слишком мало времени (предполагается), гиперактивность ума, слишком большое желание представить что-то работающее.

Я думаю, что вы задаете неправильный вопрос. Нет профессиональной цели быть профессиональным программистом. Если бы было, то был бы стандартный экзамен по программированию, но это не так. Ваша индивидуальная планка должна быть установлена ​​исходя из того, насколько вы требовательны, сколько вы можете позволить себе заплатить, сколько ошибок может позволить себе ваше программное обеспечение и сколько времени вы можете потратить на преподавание.

В этом случае, я предполагаю, что переполнение буфера, вероятно, означает, что этот код, который кандидат представил в качестве примера образцовой работы, завершается с ошибкой сегментации вместо выполнения того, что вы просили. Итак, вы должны принять кодер, который пишет код, который дает сбой с ошибкой сегментации, вместо того, чтобы делать то, что вы просили? Спросить:

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

• Является ли ваш процесс разработки достаточно прочным , таким образом, что кто - то , кто может почти написать код мог бы написать рабочий код с помощью экспертной оценки и тестирование поддержки?

• Способны ли вы научить своего рода программистов быть программистами, и готовы ли вы потратить эти усилия и подождать, может быть, несколько лет и надеяться, что внутренний талант кандидата будет реализован?