2014-02-21
Техническое интервью обычно становится вторым кругомада в цикле собеседований. После первой проверки уровня вашей адекватности, которую проводит, как правило, HR, вы перенаправляетесь на собеседование с руководителем отдела или CTO. Что вас ждёт на таком интервью и какие ошибки чаще всего совершают кандидаты?
Прежде чем открыть список ошибок, хочется сказать, что причиной абсолютно любого промаха является вот эта:
Вы упражнялись только на компьютере
На технических собеседованиях часто просят написать часть кода на бумаге или на доске. Так какой смысл практиковаться в написании только на компьютере, где все ошибки сразу выдаются компилятором? Попробуйте написать что-нибудь по старинке — ручкой на бумаге. И обязательно проверьте своё рукописное решение на компьютере.
Вы не готовились к вопросам не технического характера
В основном такие вопросы касаются проектов, над которыми вы работали, ситуаций, с которыми сталкивались, конфликтов, которые вы успешно разрешили. Вспомните все свои старые проекты и должности и постарайтесь выделить несколько ключевых историй.
Вы не репетировали
Если вы когда-нибудь готовились к выступлению на конференции, вы понимаете, что имеется в виду. Репетиция необходима. Попросите знакомых и друзей провести с вами тренировочное собеседование.
Вы судорожно заучиваете возможные варианты решений
Запоминать готовые решения и надеяться, что до них обязательно дойдёт очередь на собеседовании — не самая хорошая идея. Вместо этого попробуйте сами порешать задачки, посёрфите по Quizful, например.
Вы не рассуждаете вслух
Какой бы чёткой ни была линия ваших рассуждений, интервьюер мысли читать не умеет, и не знает, как трактовать ваше молчание: вы задумались или не знаете ответа на вопрос. Просто начните проговаривать ход своих мыслей вслух, и всем станет легче.
Вы слишком спешите
Для того, чтобы найти решение, нужно время. Не надо торопиться, будьте методичны и аккуратны, просмотрите ещё раз свой код и исправьте ошибки.
Вы пишете грязный код
Написать решение, в котором нет багов — ещё недостаточно. Хороший программист кое-что знает о дублируемом коде, кривых структурах данных, лишних пробелах и прочих нехороших вещах. Пишите код так, как будто он предназначается для создания реальной программы.
Вы не тестируете
Найдите время для того, чтобы убедиться в отсутствии багов. Да, это сложнее сделать, если вы пишете код на доске или на бумаге. Вот поэтому и нужно практиковаться.
Вы бездумно исправляете ошибки
Нашли баг — подумайте, как он здесь оказался, и только потом исправляйте. Не начинайте спешно играть с булеанами и циклами в надежде, что хоть какое-то действие поможет.
Вы слишком рано сдаётесь
Цель проблем, которые ставят перед вами на собеседовании — выяснить, как вы справляетесь со сложными задачами: будете искать выход, несмотря ни на что, или опустите руки. Вас хотят нанять, чтобы вы решали проблемы с помощью кода; вот и покажите, что вам нравится искать изящные решения.
Эти советы — выдержки из книги Gayle McDowell «Cracking the Coding Interview», пересказанные Питером Барреттом.
