Автор оригинала: javinpaul.
Когда дело доходит до собеседований по программированию, цель состоит в том, чтобы найти наиболее подходящего разработчика для этой работы. С учетом сказанного, суровая реальность такова, что очень трудно судить о чьем-либо уровне, опыте и знаниях во время короткого собеседования по программированию.
У большинства компаний-разработчиков программного обеспечения есть стандартный процесс поиска хороших программистов, начинающийся с телефонного собеседования, письменных тестов, а затем нескольких раундов личного собеседования. Несмотря на это, компаниям все еще очень трудно нанять нужных людей. Этот процесс может помочь вам отфильтровать кандидатов, но в конечном итоге все будет зависеть от вашего опыта и интуиции.
По мере того как вы будете опрашивать все больше и больше людей, вы будете знать, о чем спрашивать, а о чем не спрашивать. И, как и многие другие интервьюеры в мире, вы разработаете некоторые из своих собственных советов. Аналогичным образом, я разработал пару советов из своего собственного опыта, которые помогли мне отличить среднего программиста от хорошего программиста.
Сегодня я хотел бы поделиться с вами одним из своих советов, ребята, чтобы посмотреть, согласны ли вы с моим наблюдением.
Один из моих самых успешных советов по поиску хороших программистов во время собеседования-это поиск пробелов в требованиях. Со временем я обнаружил и узнал , что хорошие разработчики умеют нарушать требования и находить пробелы , что очень важно для создания качественного программного обеспечения и продуктов.
Хотя этот навык приходит с опытом, хороший разработчик с меньшим опытом может обладать этой способностью. В этой статье я поделюсь двумя различными сценариями интервью с двумя программистами и посмотрю, что произошло.
Средний программист против Хороший Программист
Ключ состоит в том, чтобы указать требование к одной строке кандидату и сравнить качество программы, разработанной несколькими программистами.
Обычно я выдвигаю очень общее требование, которое не требует каких-либо знаний в области (например, финансов, здравоохранения или производства), но требует некоторого опыта программирования.
Вот гипотетический вопрос, который я задавал в реальных интервью раньше, вы можете задать:
Можете ли вы написать сценарий для архивирования файлов старше 30 дней, который можно запускать 1-го числа каждого месяца с помощью задания cron?
Среднестатистический программист перейдет к кодированию и создаст сценарий, который сделает именно то, о чем его просили. Его скрипт может найти все файлы в каталоге, предоставленном в качестве входных данных, и может создать архив того же каталога с указанным именем и датой резервного копирования в качестве суффикса.
Хорошо выглядит, правда? но погоди, кое-чего не хватает:
Он не исключил архивные файлы, созданные самим сценарием, что означает, что в следующем месяце сценарий архивирования также будет включать архив за прошлый месяц, и у вас будет больший и постоянно растущий файл.
Если вы не ведете мониторинг, вы поймете эту проблему только тогда, когда вам нужно будет что-то извлечь из архива или когда вы получите предупреждение о том, что ваша файловая система заполнена.
Он не подумал о двух противоречащих частях этого сценария — поиске файлов старше 30 дней и запуске их первого числа каждого месяца. Цель скрипта-создать резервную копию данных за прошлый месяц, продолжительность которых может составлять 28, 29, 30 или 31 день. Поэтому, если вы запустите этот скрипт 1 марта, он не будет архивировать никакие файлы, потому что всем им меньше 30 дней (февраль обычно длится 28 дней).
Его скрипт не удаляет файлы после того, как они были заархивированы. Хотя это не было указано как часть требования, это неявное требование, если только интервьюер специально не упомянул, что этого делать не следует. Вся цель архивирования заключается в экономии места за счет уменьшения размера старых файлов.
Это всего лишь пара примеров отсутствующих требований, но этот случай довольно распространен в реальном программировании. Большинство пользователей будут предъявлять общие требования, подобные этому — опытные программисты должны знать, что “дьявол всегда в деталях”.
Если ваш кандидат хороший программист , прежде чем что-либо делать, он сначала попытается понять цель, а затем подумает о том, чего не хватает. Точно так же, как когда вы идете к врачу и говорите, что у вас какая-то проблема, он или она задаст несколько вопросов, чтобы лучше понять проблему. Хорошие программисты всегда должны задавать вопросы , чтобы прояснить вопросы и сообщить пользователю, чего не хватает и многое другое.
Как эксперт в области разработки программного обеспечения, вы несете ответственность за получение достаточного количества деталей, чтобы создать что-то, что будет соответствовать ожиданиям пользователя и выдержит испытание временем. Мне нравится задавать такого рода вопросы, потому что они не относятся к конкретной области и носят очень общий характер.
Это не только дает вам возможность оценить опыт кандидата в какой-либо конкретной технологии (например, Perl, Python или скрипт Bash), но и его или ее общий мыслительный процесс.
Любой разработчик, который может продумать и найти пробелы в требованиях, станет ценным активом для вашей команды. Имейте в виду, как и все остальное, это не всегда так, и это не жесткое и быстрое правило. Это всего лишь еще один показатель, который потенциально может помочь вам найти хороших программистов.
Еще Несколько Примеры Вопросов
Вот еще несколько примеров, которые помогут вам отличить среднего программиста от хорошего программиста.
1. Попросите разработчика написать код для чтения файла.
Хороший программист всегда задает вопросы о содержимом файла (например, двоичном или текстовом, если текст, то какова кодировка), в то время как средний разработчик просто напишет код для чтения файла.
Хороший разработчик позаботится о правильном закрытии потоков и выпуске файловых дескрипторов, в то время как средний программист забудет об этом.
2. Спросите кандидатов о том, как быстро отсортировать любой массив
Средние разработчики расскажут вам об алгоритме быстрой сортировки, но хорошие разработчики начнут с вопроса о размере массива. Почему? потому что, если массив достаточно мал, то самым быстрым способом его сортировки будет использование сортировки по вставке. На самом деле, большинство библиотечных методов, основанных на quicksort , обычно используют сортировку по вставкам для небольших массивов.
Например, в Java API реализация метода Arrays.sort() сортирует небольшой целочисленный массив менее 286 элементов с использованием быстрой сортировки и крошечный массив элементов менее 47 с использованием сортировки по вставке.
Примечание : вот почему вы должны следовать совету Джошуа Блоха о том, чтобы всегда использовать библиотечный метод, если он доступен (см. Эффективная Java ). Вы никогда не добьетесь такой оптимизации за короткое время написания своей библиотеки, забудьте обо всех тестах, которые пользователи проводили в библиотеке с открытым исходным кодом.
Вывод
Вот и все для этого совета о том, как отличить среднего программиста от хорошего программиста. Как я уже сказал, это лишь один из нескольких моментов, на которые обращают внимание многие собеседования, для программистов это дает им возможность показать свой мыслительный процесс и то, насколько они хороши в понимании требований и поиске пробелов.
Этот совет помогал мне в прошлом, но найти хороших разработчиков не является жестким и быстрым правилом. На самом деле, нет правил о том, как их найти. Вам просто нужно проработать некоторые показатели и свое внутреннее чутье.
Дайте мне знать, какие советы вы, ребята, используете, чтобы найти хороших программистов во время собеседований!
Вот несколько хороших общих советов о том, как проводить собеседования с разработчиками программного обеспечения!
P.S. Если вы хотите стать хорошим программистом, не забудьте прочитать эти 10 советов, как стать хорошим программистом и эти 10 статей должен прочитать каждый программист .
Оригинал: “https://www.codementor.io/@savingfunda/how-to-differentiate-average-programmers-from-good-programmers-98g1uip92”