Как достичь прогресса при подготовке к собеседованиям по кодированию

1656663997 kak dostich progressa pri podgotovke k sobesedovaniyam po kodirovaniyu

Сэм Гевис-Хьюсон

1*yood0dc7U0s5QaogPZt4bQ

Застрягать никогда не весело. Особенно когда вы очень много работаете. И все же я вижу, что это случается с людьми, которые постоянно готовятся к собеседованиям по кодированию.

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

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

Когда я работаю с клиентами-коучингами 1:1, я часто нахожу их в такой ситуации. И почти во всех случаях, когда мы определим, что (или вещи) их сдерживает, они переживают серьезные прорывы. Решение этих проблем позволило моим клиентам получить работу в Amazon, Bloomberg, Uber и т.д.

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

1. Создайте прочную основу

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

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

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

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

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

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

Лучший способ сделать это – пройти курс из структур данных и алгоритмов MIT (Python) или Princeton (Java). Купите книгу, выполняйте задания и сдавайте экзамены. Если вы приложите усилия, вы сможете легко завершить курс за 3 месяца или меньше, и у вас будет прочная основа для движения вперед.

2. Получите больше опыта программирования

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

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

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

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

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

Если вы новичок в работе с открытым кодом, First Timers Only является отличным ресурсом для тех, кто хочет начать работу. Они делятся пособиями о том, как внести вклад, и составили список потенциальных проектов, которые были бы полезны для новичков.

3. Стратегически подходите к каждому вопросу собеседования

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

Самый распространенный план решения проблем собеседования, который я вижу, выглядит примерно так:

  1. Посмотрите на проблему
  2. Подумайте над проблемой
  3. Придумайте решение
  4. Запишите решение
  5. Успех

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

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

Это в лучшем случае рискованно.

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

[0:00–0:05] Устраивайтесь и убедитесь, что вы полностью понимаете проблему, которую они задают. Обработайте любые примеры ввода.

[0:05–0:10] Найдите решение проблемы грубой силой. Пока нет кодировки, просто обсудите это и нарисуйте любые рисунки, если вы считаете это полезным. Если вам не удается придумать решение грубой силой, попытайтесь проработать проблему вручную и перевести ее в алгоритм.

[0:10–0:15] Оптимизируйте свое решение. Потратьте эти 5 минут, чтобы найти лучшее решение, которое вы можете получить за этот период времени. Сравнивая решение, учитывайте временные сложности.

[0:15–0:35] Закодируйте свое решение. Даже если оно не оптимально, лучше иметь полное, неоптимальное решение, чем неполное, оптимальное решение.

[0:35–0:50] Проверьте свой код и устраните все проблемы. Это невероятно важно. Неважно, если ваш код не идеален с первого раза, но вам лучше уметь обнаруживать ошибки.

[0:50–1:00] Вопрос к вашему интервьюеру.

Следуя этим шагам, вы добьетесь двух вещей одновременно. Во-первых, вы эффективно планируете свое время. Самое большое разочарование в мире – нехватка времени, когда вы полностью знаете, как решить проблему.

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

4. Рассмотрите различные возможные решения

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

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

Например, рассмотрим эту проблему:

  • Есть одно решение O(n) сложность времени и O(1) сложность пространства
  • Другое решение есть O(log n) сложность времени и O(log n) сложность пространства

Какое из этих решений лучше?

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

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

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

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

5. Начните с применения грубой силы

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

Но позвольте мне спросить вас вот что: что лучшее, решение грубой силой или без решения?

Я скажу вам, что найти решение грубой силой на 1000% лучше, чем не найти решение вообще. И если вы начинаете с немедленной попытки найти оптимальное решение, легко застрять и остаться без полного решения до конца собеседования.

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

  1. Это дает вам запасный план. Если вы попытаетесь оптимизировать свое решение и потерпите неудачу, вы можете остановиться через 5 или 10 минут и просто закодировать свое решение грубой силой. Вы можете пройти собеседование. Не все проблемы имеют оптимальные решения.
  2. Это поможет вам прояснить проблему. Определение метода грубой силы может помочь вам понять, что нужно для решения этой проблемы. Это ключ. Глубокое понимание проблемы облегчит оптимизацию.

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

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

6. Спланируйте полное решение перед кодировкой

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

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

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

1*hpQB2b8kkBODN3GIlR3JMQ

Упорядочивать доску легче как вам, так и вашему интервьюеру. Им легче понять ваше решение, а вам гораздо легче следить за происходящим. И если вместо этого вы решите просто переписать материал, вы потеряете кучу драгоценного времени.

Другая проблема, связанная с тем, чтобы начать кодировать сразу, состоит в том, что это может зафиксировать вас в определенном образе мышления о проблеме. Мы поговорим об этом подробнее в пункте 7, но это может быть невероятно вредным для вашей эффективности на собеседовании.

Представьте, что вы видите проблему, и решение сразу приходит на ум. Вы начинаете кодировать это, но понимаете, что это уже не оптимально. Вы вряд ли захотите стереть все и начать сначала. И даже если вы это сделаете, вы будете заперты в таком образе мышления.

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

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

7. Имейте в виду общую картину

Одной из самых больших проблем, которую я вижу для более опытных разработчиков, является то, что они полностью застревают в сорняке с проблемой. Они начинают ломать голову над тем, должна ли быть петля <; Н or &lt;= N и не могу понять, какой подход верен.

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

Прекрасным примером этого является проблема, когда вы пытаетесь использовать неправильную структуру данных. Предположим, что вы сохраняете значения, проиндексированные с 1-N и вы решили использовать HashMap. Можно вставить 1 -> valу.е1, 2 -> значение2 и т.д.

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

Сейчас вы можете подумать: «Я бы никогда не совершил подобной глупости», но поверьте мне, это случается постоянно. Ваш процесс мышления нелинейный, когда вы решаете проблемы, поэтому вы, возможно, думали, что вам нужен HashMap через какое-то другое направление мышления, от которого вы впоследствии отказались.

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

8. Используйте абстракцию в своих интересах

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

Ключом к успешному решению этих проблем является использование абстракции. По сути это означает разбиение кода на меньшие функции с более конкретными целями.

Рассмотрим обычный пример. Скажем, мы хотим распечатать связанный перечень в обратном порядке. После обработки этой проблемы мы понимаем, что существует O(n) время и пространство решения проблемы с помощью стека (поместите каждый элемент в стек, когда мы просматриваем список, а затем извлеките каждый элемент и напечатайте), но мы можем решить проблему в O(n) время и O(1) пробел, перевернув соответствующий список.

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

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

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

Это имеет несколько преимуществ:

  1. Если у вас исчерпано время, у вас все еще есть практически рабочий код. Абстракция позволяет сосредоточиться на общей структуре, не погружаясь в мелочи. Если у вас есть дополнительное время, вы можете позаботиться о пустяках, но даже если у вас его нет, ваш собеседник понятно, что вы знаете, в чем дело.
  2. Четкость мышления и кода. Говорят, что чистый стол означает ясный ум, и то же касается кода. Чем лучше вы организуете свой код и разбиваете его на управляемые компоненты, тем легче будет о нем думать.

Я считаю, что чем сложнее проблема, тем ценнее может быть разбить вещи на управляемые компоненты.

9. Проверьте свой код

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

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

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

Одна из вещей, о которой люди все время забывают, – это проверить решение для собеседования. Но вы когда-нибудь зафиксировали код в реальном мире, не проверив его предварительно?

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

Главное при тестировании ваших решений – фактически пройти код строку за строкой, отслеживать значение каждой переменной и эффективно запускать код. Если вы просто читаете код на высоком уровне, вы можете легко пропустить меньшие проблемы с кодом. Я записал видео, демонстрирующее, как пройти и проверить свой код.

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

10. Получите хорошие отзывы

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

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

«Итак, — скажете вы, — кого это волнует? Я могу просто судить о своей собственной работе».

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

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

Если вы действительно серьезно относитесь к успеху на собеседованиях, я также советую поработать с тренером на имитационных собеседованиях. Имитационные интервью – это отдельные точки данных. Они говорят вам, что с конкретной проблемой в определенное время вы справились хорошо или плохо. Однако тренер может просмотреть все данные и помочь вам установить связи. Они могут помочь вам увидеть конкретные вещи, над которыми нужно работать, чтобы улучшить различные аспекты эффективности вашего собеседования.

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

Снова и снова я вижу, как люди затягивают свои интервью. И это почти всегда по одной из причин, описанных выше. Если вы не достигаете желаемого прогресса, внимательно прочтите эту статью. Определите свою проблемную область(ы) и работайте над ее исправлением. Со временем вы сможете усовершенствовать свое собеседование и начнете получать звонки, которые вы хотите услышать.

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

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