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

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

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

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

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

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

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

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

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

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

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

Наконец, после всей этой тяжелой работы, если все ваши тестовые случаи прошли, просто отправьте свое решение! Если решение было принято, молодец. Вы можете опубликовать свое решение в разделе "Обсуждение". Вы также можете проверить, что опубликовали другие, или даже посмотреть официальные решения, если они были предоставлены. В противном случае вы можете увидеть, какой тестовый пример не удался, и решить проблему (ы) в своем решении.

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