Чего я узнал из интервью по программированию

1658005220 chego ya uznal iz intervyu po programmirovaniyu

от Edaena Salinas

WHm6C3L4DrhWClxkE549mOd0beW8VmMEFQtQ
Интервью по программированию доски

В 2017 году я была на праздновании женщин в компьютерной сфере Грейс Хоппер. Это самое большое собрание такого рода, в прошлом году его посетили 17 000 женщин.

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

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

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

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

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

В последние годы мы наблюдаем разные форматы интервью:

  • Программирование в паре с инженером
  • Онлайн-викторина и онлайн-кодирование
  • Интервью на доске

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

Что я сделал не так

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

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

Здесь я совершил две ошибки:

Не уточняет информацию, которая имеет решающее значение для решения проблемы

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

Мышление без письма или общения

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

Придумать решение

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

Вот что сработало для меня:

  1. Мозговой штурм
  2. Кодирование
  3. Обработка ошибок
  4. Тестирование

1. Мозговой штурм

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

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

2. Кодирование и прохождение кода

Если вы не имеете решения сразу, всегда поможет указать очевидное наивное решение. Пока вы объясняете это, вы должны подумать, как это улучшить. Когда вы утверждаете очевидное, укажите, почему это не самое лучшее решение. Для этого полезно ознакомиться с нотацией большого O. Можно сначала просмотреть 2–3 решения. Интервьюер иногда направляет вас, говоря: «Можем ли мы улучшить?». Иногда это может означать, что они ищут более эффективное решение.

3. Обработка ошибок

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

4. Тестирование

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

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

Некоторые примеры:

  1. Производительность
  2. Случаи ошибок
  3. Положительные ожидаемые случаи

Для производительности подумайте об экстремальных количествах. К примеру, если проблема касается списков, вспомните, что у вас будет случай с большим списком и очень маленьким списком. Если речь идет о числах, вы проверите максимальное и меньшее число. Я рекомендую прочитать о тестировании программного обеспечения, чтобы получить больше идей. Моя любимая книга об этом «Как мы тестируем программное обеспечение в Microsoft».

Для случаев ошибки подумайте о том, что, как ожидается, не получится и перечислите их.

Для положительных ожидаемых случаев полезно подумать о пользовательских требованиях. Какие случаи решает это решение? Это положительные тестовые случаи.

«У вас есть ко мне вопросы?»

Почти всегда будет несколько минут, посвященных концу ты задавать вопрос. Рекомендую вам запишите вопросы, которые вы бы задали интервьюеру перед собеседованием. Не говорите: «У меня нет вопросов». Даже если вы считаете, что собеседование прошло не очень хорошо, или вы не слишком увлечены компанией, вы всегда можете что-нибудь спросить. Это может быть о том, что человек больше всего любит и ненавидит в своей работе. Либо это может быть что-то связанное с работой человека или технологиями и практиками, которые используются в компании. Не поощряйтесь что-нибудь спросить, даже если вам кажется, что вы сделали плохо.

Оформление на работу

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

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

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

Смена команд

После полутора лет работы в моей первой команде я решил, что пора исследовать что-то другое. Я нашел понравившуюся мне команду и прошел 4 раунда собеседований. Я не справился.

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

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

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

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

Это содержимое из эпизода «Интервью с программированием» на шоу «Женщины в технике»: Технические интервью с выдающимися женщинами в технике.

Добавить комментарий

Ваш адрес email не будет опубликован.