Не существует идеала, но можно делать лучше. В исходном описании задачи FizzBuzz для собеседований подчёркивается, что её суть не в
Кандидатам даётся функциональная задача, и они должны выработать идеальное решение.
а в том чтобы человек произвёл на свет хоть какое-нибудь решение. (Замечу что стандарты именно LeetCode на большинстве задач тоже очень мягкие: вы можете написать сильно неоптимальный код и он всё ещё впишется в ограничения.)
Затем, задачи должны быть неожиданными. В частности, даже для HR выглядит несложным попросить программистов компании написать три-четыре элементарных задачи с нуля вместо извлечения их из базы. Это заведомо уберёт проблему
Как насчёт разницы между кандидатами, уже встречавшими эту задачу викторины, и теми, кто ещё её не встречал?
HR может понимать специфику деятельности... несколько превратно.
Сказано: "Наша компания занимается разведением слонопотамов. Вы будете работать над программой мониторинга слонопотамьего здоровья."
На самом деле - вариант А: есть задача анализа слонопотамьих популяций в десяти разных заповедниках, в четырёх из них уже кем-то сделаны свои системы с которыми надо интегрироваться, для остальных шести нужно сделать аналогичное решение и свести всё это в единую систему представления данных.
На самом деле - вариант Б: есть фермы разведения слонопотамов; в промышленном разведении слонопотамов нужна программа, которая учитывает анализы и рекомендует как подстраивать рацион. Решение уже написано, но его надо поддерживать в актуальном состоянии, вносить в его логику поправки на основе новых статей по медицине слонопотамов, добавлять полезные фичи в интерфейс и т.д.
Так вот, 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-7-6, 6-1-8-1-6, 6-1-8-1-8-1-6.
Ну и наконец, можно посмотреть на граф переходов и сообразить решение за логарифмическое время.
В силу симметрии, есть шесть видов кнопок (плюс бесполезная 5): {{0}, {2}, {8}, {1,3}, {4,6}, {7,9}}. Обозначая число ходов начиная с кнопки этого класса за A-F(n), имеем:
A(n+1) = 2*E(n)
B(n+1) = 2*F(n)
C(n+1) = 2*D(n)
D(n+1) = C(n) + E(n)
E(n+1) = A(n) + E(n) + F(n)
F(n+1) = B(n) + E(n)
Это линейное преобразование, размерность пространства 6. Иными словами, результат N преобразований - некоторая матрица в N-ной степени умноженная на единичный вектор. Быстрое возведение в степень справится за O(log(N)), а также можно прикинуть порядок результата за постоянное время по доминирующему собственному значению (~2.43828).
Сценарий "говорится столько не относящейся к делу чуши, что по делу что-то говорить уже неловко" я себе представляю, но в живую в него не попадал. Мой опыт - и описанный отрицательный, и свой положительный - относится к ситуациям когда большинство разговоров так или иначе на тему решаемых задач, а не уводятся в сторону посторонними мемами.
Если что, я признаю что переход на онлайн улучшает общее соотношение сигнал/шум, и это хорошо. Но есть информация, которую по крайней мере некоторое разработчики (минимум я сам) склонны незаметно для себя терять или игнорировать, и при удалённом общении игнорировать её становится проще. С моей точки зрения это заметный минус. Он может перевешиваться другими плюсами, но от этого не перестаёт существовать.
Да, разумеется. Я описываю частный пример, наблюдавшийся лично мной, и пытаюсь поразмышлять вслух, а почему в данном случае результат плохой, хотя казалось бы, всё что хочется сказать по-прежнему можно сказать.
И мой текущий вывод (и на этом примере, и из моего опыта удалённой работы) - что по сравнению с нахождением в одном здании на одном этаже меняются две вещи:
а) повышаются барьеры для коммуникации - немного, но достаточно чтобы человек который в одном случае что-то бы прокомментировал, во втором сказал про себя "а, не хочется влезать" и промолчал;
б) повышается возможность дополнительно поднять эти барьеры - людям со склонностью игнорировать "странные" комментарии становится проще их игнорировать.
При разбросе по разным городам эти проблемы, понятно, не зависят от того где каждый человек находится в пределах города. Но мне кажется важным обращать на них внимание независимо от размера компании, потому что понимая минусы изменений, их можно пытаться ослабить. Скажем, для себя: если я общаюсь с человеком по ограниченному каналу, мне нужно всегда иметь в виду, что "иллюзия прозрачности" сильнее чем при личном общении.
Мешает то что получается переписка "мне неудобно X" - "X соответствует логике программы" - "я хочу Y" - "опишите всю логику и граничные условия" - "описал" - (проходит две+ недели) - "сделали" - "ваше Y ещё неудобнее X, я просил не это" - "покажите где сделанное отличается от описания".
Если пытаться анализировать происходящее, то на удалёнке проще игнорировать то что не сказано текстом определённого формата. Для команды, которая не склонна рефлексировать "а правильно ли я вообще делаю", это может усиливать довольно нежелательную динамику.
Я согласен с автором что на удалёнке также проще игнорировать бесполезные взаимодействия, но не все взаимодействия неожиданного для разработчика вида являются бесполезными.
Ну вот встречная история сомнительного успеха. Есть две команды, одна в основном в офисе, другая строго на удалёнке. Есть переписки, созвоны и прочий миллион инструментов. Быстрая петля обратной связи, когда пользователь говорит что ему неудобно, разработчик может спросить "а почему ты не используешь вот эту фичу", UX-дизайнер хватается за голову "а что, есть такой сценарий поведения", другой разработчик встревает "эту проблему можно попытаться решить вот так" - у первой команды есть, у второй нет.
Наблюдаемый эффект: удалённая команда хорошо закрывает тикеты, но результатом их трудов неудобно пользоваться. Задачи, по которой нельзя создать хорошо определённый тикет, для разработчиков фактически не существует. Соответственно, возможности для пользователей сказать "мне неудобно, сделайте не так неудобно" фактически не существует тоже, эти мысли не коммуницируются.
Да, на эти грабли наступают не все. Да, если пытаться назначать здесь вину, то можно сказать что это "плохое управление проектом". Но фигня объективно есть.
Не существует идеала, но можно делать лучше. В исходном описании задачи FizzBuzz для собеседований подчёркивается, что её суть не в
а в том чтобы человек произвёл на свет хоть какое-нибудь решение. (Замечу что стандарты именно LeetCode на большинстве задач тоже очень мягкие: вы можете написать сильно неоптимальный код и он всё ещё впишется в ограничения.)
Затем, задачи должны быть неожиданными. В частности, даже для HR выглядит несложным попросить программистов компании написать три-четыре элементарных задачи с нуля вместо извлечения их из базы. Это заведомо уберёт проблему
HR может понимать специфику деятельности... несколько превратно.
Сказано: "Наша компания занимается разведением слонопотамов. Вы будете работать над программой мониторинга слонопотамьего здоровья."
На самом деле - вариант А: есть задача анализа слонопотамьих популяций в десяти разных заповедниках, в четырёх из них уже кем-то сделаны свои системы с которыми надо интегрироваться, для остальных шести нужно сделать аналогичное решение и свести всё это в единую систему представления данных.
На самом деле - вариант Б: есть фермы разведения слонопотамов; в промышленном разведении слонопотамов нужна программа, которая учитывает анализы и рекомендует как подстраивать рацион. Решение уже написано, но его надо поддерживать в актуальном состоянии, вносить в его логику поправки на основе новых статей по медицине слонопотамов, добавлять полезные фичи в интерфейс и т.д.
Так вот, 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.
Я выше посчитал (с помощью Wolfram Alpha), основание чуть больше: 2.43828 ~ 22/9.
Не существует, хотя бы потому что мы можем разворачиваться: 6-7-6, 6-1-8-1-6, 6-1-8-1-8-1-6.
Ну и наконец, можно посмотреть на граф переходов и сообразить решение за логарифмическое время.
В силу симметрии, есть шесть видов кнопок (плюс бесполезная 5): {{0}, {2}, {8}, {1,3}, {4,6}, {7,9}}. Обозначая число ходов начиная с кнопки этого класса за A-F(n), имеем:
A(n+1) = 2*E(n)
B(n+1) = 2*F(n)
C(n+1) = 2*D(n)
D(n+1) = C(n) + E(n)
E(n+1) = A(n) + E(n) + F(n)
F(n+1) = B(n) + E(n)
Это линейное преобразование, размерность пространства 6. Иными словами, результат N преобразований - некоторая матрица в N-ной степени умноженная на единичный вектор. Быстрое возведение в степень справится за O(log(N)), а также можно прикинуть порядок результата за постоянное время по доминирующему собственному значению (~2.43828).
"Гугол" - это вполне "официальное" число, 10^100.
Сценарий "говорится столько не относящейся к делу чуши, что по делу что-то говорить уже неловко" я себе представляю, но в живую в него не попадал. Мой опыт - и описанный отрицательный, и свой положительный - относится к ситуациям когда большинство разговоров так или иначе на тему решаемых задач, а не уводятся в сторону посторонними мемами.
Если что, я признаю что переход на онлайн улучшает общее соотношение сигнал/шум, и это хорошо. Но есть информация, которую по крайней мере некоторое разработчики (минимум я сам) склонны незаметно для себя терять или игнорировать, и при удалённом общении игнорировать её становится проще. С моей точки зрения это заметный минус. Он может перевешиваться другими плюсами, но от этого не перестаёт существовать.
Да, разумеется. Я описываю частный пример, наблюдавшийся лично мной, и пытаюсь поразмышлять вслух, а почему в данном случае результат плохой, хотя казалось бы, всё что хочется сказать по-прежнему можно сказать.
И мой текущий вывод (и на этом примере, и из моего опыта удалённой работы) - что по сравнению с нахождением в одном здании на одном этаже меняются две вещи:
а) повышаются барьеры для коммуникации - немного, но достаточно чтобы человек который в одном случае что-то бы прокомментировал, во втором сказал про себя "а, не хочется влезать" и промолчал;
б) повышается возможность дополнительно поднять эти барьеры - людям со склонностью игнорировать "странные" комментарии становится проще их игнорировать.
При разбросе по разным городам эти проблемы, понятно, не зависят от того где каждый человек находится в пределах города. Но мне кажется важным обращать на них внимание независимо от размера компании, потому что понимая минусы изменений, их можно пытаться ослабить. Скажем, для себя: если я общаюсь с человеком по ограниченному каналу, мне нужно всегда иметь в виду, что "иллюзия прозрачности" сильнее чем при личном общении.
Мешает то что получается переписка "мне неудобно X" - "X соответствует логике программы" - "я хочу Y" - "опишите всю логику и граничные условия" - "описал" - (проходит две+ недели) - "сделали" - "ваше Y ещё неудобнее X, я просил не это" - "покажите где сделанное отличается от описания".
Если пытаться анализировать происходящее, то на удалёнке проще игнорировать то что не сказано текстом определённого формата. Для команды, которая не склонна рефлексировать "а правильно ли я вообще делаю", это может усиливать довольно нежелательную динамику.
Я согласен с автором что на удалёнке также проще игнорировать бесполезные взаимодействия, но не все взаимодействия неожиданного для разработчика вида являются бесполезными.
Ну вот встречная история сомнительного успеха. Есть две команды, одна в основном в офисе, другая строго на удалёнке. Есть переписки, созвоны и прочий миллион инструментов. Быстрая петля обратной связи, когда пользователь говорит что ему неудобно, разработчик может спросить "а почему ты не используешь вот эту фичу", UX-дизайнер хватается за голову "а что, есть такой сценарий поведения", другой разработчик встревает "эту проблему можно попытаться решить вот так" - у первой команды есть, у второй нет.
Наблюдаемый эффект: удалённая команда хорошо закрывает тикеты, но результатом их трудов неудобно пользоваться. Задачи, по которой нельзя создать хорошо определённый тикет, для разработчиков фактически не существует. Соответственно, возможности для пользователей сказать "мне неудобно, сделайте не так неудобно" фактически не существует тоже, эти мысли не коммуницируются.
Да, на эти грабли наступают не все. Да, если пытаться назначать здесь вину, то можно сказать что это "плохое управление проектом". Но фигня объективно есть.