Я испытал это на собственном опыте
Я пишу эту статью, потому что я никогда не хочу, чтобы кто-то тратил сотни часов на Leetcode и чтобы у них появилось ложное чувство уверенности в том, что они смогут пройти любое собеседование по кодированию. Затем, когда им отказывают во всех своих собеседованиях, потому что они не понимают технического процесса собеседования или оцениваемых критериев, они испытывают сокрушительное чувство раскаяния, думая: «Я потратил сотни часов и / или сотни долларов на Leetcode. " Я испытал это на собственном болезненном опыте.
Я думаю, что здорово практиковать свои навыки программирования для решения проблем с помощью Leetcode или даже AlgoExpert, особенно если вы не знакомы со структурами данных, такими как стеки, очереди, кучи, попытки и т. Д. В прошлом я покупал ежемесячные подписки для обоих, когда Я активно проходил собеседование на стажировку в колледже. Однако я думаю, что понимание того, чего интервьюеры ожидают от технического собеседования, имеет большую ценность. Даже если вам нужно найти наиболее оптимальное решение для данной проблемы, это еще не все, что мы ищем (что удивляет многих).
С точки зрения интервьюера, во время собеседования по кодированию мы оцениваем кандидатов по пяти различным направлениям. Некоторые особенности могут отличаться от компании к компании, но общие критерии остаются неизменными. Я буду использовать тривиальный вопрос по кодированию в качестве примера, но вы можете представить, что те же концепции применяются по мере того, как вопросы становятся все сложнее или сложнее.
1. Устранение двусмысленности
Предположим, я задал вам в интервью вопрос типа «учитывая набор чисел, верните наибольшее число». Вы сразу начинаете кодировать или тратите некоторое время (5, 10 или даже 15 минут) на то, чтобы заранее задать несколько вопросов и попытаться определить некоторые из крайних случаев? Со временем вы научитесь задавать вопросы и выявлять крайние случаи. Если вы никогда не делали этого раньше, в следующий раз, когда вы решите проблему Leetcode, начните думать о некоторых тестовых примерах, Leetcode может работать против вашего решения за кулисами. Уточняющие вопросы, которые вы, возможно, захотите задать в связи с указанной выше проблемой (я намеренно оставил вопрос расплывчатым, поскольку вы можете столкнуться с такой формулировкой во время интервью):
- «Каким будет мой ввод, в виде списка, набора и т. Д. Чисел?»
- «Что мне вернуть? Наибольшее значение или индекс наибольшего значения "?"
- «Если список пуст, что мне вернуть?»
- «Могу я предположить, что список чисел поместится в памяти» (не очень важный вопрос, но он показывает, что у вас есть некоторое понимание ограничения памяти).
Я считаю полезным потратить десять минут на обдумывание вашего решения. Вы никогда не захотите оказаться в положении, когда вы проходите 45-минутное собеседование и в течение 30 минут вы кодируете свое решение. Когда вы закончите кодирование, интервьюер может сказать что-то вроде: «Ваше решение не работает для этого пограничного случая, как мы можем изменить ваше решение, чтобы оно работало здесь?» Возможно, это простое решение, но что, если ваш алгоритм в корне неверен? У вас будет всего 15 минут, чтобы переосмыслить все свое решение, что может вызвать большой стресс и, вероятно, означает, что вы не пройдете раунд.
2. Как вы отвечаете на отзывы?
Если вы начнете кодировать свое решение, и я скажу что-то вроде «вместо использования этой структуры данных, как вы думаете, мы могли бы решить этот вопрос с помощью этой другой структуры данных»?
Есть два способа ответить. Либо вы можете сказать что-то вроде «Нет, я думаю, что вы ошибаетесь», либо вы можете сказать: «Конечно, позвольте мне подумать о том, как мы могли бы использовать эту структуру данных».
Фактический ответ, который я дал, может показаться немного преувеличенным, но общая предпосылка состоит в том, чтобы убедиться, что если интервьюер дает какой-то совет, вы не сразу его проигнорируете. Интервьюер, вероятно, знает около 95% всех различных решений проблемы, поэтому он может помочь вам, уведя вас от решения, которое может не сработать в нескольких крайних случаях, что сэкономит ваше время.
Иногда, когда респонденты не знают ответа на что-то или расстраиваются из-за того, что не могут найти решения, они могут переложить это разочарование на интервьюера, давая быстрые ответы или игнорируя обратную связь. Проблема в том, что человек, проводящий собеседование с вами, скорее всего, будет работать с вами, если вас возьмут на работу. Если вы плохо себя ведете на собеседовании, ваш собеседник может задаться вопросом, как вы отреагируете при работе над реальным проектом или новой функцией, когда нет особой ясности в том, что делать.
3. Общение
Вы говорите мне (как интервьюеру) вслух свое решение, прежде чем приступить к кодированию, или вы сразу же начинаете кодировать свой ответ молча? Я был на собеседовании, где собеседник не произносил ни слова в течение 45 минут (или сколько бы ни длился разговор) и, в конце концов, говорил мне, что их решение работает и соответствует временной / пространственной сложности. Вы можете себе представить, что это может быть довольно неудобно для интервьюеров, поскольку мы не знаем, о чем вы думаете, и не знаем, как мы можем помочь, если вы застряли. Необязательно, чтобы это звучало так, будто вы чему-то меня учит, но убедитесь, что каждую минуту или две минуты вы подаете звуковые сигналы о том, что вы делаете или на чем-то застряли.
Когда вам впервые задают проблему (или даже на протяжении всего собеседования), вполне нормально спросить интервьюера: «Могу я уделить пару минут, чтобы подумать о проблеме?» Просто убедитесь, что вы мне что-то сказали, прежде чем перестанете говорить на три или более минут. Говоря вслух о своем решении, вы можете не знать, как что-то реализовать, и вы можете отказаться от функциональности. Вы можете сказать что-то вроде: «Я не знаю, как реализовать эту конкретную часть моего алгоритма, но предположим, что у меня есть функция, которая будет возвращать этот результат и будет иметь эту пространственно-временную сложность при задании определенного ввода».
4. Возможности программирования
Это может включать в себя все:
- Вы быстро печатаете?
- Хорошо ли вы понимаете встроенные методы и библиотеки используемого вами языка программирования, или вам постоянно приходится искать документацию во время собеседования?
- Используете ли вы осмысленные имена переменных / функций и создаете вспомогательные методы, когда часть вашей логики начинает усложняться?
- Вы бездумно нажимаете кнопку «Выполнить» каждый раз, когда вносите небольшие изменения в свой код, или вы можете написать 20 строк кода без синтаксиса, а затем щелкнуть «Выполнить», чтобы увидеть, что делает ваша программа?
- Если возможно, используете ли вы классы или какие-то ООО концепции?
- Вы писали тесты (особенно с крайними случаями) для проверки созданной вами функции?
5. Компромиссные решения
У каждой проблемы кодирования, вероятно, есть много разных решений, от метода грубой силы до наиболее оптимального. Всегда приятно говорить что-то вроде: «Один из способов решить эту проблему - использовать это решение, которое будет иметь такую пространственно-временную сложность». или «Другое решение, которое будет иметь более высокую временную сложность, но меньшую пространственную сложность…». Как я уже говорил ранее, со временем вы станете лучше.
Мои особые претензии к Leetcode и как с его помощью оптимизировать свое время
Вы можете заметить одну вещь: сам процесс написания кода - это лишь одно из того, что мы ищем. Когда я провожу собеседование, в конце дня я хочу нанять кандидата с отличными навыками решения проблем, программирования и общения. Собеседования по техническому кодированию далеки от совершенства, но некоторый талант проявляется, когда кандидат может преуспеть в них. Причины, по которым я не могу сразу рекомендовать Leetcode:
- Leetcode не заставляет вас вслух объяснять свой алгоритм, прежде чем вы начнете писать код. Я думаю, это важно, потому что, если вы не можете четко сформулировать свой алгоритм, возможно, вам нужно подумать над ним еще пару минут. Я бы предпочел, чтобы кандидат сделал это, а затем начал наивно кодировать решение в течение 30 минут, натолкнулся на препятствие и не получил рабочего решения в конце собеседования. Помните, что решение методом грубой силы лучше, чем отсутствие ответа. Сначала найдите рабочее решение, а затем - решение получше.
- Leetcode не заставляет вас говорить, какова временная и пространственная сложность вашего алгоритма. Вам зададут этот вопрос на любом техническом собеседовании, на котором вы пишете код, поскольку именно так мы можем объективно измерить два решения и сказать, какое из них лучше с точки зрения времени, пространства, удобочитаемости и т. Д. Кроме того, если вы скажете что-то вроде временной сложности O (n), скажите мне, что означает n (и любая другая переменная, которую вы используете). Представляет ли n количество символов в списке, количество элементов в списке или что-то еще?
- В Leetcode вы можете запускать свой код много раз и не подвергаться наказанию, но в условиях собеседования вы, вероятно, сможете нажать кнопку «Выполнить код» только четыре или пять раз. Поэтому перед тестированием кода убедитесь, что вы более критично относитесь к синтаксическим и логическим ошибкам. Я думаю, что Google была единственной компанией, в которую я подал заявку, где вам даже не дают кнопки для запуска вашего кода, поскольку вы должны написать все это в документе Google. Необязательно быть такими крайними, но при создании решения убедитесь, что вы не слишком полагаетесь на кнопку запуска.
- Leetcode не заставляет вас думать о крайних случаях или задавать уточняющие вопросы, поскольку вся эта информация предоставляется вам заранее.
- Leetcode не задает дополнительных вопросов, таких как «как изменится ваше решение, если мы введем это новое требование» или «в чем узкое место в вашем алгоритме».
- Leetcode не накажет вас, если у вас плохие имена переменных или 100 строковых методов. Читаемый код - это то, что вы не очень часто видите в сообщениях Leetcode о проблемах.
Заключение
Напомним, что Leetcode по своей сути не плох. Я думаю, что Leetcode - это как езда на велосипеде с обучающими колесами, и на собеседовании у вас не будет этих обучающих колес для поддержки.
Всегда здорово практиковаться в среде, которая отражает реальную обстановку. Чаще всего люди, берущие интервью у вас, вероятно, будут теми же людьми, с которыми вы бы работали, если бы получили предложение. Вы, интервьюеры, хотите убедиться, что вы сообразительны, но также хотите убедиться, что у вас нет большого эго и с вами достаточно легко работать.
Кроме того, это на 100% нормально, если вы не можете решить проблему LeetCode и найти решение. В конце концов, мы делаем всю эту практику для настоящего технического собеседования, и я хочу продемонстрировать, чего вы можете ожидать.
Структуры данных и задаваемые вопросы по кодированию не сильно изменились за последние пару десятилетий и не изменятся в ближайшее время. Любые усилия, которые вы приложите для подготовки к техническому или поведенческому собеседованию сегодня, помогут вам в будущем при повторном собеседовании (или даже на работе / выполнении дополнительных проектов).
В следующий раз, когда вы будете практиковать вопросы Leetcode, попробуйте запомнить некоторые из приведенных выше моментов и начните относиться к практике как к настоящему собеседованию. Я записывал себя, когда делал Leetcode, чтобы посмотреть, как я звучу. У меня была дурная привычка бессвязно что-то выдумывать (говорить «Уммм» или «тьфу»), когда я не знала ответа. Со временем у меня это получалось лучше, но я бы никогда не заметил этого, если бы не записал себя. Скорее всего, будет неловко наблюдать за собой, но саморефлексия, возможно, является одним из лучших способов стать лучше в этих вещах.
Еще пара заявлений об отказе от ответственности и к сведению. Как всегда, идеи и мысли, которыми я делюсь, никоим образом не одобряются и не поддерживаются Salesforce (или какой-либо другой компанией, в которой я работал в прошлом). Кроме того, нет ничего плохого в использовании LeetCode (поскольку все время практиковаться в написании кода лучше, чем не писать никакого кода, особенно для выпускников начальных курсов или новичков, которые не занимались программированием в течение длительного времени).
