Прохожу собеседование на Frontend Разработчика в Яндексе. Как решать задачи правильно?
Собеседования на Frontend Разработчика в Яндексе могут быть вызывающими, но немного практики и подготовки помогут вам успешно пройти их. Ниже представлены некоторые советы о том, как правильно решать задачи во время собеседования.
1. Понимание задачи
Первым и самым важным шагом в решении задачи является полное понимание её. Не стесняйтесь задавать уточняющие вопросы, чтобы убедиться, что вы понимаете все аспекты задачи.
2. Планирование
Прежде чем приступить к кодированию, составьте план решения задачи. Разбейте задачу на более мелкие подзадачи и определите последовательность выполнения.
3. Кодирование и тестирование
Когда вы начнете писать код, обязательно используйте подробные комментарии, чтобы объяснить ваше решение. Далее проведите тестирование вашего кода, чтобы убедиться, что он работает корректно и соответствует заданию.
4. Объяснение решения
После того как вы завершили решение, обязательно объясните ваш подход и код собеседующему. Объясните, почему вы выбрали определенные методы и как это решение может быть улучшено.
5. Улучшение
Если вам предложат улучшить ваше решение, примите это как возможность продемонстрировать свою способность к обучению и адаптации. Рассмотрите предложения и дайте ответ, как вы можете улучшить ваше решение.
Следуя этим советам, вы сможете успешно решать задачи на собеседовании на Frontend Разработчика в Яндексе. Запомните, что практика делает мастера, поэтому не стесняйтесь тренироваться перед собеседованием.
А что на счет решения 2 задачи без await, вначале они сказали что именно так и надо, а по итогу только решение с await и показали
При всем уважении, чел слева очень много говорит, прям слишком, какие-то прям банальные вещи, иногда хочется сказать ДА ДАЙ ТЫ УЖЕ ЕМУ НАЧАТЬ РЕШАТЬ!
Прикол – смотрел этот ролик за день до прохождения финальной алгоритмической секции
В итоге вторая задача совпала, но я не досмотрел ролик до неё😄
Совет подписчикам – смотрите всё и до конца))
По первой задаче не очень понял. Просили же O(1), а количество итераций цикла в решении Тимура напрямую зависит от длины строки, что означает сложность O(n). Или я что то не понимаю? Подскажите, пожалуйста, люди добрые
BFS для второй задачи не нужен, здесь DFS по памяти более эффективен, т.к. не нужно хранить разом все возможные ветвления. Всё же важно правильно выбирать уметь между DFS и BFS, а не просто "потому что потому".
str.split().every((item, index, arr) => item === arr[arr.length – index – 1])
Какие же они душные
Ох уже говоруны в Яндексе , такое впечатление что мастера поговорить, а не по делу😅
Душное видео какое-то… Не посмотрел полностью 🙁
Я немного не понял, в чем смысл использовать const внутри цикла, в том смысле что чем это отличается от использования обычных переменных
ты крут
но не очень интересно слушать этих пизд@болов из яда
Результат подобного "набора" может прочувстовать каждый, обратившись к любому сервису Яндекса.
парни, как самостоятельно изучить программирование (мб кто-то может посоветовать какие-то сайты, курсы и т д) буду благодарен (JavaScript)
Не понимаю зачем фронту алгосики…..
Яндекс дно. Уже никто там не очень работать.
Курс не для начинающих изучать программирование?
Каким образом интервьюеры говорят об O(1) в первой задаче про палиндром?
Вышеприведенное решение с использованием цикла while и двух указателей (на начальный и последний символ строки), которые смещаются в цикле, не является операцией с постоянным временем O(1). Она имеет линейное время выполнения O(n), где "n" – это длина строки.
Почему? Процесс определения палиндрома требует сравнения символов, начиная с первого символа и с последнего символа строки, и постепенного смещения указателей внутри цикла while. Этот цикл будет выполняться столько раз, сколько символов есть в строке, поскольку нужно проверить каждую пару символов в строке, чтобы убедиться, что они равны. Таким образом, время выполнения зависит от длины входной строки и составляет O(n), где "n" – длина строки.
Не дают, оказывается, пользоваться консолью)) Я постоянно все, что пишу, тестирую в консоли, потому что какие-то мелочи выветриваются из головы со временем. Ну можно пойти дальше и сказать, что писать код в блокноте – это читерство, и надо писать его кровью на пергаменте)
Рассказывать слишком подробно о ходе решения, оказывается, нежелательно. Вот это можно рассказать, а это уже не надо. А если мне комфортно, когда я все проговариваю вслух? Видимо, во время решения задачи надо сосредоточиться не на решении, а на том, что можно проговорить, а что нет)
В отдельные функции выносить всякие дикие выражения не слишком приветствуется, и на имена переменных тоже, оказывается, никто не обращает внимания. А ничего. что нейминг – это один из важнейших скиллов для программиста?
Посмотрел первую половину собеса и сложилось впечатление об общей атмосфере происходящего, как об очень душной и некомфортной.
Спасибо за ролик. Лишний раз убедился в правильности отказов от общения с Яндекс. Ни ногой на подобные собесы.
если все согласованно значит собес не естественный, не интересно