Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
На сколько хватит данных советов, когда впоследствии абсолютно все будут их прислушиваться. Все будут равны..
Советы базовые, я их использовал в Яндексе, так как это мой, можно сказать, родной стиль поведения. Но стресс - больное, сразу и руки не слушаются и языки заплетаются..
Начинается пост интересно, результаты на литкоде неплохие, биография вообще интересная, но мы быстро и глубоко погружаемся в легко узнаваемый характерный LLM контент.
Реальный проект в IDE — самый хардкорный вариант. Нужно написать работающее решение, которое запустится. Обычно занимает от 90 минут. Хорошая новость: часто разрешают подготовить скелет проекта заранее.
Это про хакатоны, для тех кто не знает слова хакатон? Да, это формат возможного найма на работу, но точно не формат собеседования, или хотелось бы хотя бы один пример компании, которые так и собеседуют. Тестовое задание под это описание так себе подходит. Что имелось в виду?
Несмотря на то, что в абзаце "Ритуал решения задачи" я в целом со всем согласен, но согласен я лишь потому, что уже имею свой опыт прохождения таких собеседований, и читаю немного "по диагонали". Обычно дается не более 15-30 минут на задачу, и если много временить тратить на "уточнение corner cases" и написание "наивного решения", то то решение, которое ожидалось увидеть вы просто не успеете написать.
Для задач уровня medium и выше обычно есть более оптимальное решение.
Более оптимальное, чем наивное? Так для большинства easy задач оно тоже есть, более того, это вся суть задачи. Начинать с имплементации менее оптимального, чем подразумеваемое оптимальное решение, опять же просто трата времени. И лишний стресс из-за того, что даже наивное решение можно написать криво, и потратить на это время. Не надо писать вычисление чисел Фибоначчи через рекурсию, вы потратите не только время на написание "ненужного кода", но еще и на разговор с интервьюером о том, почему рекурсия в такой задаче плохо, во всех языках ли она плоха и так далее. Плюсов никаких, а 10 минут просто исчезли.
Теперь перейдем к примеру из статьи:
fun calcSum(input: List<Int>): Int {
// TODO: handle empty input
...Это LLM выдумала? Прекрасно эта функция будет работать и с пустым списком. Наоборот, такое TODO дает стойкое понимание интервьюеру о том, что вы не понимаете язык, на котором пишете. Просто немного неудачный пример, но зачем неудачный если есть миллионы удачных?
Про визуализацию без кода тоже надо учитывать, что возможно визуализировать процесс будет по времени дороже, чем написать код, пусть и с небольшими недочетами. Красиво рисовать дерево, переставлять значки, объяснять каждый шаг и не занервничать - это тоже скилл.
Одна строчка — одно действие
Вкусовщина. До крайности как в примере доходить не надо, но и использовать это как правило смысла нет. Те же небольшие LINQ конструкции они прямо просятся порою, чтобы их не дробили на несколько строк. if (x < 0 || y < 0) { x++; y++} тоже размазывать по нескольким строчкам затея, мягко говоря, на любителя. Если писать не в IDE а в блокноте, уйму времени потереяете на форматирование такого кода.
Интервью укладывается в 30 минут
То есть это либо одна задача на 30 минут, либо две по 15, либо "забудь обо всем, что мы сейчас говорили, и учи задачи наизусть!".
Из золотых правил остается неизменным только это по сути:
Пока не проведёте хотя бы 10 моков — не тратьте время на настоящие интервью.
Но так же и статью не напишешь. А вообще, уже какая там, пятая за месяц о литкод?
Как же я соскучился по токсичности Хабра. Просто потрясающе.
Что ж, давайте я постараюсь ответить по пунктам.
LLM
Вся статья собрана из моих постов в телеграм-канале. Можно посмотреть тут, тут, тут, тут, тут. Посты я пишу сам. Где в них LLM контент, простите?
Это про хакатоны, для тех кто не знает слова хакатон? Да, это формат возможного найма на работу, но точно не формат собеседования, или хотелось бы хотя бы один пример компании, которые так и собеседуют. Тестовое задание под это описание так себе подходит. Что имелось в виду?
Нет, это действительно есть формат собеседования. В 2021/2022 такие форматы я встречал как минимум в Bolt, Lyft (там вообще по сути интервью 3-4 были про построение одного проекта, просто с акцентом на разные вещи, типа здесь UI, там домен и тд.).
Обычно дается не более 15-30 минут на задачу, и если много временить тратить на "уточнение corner cases" и написание "наивного решения", то то решение, которое ожидалось увидеть вы просто не успеете написать.
Тут, наверное, стоит пояснить временной слот. На уточнение можно потратить пару минут, все уточняющие вопросы обычно очень типовые, и часть кейсов интервьюир подсвечивает еще при озвучивании задачи. По поводу brute-force решения. Очень часто, его достаточно просто проговорить и быстро показать. На это тоже должно уходить буквально пару минут.
Более оптимальное, чем наивное? Так для большинства easy задач оно тоже есть, более того, это вся суть задачи.
Думал, это очевидно, но, пожалуй, стоит подсветить. Конечно же, если задача легкая, и там по сути одно решение, то с него и нужно начинать. Создавать себе проблемы на ровном месте точно не стоит.
Это LLM выдумала? Прекрасно эта функция будет работать и с пустым списком. Наоборот, такое TODO дает стойкое понимание интервьюеру о том, что вы не понимаете язык, на котором пишете. Просто немного неудачный пример, но зачем неудачный если есть миллионы удачных?
Вы сейчас серьезно? Вы точно читали статью? Вполне нормально оставлять коментарии на потом. В данном случае я показываю, что есть edge case - пустой список (или отрицательное число, или еще что). Мы про этот кейс помним, и к нему вернемся попозже. Вы, конечно же, проговариваете это все.
Про визуализацию без кода тоже надо учитывать, что возможно визуализировать процесс будет по времени дороже, чем написать код, пусть и с небольшими недочетами. Красиво рисовать дерево, переставлять значки, объяснять каждый шаг и не занервничать - это тоже скилл.
А как вы будете объяснять свой алгоритм до имплементации? Сразу бросаться кодить - точно не поощряемое действие. Плюс объяснение алгоритма помогает и вам убедиться, что вы не упустили чего-то. Тут же достаточно объяснить хотя бы общий принцип, не нужно рисовать никакие супер красивые и длинные деревья.
Вкусовщина. До крайности как в примере доходить не надо, но и использовать это как правило смысла нет.
Не согласен. На интервью вам сильно проще будет дебажить ваш код.
А вообще, уже какая там, пятая за месяц о литкод?
Да ради бога, не читайте эти статьи, если они вам так надоели. Ко мне то какие вопросы? У меня есть реальный опыт, и я им поделился с теми, кому актуально это.
Как же я соскучился по токсичности Хабра. Просто потрясающе.
Так выбирайте площадки, где за набросы большие пальцы и сердечки ставят. Были времена, когда люди публиковались на хабр преимущественно, чтобы получить советы и критику, а теперь даже уже не скрывают особо, что "нет подписоты, ну и идите своей дорогой".
Вся статья собрана из моих постов в телеграм-канале.
Ну так и нормально все было с постами в тг-канале. Кроме "Coding interview #5. Leetcode #3" где телеграм все пробелы съел в критически важных местах, поясняя как именно эта текстовая отладка выглядит, но кому до этого дело есть? А вот в структуру поста для хабра они не сами собой объединились. И от этого всего "нового" очень характерно веет.
Как соотносится более менее понятное:
В 2021/2022 такие форматы я встречал как минимум в Bolt, Lyft (там вообще по сути интервью 3-4 были про построение одного проекта, просто с акцентом на разные вещи, типа здесь UI, там домен и тд.).
С чистой воды абстракцией:
Реальный проект в IDE — самый хардкорный вариант. Нужно написать работающее решение, которое запустится. Обычно занимает от 90 минут. Хорошая новость: часто разрешают подготовить скелет проекта заранее.
Так можно и написать, разрешают в два этапа написать конкретный небольшой проект. Какие подготовки скелета проекта заранее? То есть вы еще конкретной задачи не знаете, но уже дома написали какие-то наброски кода? В ТГ вот прямо пишете "- Имплементация реального проекта в Android Studio и его запуск." - так вообще и вопросов нет.
я: Более оптимальное, чем наивное? Так для большинства easy задач оно тоже есть, более того, это вся суть задачи.
Вы: Думал, это очевидно, но, пожалуй, стоит подсветить.
Это не просто не очевидно, Вы же для новичков пишете, и даже закрепляете это концепцией "Уточняющие вопросы → brute force → обсуждение → имплементация с проговариванием → дебаггинг", которое вы называете Ритуал. Кстати в этой последовательности слов "оптимальное решение" я вообще не вижу. Зачем этот brute force, если вы уже знаете хорошее решение задачи? Или зачем вообще решать литкод, если любое решение можно сделать как brute force? Опять рисуем овал, а потом сову.
Вы сейчас серьезно? Вы точно читали статью? Вполне нормально оставлять коментарии на потом. В данном случае я показываю, что есть edge case - пустой список (или отрицательное число, или еще что)
Я очень даже серьезно. Тезис оставлять edge cases на потом - справедливый, но пример Ваш:
fun calcSum(input: List<Int>): Int {
// TODO: handle empty input
var sum = 0
for (elem in input) {
sum += elem
}
return sum
}Иллюстрирует то, что это строго бесполезно. Потому что, если вы знаете, как работает for in или foreach вы уже понимаете, что с пустым списком проблем не будет. Если вы не знаете, как работает то, что вы собираетесь использовать, то отчего не писать так:
fun calcSum(input: List<Int>): Int {
// TODO: handle empty input
// TODO: handle negative values
// TODO: handle only one element
// TODO: handle unsorted data
var sum = 0
for (elem in input) {
sum += elem
}
return sum
}Все эти TODO имеют абсолютно равную силу здесь. Хотели бы придумать нормальный пример, он бы не заставил себя ждать.
fun calcIntAvg(input: List<Int>): Int {
var sum = 0
var count = 0
for (elem in input) {
sum += elem
count += 1
}
return sum / count // TODO: handle empty list
}И это имело бы смысл. Причем именно так и пишут код в проектах. С какой-такой логики на собесах мы сначала обозначаем то что мы что-то недоделали, а потом только хоть что-то делаем вообще? Но вот я уже исправляю за Вас статью, а Вы говорите "токсичность".
А как вы будете объяснять свой алгоритм до имплементации? Сразу бросаться кодить - точно не поощряемое действие. Плюс объяснение алгоритма помогает и вам убедиться, что вы не упустили чего-то. Тут же достаточно объяснить хотя бы общий принцип, не нужно рисовать никакие супер красивые и длинные деревья.
Так не надо их рисовать, если вы знаете алгоритм, что dfs, что bfs это три буквы в рассказе об алгоритме. В каком порядке поддеревья обходятся это можно и словами в одном-двух предложениях описать, это если говорить об общих принципах. Опять же, нужен какой-то другой пример, где нарисовать просто, а объяснить сложно. Я таких примеров не знаю.
И вообще, про сам дебаггинг, если речь о собеседовании в IDE, то у вас есть все нормальные средства отладки, а если речь о работе в блокноте, то собеседующий, скорее всего, сам подскажет, где вы совершили небольшой недочет (на уровне синтаксиса или забытой операции), а в худшем случае, скажет "вы уверены, что алгоритм точно сработает?". В голове визуализация в любом случае будет работать быстрее, чем ascii-артом. Как способ "доказать" собеседующему, что вы не тупите, а хоть что-то делаете, текстовая визуализация может сработать, но надо ли это собеседующему? Это же не светский разговор, где бывают неловкие паузы.
Не согласен. На интервью вам сильно проще будет дебажить ваш код.
Когда у вас три примитивного типа переменных и одна коллекция на вход, а там обычно ничего дебажить и не надо. А иначе метод близок к неприменимости, если алгоритм дерево модифицирует, то в комментариях на каждый шаг будете каждый раз это дерево перерисовывать от вершины? Не на начальном этапе, когда вы просто поясняете, что алгоритм делать собирается, а когда у вас уже есть код, который вы хотите дебажить?
У меня есть реальный опыт, и я им поделился с теми, кому актуально это.
Так реальный опыт много у кого есть. Но если выводы из этого опыта значительно превышают самые общие (если угодно, базовые) вещи, и за ними не стоит какой-то теории или исследований, то это называется мнение.
С чистой воды абстракцией
Причем тут это? У меня статья про Leetcode. Другие типы code interview освещены очень вскользь. Фокус не на этом, поэтому и придираться к этому не вижу никакого смысла.
То есть вы еще конкретной задачи не знаете, но уже дома написали какие-то наброски кода?
Да, там готовится структура типа MVVM, добавляются все библиотеки, может быть реализован супер базовый UI, сделана навигация, и даже прототипы юнит-тестов могут быть.
Реальный проект в IDE — самый хардкорный вариант.
Типа, если чуть по-другому названо, то уже сразу LLM? Сомнительно, конечно. Если честно, как андроид-разработчик большую часть жизни, я не вижу какой-то разницы в обеих формулировках. Возможно, для вас по-другому. Но опять-таки, статья про Leetcode.
Это не просто не очевидно, Вы же для новичков пишете
Тут для всех уровней. Пока что вы первый, кто за это зацепился. Нужно подумать, как лучше сформулировать тогда.
С какой-такой логики на собесах мы сначала обозначаем то что мы что-то недоделали, а потом только хоть что-то делаем вообще?
Мысль не в этом. Мысль в том, что сначала нужно фокусироваться на основном решении. Всякие edge cases, которые возникают по пути, их можно пометить комментами, мол потом рассмотрим, и идти дальше по решению. То есть вы расставляете эти комментарии по ходу имплементации, чтобы их не упустить, и чтобы не терять фокус.
Опять же, нужен какой-то другой пример, где нарисовать просто, а объяснить сложно.
Хорошо подходят практически все задачи с массивами. Где two pointer, greedy algorithm и тд. Может вы по easy задачам судите, где все довольно очевидно. Тут да, оно излишне. Но все что ближе к middle и выше, точно сильно облегчает жизнь что кандидату, что ревьюиру.
В голове визуализация в любом случае будет работать быстрее, чем ascii-артом.
Я думаю, что вы не пробовали просто. Я ровно так же рассуждал долгое время, пока не попробовал. В голове всегда хуже. Сколько багов я отлавливал вот таким вот письменным дебаггингом. Ну как бы неработающие советы я бы точно не приводил. Понятное дело, что если вы всегда все в голове делаете прекрасно, вам это не нужно. Но обычным людям помогает.
Но если выводы из этого опыта значительно превышают самые общие (если угодно, базовые) вещи, и за ними не стоит какой-то теории или исследований, то это называется мнение.
А какие тут базовые вещи превышаются, простите?
Но вот я уже исправляю за Вас статью, а Вы говорите "токсичность".
Громко сказано про исправление. Вы спрашиваете, что-то подсвечиваете, я вам отвечаю. Идет дискуссия. Но подача у вас действительно очень токсичная, она как минимум неприятная. Какие-то недостатки по вашему мнению всегда можно вполне уважительно к автору подсветить. Как никак любой автор проделывает определенную работу, выкладывает абсолютно бесплатно, чтобы помочь другим людям. За это можно хотя бы сказать спасибо. Вы же врываетесь с набросами, что тут везде LLM, что нужна "подписота" и тд. Желаю вам адекватных комментаторов к вашим статьям. Удачи.
Литкод easy - дело полезное, ради самого паттерна "а вот тут наверное можно ускорить если подумать". Задач 50 решить по вечерам - проект невеликий. Литкод mid не нужен, если оптимизация кода это не профиль позиции. Литкод hard имхо нужен 3.5 гениям, а мы не гении.
Евгений, а теперь покажите нам где в работе новополученные знания с литкода вам пригодились.
Эти знания в первую очередь нужны для того, чтобы получить работу
Эти знания в первую очередь нужны для того, чтобы получить работу
Станцевать ритуальный танец, прыгнуть через горящий обруч, сказать "ку" два раза перед обладателями жёлтых штанов...
Конторы которые дают эту муть на интервью, заслуживают только чтобы кандидат юзал ИИ для решения этого бреда
Когда рынок не на дне, как последние пару лет, то набирают без леткода, и на зарплату влияют другие вещи. А когда на дне, то и литкод не поможет.
Подскажите пожалуйста изучаю С++, STL, комбинаторику ,Компьютерные сети, немного питона и хочу попасть в такие крупные компании как Intel/Amd/Nvidia на позицию джуна, учусь в рос вузе. Какие бы вы мне советы дали ?
Для кандидата преимуществ почти нет.
Сейчас ищу третью работу программистом, решил всё таки порешать задачи с leetcode. Мне понравилось, научился новому, приобрел полезный навык. Как будто "мышление программиста" существенно усовершенствовалось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как проходить Leetcode-интервью: ритуал, который работает