Ошибки программистов на собеседовании

1. Проблемное резюме 

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

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

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

❌ Не откликайтесь, если не проходите по основным требованиям. Когда я ищу разработчика со знанием английского, то это нужно для какой-то задачи — например, для коммуникации с командой из США. Поэтому я не буду рассматривать кандидатов без опыта, а тех, кто заявляет про опыт, — постараюсь проверить самостоятельно. Если не получится — английский проверит интервьюер на собеседовании или наставник в период испытательного срока.  

✅ Идеальное резюме — это когда у кандидата есть релевантный опыт по всем пунктам вакансии. Хуже — когда опыт заменяется крепкой теорией. На грани — если кандидат не соответствует дополнительным требованиям и это не критично для работы. Например, если в вакансии написано «плюсом будет английский» — это дополнительное требование, которое подтягивается после трудоустройства. 

2. Действия без карьерного плана 

Карьерный план — это ответ на три вопроса: почему вы занялись программированием, где находитесь сейчас и к чему стремитесь через 5–10 лет. Эти ответы помогают устроиться в подходящую компанию и определить момент, когда стоит задуматься о повышении или найти новое место работы. 

❌ Не идите на собеседование, если вам интересна только зарплата. Компаниям невыгодно тратить время на одноразовых сотрудников, которые при первой возможности уйдут за более выгодным предложением — таких людей я стараюсь отсеивать на этапе телефонного разговора или скайп-интервью. 

⚠️ Триггером для меня выступает примерно такой контекст: «здесь платят Х, а я хочу 2Х и офис с бесплатным питанием. Найдёте — возвращайтесь, посмотрю вашу вакансию».  

❌ Не составляйте карьерный план «на бумаге» — только для того, чтобы понравиться на собеседовании. Типичная ситуация: кандидат рассказывает о своих амбициях → обещает за короткое время дорасти до тимлида → узнаёт, что у компании нет возможности для подобного роста → забывает о карьерном плане и готов на любую должность. 

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

✅ Подготовьте карьерный план и подумайте, как выбранная компания поможет его реализовать. Это может быть практический опыт, интересный продукт, возможность поработать в разных направлениях разработки или стать частью успешной команды под руководством крутого наставника — подойдёт что угодно, что вызывает интерес помимо зарплаты. О зарплате мы поговорим отдельно. 

3. Беда с зарплатными ожиданиями 

При трудоустройстве на зарплату влияет среднерыночная цена и бюджет, который работодатель выделяет на нового сотрудника — это связанные факторы, и поэтому одна вакансия в разных компаниях оплачивается с разницей плюс-минус 30%. Например, если средняя зарплата начинающего андроид-разработчика 60 000 ₽, то в разных компаниях эта должность оплачивается в пределах 40 000—80 000 ₽. 

❌ Не противопоставляйте высокую зарплату комфортным условиям работы. Допустим, компания предлагает начинающему андроид-разработчику 120 000 ₽ — выше максимума среднерыночной вилки. Эта зарплата предполагает 14-часовой график, 6-дневную рабочую неделю и штрафы за любое нарушение дисциплины — разработчик соглашается, терпит пару месяцев и планирует побег в компанию с лучшими условиями. С этого момента начинаются проблемные собеседования.

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

Если кандидат жалуется на работодателя или тяжёлые условия работы — для рекрутера это повод отказать по софт-скилам. В переводе — «Ты, может быть, хороший специалист, но нам нужны не только хорошие спецы, но и нормальные люди». 

Жалоба на задачи — провал по хард-скилам: «Ты, похоже, не такой хороший специалист, как ты о себе пишешь»

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

⚠️ Если разработчик не уволился и в рабочие дни тайно посещает собеседования — ко всему перечисленному добавляется этическая сторона. Кому нужен сотрудник, который обманывает и не уважает работодателя? Штраф и негативный отзыв работодателя не считаем — это бонус ко всему. Увольнение за спиной — это отдельная ошибка, и её разберём позже. 

❌ Не ходите на собеседования с расчётом «сколько предложат, на столько и соглашусь». Возьмём другого андроид-разработчика и устроим его в компанию за 20 000 ₽ — ниже минимума среднерыночной вилки. С таким окладом он быстро задумается о переходе и столкнётся примерно с теми же проблемами, что и его коллега за 120 000 ₽. Разница в том, что некоторые работодатели с пониманием отнесутся к ситуации, а другие, наоборот, не поймут, почему человек пришёл за опытом и вместо этого шастает по собеседованиям, выбивая новую зарплату. 

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

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

4. Неуважительное отношение к людям

Где-то в массовой культуре есть образ гениального программиста, которому всё сходит с рук благодаря его гениальности. Такой Доктор Хаус от мира разработки. Но в реальности никто не хочет работать с высокомерными гениями. Такие люди редко проходят собеседование, а если попадают в компанию — не задерживаются в коллективе. 

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

✅ Исходите из того, что с вами говорит не профан. Если с вами общается рекрутер, не стоит думать, что он ничего не понимает в технологиях. Большинство ИТ-рекрутеров подкованы в теории, умеют читать код на нескольких языках и знают основные принципы программирования. Если кандидат переходит на технический язык и начинает говорить бред — я это понимаю и не допускаю к дальнейшим этапам отбора. 

✅ Рекрутеры ценят вежливых и квалифицированных специалистов. Например, в рекрутинге принято осторожно относиться к кандидатам, которые ищут работу после криптовалютных проектов или онлайн-казино. Считается, что такие люди занимаются программированием только ради денег и их невыгодно нанимать. Если мне попадется такой кандидат с хорошим резюме и при этом он нормально ведёт себя на собеседовании — я разберусь в ситуации и приглашу на собеседование. Если у работодателя возникнут вопросы — попрошу не отклонять кандидатуру и сместить акцент с прошлого места работы на знание технологий. 

Но если я вижу, что человек относится к окружающим как к прислуге, его шансы невелики. 

5. Отсутствие портфолио 

Между равными кандидатами чаще выбирают того, у кого есть портфолио. Если два кандидата с портфолио — оценивают выполненные проекты. Если у двух кандидатов с портфолио одинаковое количество релевантных проектов — смотрят на того, у кого всё аккуратно оформлено, подписано и структурировано. 

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

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

✅ Старайтесь делать так, чтобы ваши портфолио запомнились. Слышала у коллег такую ситуацию: разработчик проходил собеседование на тимлида, опаздывал на встречу и всех заранее предупредил. Когда приехал — извинился и подарил девушке-интервьюеру любимые цветы. Как он о них узнал и где купил в пробке — загадка. Получился кейс, как тимлид выходит из неудобной ситуации. 

Другой случай: начинающий веб-разработчик сделал серию интересных калькуляторов в стиле «Сколько тебе осталось жить» или «Сколько чашек кофе выпито за последний год». Технически это несложно реализовать, но красивая графика и интересные темы сделали своё дело — знакомого рекрутера это затянуло, он запомнил кандидата и первым позвал его на собеседование. 

6. Нечёткие ответы 

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

❌ Не уходите в дебри и не избегайте конкретики. Спрашивают про хеш-таблицы — объясните, что это такое и где можно применить. Если есть проект в портфолио — расскажите о нём. Этого достаточно, чтобы проверить ваши знания темы — если нужно, интервьюер обязательно задаст дополнительные вопросы. Главное — не переключайтесь с таблиц на историю программирования и высокие материи искусственного интеллекта: так вы скажете много, но ни о чём. 

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

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

7. Поиск работы за спиной работодателя 

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

Из-за этого сложно сделать так, чтобы числиться в одной компании и тайно ходить по собеседованиям. Очень высока вероятность того, что об этом узнает работодатель. Чтобы избежать проблем, нужно делать всё открыто или сначала уволиться. 

❌ Не ходите по собеседованиям, если вам это запретили. Я знаю компании с таким негласным правилом: открыл на hh.ru резюме — подавай заявление об увольнении. 

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

❌ Никогда не шантажируйте компанию увольнением. У знакомого ИТ-рекрутера была такая ситуация: разработчик тайно прошёл собеседование и должен был за месяц перейти на новое место работы. Об этом узнал руководитель и предложил компромисс: доработать полгода до конца проекта и спокойно уйти. Разработчик согласился, передоговорился на новом месте работы и в середине срока пошёл на шантаж — он запросил двойную зарплату, поскольку писал основной код. 

Руководитель согласился, всё выплатил и рассчитал разработчика. Об этом много кто узнал, и разработчик отправился на фриланс — ему закрыли двери на все собеседования. Компаниям теперь будет очень трудно согласиться платить существенные деньги человеку, склонному к подобным подставам и подлости. 

✅ Хотите найти новую работу — сделайте это по-человечески. Здесь хочу поделиться двумя похожими примерами с разным успешным результатом. 

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

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

Бывают исключения, но на них лучше не надеяться 

Есть две ситуации, в которых ошибки не влияют на результат трудоустройства: 

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

Что дальше 

Если хотите следить за вакансиями и хитростями рекрутеров — посетите телеграм-канал IT Recruiter Profi.

Нужна консультация — обращайтесь к Язиле Насибуллиной. 

Думаете над резюме — посмотрите инструкцию от разработчика из Яндекс.Практикума. 

Хотите больше рекомендаций — почитайте теорию о собеседованиях в ИТ-компании.

Время на прочтение
3 мин

Количество просмотров 45K

Перевод поста пользователя Reddit

За последний год я провёл более 50 телефонных собеседований, и наблюдал, как люди делали одни и те же ошибки снова и снова. В интернете можно найти много советов по поводу навыков, полезных для прохождения интервью, но я не видел текстов, где бы описывались стратегии, помогающие людям преуспеть. Я думаю, что у большей части наших кандидатов, дошедших до интервью, есть необходимые навыки, однако они просто нервничают и не применяют эти навыки эффективно. Чтобы был ясен контекст, наша фирма – это стартап на 100 человек, а до второго раунда интервью доходят порядка 50% людей.

1) Предполагают, что существует какое-то очень удачное решение

Когда вы нанимаете человека на позицию универсала в компанию, занимающуюся разработкой ПО, маловероятно, что на собеседовании по телефону от вас потребуют знания фильтра Блума (хота это прикольная штука) и методов его применения. Однако же кандидаты постоянно вычёркивают удовлетворительные, не идеально оптимизированные решения, и начинают искать что-то из ряда вон. Как и в программировании, тут надо оставить сложные и специализированные структуры данных для ситуаций, где их применение не вызывает сомнений. Есть причина, по которой мы уже более 70 лет используем массивы (и сортировку слиянием).

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

2) Игнорируют советы и подсказки интервьюера

Эта ошибка может проявляться по-разному. Вопиющий вариант – когда интервьюер делает весьма прозрачный намёк, типа «что, если мы возьмём стек вместо дерева?», а этот намёк игнорируется или отвергается. Я, как интервьюер, пытаюсь вам помочь! В данном случае не существует ситуаций, в которых бы вас пытались обмануть. Когда интервьюер делает явное предложение, он пытается либо навести вас на правильный путь, либо заставить вас доказать, что ваше текущее решение оптимальное (а в этом случае вы, наверное, уже знаете, что ваше решение хорошее). Вне зависимости от того, что он делает, игнорирование подсказок ни к чему хорошему не приводит.

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

Как исправить: внимательно рассматривайте то, что даёт вам интервьюер.

3) Запихивают квадратный колышек в круглое отверстие

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

Как исправить: не бойтесь выбрасывать текущее решение и выбирать новое.

4) Слишком быстро зарываются в детали

Эта ошибка не топит кандидатов прямо сразу, но причиняет им неприятности двумя способами. Во-первых, описав решение очень детально, они привязываются к нему и не желают от него отказываться, что приводит к проблеме (3). Что хуже, у интервьюера уходит больше времени на то, чтобы понять, что решение неверно. Интервьюеры обычно уводят вас от неверных решений, и ведут в сторону правильных, поэтому, чем быстрее они поймут ваше решение, тем быстрее они направят вас, куда надо. Поскольку интервью ограничены по времени, лучше дать неправильное решение за 30 секунд, чем за 5 минут. А если решение правильное, или близкое к этому, интервьюер всегда сможет запросить у вас детали.

Как исправить: быстро выдавайте правильный или неправильный ответ и двигайтесь оттуда.

5) Не заполняют тишину

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

Как исправить: сообщайте о ваших мыслях, но не бойтесь привести их в порядок перед этим.

Канал Nuances of programming представил перевод статьи The Pramp Team: Technical Interviews: the 8 Most Common Mistakes Programmers Make.

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

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

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

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

(Пикель Рик)

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

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

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

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

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

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

#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. Мы бесплатно предоставляем комплексную площадку для проведения собеседований. Она уже помогла тысячам программистов избежать ошибок на собеседованиях. Готовы ли вы к собеседованию?

Вот пример практической сессии собеседования по Pramp.

 Методология

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

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

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

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

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

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

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

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

Автор этих советов, Гейл Лакман Макдауэлл — основатель и CEO CareerCup, автор известных книг по подготовке к собеседованиям. Гейл работала программистом в Microsoft, Apple и Google. У неё есть степени бакалавра и магистра University of Pennsylvania, а также MBA Wharton School. В настоящее время проживает в Пало-Альто, Калифорния.

1. Использование компьютера

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

2. Игнорирование поведенческих вопросов

Многие кандидаты тратят всё свое время на подготовку к техническим вопросам и упускают поведенческие. Но ваш интервьюер, скорее всего, их не упустит! Более того, ответы на поведенческие вопросы могут изменить восприятие интервьюером ваших профессиональных данных. К ответам на поведенческие вопросы легко подготовиться. Вспомните все свои проекты и используйте их для подготовки.

3. Отказ от псевдоинтервью

Представьте, что вы готовитесь к публичному выступлению перед своей группой, компанией или какой-нибудь другой большой аудиторией. Ваше будущее зависит от этого. Только сумасшедшие или излишне самоуверенные люди будут готовить такую речь в одиночку. Один из способов подготовки — так называемое псевдоинтервью. Если вы инженер, то должны быть знакомы с коллегами. Попросите приятеля провести для вас «собеседование». Этот метод принесет только пользу!

4. Попытка зазубрить ответ

Запоминание решения конкретной задачи пригодится вам только в том случае, если интервьюер даст именно эту задачу, но никак не поможет решить новые задачи. Очень маловероятно, что в Интернете или какой-либо книге вы найдете все или хотя бы большую часть вопросов, которые могут достаться вам на собеседовании. Намного эффективнее не привязываться к конкретике. Это поможет вам разработать стратегии решения новых задач. Лучше качество, нежели количество.

5. Решение задачи «в уме»

Откроем вам секрет — интервьюеры не телепаты и не знают, что происходит у вас в голове. Следовательно, если вы ничего не произносите вслух, не известно, о чем вы думаете. Если вы молчите, они считают, что у вас нет решения. Больше говорите и пытайтесь комментировать решение. Это покажет интервьюеру, что вы решаете поставленную задачу, а ваше молчание будет расценено как то, что вам нечего сказать. Дайте возможность интервьюеру подсказать вам путь решения или указать на ошибку, когда вы в этом будете нуждаться. Простейшие навыки коммуникации помогут получить желаемую вакансию. Что может быть лучше?

6. Спешка

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

7. Грязный код

Знаете ли вы, что код, даже написанный без ошибок, может быть просто ужасным? К сожалению, это так! Дублирование, огромные структуры данных (отказ от объектно-ориентированного программирования) и т.д. являются показателями плохой программы. Когда вы пишете код, представьте, что он должен быть ещё и хорошо поддерживемым. Разбейте код на подпрограммы и выберите оптимальную структуру, соответствующую данным.

8. Отказ от проверки

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

9. Небрежное отношение к исправлению ошибок

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

10. Отказ от решения

Очень часто вопросы оказываются достаточно сложными. Примете ли вы вызов или повернёте назад? Мы рекомендуем достойно встретить трудную задачу. Ведь собеседования для этого и проводятся. Не удивляйтесь, когда вам достанется действительно сложный вопрос.

Также рекомендуем по теме:

• 80 задач с IT-собеседований с разбором решений
• 28 cайтов с задачами по программированию

_{Советы взяты из перевода книги Г. Лакман Макдауэлл и предназначены исключительно для ознакомления.
Если они вам понравились, то рекомендуем купить книгу «Карьера программиста. Как устроиться на работу в Google, Microsoft или другую ведущую IT-компанию».}