Компания Geekfactor cовместно с Getmentor.dev проводит программу подготовки к трудоустройству в зарубежные стартапы (бесплатно помогаем подготовиться к интервью и показываем резюме классным компаниям) — почитать о ней подробней и зарегистрироваться можно тут. Свой блог на Хабре мы хотим посвятить теме трудоустройства зарубеж и наша первая статья — про то, каких ошибок стоит избегать при прохождении технических интервью в зарубежные компании.
Недавно я провел свое 600-е собеседование на платформе interviewing.io (IIO). В этой статье я хочу рассказать о своем опыте, подходе к проведению собеседований и основных проблемах, которые встречались у кандидатов на технических собеседованиях.
Во время собеседований на платформе IIO мы оцениваем участников по трём критериям и ставим им от 1 до 4 баллов. 1 балл означает, что у кандидата все очень плохо в этой области, а 4 — все отлично. Обычно в начале собеседования я даю кандидатам 3 или 4 балла, и по мере продвижения встречи участники получают/теряют очки.
У каждого интервьюера, работающего на платформе, есть аспекты, на которые он обращает больше внимания. Я, например, больше всего ценю навыки общения и решения проблем, о чём и расскажу ниже.
Владение техническими навыками
В этой категории я оцениваю, насколько хорошо кандидаты умеют программировать на выбранном языке, есть ли у них серьезные трудности в составлении различных алгоритмов, нужно ли мне часто давать подсказки при написании кода.
Решение проблем
Здесь я оцениваю, насколько хорошо кандидат умеет разбивать задачу на составные части, вырабатывать стратегию по решению этих небольших задач и исправлять проблемы во время написания кода. Способность анализировать проблемы и решать их важна так же, как и навыки программирования. Может ли проблема поставить кандидатов в тупик, или же они могут самостоятельно найти её решение?
Общение
В действительности интервьюеры хотят услышать, как вы принимаете решение. Это очень важно при исправлении кода. Я обычно нанимаю специалистов для небольших команд или групп разработчиков. Поэтому для меня важно увидеть, что претендент умеет работать в команде и общаться.
Распространенные проблемы соискателей на основе моего опыта в качестве интервьюера
Я составил список основных проблем, которые встречаются у кандидатов во время технических собеседований не только на платформе IIO, но и в индустрии в целом. Надеюсь, вам пригодится.
Распространенная проблема № 1: поспешный переход к написанию кода
Эта проблема встречается у разработчиков разного уровня и различных специализаций, но все же чаще всего у специалистов «среднего» уровня с опытом работы 2–5 лет. Они выслушивают задачу, в течение примерно 30 секунд рассказывают о высокоуровневой структуре кода, а затем приступают к его написанию. Как будто речь идет о гонке на время и надо как можно быстрее завершить задачу — как можно быстрее добраться до финиша. Кто первый написал код, тот и победил.
Всё же правильно? Нет.
Сбавьте темп. Спланируйте, что вы будете делать. Расскажите о том, как вы решите поставленную задачу.
Люди, которые продумывают структуру кода на среднем уровне — с помощью псевдокода или просто заметок — затем тратят меньше времени на исправление ошибок. А вот те, кто сразу начинают программировать, сталкиваются с проблемой проектирования кода «на ходу». Они тратят много времени на рефакторинг, потому что им, например, нужно изменить передачу параметров или возвращаемое значение, или «ой, что здесь делает этот цикл?». Интервьюер быстро подмечает такие проблемы.
Конечно, тот факт, что вы потратите время на среднеуровневое проектирование кода не гарантирует успеха, но в долгосрочной перспективе может сэкономить время. Затем это время можно потратить на исправление ошибок.
К тому же я с позиции интервьюера хочу увидеть, как вы справитесь с задачей. Особенно если у вас собеседование в компании (в офисе или, как все чаще бывает в настоящее время, в дистанционном формате), потому что проведение собеседования в компании — процесс дорогостоящий. Мне нужно помогать всем кандидатам в равной степени. Если я вижу, что у вас есть предварительная структура, и замечу в ней ошибку, я могу задать наводящие вопросы, чтобы помочь вам понять, в чём проблема и подправить код на ранней стадии.
Если вы сразу начинаете программировать, я совершенно не понимаю, будет ли ваш код работать, а это ставит интервьюера не в самую лучшую позицию. Мне гораздо сложнее помочь, когда вы уже написали 100 строк на Java, и я только тогда понял, что в действительности делает ваш код.На одном из интервью в 2012 году я стал свидетелем того, как такое недостаточное планирование серьезно подвело претендента. Рекрутер привел ко мне кандидата, спросил не принести ли тому воды и вышел из кабинета. Я поздоровался, представился, и мы приступили к выполнению технического задания. Кандидат не поделился подробностями, не продумал структуру, сказал пару слов о высокоуровневом дизайне кода, ничего не записал и принялся сразу писать код на доске. (Это было мое второе и последнее собеседование с использованием доски. Ненавижу доски!) Рекрутер пришел через несколько минут, громко постучав в дверь, вошел в кабинет, передал бутылку воды и ушел. Кандидат поблагодарил за воду, открыл бутылку и начал пить. Затем его лицо исказилось — я увидел его испуганный взгляд. Он отвлекся, и у него совершенно вылетело из головы, что он хотел написать дальше, а я не мог ему помочь, потому что не знал, в чём состоит его идея. Кандидат потерял несколько минут, вновь обдумывая задачу, и начал писать код заново.
Но есть и «обратная сторона» медали: можно потратить слишком много времени на проектирование структуры кода и не успеть воплотить свой гениальный план в жизнь. Мне встречались и такие ситуации, когда кандидаты рассказывали о среднеуровневой структуре, делали заметки, вручную анализировали пример с помощью этих заметок, чтобы убедиться, что алгоритм работает, и у них оставалось всего несколько минут на выполнение задачи. Возможно, такие претенденты получат дополнительные очки за общение, но нам важно увидеть и то, как человек пишет код.
Какая же стратегия наиболее оптимальная?
Я рекомендую практиковаться. У вас должно уходить примерно 5 минут на продумывание высокоуровневого дизайна, еще 5 минут на планирование среднеуровневой структуры и оставшееся время — на написание кода. Есть и хорошая новость: чем больше вы прокачиваете навыки разработки дизайна и решения проблем, тем лучше вы справляетесь с подобными задачами. Поговорим об этом подробнее ниже.
Распространенная проблема № 2: «полумысли»
Мой многолетний опыт показывает, что это наиболее точный термин. Он означает, что вы начинаете что-то говорить вслух, а потом заканчиваете предложение про себя и меняете что-то в своем коде. Обычно это звучит так: «Возможно, я мог бы… а нет, лучше вот так».
Возвращаемся к моей придирчивости в плане навыков общения.
Интервьюеры хотят узнать, о чём вы думаете. Им важно понимать, как вы принимаете решения. Насколько правильны или неправильны ваши идеи? Почему вы хотите сделать что-то именно так? Возможно, вы заметили ошибку в коде? В чём она состоит?
Эта недостающая информация — настоящая кладезь для интервьюера. Нужно всего лишь несколько секунд, чтобы сказать что-то вроде: «Мне кажется… я думаю, что здесь можно применить поиск в глубину, но учитывая ___, я думаю, что лучше было бы ___. Как вы считаете?».
Конечно, это отнимет у вас две–три секунды, но вы поинтересуетесь моим мнением и получите поддержку. Мы сможем вместе рассмотреть какие-то варианты — и вот это называется командной работой. Я увижу, что мы сработаемся.
Распространенная проблема № 3: не задавать уточняющие вопросы
Я часто в качестве разминки задаю задачку. Например:
«У вас есть совокупность целых чисел. Напишите алгоритм, который находит два числа. В сумме они должны дать заданное значение. Когда алгоритм находит пару чисел, он перестает считать и показывает найденные значения. Если такие числа не найдены, возвратите два “пустых” значения».
Это отличный способ посмотреть, как вы работаете с алгоритмами и умеете строить предположения при решении задачи.
Я занимаюсь разработкой кода довольно долго. Если быть точным, с 1982 года. Ни в одном языке, на котором я когда-либо работал, не существует структуры данных, которая бы называлась «совокупность». Что же можно сказать о поставленной задаче?
Большинство кандидатов тут же ответят, что «совокупность» чисел — это массив. Конечно, можно решить эту задачу с помощью массива для хранения числовых значений. В этом случае трудоемкость алгоритма будет O(n^2), потому что вы будете перебирать данные экспоненциально: для каждого элемента нужно проверять оставшиеся числа. Но есть и более оптимальный способ решить поставленную задачу за O(n) время, выбрав иную структуру данных.
Не бойтесь и спросите, как лучше поступить. Если интервьюер ответит, что вам нужно решить самому, — это одно. В таком случае спросите, правильны ли ваши предположения. Спросите, есть ли альтернативный набор данных, который вы можете использовать в качестве тестовых случаев и которые могут повлиять на алгоритм.
Распространенная проблема № 4: предполагать, что интервьюеры устанавливают все правила
Подождите, что? Вы всё верно прочитали.
Да, вы находитесь на собеседовании. Но вы пришли, чтобы показать, что умеете работать в команде, а это прежде всего подразумевает открытое общение и дух сотрудничества. В первые несколько минут собеседования постарайтесь рассказать о своих ожиданиях, в том числе в плане общения и процесса работы.
Нет ничего плохого в том, чтобы обсудить эти вопросы с интервьюером:
«Во время работы над такими технически сложными заданиями я обычно одну–две минуты спокойно обдумываю проблему и делаю заметки. Чуть позже я буду готов(-а) поделиться с вами своими мыслями, чтобы узнать, чтобы вы думаете. Когда я пишу код, я также предпочитаю работать не спеша. Иногда я буду останавливаться, чтобы пояснить, что делаю. Затем мы сможем более подробно просмотреть код перед тем, как я запущу его. Вам это подходит? Совпадает ли ваше видение процесса работы над кодом с моим? Как вы предпочитаете общаться или взаимодействовать во время выполнения задания?».
Обещаю, вы станете звездой в глазах интервьюера. Большинство и вовсе не будут готовы к тому, что вы спросите у них, чего они ожидают. Это покажет, что вы умеете работать в команде. Вы сами задаёте условия: показываете себя с наилучшей стороны и одновременно демонстрируете, что учитываете мнение других. Вы сразу же говорите о своих планах и даете интервьюерам возможность для взаимодействия в процессе собеседования.
Распространенная проблема № 5: не просить о помощи
В качестве вашего интервьюера я могу лишь немного помочь вам во время выполнения задания. Естественно, я не могу просто сказать, что делать. Но я могу подсказать вам, вычесть один пункт из категории и посмотреть, справитесь ли вы в итоге с задачей. Если же молчаливо страдать и стоять на месте, тогда мы оба будем чувствовать, что это потеря времени.
Как профессиональный интервьюер и преподаватель в школе программирования, я отлично умею задавать наводящие вопросы, чтобы направить вас или ответить, но при этом не дать все решение.
Нет ничего плохого в том, чтобы признать, что у вас возникли трудности. Это не делает вас неудачником, а говорит лишь о том, что вы человек. Расскажите интервьюеру, что вы думаете и с какими проблемами вы столкнулись. Внимательно выслушайте ответ — возможно, вам дадут подсказку или посоветуют, что делать дальше.
Мои любимые полезные ресурсы
После собеседования на IIO мне нравится давать обратную связь и рекомендации о том, над чем стоит поработать. Обычно это занимает 10–20 минут, но иногда превышает час, отведённый на собеседование. Я использую это время, чтобы ответить на вопросы и более подробно обсудить разные аспекты. Я ОБОЖАЮ помогать людям на IIO. И вот что я могу порекомендовать.
Общение
Как же ужасно слушать свой голос в записи! Тем не менее, все собеседования на IIO записываются, и я часто советую кандидатам просмотреть последние несколько минут разговора, чтобы проанализировать обратную связь. Запись всегда можно остановить и вернуться к коду. (Записи, естественно, конфиденциальны и доступны только вам и интервьюеру).
Во время просмотра обратите внимание на то, что вы говорили и как. Во время работы над другими задачами найдите возможность записать себя, проговорите вслух проблему и затем снова прослушайте. Так вы научитесь более четко и ясно формулировать полноценные мысли.
Решение проблем и разработка кода на среднем уровне
Чтобы попрактиковаться в написании алгоритмов, чаще всего используют сайты HackerRank, CodeWars, LeetCode и т. д. (скоро в нашем блоге выйдет подборка таких сайтов — прим. переводчика). Только они не дают возможности научиться проектировать структуру кода.
Своим студентам я рекомендую Project Euler («Проект Эйлера»). Эйлер был математиком, поэтому на сайте представлены в основном математические задачи. Но вы можете изменить условия, чтобы вам было привычнее. Например, если вы не умеете находить простые числа, ничего страшного. Просто попробуйте найти число, которое делится на 17 без остатка, или что-то в этом роде.
Мне нравится Project Euler, потому что задачи описаны с помощью слов. Вам нужно продумать все: алгоритм, какую структуру данных использовать, особенно если вы разбиваете задачу на части.
Одна из моих любимых задач — задача № 19 из архива. В ней необходимо посчитать, сколько месяцев с января 1901 года по декабрь 1999 года начиналось в воскресенье. Вам дано количество календарных дней в каждом месяце, указано, что 1 января 1900 года выпало на понедельник, и показано, как вычислять високосные годы. Дальше дело за вами.
Чем больше вы решаете разные задачи, тем лучше вы распознаете паттерны — практика, практика и еще раз практика
Ещё один совет, который я даю студентам: решать каждое задание несколько раз. Наш исполнительный директор, Джефф Казимир, говорит, что нужно решать каждую задачу по десять раз. Но это много. Я бы сказал, что достаточно три–четыре раза, и вот почему.
В первый раз вы решаете задачу. Возможно, у вас возникнут трудности, но главное — решить задачу до конца. Во второй раз вы, возможно, придумаете новое решение, более оптимальное. Может быть и нет, но, по крайней мере, вы потренируетесь решать такого рода задачи. Теперь снова все стираете и решаете третий раз. Затем четвертый. Так вы запоминаете стратегию, с помощью которой необходимо выполнять подобные задания. «Мышечная память» поможет вам при решении других задач, когда вы начнете видеть схожие элементы: «Это же похоже на задачу о рюкзаке». Поскольку вы уже решали нечто подобное несколько раз, вам потребуется гораздо меньше времени на высокоуровневую и среднеуровневую разработку.
Одно из моих любимых заданий можно решить с помощью разных алгоритмов (поиск в глубину, поиск в ширину, динамическое программирование и т. д.). Если вы думаете, что можете решить задачу аналогичным образом, тогда решите ее три или четыре раза, используя каждый раз один из предложенных алгоритмов. Тогда вы НАУЧИТЕСЬ подмечать общие черты, и у вас будет широкий арсенал стратегий для решения заданий для технических собеседований.
Напоминаем, что компания Geekfactor помогает в трудоустройстве в крутые зарубежные стартапы на удалёнке и с релокацией. 2-го ноября стартует наша первая программа подготовки, организованная совместно с Getmentor.dev. Читайте подробности и регистрируйтесь (бесплатно и без смс).
Перевод подготовлен компанией Itrex.
Читайте также:
