Причем тут это? У меня статья про Leetcode. Другие типы code interview освещены очень вскользь. Фокус не на этом, поэтому и придираться к этому не вижу никакого смысла.
То есть вы еще конкретной задачи не знаете, но уже дома написали какие-то наброски кода?
Да, там готовится структура типа MVVM, добавляются все библиотеки, может быть реализован супер базовый UI, сделана навигация, и даже прототипы юнит-тестов могут быть.
Реальный проект в IDE — самый хардкорный вариант.
Типа, если чуть по-другому названо, то уже сразу LLM? Сомнительно, конечно. Если честно, как андроид-разработчик большую часть жизни, я не вижу какой-то разницы в обеих формулировках. Возможно, для вас по-другому. Но опять-таки, статья про Leetcode.
Это не просто не очевидно, Вы же для новичков пишете
Тут для всех уровней. Пока что вы первый, кто за это зацепился. Нужно подумать, как лучше сформулировать тогда.
С какой-такой логики на собесах мы сначала обозначаем то что мы что-то недоделали, а потом только хоть что-то делаем вообще?
Мысль не в этом. Мысль в том, что сначала нужно фокусироваться на основном решении. Всякие edge cases, которые возникают по пути, их можно пометить комментами, мол потом рассмотрим, и идти дальше по решению. То есть вы расставляете эти комментарии по ходу имплементации, чтобы их не упустить, и чтобы не терять фокус.
Опять же, нужен какой-то другой пример, где нарисовать просто, а объяснить сложно.
Хорошо подходят практически все задачи с массивами. Где two pointer, greedy algorithm и тд. Может вы по easy задачам судите, где все довольно очевидно. Тут да, оно излишне. Но все что ближе к middle и выше, точно сильно облегчает жизнь что кандидату, что ревьюиру.
В голове визуализация в любом случае будет работать быстрее, чем ascii-артом.
Я думаю, что вы не пробовали просто. Я ровно так же рассуждал долгое время, пока не попробовал. В голове всегда хуже. Сколько багов я отлавливал вот таким вот письменным дебаггингом. Ну как бы неработающие советы я бы точно не приводил. Понятное дело, что если вы всегда все в голове делаете прекрасно, вам это не нужно. Но обычным людям помогает.
Но если выводы из этого опыта значительно превышают самые общие (если угодно, базовые) вещи, и за ними не стоит какой-то теории или исследований, то это называется мнение.
А какие тут базовые вещи превышаются, простите?
Но вот я уже исправляю за Вас статью, а Вы говорите "токсичность".
Громко сказано про исправление. Вы спрашиваете, что-то подсвечиваете, я вам отвечаю. Идет дискуссия. Но подача у вас действительно очень токсичная, она как минимум неприятная. Какие-то недостатки по вашему мнению всегда можно вполне уважительно к автору подсветить. Как никак любой автор проделывает определенную работу, выкладывает абсолютно бесплатно, чтобы помочь другим людям. За это можно хотя бы сказать спасибо. Вы же врываетесь с набросами, что тут везде LLM, что нужна "подписота" и тд. Желаю вам адекватных комментаторов к вашим статьям. Удачи.
Как же я соскучился по токсичности Хабра. Просто потрясающе. Что ж, давайте я постараюсь ответить по пунктам.
LLM
Вся статья собрана из моих постов в телеграм-канале. Можно посмотреть тут, тут, тут, тут, тут. Посты я пишу сам. Где в них LLM контент, простите?
Это про хакатоны, для тех кто не знает слова хакатон? Да, это формат возможного найма на работу, но точно не формат собеседования, или хотелось бы хотя бы один пример компании, которые так и собеседуют. Тестовое задание под это описание так себе подходит. Что имелось в виду?
Нет, это действительно есть формат собеседования. В 2021/2022 такие форматы я встречал как минимум в Bolt, Lyft (там вообще по сути интервью 3-4 были про построение одного проекта, просто с акцентом на разные вещи, типа здесь UI, там домен и тд.).
Обычно дается не более 15-30 минут на задачу, и если много временить тратить на "уточнение corner cases" и написание "наивного решения", то то решение, которое ожидалось увидеть вы просто не успеете написать.
Тут, наверное, стоит пояснить временной слот. На уточнение можно потратить пару минут, все уточняющие вопросы обычно очень типовые, и часть кейсов интервьюир подсвечивает еще при озвучивании задачи. По поводу brute-force решения. Очень часто, его достаточно просто проговорить и быстро показать. На это тоже должно уходить буквально пару минут.
Более оптимальное, чем наивное? Так для большинства easy задач оно тоже есть, более того, это вся суть задачи.
Думал, это очевидно, но, пожалуй, стоит подсветить. Конечно же, если задача легкая, и там по сути одно решение, то с него и нужно начинать. Создавать себе проблемы на ровном месте точно не стоит.
Это LLM выдумала? Прекрасно эта функция будет работать и с пустым списком. Наоборот, такое TODO дает стойкое понимание интервьюеру о том, что вы не понимаете язык, на котором пишете. Просто немного неудачный пример, но зачем неудачный если есть миллионы удачных?
Вы сейчас серьезно? Вы точно читали статью? Вполне нормально оставлять коментарии на потом. В данном случае я показываю, что есть edge case - пустой список (или отрицательное число, или еще что). Мы про этот кейс помним, и к нему вернемся попозже. Вы, конечно же, проговариваете это все.
Про визуализацию без кода тоже надо учитывать, что возможно визуализировать процесс будет по времени дороже, чем написать код, пусть и с небольшими недочетами. Красиво рисовать дерево, переставлять значки, объяснять каждый шаг и не занервничать - это тоже скилл.
А как вы будете объяснять свой алгоритм до имплементации? Сразу бросаться кодить - точно не поощряемое действие. Плюс объяснение алгоритма помогает и вам убедиться, что вы не упустили чего-то. Тут же достаточно объяснить хотя бы общий принцип, не нужно рисовать никакие супер красивые и длинные деревья.
Вкусовщина. До крайности как в примере доходить не надо, но и использовать это как правило смысла нет.
Не согласен. На интервью вам сильно проще будет дебажить ваш код.
А вообще, уже какая там, пятая за месяц о литкод?
Да ради бога, не читайте эти статьи, если они вам так надоели. Ко мне то какие вопросы? У меня есть реальный опыт, и я им поделился с теми, кому актуально это.
Было бы прикольно, если в этой библиотеке поддерживались деревья компонентов. И тогда при уничтожении корня погибали бы и дочерние компоненты.
У вас кстати есть такая проблема с деревьями?
v1sar — автор концепции, он отлично все распишет.
но реально, в видео все рассказываем
никто не мешает делать цитаты оттуда и уже более предметно пообщаться
Причем тут это? У меня статья про Leetcode. Другие типы code interview освещены очень вскользь. Фокус не на этом, поэтому и придираться к этому не вижу никакого смысла.
Да, там готовится структура типа MVVM, добавляются все библиотеки, может быть реализован супер базовый UI, сделана навигация, и даже прототипы юнит-тестов могут быть.
Типа, если чуть по-другому названо, то уже сразу LLM? Сомнительно, конечно. Если честно, как андроид-разработчик большую часть жизни, я не вижу какой-то разницы в обеих формулировках. Возможно, для вас по-другому. Но опять-таки, статья про Leetcode.
Тут для всех уровней. Пока что вы первый, кто за это зацепился. Нужно подумать, как лучше сформулировать тогда.
Мысль не в этом. Мысль в том, что сначала нужно фокусироваться на основном решении. Всякие edge cases, которые возникают по пути, их можно пометить комментами, мол потом рассмотрим, и идти дальше по решению. То есть вы расставляете эти комментарии по ходу имплементации, чтобы их не упустить, и чтобы не терять фокус.
Хорошо подходят практически все задачи с массивами. Где two pointer, greedy algorithm и тд. Может вы по easy задачам судите, где все довольно очевидно. Тут да, оно излишне. Но все что ближе к middle и выше, точно сильно облегчает жизнь что кандидату, что ревьюиру.
Я думаю, что вы не пробовали просто. Я ровно так же рассуждал долгое время, пока не попробовал. В голове всегда хуже. Сколько багов я отлавливал вот таким вот письменным дебаггингом. Ну как бы неработающие советы я бы точно не приводил. Понятное дело, что если вы всегда все в голове делаете прекрасно, вам это не нужно. Но обычным людям помогает.
А какие тут базовые вещи превышаются, простите?
Громко сказано про исправление. Вы спрашиваете, что-то подсвечиваете, я вам отвечаю. Идет дискуссия. Но подача у вас действительно очень токсичная, она как минимум неприятная. Какие-то недостатки по вашему мнению всегда можно вполне уважительно к автору подсветить. Как никак любой автор проделывает определенную работу, выкладывает абсолютно бесплатно, чтобы помочь другим людям. За это можно хотя бы сказать спасибо. Вы же врываетесь с набросами, что тут везде LLM, что нужна "подписота" и тд. Желаю вам адекватных комментаторов к вашим статьям. Удачи.
Как же я соскучился по токсичности Хабра. Просто потрясающе.
Что ж, давайте я постараюсь ответить по пунктам.
Вся статья собрана из моих постов в телеграм-канале. Можно посмотреть тут, тут, тут, тут, тут. Посты я пишу сам. Где в них LLM контент, простите?
Нет, это действительно есть формат собеседования. В 2021/2022 такие форматы я встречал как минимум в Bolt, Lyft (там вообще по сути интервью 3-4 были про построение одного проекта, просто с акцентом на разные вещи, типа здесь UI, там домен и тд.).
Тут, наверное, стоит пояснить временной слот. На уточнение можно потратить пару минут, все уточняющие вопросы обычно очень типовые, и часть кейсов интервьюир подсвечивает еще при озвучивании задачи. По поводу brute-force решения. Очень часто, его достаточно просто проговорить и быстро показать. На это тоже должно уходить буквально пару минут.
Думал, это очевидно, но, пожалуй, стоит подсветить. Конечно же, если задача легкая, и там по сути одно решение, то с него и нужно начинать. Создавать себе проблемы на ровном месте точно не стоит.
Вы сейчас серьезно? Вы точно читали статью? Вполне нормально оставлять коментарии на потом. В данном случае я показываю, что есть edge case - пустой список (или отрицательное число, или еще что). Мы про этот кейс помним, и к нему вернемся попозже. Вы, конечно же, проговариваете это все.
А как вы будете объяснять свой алгоритм до имплементации? Сразу бросаться кодить - точно не поощряемое действие. Плюс объяснение алгоритма помогает и вам убедиться, что вы не упустили чего-то. Тут же достаточно объяснить хотя бы общий принцип, не нужно рисовать никакие супер красивые и длинные деревья.
Не согласен. На интервью вам сильно проще будет дебажить ваш код.
Да ради бога, не читайте эти статьи, если они вам так надоели. Ко мне то какие вопросы? У меня есть реальный опыт, и я им поделился с теми, кому актуально это.
Что-то не дает подправить ссылку. В любом случае, вот правильная - https://github.com/KasperskyLab/Kaspresso/blob/master/wiki/03_Kaspresso_configurator.md
Расскажи, интересно же =)
Я надеюсь, что в автоматизации тестирования будут рассмотрены только православные инструменты??
Дык подход, описанный здесь, и то, что рассказывал Володя, мега коррелируют друг с другом =) Разве не так?
В сентябре
В сентябре
готово
Поддержка планируется
Надо, но не обязательно. Об этом в следующих статьях
можете поделиться впечатлениями?)
C Котлином часть вещей упростилась. Ну и плюс опыт, конечно же.
У вас кстати есть такая проблема с деревьями?
но реально, в видео все рассказываем
никто не мешает делать цитаты оттуда и уже более предметно пообщаться