Был бы у нас ещё какой-то автоматизированный детектор нейрослопа. А так все равно время людей будет расходоваться. Сходу и правда кажется, что подача репортов на баунти должна быть платной.
Немного подушню, на тему того, что эти 97% дейтрейдеров в минусе - это все-таки местечковая история, полученная на базе двух исследований, на биржах с по современным меркам конскими комиссиями, но к статье это почти никак не относится.
А вот с остальными цифрами из статьи согласен почти полностью. Очень похожие и у себя наблюдал. Тейки и подходы из статьи, - по сути все полностью справедливо. Даже с, казалось бы, спорным
Переписал кусок. Было 50 мс, стало 0.5 мс. Гордый, замерил общий roundtrip. Был 150 мс, стал 100.5 мс. Месяц работы ради 33%. На daily-стратегии это технически интересно, но фактически бесполезно
Я получил ответ на свои вопросы, - здесь помогает теорема Пуанкаре, которая дает следствие, что множество пар орбит, которые никогда не сталкиваются, является открытым, плотным и полной меры в пространстве всех пар орбит. То есть потенциально сталкивающиеся орбиты имеют меру ноль. Это не нулевая вероятность, но также не дает права поднимать вопросы теории вероятности на множестве сталкивающихся орбит.
Так и есть. Наверное удалюсь пока из этой ветки рассуждений, потому что "чем больше поваров, тем хуже суп", каждый что-то свое имеет в виду и общими словами хочет обозначить, да и что-то свое считает. События действительно независимые, и результат каждого следующего круга не определяется предыдущим (даже если не менять траектории), но при этом вероятности не умножаются (и уж тем более не складываются, как это вообще), потому что это не одновременное существование независимых событий, а каждый круг это просто "перезапуск эксперимента". Но даже в этом я на 100% не уверен без симуляции. Есть бесконечное число траекторий, которые не пересекаются вот прям вообще никогда. Больше ли это множество, чем множество пересекающихся траекторий? А насколько?
А не так это надо моделировать, представьте две команды снайперов, 5000 с одной стороны 5000 с другой, на расстоянии 1км, стреляют, ну не принципиально это настолько, но 50 BMG, для ясности, будут ли жертвы через неделю?
В случае ровно двух спутников, да независимые. В случае большого их количества уже не так просто. Там все-таки надо считать вероятность для каждого столкнуться (или не столкнуться) с любым (или каждым) из остальных.
Как же я соскучился по токсичности Хабра. Просто потрясающе.
Так выбирайте площадки, где за набросы большие пальцы и сердечки ставят. Были времена, когда люди публиковались на хабр преимущественно, чтобы получить советы и критику, а теперь даже уже не скрывают особо, что "нет подписоты, ну и идите своей дорогой".
Вся статья собрана из моих постов в телеграм-канале.
Ну так и нормально все было с постами в тг-канале. Кроме "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-артом. Как способ "доказать" собеседующему, что вы не тупите, а хоть что-то делаете, текстовая визуализация может сработать, но надо ли это собеседующему? Это же не светский разговор, где бывают неловкие паузы.
Не согласен. На интервью вам сильно проще будет дебажить ваш код.
Когда у вас три примитивного типа переменных и одна коллекция на вход, а там обычно ничего дебажить и не надо. А иначе метод близок к неприменимости, если алгоритм дерево модифицирует, то в комментариях на каждый шаг будете каждый раз это дерево перерисовывать от вершины? Не на начальном этапе, когда вы просто поясняете, что алгоритм делать собирается, а когда у вас уже есть код, который вы хотите дебажить?
У меня есть реальный опыт, и я им поделился с теми, кому актуально это.
Так реальный опыт много у кого есть. Но если выводы из этого опыта значительно превышают самые общие (если угодно, базовые) вещи, и за ними не стоит какой-то теории или исследований, то это называется мнение.
Начинается пост интересно, результаты на литкоде неплохие, биография вообще интересная, но мы быстро и глубоко погружаемся в легко узнаваемый характерный 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 моков — не тратьте время на настоящие интервью.
Но так же и статью не напишешь. А вообще, уже какая там, пятая за месяц о литкод?
Почитал оригинал, понятнее все равно не стало. Получается велосипед держит постоянное подключение к интернет? И что будет если просто снять батарею, как система защиты тогда сработает?
Это, кстати, отличное наблюдение. Если бы это было моё казино, я бы после каждого броска менял бы монетку игроку. Корректнее было бы так, выложить тысячу монет на стол, пусть следующую выбирает сам.
"Пренебрежимо мала" это оно и есть, откройте любое определение. Это то, что можно считать нулем (исключая построения, где это "пренебрежимо малое" испольузется в математическом анализе, ну и собственно, чтобы оно стало чем-то существенным его нужно домножить на что-то "практически" бесконечное), а значит на практике можно считать невозможным в принципе :)
Поизучал самые невероятные истории этого мира, к сожалению большинство из них выглядят совсем уж мифами и легендами, но из чего-то более менее достоверного самое производящее впечатление - это история Роя Салливана. В него молния попала аж 7 раз за жизнь, а умер он по другим причинам. Википедия оценивает эту вероятность в 2^-80 (но они как-то совсем не старались считать). У меня если учесть все все-таки зависимые события получилось 2^-60 и это правда офигеть какое редкое событие. А из других историй даже близко к 2^-40 уже ничего не нашел. А вот около 2^-30 да, так бывает, людей-то много, все что-то делают, событий ого-го как много, вот что-то иногда и происходит почти феноменальное.
А вообще только сейчас заметил, что вы про 120 говорите в контексте орлов и решек, но 10^120 это в переводе на игру в монетку 2^399. Так вот между 2^-60 (и это самое редкое из всех известных редких событий в мире, реже только что-то из космологии, но там сложнее с пруфами) и 2^-399 есть немноожечко разницы.
В этом случае и без зеро все прекрасно у казино. Если вступительный взнос больше 20 рублей (а я замахнулся аж на 1024) в абсолютном большинстве практических случаев казино будет в существенном плюсе.
Я статью читал :) Недостаточно связи, относительно той же задачи о Кёнингсбергских мостах. Намек был на то, что быть может, в Санкт-Петербурге были какие-то характерные (уникальные?) игры, похожие на несколько описанных, что надоумило Бернулли об этих играх подумать. А так, немало кто еще работал в СПбГУ и среди их работ находились куда более парадоксальные вещи.
Да, хорошая идея.
Был бы у нас ещё какой-то автоматизированный детектор нейрослопа. А так все равно время людей будет расходоваться. Сходу и правда кажется, что подача репортов на баунти должна быть платной.
Идею я всерьёз конечно не воспринимаю, но какой бы была адекватная стоимость отклика?
Вообще прецедент зловещий. Это же любую компанию так могут заспуфить кривыми ИИ репортами...
Правильно я понимаю, что турбо-записи и обычные были ни в одну сторону не совместимы?
Отличная статья!
Немного подушню, на тему того, что эти 97% дейтрейдеров в минусе - это все-таки местечковая история, полученная на базе двух исследований, на биржах с по современным меркам конскими комиссиями, но к статье это почти никак не относится.
А вот с остальными цифрами из статьи согласен почти полностью. Очень похожие и у себя наблюдал. Тейки и подходы из статьи, - по сути все полностью справедливо. Даже с, казалось бы, спорным
По опыту абсолютно согласен.
Я получил ответ на свои вопросы, - здесь помогает теорема Пуанкаре, которая дает следствие, что множество пар орбит, которые никогда не сталкиваются, является открытым, плотным и полной меры в пространстве всех пар орбит. То есть потенциально сталкивающиеся орбиты имеют меру ноль. Это не нулевая вероятность, но также не дает права поднимать вопросы теории вероятности на множестве сталкивающихся орбит.
Так и есть. Наверное удалюсь пока из этой ветки рассуждений, потому что "чем больше поваров, тем хуже суп", каждый что-то свое имеет в виду и общими словами хочет обозначить, да и что-то свое считает. События действительно независимые, и результат каждого следующего круга не определяется предыдущим (даже если не менять траектории), но при этом вероятности не умножаются (и уж тем более не складываются,
как это вообще), потому что это не одновременное существование независимых событий, а каждый круг это просто "перезапуск эксперимента". Но даже в этом я на 100% не уверен без симуляции. Есть бесконечное число траекторий, которые не пересекаются вот прям вообще никогда. Больше ли это множество, чем множество пересекающихся траекторий? А насколько?А не так это надо моделировать, представьте две команды снайперов, 5000 с одной стороны 5000 с другой, на расстоянии 1км, стреляют, ну не принципиально это настолько, но 50 BMG, для ясности, будут ли жертвы через неделю?
В случае ровно двух спутников, да независимые. В случае большого их количества уже не так просто. Там все-таки надо считать вероятность для каждого столкнуться (или не столкнуться) с любым (или каждым) из остальных.
Так выбирайте площадки, где за набросы большие пальцы и сердечки ставят. Были времена, когда люди публиковались на хабр преимущественно, чтобы получить советы и критику, а теперь даже уже не скрывают особо, что "нет подписоты, ну и идите своей дорогой".
Ну так и нормально все было с постами в тг-канале. Кроме "Coding interview #5. Leetcode #3" где телеграм все пробелы съел в критически важных местах, поясняя как именно эта текстовая отладка выглядит, но кому до этого дело есть? А вот в структуру поста для хабра они не сами собой объединились. И от этого всего "нового" очень характерно веет.
Как соотносится более менее понятное:
С чистой воды абстракцией:
Так можно и написать, разрешают в два этапа написать конкретный небольшой проект. Какие подготовки скелета проекта заранее? То есть вы еще конкретной задачи не знаете, но уже дома написали какие-то наброски кода? В ТГ вот прямо пишете "- Имплементация реального проекта в Android Studio и его запуск." - так вообще и вопросов нет.
Это не просто не очевидно, Вы же для новичков пишете, и даже закрепляете это концепцией "Уточняющие вопросы → brute force → обсуждение → имплементация с проговариванием → дебаггинг", которое вы называете Ритуал. Кстати в этой последовательности слов "оптимальное решение" я вообще не вижу. Зачем этот brute force, если вы уже знаете хорошее решение задачи? Или зачем вообще решать литкод, если любое решение можно сделать как brute force? Опять рисуем овал, а потом сову.
Я очень даже серьезно. Тезис оставлять edge cases на потом - справедливый, но пример Ваш:
Иллюстрирует то, что это строго бесполезно. Потому что, если вы знаете, как работает for in или foreach вы уже понимаете, что с пустым списком проблем не будет. Если вы не знаете, как работает то, что вы собираетесь использовать, то отчего не писать так:
Все эти TODO имеют абсолютно равную силу здесь. Хотели бы придумать нормальный пример, он бы не заставил себя ждать.
И это имело бы смысл. Причем именно так и пишут код в проектах. С какой-такой логики на собесах мы сначала обозначаем то что мы что-то недоделали, а потом только хоть что-то делаем вообще? Но вот я уже исправляю за Вас статью, а Вы говорите "токсичность".
Так не надо их рисовать, если вы знаете алгоритм, что dfs, что bfs это три буквы в рассказе об алгоритме. В каком порядке поддеревья обходятся это можно и словами в одном-двух предложениях описать, это если говорить об общих принципах. Опять же, нужен какой-то другой пример, где нарисовать просто, а объяснить сложно. Я таких примеров не знаю.
И вообще, про сам дебаггинг, если речь о собеседовании в IDE, то у вас есть все нормальные средства отладки, а если речь о работе в блокноте, то собеседующий, скорее всего, сам подскажет, где вы совершили небольшой недочет (на уровне синтаксиса или забытой операции), а в худшем случае, скажет "вы уверены, что алгоритм точно сработает?". В голове визуализация в любом случае будет работать быстрее, чем ascii-артом. Как способ "доказать" собеседующему, что вы не тупите, а хоть что-то делаете, текстовая визуализация может сработать, но надо ли это собеседующему? Это же не светский разговор, где бывают неловкие паузы.
Когда у вас три примитивного типа переменных и одна коллекция на вход, а там обычно ничего дебажить и не надо. А иначе метод близок к неприменимости, если алгоритм дерево модифицирует, то в комментариях на каждый шаг будете каждый раз это дерево перерисовывать от вершины? Не на начальном этапе, когда вы просто поясняете, что алгоритм делать собирается, а когда у вас уже есть код, который вы хотите дебажить?
Так реальный опыт много у кого есть. Но если выводы из этого опыта значительно превышают самые общие (если угодно, базовые) вещи, и за ними не стоит какой-то теории или исследований, то это называется мнение.
Начинается пост интересно, результаты на литкоде неплохие, биография вообще интересная, но мы быстро и глубоко погружаемся в легко узнаваемый характерный LLM контент.
Это про хакатоны, для тех кто не знает слова хакатон? Да, это формат возможного найма на работу, но точно не формат собеседования, или хотелось бы хотя бы один пример компании, которые так и собеседуют. Тестовое задание под это описание так себе подходит. Что имелось в виду?
Несмотря на то, что в абзаце "Ритуал решения задачи" я в целом со всем согласен, но согласен я лишь потому, что уже имею свой опыт прохождения таких собеседований, и читаю немного "по диагонали". Обычно дается не более 15-30 минут на задачу, и если много временить тратить на "уточнение corner cases" и написание "наивного решения", то то решение, которое ожидалось увидеть вы просто не успеете написать.
Более оптимальное, чем наивное? Так для большинства easy задач оно тоже есть, более того, это вся суть задачи. Начинать с имплементации менее оптимального, чем подразумеваемое оптимальное решение, опять же просто трата времени. И лишний стресс из-за того, что даже наивное решение можно написать криво, и потратить на это время. Не надо писать вычисление чисел Фибоначчи через рекурсию, вы потратите не только время на написание "ненужного кода", но еще и на разговор с интервьюером о том, почему рекурсия в такой задаче плохо, во всех языках ли она плоха и так далее. Плюсов никаких, а 10 минут просто исчезли.
Теперь перейдем к примеру из статьи:
Это LLM выдумала? Прекрасно эта функция будет работать и с пустым списком. Наоборот, такое TODO дает стойкое понимание интервьюеру о том, что вы не понимаете язык, на котором пишете. Просто немного неудачный пример, но зачем неудачный если есть миллионы удачных?
Про визуализацию без кода тоже надо учитывать, что возможно визуализировать процесс будет по времени дороже, чем написать код, пусть и с небольшими недочетами. Красиво рисовать дерево, переставлять значки, объяснять каждый шаг и не занервничать - это тоже скилл.
Вкусовщина. До крайности как в примере доходить не надо, но и использовать это как правило смысла нет. Те же небольшие LINQ конструкции они прямо просятся порою, чтобы их не дробили на несколько строк. if (x < 0 || y < 0) { x++; y++} тоже размазывать по нескольким строчкам затея, мягко говоря, на любителя. Если писать не в IDE а в блокноте, уйму времени потереяете на форматирование такого кода.
То есть это либо одна задача на 30 минут, либо две по 15, либо "забудь обо всем, что мы сейчас говорили, и учи задачи наизусть!".
Из золотых правил остается неизменным только это по сути:
Но так же и статью не напишешь. А вообще, уже какая там, пятая за месяц о литкод?
Почитал оригинал, понятнее все равно не стало. Получается велосипед держит постоянное подключение к интернет? И что будет если просто снять батарею, как система защиты тогда сработает?
Но внешний аккумулятор не даёт константных 12в, и о чем я выше писал, все равно нужен dc-dc преобразователь.
Ну медицину по сериалу Доктор Хаус тоже не выучить. А чужой код, ясно дело, надо не по диагонали читать. Хотя свой можно вполне)
Это, кстати, отличное наблюдение. Если бы это было моё казино, я бы после каждого броска менял бы монетку игроку. Корректнее было бы так, выложить тысячу монет на стол, пусть следующую выбирает сам.
"Пренебрежимо мала" это оно и есть, откройте любое определение. Это то, что можно считать нулем (исключая построения, где это "пренебрежимо малое" испольузется в математическом анализе, ну и собственно, чтобы оно стало чем-то существенным его нужно домножить на что-то "практически" бесконечное), а значит на практике можно считать невозможным в принципе :)
Поизучал самые невероятные истории этого мира, к сожалению большинство из них выглядят совсем уж мифами и легендами, но из чего-то более менее достоверного самое производящее впечатление - это история Роя Салливана. В него молния попала аж 7 раз за жизнь, а умер он по другим причинам. Википедия оценивает эту вероятность в 2^-80 (но они как-то совсем не старались считать). У меня если учесть все все-таки зависимые события получилось 2^-60 и это правда офигеть какое редкое событие. А из других историй даже близко к 2^-40 уже ничего не нашел. А вот около 2^-30 да, так бывает, людей-то много, все что-то делают, событий ого-го как много, вот что-то иногда и происходит почти феноменальное.
А вообще только сейчас заметил, что вы про 120 говорите в контексте орлов и решек, но 10^120 это в переводе на игру в монетку 2^399. Так вот между 2^-60 (и это самое редкое из всех известных редких событий в мире, реже только что-то из космологии, но там сложнее с пруфами) и 2^-399 есть немноожечко разницы.
В этом случае и без зеро все прекрасно у казино. Если вступительный взнос больше 20 рублей (а я замахнулся аж на 1024) в абсолютном большинстве практических случаев казино будет в существенном плюсе.
Я статью читал :) Недостаточно связи, относительно той же задачи о Кёнингсбергских мостах. Намек был на то, что быть может, в Санкт-Петербурге были какие-то характерные (уникальные?) игры, похожие на несколько описанных, что надоумило Бернулли об этих играх подумать. А так, немало кто еще работал в СПбГУ и среди их работ находились куда более парадоксальные вещи.