Не вижу в этом ничего плохого. 10 лет — вообще не срок для инженерной культуры и ее формирования. Медицине, например, понадобилось условно триста лет на то, чтобы договориться о базовой гигиене: мытью рук перед операцией, поддержке инстурментов в чистом состоянии, использованию специальной одежды и специальных мест. Это долгий и мучительный процесс — и он идет вперед.
Ну вот а мне хочется видеть рядом людей, которые в первую очередь умеют думать. Потом еще раз думать. А потом только писать код, отвлекаясь между делом на хорошие книги или оперный театр. Мой жизненный опыт показывает, что такие кадры справляются с задачами гораздо лучше, если речь о долгосрочной перспективе. Но опять же, вопрос метрики, я согласен.
Правильный вопрос, который нужно задать себе — как вообще они попыдают на собеседование? Что не так с предварительным отсевом? И как повысить его качество?
На самом деле вы не правы. Смысл в них уверенно стремится к нулю. Если с этих вопросов вы начинаете собеседование с человеком, который претенудет на роль senior или даже middle, то по моему мнению — вы просто плохой интервьюер. Мало того, что вы тратите свое время, так еще и чужое. Начинать нужно с вопросов, где кандидату «есть где развернуться». В качестве примера, это может быть «назови основные причины, почему на твой взгляд ООП — это плохо?» или «какие вопросы и в какой последовательности ты задаешь себе, когда проектируешь фреймворк с нуля?», или «какие конкретно выводы ты сделал из последних трех прочитанных тобой книг и как они изменили твое повседневное поведение?» — что-нибудь в таком духе. На такие вопросы нет однозначно-правильных ответов и это-то и нужно. А вопросы в стиле «как работает сборщик мусора?» или «как рабоает LINQ?» — это, по крайней мере для меня, индикатор безвыходной тупиковости. Если вам пришлось докатиться до них, чтобы поддерживать беседу, то интервью имеет смысл просто прекратить: кандидат явно не подходит. Исключения есть: когда конкретный вопрос выражает вполне конкретную боль вполне конкретного проекта (или команды) и нужен именно такой человек, который сможет с этой болью жить или не усугублять ее как минимум. Но такие ситуации — редки.
Как раз тем и отличаются, что все необходимое собрано в одной главе. Более того, часто достаточно просто пробежаться глазами по оглавлению, чтобы отметить для себя наиболее вероятные варианты. Да и потом — стэковерфлоу тоже нужно прочитать, осознать и адаптировать решение под свою задачу. Копипаст 1 к 1 редко когда сработает.
В конце-концов, есть и другие инженерные направления помимо софта. И там справочники очень даже в ходу.
Я все таки с этим не соглашусь. Математик — это математик. И далеко не каждый математик может быть еще и хорошим программистом, обратное тоже справедливо.
Крайне странные вопросы, если честно. Можете еще показать кандидату квадрат Малевича и спросить, что он об этом думает. Как это помогает решить ту задачу, которая стоит перед интервьювером?
Есть еще хороший метод, которым я пользуюсь сам: попросить человека дать профессиональные советы самому себе, скажем, 5 лет назад. Эффект примерно такой же.
Вы не там ищете дуальность. Обратная функция — это очень частный случай дуальной функции. Дуальность, о которой пишу я, это именно дуальность на уровне стрелки (откуда она «выходит» и куда она «входит» — и не более того). Такая дуальность не предполагает никаких решений никаких уравнений; в том числе, биекция (она же «взаимо однозначная» связь) не является необходимым условием.
Математически говоря, сигнатуру t -> () можно задать только единственным образом: по определению, () не может быть пустым множеством; а вот «синглтоном» — т.е. множеством с одним-единственным элементом — может быть вполне. Из любого множества существует одна и только одна такая функция: попробуйте сами определить две разных и убедитесь, что вы получите одну и ту же.
MoveNext' :: Bool -> () это промежуточная версия. Чуть пониже был абзац о том, что как раз этот (промежуточный) результат дуальности и вызывает диссонанс, который я, видимо, не очень доступно объяснил.
Смысл в том, что бинарная неопределенность теряется, поэтому boolean не нужен: речь о «функции без параметров» (антиматематическое определение, но понятное программистам).
Если до сих пор не ясно — задайте вопрос поточнее, я постараюсь дать более развернутый ответ.
Это, конечно, совершенно немыслимый подход для крупного софта. Если над проектом работают хотя бы 10 человек хотя бы в двух разных городах — предлагаемый подход гарантированно ведет в тупик. Во-первых, в команде ни у кого никогда не бывает равное «количество» знаний — не только сугубо профессиональных (паттерны — ООПшные, ФПшные, теория сложности, знание фундаментальной математики и конкретных рантаймов и языков программирования в привязке к конкретной операционной системе), но и «бизнес»-знаний — в первую очередь, понимание дальних перспектив сервиса, финансовой модели (на чем делаются деньги) и возможных (резких) изменений в последней. С таким разнобоем в стартовых условиях, люди просто объективно не могу «на равных» участвовать в принятии судьбоносных решений, не упоминая уже о том, что это предполагает и некоторую ответственность (большинство людей ее избегают или стремятся переложить на плечи соседа, человеческая природа — еще один фактор, о котором не пишет автор).
Поэтому на деле — архитектура всегда была и будет уделом немногих. Они будут разрабатывать framework-like core-библиотеки, распространять их через ту или иную систему управления зависимости типа nuget, npm, pip, по-возможности снабжая код хорошими комментариями и сопроводительными описаниями где-то на confluence. Еще хорошо бы, чтобы все изменения в этих библиотеках проходили через них на merge request'ах (что тоже далеко не общая практика — такие люди часто очень востребованы и у них просто нет времени уследить за всем, иначе небольшие по объему MR могут висеть неделями, что круто стопорит общий процесс разработки и в глазах менеджмента выглядит как сигнал к более отчаянным действиям). Остальное же — неизбежно будет с примесью шумов: неверные структуры данных, заведомо тупиковые алгоритмы, крайне неудачные API интерфейсов или полное их отсутствие, просто дерьмокод: все это попадает в проект не потому что нет архитектуры, тонн UML-диаграм или благословения РПЦ, а вследствие определенного уровня развития определенных разработчиков. Караван всегда идет со скоростью самого медленного верблюда.
Теперь еще немножко жизненного опыта. За мою карьеру, мои идеи заворачивали не раз. Я предлагаю гораздо более красивые архитектурные решения; пользуясь теорией сложности, показывал их значительное превосходство по сравнению с существующим подходом; демонстрировал готовые прототипы с бенчмарками; показывал научные работы уровня PhD (не мои, конечно — те, которые в свободном доступе), где эти решения обсуждались с теоретической стороны и бла-бла-бла. 95% — натыкалось на полнейшее непонимание. Либо от этого отказывались еще на этапе предварительных обсуждений и демонстрации демо, либо впоследствии делали git revert: потому что «коллегам было нипанятна». Люди в большинстве своем весьма аморфные и нелюбознательные существа и с этим приходится считаться.
Еще раз главный вывод — караван всегда идет со скоростью самого медленного верблюда. А за быстрых верблюдов нужно дорого платить.
Насчет семантики Хаскеля — бесспорно. Но хотелось просто удержать внимание читателя на сигнатурах, пренебрегая по ходу некоторыми вещами типа IO. Сначала думал держаться чисто математической нотации, но Хаскель по сути так и делает.
В конце-концов, есть и другие инженерные направления помимо софта. И там справочники очень даже в ходу.
Математически говоря, сигнатуру t -> () можно задать только единственным образом: по определению, () не может быть пустым множеством; а вот «синглтоном» — т.е. множеством с одним-единственным элементом — может быть вполне. Из любого множества существует одна и только одна такая функция: попробуйте сами определить две разных и убедитесь, что вы получите одну и ту же.
Смысл в том, что бинарная неопределенность теряется, поэтому boolean не нужен: речь о «функции без параметров» (антиматематическое определение, но понятное программистам).
Если до сих пор не ясно — задайте вопрос поточнее, я постараюсь дать более развернутый ответ.
Поэтому на деле — архитектура всегда была и будет уделом немногих. Они будут разрабатывать framework-like core-библиотеки, распространять их через ту или иную систему управления зависимости типа nuget, npm, pip, по-возможности снабжая код хорошими комментариями и сопроводительными описаниями где-то на confluence. Еще хорошо бы, чтобы все изменения в этих библиотеках проходили через них на merge request'ах (что тоже далеко не общая практика — такие люди часто очень востребованы и у них просто нет времени уследить за всем, иначе небольшие по объему MR могут висеть неделями, что круто стопорит общий процесс разработки и в глазах менеджмента выглядит как сигнал к более отчаянным действиям). Остальное же — неизбежно будет с примесью шумов: неверные структуры данных, заведомо тупиковые алгоритмы, крайне неудачные API интерфейсов или полное их отсутствие, просто дерьмокод: все это попадает в проект не потому что нет архитектуры, тонн UML-диаграм или благословения РПЦ, а вследствие определенного уровня развития определенных разработчиков. Караван всегда идет со скоростью самого медленного верблюда.
Теперь еще немножко жизненного опыта. За мою карьеру, мои идеи заворачивали не раз. Я предлагаю гораздо более красивые архитектурные решения; пользуясь теорией сложности, показывал их значительное превосходство по сравнению с существующим подходом; демонстрировал готовые прототипы с бенчмарками; показывал научные работы уровня PhD (не мои, конечно — те, которые в свободном доступе), где эти решения обсуждались с теоретической стороны и бла-бла-бла. 95% — натыкалось на полнейшее непонимание. Либо от этого отказывались еще на этапе предварительных обсуждений и демонстрации демо, либо впоследствии делали git revert: потому что «коллегам было нипанятна». Люди в большинстве своем весьма аморфные и нелюбознательные существа и с этим приходится считаться.
Еще раз главный вывод — караван всегда идет со скоростью самого медленного верблюда. А за быстрых верблюдов нужно дорого платить.
Спасибо за отзыв!