Шаг вперёд: верить тому кто тщательно изучил и не обруган другими кто тщательно изучил.
Шаг назад: верить пересказу мнения тех кто тщательно изучил и не обруган другими кто тщательно изучил.
...
Заблудиться: потерять связь, восходящую к "тщательно изучить", и считать что есть только равноправные мнения людей и собственные глаза. Нет, не равноправные. "Может быть неправдой" подразумевает вероятность, она может быть сильно разной на основе чего-то изученного.
На практике большинство бредовых идей в нашем меметическом пространстве бредовы очевидно. Даже без каких-то сложных социальных графов: опровергатели теории относительности путаются в школьной физике, носители грандиозных идей о возникновении человека не знают анатомии, etc.
На вопрос "чем вы верующие безусловно в круглость земли отличаетесь от тех, кто верит в то, что она плоская" в основном обижаются. Говорят, что они верят в правильное, а плоскоземельцы в неправильное...
И таки-правы, нет? У стратегии "сразу (a priori) иметь правильные убеждения и не заниматься обработкой свидетельств" есть плюсы, особенно по сравнению со стратегией "начать с правильных убеждений, налажать в анализе свидетельств и придти к неправильным".
Даже "классические" курсы со временем меняются (скажем, определение предела через фильтры). А есть ещё приоритеты: что программистам неплохо бы прочитать основы квантовой механики, что численная оптимизация где-то стала важнее дифуров, etc. Скажем, мне в своё время читали отдельную лекцию про углы Эйлера. Сама теория, абстрактно, осталась, но её актуальность для программистов заметно снизилась.
Как бывший олимпиадник, замечаю что лично у меня такого правила не было, ближайшее к нему "если в задаче А затык, реши пока задачу Б, может потом придут умные мысли". Вообще обычно на олимпиаде предполагается что участник напишет что-то осмысленное про все задачи (ну, если он претендует на хороший результат).
Но разработчики TrapC уверяют, что их компилятор минимизирует накладные расходы, выполняя большинство проверок во время компиляции, а не работы программы.
А это как, простите? В этих искусственных примерах - верю, но в них и любой линтер вроде cppcheck ругнётся. А если у меня в функцию передан указатель на начало массива и из совершенно другой переменной выводится его длина, то компилятор же хрен докажет что длина корректная, это нужно анализировать всю программу.
отсутствуют макросы: упрощение синтаксиса и устранение ошибок, связанных с их использованием;
Замена того что делалось макросами на примерно эквивалентные им шаблоны упростит синтаксис? Ну-ну.
Но (код) сохраняет высокую производительность благодаря оптимизации работы компилятора.
Какой-то словесный салат. Работающий эффективно компилятор и компилятор, порождающий эффективный код - это очевидно разные вещи. "Автоматически освобождает память" - программа/среда исполнения, а не компилятор. Если компилятор вставил в код проверку, а не надо ли "автоматически" освободить память - эта проверка съела минимум одну ассемблерную инструкцию, чудес не будет. (А в многопоточной программе такие проверки на произвольную память делать больно, многопоточные структуры стараются разнести во времени работу с данными и выделение памяти.)
При каких-то условиях (не знаю могу хорошо сформулировать каких, не тестировщик) ссылка на комментарии (с /comments/) не позволяет видеть текст поста, в то время как ссылка на пост при прокрутке вниз отображает комментарии.
Желание получить 99/100% времени и что-нибудь хорошее по памяти понятно, но не должно быть частью использования LeetCode как инструмента отбора кандидатов. Если вас мало интересует оптимизация - потому что интересует мало и нефиг отбирать людей по тому что вас интересует мало, если вас сильно интересует оптимизация - потому что нормальная оптимизация делается профилировщиком, а не на глаз. Опять же, результаты LeetCode не отличаются хорошей повторяемостью, особенно по памяти.
Не существует идеала, но можно делать лучше. В исходном описании задачи FizzBuzz для собеседований подчёркивается, что её суть не в
Кандидатам даётся функциональная задача, и они должны выработать идеальное решение.
а в том чтобы человек произвёл на свет хоть какое-нибудь решение. (Замечу что стандарты именно LeetCode на большинстве задач тоже очень мягкие: вы можете написать сильно неоптимальный код и он всё ещё впишется в ограничения.)
Затем, задачи должны быть неожиданными. В частности, даже для HR выглядит несложным попросить программистов компании написать три-четыре элементарных задачи с нуля вместо извлечения их из базы. Это заведомо уберёт проблему
Как насчёт разницы между кандидатами, уже встречавшими эту задачу викторины, и теми, кто ещё её не встречал?
1) батарея автоматических тестов по прошлым багам является инструментом защиты от регрессий и, по совместительству, хранилищем странных краевых случаев;
2) писанный протокол ручного тестирования позволяет быть уверенным что по крайней мере функциональность основных, оптимистичных путей выполнения не сломана совсем;
С моей точки зрения это вполне себе практически полезные, достижимые разумными усилиями гарантии.
Если есть 1) "старшие товарищи" и 2) способность сказать "возможно тут проблема" вместо двадцати железобетонных аргументов "это так и надо" (к сожалению, она есть не у всех), то хорошо. А если нет ни того ни другого, то приходится рекомендовать клиентам использовать Firefox, потому что приложение кушает гигабайт в десять минут, а ответственный за фронт программист считает что так и надо.
Я могу быть пристрастен, лично мне как раз было неплохим отвлечением поупихивать вчерашний LeetCode в 7 мс времени, но от полного игнора производительности я проблемы в задачах за которые платят деньги вижу достаточно регулярно.
И в реальном энтерпрайзе редко заморачиваешься, например, производительностью.
Моё развлечение прошлой недели: попытки отлаживать код, исполнение которого занимает 18 часов. После пары часов медитации с инструментами анализа, без изменения базового алгоритма, время уменьшается до 75 минут. Да, это относительно экзотичный сценарий, но не то чтобы нулевой.
А самое главное, как раз если в норме команда разработки "не заморачивается" производительностью, то оценка асимптотик должна быть на уровне спинного мозга: логика "если окажется медленно, поправим" работает только если кто-то post factum тратит время и силы на оценку не медленно ли оно. А без этого отдел маркетинга поможет клиентам свыкнуться с мыслью что с этой скоростью надо жить, и мир в целом станет немного хуже.
Я всегда понимал эту задачу как упражнение на рефлексию над моделями. Достаточно ли того упрощения реального люка которое у меня в голове? Какие особенности я забыл?
Реально я видел и квадратные люки крышки, и я довольно сильно ожидаю что даже такую крышку в закрываемое ей отверстие вы нарочно-то замучаетесь просовывать, с шестиугольной миссия становится практически невыполнима (потому что а) крышка толстая и б) она закрывает люк потому что размер дырки меньше размера крышки, она лежит на "полочке"; численное соотношение между этими параметрами при котором задача для шестиугольника становится нерешаемой даже теоретически читатель может вывести самостоятельно, для люка метрового диаметра это единицы сантиметров).
Я в основном хотел обратить внимание что ответы даже в хорошем случае показывают не "как кандидат мыслит", а некоторую сумму "как он мыслит" + "как он вербально рефлексирует" + "как у него получается вести себя в обстановке собеседования".
Если вас как раз интересует что-то близкое к этой сумме, то и хорошо. Но это не универсальное предпочтение.
Оно показывает хорошо если человек а) умеет вслух рассказывать как он мыслит, б) либо умеет это делать в стрессовой ситуации, либо не нервничает на интервью. Проблема в том, что хорошие программисты... не обязательно обладают этими свойствами.
Проблема в том, что "есть 12 типов людей, по 12 знакам Зодиака [забывая про Змееносца]" - это современное попсовое изложение. "Во времена магии и драконов" астрология была большим искусством, всякие натальные карты, привязка ко времени первого крика младенца, etc. Поэтому вряд ли дело в сезонности, просто старое доброе "люди не умеют не искать закономерности".
Затем что истинный вопрос X, на который хочется ответ - "будет ли группе разработки хорошо, если этот человек проработает в ней полгода". Самый очевидный способ ответа требует полгода.
Поэтому все пытаются найти такой индикатор Y, который а) вычислим за разумное время и б) коррелирует с X. Поскольку задача примерно одна и та же, разные агенты приходят к очень похожим индикаторам.
А дальше приходит Гудхарт и говорит "а хрен, в окружении где многие оптимизируют Y, он больше не коррелирует с X". Люди пытаются решать проблему, в первую очередь поиском какого-то волшебного индикатора который бы был устойчив к этому эффекту, "истинного имени" X. Как ни странно, это не получается.
(Как известно людям, соприкасающимся со вступительными экзаменами, более-менее универсальный способ - задавать простые, коррелирующие с желаемой характеристикой, но при этом неожиданные вопросы. Но массовый рынок неизбежно трактует "неожиданный вопрос" как "вопрос из сборника неожиданных вопросов".)
Я усложняю чтобы получить точный ответ. (Не то чтобы сильно усложняю: задаче "посчитать остаток от деления миллиардного числа Фибоначчи на 10*9+7" сто лет в обед, она решается так же.)
Интуитивно, при случайном блуждании вы будете чаще оказываться в узлах степени 3, поэтому ожидание числа вариантов перехода больше среднего арифметического степеней узлов. (Близкий родственник этого наблюдения - "парадокс дружбы" a.k.a. "у ваших друзей в среднем больше друзей чем у вас".) Как можно видеть, в данном случае поправка около 10%, не так уж мало.
Хороший вопрос. Я изначально думал что это из каких-то кавказских легенд.
Поисковик напомнил что есть и русскоязычное ("Мастер и Маргарита"):Но утверждается что на МиМ.
Начало: верить собственным глазам.
Шаг вперёд: верить собственному тщательному изучению.
Шаг назад: верить тому кто тщательно изучил.
Шаг вперёд: верить тому кто тщательно изучил и не обруган другими кто тщательно изучил.
Шаг назад: верить пересказу мнения тех кто тщательно изучил и не обруган другими кто тщательно изучил.
...
Заблудиться: потерять связь, восходящую к "тщательно изучить", и считать что есть только равноправные мнения людей и собственные глаза. Нет, не равноправные. "Может быть неправдой" подразумевает вероятность, она может быть сильно разной на основе чего-то изученного.
На практике большинство бредовых идей в нашем меметическом пространстве бредовы очевидно. Даже без каких-то сложных социальных графов: опровергатели теории относительности путаются в школьной физике, носители грандиозных идей о возникновении человека не знают анатомии, etc.
И таки-правы, нет? У стратегии "сразу (a priori) иметь правильные убеждения и не заниматься обработкой свидетельств" есть плюсы, особенно по сравнению со стратегией "начать с правильных убеждений, налажать в анализе свидетельств и придти к неправильным".
Даже "классические" курсы со временем меняются (скажем, определение предела через фильтры). А есть ещё приоритеты: что программистам неплохо бы прочитать основы квантовой механики, что численная оптимизация где-то стала важнее дифуров, etc.
Скажем, мне в своё время читали отдельную лекцию про углы Эйлера. Сама теория, абстрактно, осталась, но её актуальность для программистов заметно снизилась.
Как бывший олимпиадник, замечаю что лично у меня такого правила не было, ближайшее к нему "если в задаче А затык, реши пока задачу Б, может потом придут умные мысли". Вообще обычно на олимпиаде предполагается что участник напишет что-то осмысленное про все задачи (ну, если он претендует на хороший результат).
То есть просто лжи вам мало, хотите добавить ещё и ложь о том что Х "казнён за лож гражданам"?
А это как, простите? В этих искусственных примерах - верю, но в них и любой линтер вроде cppcheck ругнётся. А если у меня в функцию передан указатель на начало массива и из совершенно другой переменной выводится его длина, то компилятор же хрен докажет что длина корректная, это нужно анализировать всю программу.
Замена того что делалось макросами на примерно эквивалентные им шаблоны упростит синтаксис? Ну-ну.
Какой-то словесный салат. Работающий эффективно компилятор и компилятор, порождающий эффективный код - это очевидно разные вещи. "Автоматически освобождает память" - программа/среда исполнения, а не компилятор. Если компилятор вставил в код проверку, а не надо ли "автоматически" освободить память - эта проверка съела минимум одну ассемблерную инструкцию, чудес не будет. (А в многопоточной программе такие проверки на произвольную память делать больно, многопоточные структуры стараются разнести во времени работу с данными и выделение памяти.)
При каких-то условиях (не
знаюмогу хорошо сформулировать каких, не тестировщик) ссылка на комментарии (с/comments/) не позволяет видеть текст поста, в то время как ссылка на пост при прокрутке вниз отображает комментарии.Желание получить 99/100% времени и что-нибудь хорошее по памяти понятно, но не должно быть частью использования LeetCode как инструмента отбора кандидатов. Если вас мало интересует оптимизация - потому что интересует мало и нефиг отбирать людей по тому что вас интересует мало, если вас сильно интересует оптимизация - потому что нормальная оптимизация делается профилировщиком, а не на глаз. Опять же, результаты LeetCode не отличаются хорошей повторяемостью, особенно по памяти.
Не существует идеала, но можно делать лучше. В исходном описании задачи FizzBuzz для собеседований подчёркивается, что её суть не в
а в том чтобы человек произвёл на свет хоть какое-нибудь решение. (Замечу что стандарты именно LeetCode на большинстве задач тоже очень мягкие: вы можете написать сильно неоптимальный код и он всё ещё впишется в ограничения.)
Затем, задачи должны быть неожиданными. В частности, даже для HR выглядит несложным попросить программистов компании написать три-четыре элементарных задачи с нуля вместо извлечения их из базы. Это заведомо уберёт проблему
Как минимум:
1) батарея автоматических тестов по прошлым багам является инструментом защиты от регрессий и, по совместительству, хранилищем странных краевых случаев;
2) писанный протокол ручного тестирования позволяет быть уверенным что по крайней мере функциональность основных, оптимистичных путей выполнения не сломана совсем;
С моей точки зрения это вполне себе практически полезные, достижимые разумными усилиями гарантии.
Если есть 1) "старшие товарищи" и 2) способность сказать "возможно тут проблема" вместо двадцати железобетонных аргументов "это так и надо" (к сожалению, она есть не у всех), то хорошо. А если нет ни того ни другого, то приходится рекомендовать клиентам использовать Firefox, потому что приложение кушает гигабайт в десять минут, а ответственный за фронт программист считает что так и надо.
Я могу быть пристрастен, лично мне как раз было неплохим отвлечением поупихивать вчерашний LeetCode в 7 мс времени, но от полного игнора производительности я проблемы в задачах за которые платят деньги вижу достаточно регулярно.
Моё развлечение прошлой недели: попытки отлаживать код, исполнение которого занимает 18 часов. После пары часов медитации с инструментами анализа, без изменения базового алгоритма, время уменьшается до 75 минут. Да, это относительно экзотичный сценарий, но не то чтобы нулевой.
А самое главное, как раз если в норме команда разработки "не заморачивается" производительностью, то оценка асимптотик должна быть на уровне спинного мозга: логика "если окажется медленно, поправим" работает только если кто-то post factum тратит время и силы на оценку не медленно ли оно. А без этого отдел маркетинга поможет клиентам свыкнуться с мыслью что с этой скоростью надо жить, и мир в целом станет немного хуже.
Я всегда понимал эту задачу как упражнение на рефлексию над моделями. Достаточно ли того упрощения реального люка которое у меня в голове? Какие особенности я забыл?
Реально я видел и квадратные
люкикрышки, и я довольно сильно ожидаю что даже такую крышку в закрываемое ей отверстие вы нарочно-то замучаетесь просовывать, с шестиугольной миссия становится практически невыполнима (потому что а) крышка толстая и б) она закрывает люк потому что размер дырки меньше размера крышки, она лежит на "полочке"; численное соотношение между этими параметрами при котором задача для шестиугольника становится нерешаемой даже теоретически читатель может вывести самостоятельно, для люка метрового диаметра это единицы сантиметров).Я в основном хотел обратить внимание что ответы даже в хорошем случае показывают не "как кандидат мыслит", а некоторую сумму "как он мыслит" + "как он вербально рефлексирует" + "как у него получается вести себя в обстановке собеседования".
Если вас как раз интересует что-то близкое к этой сумме, то и хорошо. Но это не универсальное предпочтение.
Оно показывает хорошо если человек а) умеет вслух рассказывать как он мыслит, б) либо умеет это делать в стрессовой ситуации, либо не нервничает на интервью. Проблема в том, что хорошие программисты... не обязательно обладают этими свойствами.
Проблема в том, что "есть 12 типов людей, по 12 знакам Зодиака [забывая про Змееносца]" - это современное попсовое изложение. "Во времена магии и драконов" астрология была большим искусством, всякие натальные карты, привязка ко времени первого крика младенца, etc. Поэтому вряд ли дело в сезонности, просто старое доброе "люди не умеют не искать закономерности".
Затем что истинный вопрос X, на который хочется ответ - "будет ли группе разработки хорошо, если этот человек проработает в ней полгода". Самый очевидный способ ответа требует полгода.
Поэтому все пытаются найти такой индикатор Y, который а) вычислим за разумное время и б) коррелирует с X. Поскольку задача примерно одна и та же, разные агенты приходят к очень похожим индикаторам.
А дальше приходит Гудхарт и говорит "а хрен, в окружении где многие оптимизируют Y, он больше не коррелирует с X". Люди пытаются решать проблему, в первую очередь поиском какого-то волшебного индикатора который бы был устойчив к этому эффекту, "истинного имени" X. Как ни странно, это не получается.
(Как известно людям, соприкасающимся со вступительными экзаменами, более-менее универсальный способ - задавать простые, коррелирующие с желаемой характеристикой, но при этом неожиданные вопросы. Но массовый рынок неизбежно трактует "неожиданный вопрос" как "вопрос из сборника неожиданных вопросов".)
Я усложняю чтобы получить точный ответ. (Не то чтобы сильно усложняю: задаче "посчитать остаток от деления миллиардного числа Фибоначчи на 10*9+7" сто лет в обед, она решается так же.)
Интуитивно, при случайном блуждании вы будете чаще оказываться в узлах степени 3, поэтому ожидание числа вариантов перехода больше среднего арифметического степеней узлов. (Близкий родственник этого наблюдения - "парадокс дружбы" a.k.a. "у ваших друзей в среднем больше друзей чем у вас".) Как можно видеть, в данном случае поправка около 10%, не так уж мало.
Максимальный корень уравнения λ^6 - λ^5 - 7 λ^4 + 4 λ^3 + 14 λ^2 - 4 λ - 8 = 0
Аналитически это (1 + √5 + √(38+2√5))/4.