Перевод статьи Эдены Салинас.
В 2017 году я побывала на Grace Hopper Celebration of women in computing (GHC). Это самое большое собрание такого рода, в прошлом году его посетили 17 тысяч женщин.
Эта конференция включает огромную ярмарку карьерных возможностей, где компании проводят интервью с участницами конференции. Кому-то из них предлагают работу. Прогуливаясь в этой зоне, я заметила, что некоторые люди выглядели взволнованными и скованными. Я прислушалась к разговорам: говорили о том, как они не показали себя с лучшей стороны на собеседовании.
Я подошла к группе людей, чей разговор подслушала, и кое-что посоветовала им. Думаю, некоторые советы, данные мной, были элементарными, вроде “это нормально вначале придумать простое решение”. Но большая часть моих советов их удивила.
Мне бы хотелось помочь большему количеству людей. Поэтому я собрала список советов, сработавших для меня самой, и опубликовала подкаст с ними. Также они являются темой данного поста.
Я проходила много программистских интервью, как в ходе стажировок так и при приеме на полноценную работу. Кода я изучала информатику в колледже, там каждый осенний семестр проводилась ярмарка профессий, где имел место первый раунд интервью. Я провалилась на первом и последнем раунде. После каждого интервью я обдумывала, что следовало сделать лучше, и заново проигрывала ситуацию собеседования с друзьями, которые затем высказывали свое мнение.
Находим ли мы работу на портале вакансий, в сети, университетской системе рекрутинга – частью процесса будет техническое интервью.
За последние годы я видела появление различных форматов:
- парное программирование с инженером
- онлайн-тест и написание кода онлайн
- интервью с применением белой доски.
Я сконцентрируюсь на интервью с белой доской, потому что в этом у меня есть опыт. У меня было много собеседований. Некоторые прошли хорошо, другие – нет.
Что я делала неправильно
Для начала я хочу пройтись по тому, что я делала неверно на моих интервью. Это помогает увидеть проблему и определить, что нужно улучшить.
Когда интервьюер выдавал мне техническую проблему, я немедленно шла к белой доске и начинала пытаться решать ее. Не говоря ни слова.
Здесь я сделала две ошибки:
Не выяснила информацию, важную для решения проблемы
Например, работаем ли мы только с числами или и со строками тоже? Поддерживаем ли мы множественные типы данных? Если вы не задаете вопросов прежде чем начать работать над проблемой, у интервьюера может сложиться впечатление, что вы и работая над проектом в их компании тоже не будете задавать вопросов. Это важный навык для рабочего окружения. Вы больше не в школе. У вас нет расписанных и детализированных кем-то шагов. Вам придется самостоятельно их находить и определять.
Обдумывала проблему, не озвучивая и не записывая свои мысли
Частенько я стояла, обдумывая, и ничего не писала в это время. Когда я проигрывала ситуацию интервью с другом, он сказал, что знал, что я в процессе обдумывания, потому что мы работали вместе. Чужому человеку скорее покажется, что у меня просто нет зацепок, чем что я думаю. Важно не бросаться на решение сразу же. Отведите немного времени для поиска идей. Иногда интервьюер с радостью примет участие в таком мозговом штурме. В конце концов, именно так и происходит на рабочих собраниях.
Предложение решения
Будет лучше, если вы представите алгоритм своих действий прежде чем начнете писать код. Не начинайте писать в надежде, что вы решите проблему в процессе.
Вот план действий, который подошел мне:
- Мозговой штурм
- Написание кода
- Обработка ошибок
- Тестирование
1. Мозговой штурм
Мне это помогает изначально визуализировать проблему при помощи серии примеров. Если эта проблема касается деревьев, я бы начала с null case, одного узла, двух узлов, трех узлов. Это может помочь обобщить проблему.
На доске запишите список вещей, которые алгоритм должен выполнять. Таким образом вы можете найти баги и проблемы прежде чем начнете писать код. Следите за временем. Однажды я сделала ошибку, потратив слишком много времени на уточняющие вопросы и мозговой штурм и просто не оставив его для написания кода. Это плохо, потому что так ваш интервьюер не увидит, как вы пишете код. Также ему может показаться, что вы хотели избежать написания кода. Наручные или настенные часы могут помочь – поглядывайте на них время от времени. Бывает, интервьюер сам скажет «Я думаю, у нас уже достаточно информации, давайте начинать писать код».
2. Написание и разбор кода
Если у вас нет готового решения, может помочь приведение простого, очевидного решения. Объясняя его, обдумывайте, как его улучшить. Хотя ваше предложение очевидно, это не мешает ему быть лучшим вариантом. Здесь помогает знакомство с О-нотацией. Также нормально сначала отобрать 2-3 решения. Интервьюер иногда может направить вас, спросив, есть ли лучший способ. Это может означать, что они ищут более эффективное решение.
3. Обработка ошибок
Когда будете писать код, говорите, что оставляете комментарий для обработки ошибок. Однажды интервьюер сказал: «Это хорошо. Как вы поступите? Выберете исключение? Или возвращение определенного значения?». Это может послужить началом краткого обсуждения качества кода. Упомяните несколько случаев ошибок. Или, например, интервьюер может предложить ситуацию, когда параметры, получаемые вами, уже прошли проверку. Но все равно стоит поднять эту тему, чтобы показать свои знания ошибок.
4. Тестирование
Когда вы закончили писать код решения, используйте повторно примеры из мозгового штурма чтобы провести сквозной анализ кода и убедиться, что он работает. Например, вы можете предложить рассмотреть пример дерева с одним узлом, с двумя узлами.
По окончании интервьюер может спросить вас, как бы вы тестировали ваш код, каковы были бы тестовые случаи. Я рекомендую вам организовать ваши варианты тестов по категориям.
Например:
- Производительность.
- Ошибки.
- Позитивное тестирование.
Что касается производительности, думайте о предельных значениях. Например, если проблема касается списков, скажите, что вы бы предложили тестовый случай с большим и очень маленьким списком. Если касается чисел, вы бы тестировали максимальное и минимальное целое число. Я советую почитать о тестировании ПО, чтобы запастись идеями. Моя любимая книга по этой теме – How We Test Software at Microsoft.
Касательно ошибок подумайте, где могут быть сбои, и перечислите.
Позитивное тестирование помогает задуматься над ожиданиями пользователя. Для каких случаев понадобилось это решение? Это и есть кейсы для позитивного тестирования.
«Есть ли у вас вопросы ко мне?»
Почти всегда в конце собеседования отводится несколько минут на то, чтобы вы могли задать вопросы. Я советую еще перед интервью записать, что бы вы хотели спросить. Не говорите, что у вас нет вопросов. Даже если чувствуете, что интервью прошло не очень хорошо, или вы не слишком впечатлены компанией, всегда есть что спросить. Это может касаться того, что человек любит и чего терпеть не может на своей позиции. Или что-то, касающееся работы, технологий и практик, используемых в компании. Не стесняйтесь спрашивать, даже если думаете, что провалили интервью. (См. статью о вопросах, которые стоит задть на интервью).
Подача заявки по вакансии
Что касается поиска работы и подачи заявлений по вакансиям, мне говорили, что нужно подаваться только в те компании, в которых вы действительно хотели бы работать. Советуют выбирать компанию, которая вам нравится, или продукт, которым вам нравится пользоваться, и пробовать туда устроиться.
Не думаю, что это всегда верно. Так можно пропустить много хороших возможностей, особенно если вы ищете стажировку или свое первое рабочее место.
Вместо этого вы могли бы сосредоточиться на других целях. В чем бы вам хотелось приобрести опыт? Облачные вычисления, веб-разработка, искусственный интеллект? Когда общаетесь с представителями компаний на ярмарках вакансий, узнайте, есть ли у них открытые вакансии в данной области. Вы можете найти действительно хорошую позицию в компании или неприбыльной организации, которых не было в вашем списке.
Смена команд
Проработав полтора года в своей первой команде, я решила, что пришло время открыть для себя что-то новое. Я нашла команду по душе и прошла 4 раунда интервью. Прошли они не очень хорошо.
Я не готовилась, даже не тренировалась писать на белой доске. Моя логика была такая: раз я проработала в компании почти два года, зачем мне практиковаться? Тут я ошиблась. Я попыталась записать свое решение на белой доске. Провалу способствовали мелкий почерк, начало не с верхнего левого угла и как следствие – нехватка места.
Я не повторила структуры данных и алгоритмы. Если бы я это сделала, то была бы более уверенной. Даже если вы работаете в компании на позиции инженера программ, перед собеседованием в другой команде я настоятельно советую вам попрактиковаться в использовании белой доски.
Что касается поиска команды, если вы хотите сменить ее в рамках своей компании, полезно будет неформально пообщаться с членами этой команды. Как я обнаружила, практически никто не откажется пообедать с вами. Люди также бывают свободны в полдень, в это время низка вероятность недоступности и пересечения с другими встречами. Это неформальный способ узнать, над чем работает команда, и что это за люди. В ходе встречи за обедом вы можете узнать много такого, что поможет вам на официальных интервью.
В конечном итоге, нужно осознавать, что вы проходите интервью для вхождения в конкретную команду. Даже если вы хорошо справитесь, вам могут не сделать предложения потому что вы не соответствуете их культуре. Частично именно поэтому я стараюсь сначала познакомиться с разными людьми из этой команды, но это не всегда возможно. Пусть отказ вас не расстраивает, продолжайте перебирать варианты и практикуйтесь.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]