Часть 1 - Введение
Предисловие
Предисловие к этому сообщению в блоге (и, надеюсь, серии сообщений в блоге), как я полагаю, поможет понять, почему эта информация - это то, чем, как мне кажется, следует поделиться. Эта серия предназначена для людей с небольшим опытом работы в области компьютерных наук, которые хотят изучить / отточить свои навыки проведения собеседований. Когда я начал свою карьеру в качестве разработчика программного обеспечения, мой отец сказал мне, что овладение процессом собеседования должно быть моим самым большим приоритетом с точки зрения моей карьеры. В то время я не понимал этого факта, но я ценю это после прохождения процесса. Хорошее прохождение собеседований позволит вам увидеть мир, попробовать что-то новое и, что, возможно, наиболее важно, узнать, действительно ли разработка программного обеспечения для вас. Все это невероятно важные вещи, которые должен открыть любой, особенно в начале карьеры. Таким образом, я надеюсь, что вы считаете эту серию блогов мини-учебным курсом, который дает вам шанс войти в индустрию программного обеспечения.
Процесс
Каждый процесс начинается с приложения. Однако приложения бывают разных форм. Лучший способ войти в дверь - это узнать кого-то, кто уже находится внутри. Запрос на направление - отличный способ гарантировать, что рекрутер изучит ваше резюме. Еще один отличный способ - посетить университетские ярмарки вакансий. Там вы найдете рекрутеров и инженеров, которые могут провести вас к техническим экранам, а также дать вам хорошие ответы о том, что такое работа в компании.
Все компании разные, но технические собеседования обычно проводятся по нескольким правилам. Как правило, существует несколько раундов, в которых более одного раунда сосредоточены на технических способностях, а еще один посвящен поиску поведенческого / культурного соответствия. Помните, что в этом процессе ваш рекрутер станет вашим другом, задавайте вопросы и убедитесь, что вы знаете, что делать дальше по мере продвижения вперед.
Поведенческая сторона
Поведенческие интервью проводятся в самом начале или в конце процесса. Также есть возможность поговорить об этих вопросах непосредственно перед / после технических частей. Как правило, они позволяют вам узнать компанию так же хорошо, как они хотят, чтобы вы познакомились с ней. Как правило, всем нравятся скромные, инициативные и в целом люди, жаждущие учиться. Воспринимайте это как шанс узнать немного больше о корпоративной культуре. Спросите, чем интервьюеры занимаются для развлечения, баланса работы и личной жизни, какими они видят себя через несколько лет. Эти ответы помогут вам понять, в каком месте работать. Я расскажу об этом подробнее в более конкретном сообщении в блоге позже, но, как правило, нет правильных / неправильных способов ответить на поведенческие вопросы.
Техническая сторона
Процесс собеседования, чтобы стать разработчиком программного обеспечения, во всех отношениях несовершенный. Я твердо верю, что вы можете быть отличным инженером и плохо проходить собеседования. Точно так же вы могли бы быть фантастическим интервьюером, но плохим инженером. Это связано с тем, что настоящая инженерия не происходит в течение одного часа в контролируемой среде. Это важный факт, который следует избегать, поскольку он должен сформировать ваше мнение о том, как вам следует подготовиться к технической стороне собеседования.
Если техническое собеседование проводится по телефону и запрашивается компьютер, ожидайте, что код будет в каком-нибудь программном обеспечении для совместного использования экрана. Иногда интервьюер просит код скомпилировать, а иногда нет. Для сравнения, личные интервью, как правило, проводятся с использованием досок, где синтаксис менее оценивается и проверяется общее общение / понимание проблемы.
Важно отметить, что именно здесь большинство людей не проходят собеседование. Это ПОЛНОСТЬЮ НОРМАЛЬНО. Есть много сбивающих с толку переменных, которые могут повлиять на производительность, которые находятся вне вашего контроля. Иногда возникает вопрос, на который вы просто не знаете ответа, иногда интервьюеру не нравится ваша кишка, иногда у вас просто плохой день. Это все, что могло (и произошло) случиться.
Чтобы начать техническую подготовку, лучше всего заняться проблемами глубокого погружения. Лучшие ресурсы для решения проблем - это онлайн-сайты (leetcode.com, hackerrank.com, careercup.com и т. Д.), Где есть множество вопросов, с которыми вы можете поиграть и протестировать. Создание учетной записи для обоих сайтов - отличный способ начать работу с этими проблемами.
Решение технических проблем
Именно здесь большая часть времени в этих статьях будет посвящена рассмотрению. В качестве примера я представлю следующую проблему. Вкратце говоря об этой единственной проблеме, я надеюсь познакомить вас с некоторыми основными моментами, которые следует отметить в технических интервью. Не беспокойтесь, если некоторые вещи пройдут через вашу голову, это строго введение в форматирование того, как я буду писать ответы на эти вопросы, а не настоящий первый урок.
Две суммы
В этой задаче мы рассмотрим, как найти два числа в массиве, которые суммируются с целевым значением.
Вопросы / предположения для уточнения
- Сколько возможных решений существует в массиве?
- Можно ли использовать номер дважды?
- Нам гарантировано решение
В этом случае мы будем следовать предположению, данному LeetCode, где «вы можете предположить, что каждый ввод будет иметь ровно одно решение, и вы не можете использовать тот же дважды. " Если они спросят, можно также поднять другие проблемы, такие как целочисленное переполнение, но в целом эти случаи не слишком заметны для интервьюеров.
Наивное решение
Нам нравится начинать с наивного решения, чтобы наши мозговые соки текли. Похоже, мы можем просто определить буферный массив и цикл, чтобы найти ваши ответы.
Так что же делает это наивным? Для каждой итерации внешнего цикла мы проверяем каждый элемент внутреннего цикла. Если бы мы изобразили время выполнения в зависимости от размера чисел, мы получили бы экспоненциальный график. Это представляет собой концепцию под названием Big (O), которая будет рассмотрена позже в этой серии. Если вам интересно, попробуйте запустить этот код в LeetCode, этот код будет лучше большинства других введенных решений.
Итак, как мы можем добиться большего?
Оптимальный / Введение в хеширование
Я начну это обсуждение, сказав, что не беспокойтесь, если нижеследующее не имеет смысла. Мы рассмотрим хеширование более подробно в следующих статьях, но здесь мы рассмотрим его как мощный способ ускорить наш код.
Хеширование - это метод доступа к элементу в линейное время. Хеширование - это обычно просто операция модуля, выполняемая с размером массива, но может усложняться в зависимости от того, какой из них хешируется.
Основная идея здесь в том, что, поскольку хеширование происходит почти мгновенно, мы можем избавиться от необходимости во втором цикле for.
Как?
Когда мы зацикливаем массив nums, каждый индекс содержит число. Разница между целью и числом в индексе - это еще одно число, которое мы ищем. Посмотрите этот пример:
Ввод: nums = [1,2,3], target = 3.
При индексе 0 число равно 1
Поскольку цель - 3, мы знаем, что любой индекс, где есть 2, решит эту проблему.
Поскольку мы можем хешировать 2, все, что нам нужно сделать, это проверить, существует ли число в нашей Hashtable на будущих итерациях цикла. Если это так, мы знаем, что у нас есть решение.
Давай проверим
Если мы попробуем запустить его, то обнаружим, что общее время выполнения также нам больше нравится.
Заключительные слова
Целью этого поста было познакомить с процессом технического собеседования и обсудить вводную проблему. Скорее всего, со временем мы будем уделять больше времени техническим вопросам, поскольку именно здесь будет проходить основная тяжесть собеседования. Если вы впервые отвечаете на подобные вопросы, не отчаивайтесь от ярлыков Easy / Medium / Hard. Как и в большинстве случаев в жизни, это субъективно. Просто выполните их, посмотрите, что пошло не так, и повторите их снова. Мы поговорим больше об эффективности / Big (O) в следующих нескольких публикациях. А пока продолжайте учиться!
