чтобы понимать, что применение многопоточности в разных кейсах может привести как к повышению производительности, так и к потере производительности.
Я бы сказал, что это нужно не понимать, а измерять. Во первых, многопоточность по определению может как замедлить, так и ускорить. Ведь все имеет накладные расходы. А во вторых, измерять, измерять и ещё раз измерять. Невозможно утверждать, что мы добавили многопоточность в наш проект и теперь оно бысирее, не имея таймингов перед изменением и после изменения, для сравнения. Такое утверждение будет просто враньём. Поэтому, понимать не нужно, нужно просто замерить изменение скорости работы и все будет видно.
В книжке "Are you smart enough to work at Google?"
Ой не нужно ориентироваться на гугл. Ваша компания не гугл и вряд ли когда нибудь будет. Это типичный карго культ. Ну а уж ссылаться, в качестве аргумента, на какую-то книгу, какого-то гугла... Тоже мне, истина в последней инстанции.
Вот честно говоря, на мой взгляд, вот это вот онлайновое думанье - так себе штука. Было у меня, показывают экран с кодом и спрашивают, что в нём плохо. У меня от стресса глаза по экрану бегают, ни за что зацепиться не могут. Говорю, ну вот это выглядит странно. Ну вот это при каких-то условиях будет странным. А так, вроде, ничего фатального не замечаю. Наконец мне тыкают пальцем и я восклицаю: ну позвольте, в одном контексте - это плохое, а в других контекстах вообще без разницы, тут всё зависит от деталей, которые мне не известны. Т.ч. в таком вот онлайновом думанье есть минимум две проблемы.
У некоторых людей возникает стресс просто от того, что они находятся рядом с незнакомыми людьми. И кажется мне, что это не является чем-то необычным для программистов. Много среди нас разной степени интравертов и даже в чем-то аутистов.
Всё эти задачи очень субъективны, т.к. у спрашивающего в голове какой-то контекст, а у отвечающего - нет.
И это тоже валидный ответ, на мой взгляд. У кого-то нет таких решений, а у кого-то есть. Всё нормально. Так что Ваш ответ на этот вопрос ничего плохого бы мне не сказал о Вас.
Если позволите, я бы указал здесь ссылку на обсуждение и статью по той же самой теме: Статья
Странно, что в комментарии не набежали доброхоты, доказывающие, что именно знание конкретного event loop им всё о кандидате и говорит, ведь это же основы.
Вот-вот. Мне кажется, основываясь на том, что бы я спросил самого себя, спрашивать имеет смысл:
Расскажите, с какими сложностями вы столкнулись в предыдущих проектах и каким способом вы их преодолели.
Расскажите, какими решениями из предыдущих проектов вы можете гордиться.
Расскажите о решениях, которые вы вынуждены были использовать в предыдущих проектах и почему они вам не нравились и почему вы, всё таки были вынуждены использовать.
Правда тут возникает проблема, если собеседующий менее опытный, чем кандидат.
А вот честно, шут его знает. Я не начинающий программист, с 20+ годами опыта и тем не менее, имею опыт работы проблемы с поиском работы. В том числе и по описанным в статье причинам. Начинающим я могу только в полной мере посочувствовать.
Я ещё раз уточню, для этой задачи - это костыль, по сравнению с языками, где ООП реализован нормально. И я буду вынужден использовать подобный костыль только по той причине, что кто-то решил что ООП устарел и интерфейсов хватит всем. И как важно этой не называй, стратегия-ли, паттерн или ещё какое громкое название, всё равно это останется костылём, по сравнению с языками, где ООП реализовано в полной мере.
Наследование переоценено и заменяется интерфейсами
Не-а, не заменяется. Берём Go. Вот у меня есть тип А, у которого есть метод А1, который что-то делает и вызывает метод А2. Я делаю тип Б, включающий в себя типа А (грубо скажем наследующий), с методом А2 и хочу, что бы при вызове Б.А1(), который будет на самом деле А.А1(), был вызван Б.А2(), а не А.А2(). И не могу этого добиться, без применения костылей, т.к. кто-то решил, что наследование переоценено.
В реальности, продукт - это результат работы десятков/сотен/тысяч человек.
Не всегда. Иногда - это результат работы одного / двух человек. И в этом случае финансовые показатели - это в том числе и показатели работы этих двух землекопов. Да, на короткой дистанции - это может быть просто везение или результат работы сейлзов. Но на протяжении десятка лет - это точно не везение. Потому, что если система не потянет нагрузку - никакие сейлзы не помогут.
не могут начать отвечать на (конкретный) вопрос
Извините, не могу согласиться. Вопрос типа "опишите, как бы вы построили высоконагруженную систему загрузки террабайтных данных" - это совсем не конкретный вопрос.
Вы тоже упорно игнорирует, что для таких людей начать решать задачу - означает, походить и повертеть в руках любимый предмет, прежде, чем в голове оформит я хоть что-то, что можно выразить словами.
Суждение о том хороший специалист или плохой - оценочное.
Что же тут оценочного? Если результат работы такого специалиста приносит компании прибыль, то это вполне объективный показатель.
пока вы выучите фреймворк или библиотеку, когда срочно нужно закрыть багу.
Это какой-то миф. Во первых, мне приходилось исправлять ошибки в проектах, написанных на незнакомом мне языке.
Во вторых, если только что принятый человек в первый же день полезет что-то исправлять, я бы такого по рукам бил, ибо не фиг костылить, пока не изучил архитектуру проекта. А результатом такого изменения 100% будут костыли. И хорошо, если хотя бы следствие бага будет исправленное, а не добавлено ещё 2 новых.
А в конце третьих, кого бы не приняли, минимум месяц этот человек будет вникать в новый проект, прежде, чем сможет что-то осмысленно в нем делать.
По моему опыту, в современном бизнесе вообще все выполняется так, как хочется "Васе", а не так, как нужно бизнесу. Менеджеры свои обязанности "делегировали" и оставили за собой только обязанность получать зарплату / премии. Потом они увольняют последнего человека, знающего X и через несколько месяцев, внезапно, обнаруживают, что как делать X никто не знает. Или, например, обнаруживают, что сервис компании работают на личном аккаунте уволенного разработчика. Оба случая реальны и из моей практики.
Ваше мнение является ошибочным и легко опровергается. Имеется реальный человек, который никакое решение не может выдать в реальном времени. Этот человек разработал и поддерживает систему, приносящую компании доход. Вы действительно продолжите утверждать, что этот человек не является хорошим специалистом, на том основании, что он не может немедленно выдать какое-то решение, без предварительного обдумывания?
команда должна нанять и обучить до требуемого уровня именно вас за миллион денег
Да почему обучить и почему за миллион? Откуда это взялось? Человека с 10-ками лет опыта не нужно обучать. Он сам и вас обучить может и сам обучится, притом бесплатно. Вот мы как раз и пришли к тому, что описано в статье. Видит эдакий "сеньёр" с 5 годами опыта, на собеседовании, человека 20 годами опыта и понимает, что ему самому ещё учиться и учиться. А признаваться в этом не хочется и другим показать страшно.
А легаси - это что-то очень плохое? А если это легаси приносит миллионы долларов? Человек, который 20 лет сидит на саппорте легасей, скорее всего знает и умеет гораздо больше, чем тот, который за 5 лет проект до IPO довёл. Первый опытный специалист, решивший за эти годы множество проблем, походивший по множеству граблей и поддерживающий в рабочем состоянии систему, приносящую компании миллионы долларов. А второй - обыкновенный болтун, навешавший лапши на уши инвесторам, решивший ковать, пока горячо и продать свой проект пока он не успел развалиться.
Т.е. Вы считаете, что специалист с опытом работы 20 лет, которому не пришлось использовать, ну допустим, mongodb, хуже новичка с опытом работы 5 лет, который утверждает (замечу в скобках, всего лишь утверждает, что он работал с mongodb)?
Это я вспоминаю, что начать использовать mongodb у меня не заняло нисколько времени. Ну в самом деле, люди (это я уже не Вам пишу сейчас) . Вы что, считаете, что все эти фреймворки - это какой-то рокет сайнс, которые ну никак нельзя начать использовать, просто прочитав документацию и имея опыт работы с другими фреймворками?
Я бы сказал, что это нужно не понимать, а измерять. Во первых, многопоточность по определению может как замедлить, так и ускорить. Ведь все имеет накладные расходы. А во вторых, измерять, измерять и ещё раз измерять. Невозможно утверждать, что мы добавили многопоточность в наш проект и теперь оно бысирее, не имея таймингов перед изменением и после изменения, для сравнения. Такое утверждение будет просто враньём. Поэтому, понимать не нужно, нужно просто замерить изменение скорости работы и все будет видно.
Ой не нужно ориентироваться на гугл. Ваша компания не гугл и вряд ли когда нибудь будет. Это типичный карго культ. Ну а уж ссылаться, в качестве аргумента, на какую-то книгу, какого-то гугла... Тоже мне, истина в последней инстанции.
Вот честно говоря, на мой взгляд, вот это вот онлайновое думанье - так себе штука. Было у меня, показывают экран с кодом и спрашивают, что в нём плохо. У меня от стресса глаза по экрану бегают, ни за что зацепиться не могут. Говорю, ну вот это выглядит странно. Ну вот это при каких-то условиях будет странным. А так, вроде, ничего фатального не замечаю. Наконец мне тыкают пальцем и я восклицаю: ну позвольте, в одном контексте - это плохое, а в других контекстах вообще без разницы, тут всё зависит от деталей, которые мне не известны. Т.ч. в таком вот онлайновом думанье есть минимум две проблемы.
У некоторых людей возникает стресс просто от того, что они находятся рядом с незнакомыми людьми. И кажется мне, что это не является чем-то необычным для программистов. Много среди нас разной степени интравертов и даже в чем-то аутистов.
Всё эти задачи очень субъективны, т.к. у спрашивающего в голове какой-то контекст, а у отвечающего - нет.
И это тоже валидный ответ, на мой взгляд. У кого-то нет таких решений, а у кого-то есть. Всё нормально. Так что Ваш ответ на этот вопрос ничего плохого бы мне не сказал о Вас.
Если позволите, я бы указал здесь ссылку на обсуждение и статью по той же самой теме: Статья
Странно, что в комментарии не набежали доброхоты, доказывающие, что именно знание конкретного event loop им всё о кандидате и говорит, ведь это же основы.
Вот-вот. Мне кажется, основываясь на том, что бы я спросил самого себя, спрашивать имеет смысл:
Расскажите, с какими сложностями вы столкнулись в предыдущих проектах и каким способом вы их преодолели.
Расскажите, какими решениями из предыдущих проектов вы можете гордиться.
Расскажите о решениях, которые вы вынуждены были использовать в предыдущих проектах и почему они вам не нравились и почему вы, всё таки были вынуждены использовать.
Правда тут возникает проблема, если собеседующий менее опытный, чем кандидат.
А вот честно, шут его знает. Я не начинающий программист, с 20+ годами опыта и тем не менее, имею опыт работы проблемы с поиском работы. В том числе и по описанным в статье причинам. Начинающим я могу только в полной мере посочувствовать.
Я ещё раз уточню, для этой задачи - это костыль, по сравнению с языками, где ООП реализован нормально. И я буду вынужден использовать подобный костыль только по той причине, что кто-то решил что ООП устарел и интерфейсов хватит всем. И как важно этой не называй, стратегия-ли, паттерн или ещё какое громкое название, всё равно это останется костылём, по сравнению с языками, где ООП реализовано в полной мере.
Полностью согласен с Вашей статьёй и ситуацию вижу так же. Всё ещё усугубляется вот этим
В результате, врать вынуждены все. Иначе те, кто не будет врать - оказываются в проигрыше.
Можно. Сделать вообще всё можно и на чём угодно. Но я то написал:
Не-а, не заменяется. Берём Go. Вот у меня есть тип А, у которого есть метод А1, который что-то делает и вызывает метод А2. Я делаю тип Б, включающий в себя типа А (грубо скажем наследующий), с методом А2 и хочу, что бы при вызове Б.А1(), который будет на самом деле А.А1(), был вызван Б.А2(), а не А.А2(). И не могу этого добиться, без применения костылей, т.к. кто-то решил, что наследование переоценено.
Не всегда. Иногда - это результат работы одного / двух человек. И в этом случае финансовые показатели - это в том числе и показатели работы этих двух землекопов. Да, на короткой дистанции - это может быть просто везение или результат работы сейлзов. Но на протяжении десятка лет - это точно не везение. Потому, что если система не потянет нагрузку - никакие сейлзы не помогут.
Извините, не могу согласиться. Вопрос типа "опишите, как бы вы построили высоконагруженную систему загрузки террабайтных данных" - это совсем не конкретный вопрос.
Вы тоже упорно игнорирует, что для таких людей начать решать задачу - означает, походить и повертеть в руках любимый предмет, прежде, чем в голове оформит я хоть что-то, что можно выразить словами.
Что же тут оценочного? Если результат работы такого специалиста приносит компании прибыль, то это вполне объективный показатель.
Это какой-то миф. Во первых, мне приходилось исправлять ошибки в проектах, написанных на незнакомом мне языке.
Во вторых, если только что принятый человек в первый же день полезет что-то исправлять, я бы такого по рукам бил, ибо не фиг костылить, пока не изучил архитектуру проекта. А результатом такого изменения 100% будут костыли. И хорошо, если хотя бы следствие бага будет исправленное, а не добавлено ещё 2 новых.
А в конце третьих, кого бы не приняли, минимум месяц этот человек будет вникать в новый проект, прежде, чем сможет что-то осмысленно в нем делать.
По моему опыту, в современном бизнесе вообще все выполняется так, как хочется "Васе", а не так, как нужно бизнесу. Менеджеры свои обязанности "делегировали" и оставили за собой только обязанность получать зарплату / премии. Потом они увольняют последнего человека, знающего X и через несколько месяцев, внезапно, обнаруживают, что как делать X никто не знает. Или, например, обнаруживают, что сервис компании работают на личном аккаунте уволенного разработчика. Оба случая реальны и из моей практики.
Ваше мнение является ошибочным и легко опровергается. Имеется реальный человек, который никакое решение не может выдать в реальном времени. Этот человек разработал и поддерживает систему, приносящую компании доход. Вы действительно продолжите утверждать, что этот человек не является хорошим специалистом, на том основании, что он не может немедленно выдать какое-то решение, без предварительного обдумывания?
Ловите эффективного менеджера. Очень безаппеляционное утверждение.
Да почему обучить и почему за миллион? Откуда это взялось? Человека с 10-ками лет опыта не нужно обучать. Он сам и вас обучить может и сам обучится, притом бесплатно. Вот мы как раз и пришли к тому, что описано в статье. Видит эдакий "сеньёр" с 5 годами опыта, на собеседовании, человека 20 годами опыта и понимает, что ему самому ещё учиться и учиться. А признаваться в этом не хочется и другим показать страшно.
А легаси - это что-то очень плохое? А если это легаси приносит миллионы долларов? Человек, который 20 лет сидит на саппорте легасей, скорее всего знает и умеет гораздо больше, чем тот, который за 5 лет проект до IPO довёл. Первый опытный специалист, решивший за эти годы множество проблем, походивший по множеству граблей и поддерживающий в рабочем состоянии систему, приносящую компании миллионы долларов. А второй - обыкновенный болтун, навешавший лапши на уши инвесторам, решивший ковать, пока горячо и продать свой проект пока он не успел развалиться.
Т.е. Вы считаете, что специалист с опытом работы 20 лет, которому не пришлось использовать, ну допустим, mongodb, хуже новичка с опытом работы 5 лет, который утверждает (замечу в скобках, всего лишь утверждает, что он работал с mongodb)?
Это я вспоминаю, что начать использовать mongodb у меня не заняло нисколько времени. Ну в самом деле, люди (это я уже не Вам пишу сейчас) . Вы что, считаете, что все эти фреймворки - это какой-то рокет сайнс, которые ну никак нельзя начать использовать, просто прочитав документацию и имея опыт работы с другими фреймворками?