Вместо того чтобы пытаться понять и обьяснить (классическая задача науки) мы делаем сложный черный ящик для предсказаний и уже не пытаемся ничего понять. Разве это не деградация?
Не обобщайте личный опыт на весь мир. На ICML и NIPS (ныне NeurIPS) уже не то что доклады, а целые отдельные секции есть по теме интерпретируемости ML-моделей. И там есть очень даже хорошие результаты, позволяющие даже в нейросетках (пусть пока и не очень сложных) иногда разбираться. Нет никакой деградации, есть научный подход и развитие.
Я правильно понимаю, что вместо создания своего поисковика (что является неподъёмной задачей для всех кроме супер-гигантов) эти несколько организаций решили поездить на самокате Яндекса? А когда Яндекс сказал, что у него своих детей хватает — те обиделись. Для меня это странно: Яндекс же коммерческая организация и работает ради своей выгоды.
Может кто-то пояснить цель претензий и почему у этих организаций вообще есть шанс что-то выиграть в суде?
У шахмат (как настольной игры, в которую играют для удовольствия) есть несколько недостатков:
Нет многопользовательского режима. Когда мы собираемся вчетвером с друзьями, нам хочется играть всем вместе в одну игру. Желательно — не по командам, а каждый сам за себя.
Нет социальной составляющей. В шахматах будет абсурдно звучать предложение «давай ты мне сдашь вот тут пешку, а я тебе вон там?». Во многих настолках есть шанс общаться и договариваться с оппонентами.
Слишком сильно выражена боевая составляющая — не видно ничего кроме неё. По сути игра именно вокруг этого и строится. В очень урезанной форме есть управление ресурсами (каждая фигура — ресурс), но это не сравнится с тем, что происходит в экономических стратегиях. Помимо этого — почти нет возможности в развитии/улучшении своей ситуации без боевого взаимодействия. Нельзя «купить ещё одну ладью» или «вернуть ферзя на пару ходов»
Шахматы — отличная соревновательная дисциплина. Но в качестве игры для развлечения — на любителя.
Для генерации голоса нужен динамик другого уровня, нежели для громкого низкочастотного гула. Помимо этого нужна ещё доп. плата, которая сгенерит аналоговый сигнал для динамика, воспроизводящий заранее записанный (на какой-то носитель) голос. И потребление энергии у этой платы будет тоже нехилое, т.е. время жизни устройства сократится. Поэтому кажется более логичным написать прям на этой штуковине инструкцию.
Нет, дело не в неуверенности в себе, а в понимании принципов действия рынка.
Приведу другую аналогию. Садясь за покерный стол, никто не может быть на 100% уверен, что выиграет. По мат. ожиданию каждый за столом получит одинаковую сумму (при одинаковых силах игроков). Но реально выиграет кто-то один. В данном случае Вася не хочет рисковать и выбирает роль крупье: стабильный заработок, но меньше, чем у победителя. А те, кто покупают его ПО — садятся за стол и играют против других. Могут выиграть, могут проиграть — зависит от них в том числе.
Если Вася при этом говорит, что выиграют все — то он шарлатан. Но эти ребята, которые продавали К1, такого не заявляли. Они показали, что их алгоритм _может_ получать ощутимую прибыль в долгосрочной перспективе (большинство алгоритмов этим не могут похвастаться).
Игра на бирже — это всегда риск. Иногда дисперсия выше, иногда ниже — но риск проиграть есть всегда. Допустим, этот чудо-алгоритм зарабатывает 20% в год, но при этом вариация составляет 30%. Т.е. может проиграть 10%, а может выиграть 50%. Но в среднем +20%.
Программист Вася не хочет рисковать своими деньгами — он хочет стабильный заработок. И поэтому он может продавать свой алгоритм за, например, эквивалент 8%. Тогда и ему удобно (стабильная прибыль), и покупателю — он (по мат. ожиданию) в плюсе на 12%. Для меня, как для программиста, 8% надёжной прибыли (с почти нулевой дисперсией) — лучше, чем 20% прибыли с гигантской дисперсией. Думаю, программист Вася мыслит так же.
Оба игрока должны понимать, что никаких гарантий прибыли от игры на бирже нет и не будет. Просто один проиграл и теперь строит из себя дурачка, мол «мне пообещали беспроигрышную стратегию и вообще обманули». Интересно, если бы он выиграл 20млн — он пошёл бы делиться с создателями К1? Вряд ли.
Гораздо приятнее в данном случае было бы заменить на std::list, которому всё равно, куда происходит вставка (хотя именно в этом случае можно прекрасно видеть, что не надо просто insert использовать. Но это просто пример, не более
Кажется, это неудачный пример, т.к. в этом случае deque подходит лучше: время вставки у него примерно такое же, как у листа, но зато итерация намного быстрее.
Предлагаю рассказать, что делает вот этот (между прочим, очень полезный и важный) класс и привести аналогичный пример из питона, джавы или что там нынче популярно:
Я не знаю наверняка, но выглядит так, будто это сделано чтобы воссоздать поведение boost::optional.
Люди уже привыкли таким образом использовать optional в бусте и не могут проект одним махом перевести с boost::optional на std::optional. Разный принцип работы operator* и ::value() внутри одного большого проекта создаст гораздо больше проблем.
Спасибо, конструктив понравился! Если есть ещё — пишите.
И после того как разберусь с solve(), я вернусь к spam() и egg(). Как реализовать это подход на листочке? Оставлять место? Продумывать заранее?
Я в таких случаях просил дополнительные листы бумаги и на каждом отдельном листе писал конкретную функцию. В случае с доской это сложнее — обычно делил её на несколько частей.
2. Мне нравится итеративный подход, я «думаю кодом», я использую редактор как буфер мыслей, постоянного меняю код, выделяю методы если вижу в них необходимость и т. д., тут ваш листочек тоже не позволит это сделать, извольте сразу писать правильно.
Хочется проверить размер этого буфера. Я почти уверен, что вы в голове не одну строчку держите, а некий блок кода. И чем больше этот блок — тем лучше. Сначала я даю задачу типа «найти максимальный элемент». Кстати, даже с этой задачей уже не все кандидаты справляются (это было для меня открытием). Ну и потом по нарастающей. Есть кандидаты, которые BFS пишут с ходу (не олимпиадники).
3. Меня на собеседованиях иногда просили модифицировать решение, добавить А или Б фичи, с листочком вы тоже лишаете себя этой возможности.
Да, согласен. За всё приходится платить =) Но, если честно, у меня обычно не возникает желание модифицировать задачу по ходу.
4. Когда человек пишет решение в редакторе под присмотром интервьюера, второй может наблюдать за ходом мысли, как и что он исправляет и меняет, что вы увидите в случае листочка? Правильно, как человек сидит и смотрит в одну точку.
Это только в теории. На практике происходит иначе: начиная с мидлов — люди общаются и обсуждают своё решение. По крайней мере, на моём опыте именно так бывает. Если человек сидит и смотрит в точку — либо что-то идёт не так и надо задавать наводящие вопросы, либо человек в раздумьях и он так же сидел бы перед IDE.
С джунами чуть сложнее (они не привыкли проговаривать вслух ход мыслей), но там обычно нет смысла человека мурыжить задачами, достаточно просто пообщаться, т.к. у джуна всё равно опыта особого нет — важно чтобы хотел обучаться и работать.
5. Писать код от руки непривычно, человек уже под стрессом и в неудобной обстановке, так вы еще добавляете один фактор, который мешает, не получая преимуществ кроме вымышленных «думает, перед тем как написать» (wat?).
Так, писать от руки непривычно — согласен, это действительно проблема. А какой фактор добавляю? Не понял.
Итого: собеседование на листочке подходит только для эгоистичных интервьюеров, которые рассматривают собеседования как проверку кандидата на прочность в экстренных условиях, в которых ему не придется работать, а не как равный диалог о будущем кандидата в компании.
Не-не-не, никакой проверки на прочность. Интервью это стресс в любом случае, согласен. Но при чём тут эгоизм? Обычно у меня с кандидатом равный и достаточно свободный диалог (люди порой могут посмеяться над чем-то, или порассуждать на отвлечённые темы — это расслабляет), да и почти все собеседования, в которых мне надо было писать код на бумаге/доске тоже проходили вполне комфортно и я не чувствовал, что со мной общаются «свысока».
а не как равный диалог о будущем кандидата в компании.
Всё же техническое интервью — это не диалог о будущем, а проверка знаний и калибровка уровня кандидата. Диалог о будущем — это к HR'ам.
Пока что я увидел фразу «пережиток прошлого» и ни одного конструктивного аргумента против. О том, что нет смысла — я уже написал, какой в этом смысл и эта практика даёт плоды.
Буду рад прочитать конструктивные аргументы против такого подхода.
Ожидается увидеть то, как человек подходит к написанию кода. Ни разу ещё не было такого, чтобы опытный разработчик после прослушивания задачи сразу начал её писать. Обычно идёт несколько вопросов, размышление/обсуждение, строится решение, продумываются корнер-кейсы и после этого быстро пишется код на бумаге. У джунов (и некоторых мидлов) обычно происходит иначе.
Ровно об этом я и подумал, но решил не писать, т.к. прозвучало бы слишком резко, а я и так вон уже минусов нахватал =)
А так — да, судя по всему многие «комментаторы» не дотягивают по уровню, оттого и не понимают, зачем всё это нужно.
Ваш проект приносит много денег? Стабильно ли он работает, легко ли проходят релизы? И при этом он уже много лет на рынке?
Кажется, на большинство вопросов ответ будет «нет».
Да, программист. Опыт более 10 лет, успел поработать в нескольких крупных (5000+) айтишных организациях, сейчас я Senior SWE в одной из них.
Откуда у программиста детальное знание синтаксиса?
Вы же каждый (рабочий) день код пишете — как иначе?
У сеньеров в голове 10-20 языков, причем многие похожи.
На кой чёрт нужно в одном проекте 10 языков? Это же зоопарк технологий, который нереально поддерживать. На своём опыте в успешных проектах видел не болоее трёх языков одновременно. При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.
Так зачем мне это помнить?
И правда — зачем?.. Я, кажется, писал о том, что придираться к запятым и потерянным скобкам — глупость, мы таким не занимаемся.
На уровне сеньера баги совсем совсем другие:
Не верно продумал архитектуру базовых классов
Согласен, что баги другие. Но как, по-вашему, человек продумает архитектуру сложного объекта, если он даже не может в голове удержать простую программу? Или вы считаете, что каким-то волшебным образом можно решать сложные задачи не умея решать простые?
В тексте вакансии я хочу узнать о самой работе, о функциях, обязанностях и т.п., а не о процессе найма.
просто вы понимаете, что после этого к вам никто не придет на чудесное собеседование
Каким же тогда, по-вашему, образом в Google и Facebook работают тысячи программистов, если «никто не хочет на такие собеседования ходить»? Может проблема в ваших представлениях о том, что должен уметь скилловый разраб?
поэтому и тяните до последнего
Вы намеренно проигнорировали слова о том, что рекрутер всегда предупреждает человека?
Было бы здорово, если бы Вы включали Ваши предпочтения по вайтбордингу и бумажкам в описание вакансии. Сэкономили бы кучу времени себе и таким противникам извращений как я.
В описании вакансии этому не место, но рекрутер всегда предупреждает потенциальных кандидатов об этом.
Не обобщайте личный опыт на весь мир. На ICML и NIPS (ныне NeurIPS) уже не то что доклады, а целые отдельные секции есть по теме интерпретируемости ML-моделей. И там есть очень даже хорошие результаты, позволяющие даже в нейросетках (пусть пока и не очень сложных) иногда разбираться. Нет никакой деградации, есть научный подход и развитие.
Когда-то люди не верили в существование летательных аппаратов тяжелее воздуха.
Может кто-то пояснить цель претензий и почему у этих организаций вообще есть шанс что-то выиграть в суде?
Шахматы — отличная соревновательная дисциплина. Но в качестве игры для развлечения — на любителя.
Приведу другую аналогию. Садясь за покерный стол, никто не может быть на 100% уверен, что выиграет. По мат. ожиданию каждый за столом получит одинаковую сумму (при одинаковых силах игроков). Но реально выиграет кто-то один. В данном случае Вася не хочет рисковать и выбирает роль крупье: стабильный заработок, но меньше, чем у победителя. А те, кто покупают его ПО — садятся за стол и играют против других. Могут выиграть, могут проиграть — зависит от них в том числе.
Если Вася при этом говорит, что выиграют все — то он шарлатан. Но эти ребята, которые продавали К1, такого не заявляли. Они показали, что их алгоритм _может_ получать ощутимую прибыль в долгосрочной перспективе (большинство алгоритмов этим не могут похвастаться).
Программист Вася не хочет рисковать своими деньгами — он хочет стабильный заработок. И поэтому он может продавать свой алгоритм за, например, эквивалент 8%. Тогда и ему удобно (стабильная прибыль), и покупателю — он (по мат. ожиданию) в плюсе на 12%. Для меня, как для программиста, 8% надёжной прибыли (с почти нулевой дисперсией) — лучше, чем 20% прибыли с гигантской дисперсией. Думаю, программист Вася мыслит так же.
Оба игрока должны понимать, что никаких гарантий прибыли от игры на бирже нет и не будет. Просто один проиграл и теперь строит из себя дурачка, мол «мне пообещали беспроигрышную стратегию и вообще обманули». Интересно, если бы он выиграл 20млн — он пошёл бы делиться с создателями К1? Вряд ли.
Кажется, это неудачный пример, т.к. в этом случае deque подходит лучше: время вставки у него примерно такое же, как у листа, но зато итерация намного быстрее.
Минимальный срок оформления патента в России — 6 месяцев, поэтому задержка на полгода будет всегда.
В этих 30 строках кода используется сразу несколько редких фич языка, и без них этот код не стал бы рабочим и полезным.
Люди уже привыкли таким образом использовать optional в бусте и не могут проект одним махом перевести с boost::optional на std::optional. Разный принцип работы operator* и ::value() внутри одного большого проекта создаст гораздо больше проблем.
Я в таких случаях просил дополнительные листы бумаги и на каждом отдельном листе писал конкретную функцию. В случае с доской это сложнее — обычно делил её на несколько частей.
Хочется проверить размер этого буфера. Я почти уверен, что вы в голове не одну строчку держите, а некий блок кода. И чем больше этот блок — тем лучше. Сначала я даю задачу типа «найти максимальный элемент». Кстати, даже с этой задачей уже не все кандидаты справляются (это было для меня открытием). Ну и потом по нарастающей. Есть кандидаты, которые BFS пишут с ходу (не олимпиадники).
Да, согласен. За всё приходится платить =) Но, если честно, у меня обычно не возникает желание модифицировать задачу по ходу.
Это только в теории. На практике происходит иначе: начиная с мидлов — люди общаются и обсуждают своё решение. По крайней мере, на моём опыте именно так бывает. Если человек сидит и смотрит в точку — либо что-то идёт не так и надо задавать наводящие вопросы, либо человек в раздумьях и он так же сидел бы перед IDE.
С джунами чуть сложнее (они не привыкли проговаривать вслух ход мыслей), но там обычно нет смысла человека мурыжить задачами, достаточно просто пообщаться, т.к. у джуна всё равно опыта особого нет — важно чтобы хотел обучаться и работать.
Так, писать от руки непривычно — согласен, это действительно проблема. А какой фактор добавляю? Не понял.
Не-не-не, никакой проверки на прочность. Интервью это стресс в любом случае, согласен. Но при чём тут эгоизм? Обычно у меня с кандидатом равный и достаточно свободный диалог (люди порой могут посмеяться над чем-то, или порассуждать на отвлечённые темы — это расслабляет), да и почти все собеседования, в которых мне надо было писать код на бумаге/доске тоже проходили вполне комфортно и я не чувствовал, что со мной общаются «свысока».
Всё же техническое интервью — это не диалог о будущем, а проверка знаний и калибровка уровня кандидата. Диалог о будущем — это к HR'ам.
Буду рад прочитать конструктивные аргументы против такого подхода.
А так — да, судя по всему многие «комментаторы» не дотягивают по уровню, оттого и не понимают, зачем всё это нужно.
Кажется, на большинство вопросов ответ будет «нет».
Да, программист. Опыт более 10 лет, успел поработать в нескольких крупных (5000+) айтишных организациях, сейчас я Senior SWE в одной из них.
Вы же каждый (рабочий) день код пишете — как иначе?
На кой чёрт нужно в одном проекте 10 языков? Это же зоопарк технологий, который нереально поддерживать. На своём опыте в успешных проектах видел не болоее трёх языков одновременно. При этом ни разу не было такого, чтобы один разраб коммитил сразу на всех трёх языках.
И правда — зачем?.. Я, кажется, писал о том, что придираться к запятым и потерянным скобкам — глупость, мы таким не занимаемся.
Согласен, что баги другие. Но как, по-вашему, человек продумает архитектуру сложного объекта, если он даже не может в голове удержать простую программу? Или вы считаете, что каким-то волшебным образом можно решать сложные задачи не умея решать простые?
В тексте вакансии я хочу узнать о самой работе, о функциях, обязанностях и т.п., а не о процессе найма.
Каким же тогда, по-вашему, образом в Google и Facebook работают тысячи программистов, если «никто не хочет на такие собеседования ходить»? Может проблема в ваших представлениях о том, что должен уметь скилловый разраб?
Вы намеренно проигнорировали слова о том, что рекрутер всегда предупреждает человека?
В описании вакансии этому не место, но рекрутер всегда предупреждает потенциальных кандидатов об этом.