Собеседование: 8 самых распространенных ошибок программистов

Изучим ошибки и поймем, как их избежать

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

Причина, по которой некто мог бы выполнить нечто, если бы такая возможность была, состоит в том, что он сделал бы то, что выполнить не может. (Огурчик Рик)

Мы уверены, что вы бы провели полномасштабное статистическое исследование. Именно потому, что у нас такая возможность была, мы за это и взялись.

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

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

В конце вы найдете описание методологии, примененной нами для написания статьи.

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

Давайте сначала бросим взгляд на проблему с высоты птичьего полета:

Общее количество всех столбцов составляет более 100%, поскольку некоторые отзывы описывают более одной ошибки.

#1: Написание кода до записи наброска решения

Частота ошибки на собеседовании: 20.66%.

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

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

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

Только после того, как вы и ваш собеседник согласитесь, что получено хорошее решение, приступайте к реализации.

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

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

#2: Слабые знания основ Computer Science

Частота ошибки на собеседовании: 20.05%.

Понравится вам это или нет, но большинство ключевых тем собеседований с программистами сегодня по-прежнему вращаются вокруг проблем, связанных с структурами данных и алгоритмами (DS&A). Это справедливо как для стартапов так и крупных компаний, таких как Dropbox, Airbnb, Uber & Palantir и, конечно же, для таких гигантов, как Google, Facebook, Amazon & Apple.

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

Совет. Потратьте какое-то время на изучение структур данных и алгоритмов. Это поможет не только в программировании, но и в профессиональном росте. Понимание базовых DS&A является важной составляющей при разработке любого программного обеспечения.

Примечание переводчика: в англоязычной литературе DS&A — аббревиатура для фразы Data Structures & Algorithms – структуры данных и алгоритмы.

Помимо Pramp.com, вот список ресурсов, которые мы рекомендуем:

1. Отличный курс от Courcera, предоставляющий всю важную информацию об алгоритмах и структурах данных, необходимую каждому серьезному программисту: Алгоритмы, часть 1, Алгоритмы, часть 2.
2. «Cracking Coding Interviews» Гейла Лаакманн Макдауэлла — хорошая книга, в которой есть примеры задач, решения и рассказы о том, как разные компании подходят к найму.
3. Два хороших бесплатных учебных курса, посвященных тому, чтобы помочь вам добиться успеха в техническом собеседовании:

• Подготовительный курс по техническому собеседованию от Udacity & Pramp
• Подготовка к собеседованию по программной инженерии от Coursera

#3: Успокойтесь

Частота ошибки на собеседовании: 15.80%.

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

Совет. Самое распространенное когнитивное искажение – думать, что ваши мысли очевидны и понятны для других. Выполняя задачу, объясняйте каждый шаг рассуждений. Говорить и писать код одновременно для многих из нас не является естественным. К счастью, есть отличная платформа, которая поможет вам практиковаться :). Если волнение мешает правильно высказывать мысли, можете попробовать эти методы, чтобы овладеть собой.

#4: Слабое знание языка программирования

Частота ошибки на собеседовании: 12.56%.

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

Однако, если вы не справились с такими элементарными вещами, как, например, управление памятью в C, наследованием в Java, генератор списков в Python или замыкания в JavaScript, ваше собеседование обречено на провал. Хотя подобные ошибки обычно совершают новички, она также распространена и среди специалистов из академической среды, имеющих глубокие теоретические знания, но скудные практические инженерные навыки.

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

Если это не так – например, если вы проходите собеседование на позицию фронтэнд-разработчика, где требуется знание JavaScript, заранее потренируйте навыки программирования на этом языке.

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

Разработка собственного проекта – единственный способ на практике освоить язык программирования. Нет идей? Вбейте простой поисковый запрос в Google.

#5: Отсутствие тестирования

Частота ошибки на собеседовании: 10.33%.

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

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

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

Совет. Рекомендуется трижды использовать тесты во время собеседования. В первый раз – сразу после того, как ваш интервьюер закончил задавать вам вопросы по вашему коду. Используйте один-два примера, чтобы проверить, что вы поняли вопрос (подробнее см. # 6 ниже). Второй раз после того, как вы набросали свое решение. Используйте нетривиальный тестовый пример, чтобы вместе с интервьюеров пройтись по вашему псевдокоду и проверить его правильность. Наконец, как только вы закончите программировать свое решение, проверьте еще раз, что в вашем коде нет ошибок.

#6: Неправильное понимание вопроса

Частота ошибки на собеседовании: 9.11%.

Среди всех перечисленных нами ошибок избежать эту легче всего. Довольно удивительно, что около 9% всех кандидатов все еще совершают эту ошибку.

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

Совет. Первое, что вы должны сделать после того, как ваш интервьюер закончил объяснять свой вопрос ‑ повторить этот вопрос своими словами, чтобы убедиться, что вы все правильно поняли. Если вы ошибаетесь, вам подскажут. Это избавит вас от ошибочного ответа на совершенно другой вопрос. Иногда мы слишком поздно понимаем, что совершили ошибку и времени на исправление уже не остается.

Повторяя вопрос, приведите несколько простых примеров входных данных и убедитесь, что вы правильно оцениваете ожидаемый результат. Второй момент – спросите, можете ли вы сделать определенные предположения. Например, спросите, можете ли вы предположить, что входные данные находится в определенном диапазоне. Или, в зависимости от вопроса, спросите, нужно ли сортировать данные на входе. Наконец, также хорошо прояснить заранее, требуется ли проводить оптимизацию.

#7: Игнорирование граничных случаев

Частота ошибки на собеседовании: 8.31%.

Не учет граничных случаев, может являться признаком неразвитых навыков решения задач программирования. Во-первых, если ваш алгоритм не обрабатывает все корректные данные — решение является неполным. Во-вторых, не учитывая граничные случаи, вы упускаете возможность придумать более удачный алгоритм решения. Например, в задаче «Поиск недостающего числа» прямое («силовое», грубое) решение заключается в том, чтобы вычесть сумму входного массива из общей суммы (1, …, n). Однако при достаточно большом «n» решение будет неверным из-за переполнения целочисленного значения. Осознание этого граничного случая заставит вас подумать о более подходящем решении. И действительно, используя побитовый оператор XOR, мы можем разработать решение, которое больше не подвержено переполнению (более подробно см. второе решение в ссылке выше).

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

#8: Сырой код

Частота ошибки на собеседовании: 7.69%.

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

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

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

• Использование непонятных имен для переменных, функций и т.д. Обычно это использование одиночных символов в качестве имен переменных. Или вызов функции с именем«func». Особенно внимательным нужно быть спортивным программистам, поскольку они привыкли использовать сверхкороткие имена в своих программах, чтобы быстрее кодировать. Это не сработает во время собеседования.
• Непоследовательный стиль кодирования. Несмотря на то, что у каждого имеется свой стиль программирования, следует избегать смешения различных стандартов оформления программного кода. Например, использование различных соглашений об именах. Или использование табуляции в одних частях вашего кода и использование пробелов – в других. Вам следует придерживаться определенного стиля. Например, если вы поместите открывающую фигурную скобку в одну строку, не помещайте затем ее с новой строки. Подобных примеров можно приводить множество, но я думаю, вы уже поняли.
• Использование безопасного программирования, такого как NULL-проверки и множество особых случаев, не задумываясь о том, нужны ли они. Это приводит к более сложному коду, который трудно понять и отладить.

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

Выводы

Если вы дочитали статью до этого места, вы, возможно, заметили, что значительная доля всех ошибок, допущенных кандидатами, имеет мало общего с техническими навыками. Фактически, не технические ошибки (№ 1, № 3, № 6) составляют 44% всех ошибок.

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

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

Именно этим мы занимаемся в Pramp. Мы бесплатно предоставляем комплексную площадку для проведения собеседований. Она уже помогла тысячам программистов избежать ошибок на собеседованиях. Готовы ли вы к собеседованию?

Методология

Чтобы идентифицировать ошибки и рассчитать их частоту, мы рассмотрели данные о последних 20 000 интервью с программистами, проведенных на Pramp.

Сначала о самой платформе. Pramp — бесплатная «точка-точка» площадка для тренировки и самопроверки программистов. Проще говоря, мы проверяем разработчиков программного обеспечения с помощью видеочата и совместно используемой среды программирования, чтобы имитировать проведение собеседований по программированию.

Каждый такой сеанс интервью является двунаправленным. Это означает, что оба эксперта беседуют друг с другом в одной сессии. Каждый из них выбирается случайным образом, быть ли интервьюером или кандидатом, а затем через 30-45 минут они меняют свои роли – интервьюер становится кандидатом, а кандидат становится интервьюером.

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

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

Мы проанализировали ответы в более чем 20 000 интервью на вопрос «Что было не так хорошо».

Первым шагом в нашем анализе было выяснение повторяющийся «категории ошибок» в ответах пользователей на вопрос «Что было не так хорошо?» В форме обратной связи. С этой целью мы выбрали случайные 1 068 интервью из 20 000 интервью. При таком размере выборки результаты статистически значимы (уровень достоверности 95% и допустимая погрешность менее 3%). Затем мы перечислили вручную эти 1 068 ответов.

Мы определили девять категорий. Восемь из них ‑ упомянуты в статье. 9-я категория была «Другая». Эта категория включала отзывы, которые либо не говорили ничего значимого (например: «Вы отлично поработали, мне нечего добавить», «Ничего не могу придумать» и т.д.), или что указывает на проблему, частота которой не была статистически значимой (например, ~ 1% всех обратных связей относились к скорости кодирования сверстников). При расчете распространенности ошибок мы исключили все отзывы, которые попали под категорию «Другие».

Предполагая, что интервью на Pramp является хорошей моделью реальных технических интервью (а у нас нет оснований полагать противное), размер выборки в 1 068 интервью также является репрезентативным и для общего числа технических интервью, проводимых в «реальном мире».

Специально для сайта ITWORLD.UZ. Новость взята с сайта NOP::Nuances of programming