Бизнесу нужна автоматизация любой ценой, и повышение надёжности процесса её просто убьёт.
Разве это так? Мне казалось, что цель у менеджера - нанять сотрудника посильнее, плюс тратить поменьше времени: как своего, так и в целом.
Более того, если на закрытие вакации потребуется Х месяцев, когда у конкурентов оно Х/2, то сильные кандидаты будут уходить к конкурентам. По факту, это ведь типичный случай: пока были раунды собеседований, человек уже получил оффер и согласился на него (ибо синица в руках и так далее).
Спасибо! Да, хорошо расписано. В целом, выглядит так, что просто система перестроится под другой подход, ибо кризис слишком очевиден. Сейчас очень легко накрутить опыт и умения, так что, возможно, появится что-то, что будет этому препятствовать: или история резюме будет трекаться, или появятся сервисы "с репутацией", которые будут делать первичную оценку знаний, но скорее всего - что-то очень неожиданное.
На деле, в западных крупных фирмах так и устроено - после собеседования будет background check, где проверят резюме: действительно ли человек учился в том вузе или правда ли, что человек работал в определенном месте.
Но это сейчас стало тоже плохо работать, так как если кто-то работал в определенной компании, а в резюме декларирует определенные навыки, то невозможно заранее определить, правду человек пишет или нет.
Я знаю. О том и речь - HR не может отличить, так как никто не может. Но, если на вакансию пришло несколько сотен человек, то придется кому-то проигнорировать основную массу.
Другими словами - с текущим подходом к разбору резюме, эта задача не может быть решена в принципе.
Возможно... Но мой же посыл в том, что, если резюме кто-то просто скопирует и сменит имя, то, за неимением никаких других средств верификации, без собеседования никто физически не сможет ответить, была ли фальсификация или нет.
А потому и получается, что HR (у которых есть только резюме на руках) не сможет никак отличить самозванца от специалиста.
следствие того что HR-ши некомпетентны и не могут отличить самозванца от специалиста
Ради интереса - а как это можно сделать? Допустим, что самозванец взял несколько реальных CV от специалистов, а далее просто поменял имя и отправил в разные компании.
Собственно, если нет быстрых пруфов в виде активности на GitHub или статей на том же Хабре, то как можно понять, что первое резюме честное и от профессионала, а три других содержат обман выше порога?
И либо сносит заодно вид всех прочих элементов, которым понаприсваивали стиль red-button, либо присваивает ей стиль red-button2, другого оттенка, ломая бизнес-логику, после чего куча народа срочно-срочно мечется по коду в поисках WTF?!
А тесты? Вроде, изначально автор говорил про сложность найма опытного и высококвалифицированного профессионала в профессиональную команду, так что аргумент "скорее всего бизнес логика сделана через стили, а тестов нет" слабо подходит к теме.
И все же, с вас финансовый директор будет спрашивать расходную часть бюджета, ему ж надо у инвестора защищать свой бюджет.
А как тогда Space X смогли защитить у инвесторов, если поступательный прогресс не работает?
Инвестору показывают тренд прибыли/убытков/оборота и подобных вещей, чтобы видеть перспективу. Если у Вас есть текущий бюджет и примерный план в стиле "оставляем ту же команду, нанимаем еще 10% и повышаем расход на существующих на ставку инфляции", то это и будет ответом финансовому директору. Если же финансовый директор требует точно запланировать, например, затраты на исправления будущих уязвимостей, то здесь уже вопросы будут к нему :)
мы будем Вам ставку менять поступательно - это ведь намного эффективней, да?
Ипотека - это типовой продукт. Мы говорим про IT, где именно создается новое решение. Поэтому, правильнее брать в пример тот же Space X, Tesla и так далее.
и все это вот с каждым релизом коту под хвост раз в пол года?
Релизы раз в неделю. Если продукт переписывают с нуля раз в неделю - то это странно.
И да, если вдруг станет выгодно деплоить сервисы в Kubernetes клиентов (так как рынок поменялся), а не хостить их на заранее выбранном сервисе - то, зачастую, выгоднее остановиться и начать делать решения для клиентов, а не продолжать следовать старому направлению, постепенно теряя доходы.
Это называется "корреляция". Например, выпускники сильных вузов чаще всего будут лучше в определенной профессии, чем выпускники слабых (при условии, что в вузе обучали именно эту профессию и так далее). Это не строгая зависимость, это просто корреляция.
Представьте что Вы руковод отдела, Вам надо бюджет заложить на год - год это стандартный период планирования
Вроде как уже много лет назад поняли, что такой способ планирования нерационален. Намного эффективнее поступательный прогресс, когда небольшими изменениями продукт двигается в сторону, которую определяют раз в X месяцев (или раз в год).
Собственно, пример - Linux или Chrome. Они поступательно улучшаются, с частыми релизами.
Вы же предлагаете классический подход, когда сначала люди пытаются спланировать всё-всё очень надолго (да еще и со сроками, с учетом рисков и так далее), а потом пытаются уложить именно в эти сроки именно эти запросы, даже несмотря на то, что ситуация может измениться.
Еще пример из инженерии: для условного Space X технологические прорывы будут играть на руку, а для более классического SLS - нет. Но это не говорит, что рост технологии плох, это говорит о разных способах управления.
Это зависит от сложности запроса, а точнее - от того, насколько много уже готовых/похожих ответов есть на GitHub/StackOverflow.
Например, если задать вопрос "напиши перевод из двоичной системы в десятичную на питоне", то реализация будет идеальной. Но если вопрос будет в стиле "на С++ версии С++11 скорректируй модуль большого приложения А, с учетом требований Б и без явных проблем с памятью/производительностью", то вероятность ответа будет стремиться к нулю. Правда, во второй части LLM может неплохо сделать ревью кода, так что определенный процент рекомендаций будет даже полезен.
Собственно, из-за этого и разнятся отзывы об LLM - очень популярные задачи на очень популярных технологиях (и, желательно, без своих типов) генерятся очень хорошо, тогда как если у человека работа в другой области, то LLM превращается в просто слегка более умный autocomplete.
Это не будет работать асинхронно, что приведет к негативному клиентскому опыту.
Почему? Есть как минимум несколько вариантов:
Телефон общается с пылесосом/базой напрямую, как в протоколе AirPrint (технология используется с 2010 года).
Пылесос дает возможность использовать "свой сервер" - это реализовано во многих играх, например.
Использовать аналог Ubiquiti's Remote Management feature - по сути, сервер компании работает как "прокси" в случае, когда вы с устройством в разных сетях. Иначе общение идет напрямую.
Все три решения крайне популярны и работают без особых проблем.
Это противоположные вещи. Если считать, что "рациональность" и "ум" коррелируют между собой, то тогда, при учете того, что "рациональный" == "умеющий в кооперацию", мы приходим к "умный" == "склонный к кооперации" == "сговорчивый".
Собственно, подобное работает и в реальной жизни, так как, если группа людей действует сообщая (при более-менее справедливом распределении благ), но она будет успешнее независимых одиночек.
Более того, если человек не умеет в кооперацию, то ему довольно сложно будет быть "умным", так как основная энергия будет тратиться на конфликты, которых бы избежал рациональный человек.
Собственно, пример из жизни: если взять двух хороших разработчиков, но один из них идеалист, а другой закроет глаза на мелкие неважные огрехи, то первому будет очень сложно будет добиться результата как тимлиду, так как очень много времени будет тратиться на споры об идеальном коде и так далее, тогда как второй (более сговорчивый) сможет выпустить продукт намного раньше. Если также принять во внимание то, что люди могут ошибаться (а такой факт сделал бы рационалист - как про других, так и про себя), то запросто может быть, что первая команда (с идеалистом) сделает продукт также с ошибками (если не с большим их числом), несмотря на более медленную скорость разработки.
Я подозреваю, что ожидания были "для достижения того же результата Вам теперь требуется вдвое меньше курсов, так как остальные знания Вы можете получить из LLM; а потому - вот Вам скидка".
В каждой работе есть некое "дополнительная ценность", за которую платят. Например, если сделать копию хабра и продавать доступ к ней в интернете, то этой самой дополнительной ценности не будет - хабр и так доступен.
В случае учебника, где автор берет результат работы нейросети, добавочная ценность будет околонулевая, так как ученик сам может спросить у нейросети. И, в отличии от классических поисковиков, это будет работать.
Пример с работой программиста некорректен, так как дополнительная ценность этого специалиста идет уже с учетом громадного числа инструментов - и IDE, и гугл, и разные линтеры, и LLM модели. Другими словами - с хорошими LLM, как и с хорошими IDE, ожидания от результата растут.
Меня пока смущает то, что решения ARM монолитные, в отличии от IBM-PC: насколько я понимаю, не получится купить отдельно материнскую карту, процессор и так далее.
но при этом потреблять 90+% процессорного времени (как в каких нибудь нейронках).
Самый главный вопрос, ответ на который необходимо четко понимать: "какую проблему мы решаем?"
Если перемножение матриц будет постоянно использоваться, да еще и с серьезной математикой, а вдобавок еще и с большим потреблением памяти, то будет один выбор (скорее всего, тут будет Rust или иной язык, а также библиотеки оттуда).
Если планируется получить очень большой долгоживущий сервис с громадным объемом бизнес логики, но с малым числом слабонагруженных реплик в k8s, то, скорее всего, выбор падет на JVM, а далее уже следует просто прагматично подбирать пакеты.
Если планируется очень маленький сервис без жестких требований по части типов, то может подойти и Python, но тогда потребуется серьезнее подходить к оптимизации математики.
Собственно, далеко не всегда отдельная библиотека принесет пользу. Условные Eclipse Collections помогут в Java, но не будут иметь смысла в Kotlin.
И да, где-то подключение еще одного пакета будет целесообразным, а где-то - нет. Самое важное - какую конкретно проблему мы решаем?
Разве это так? Мне казалось, что цель у менеджера - нанять сотрудника посильнее, плюс тратить поменьше времени: как своего, так и в целом.
Более того, если на закрытие вакации потребуется Х месяцев, когда у конкурентов оно Х/2, то сильные кандидаты будут уходить к конкурентам. По факту, это ведь типичный случай: пока были раунды собеседований, человек уже получил оффер и согласился на него (ибо синица в руках и так далее).
Спасибо! Да, хорошо расписано. В целом, выглядит так, что просто система перестроится под другой подход, ибо кризис слишком очевиден. Сейчас очень легко накрутить опыт и умения, так что, возможно, появится что-то, что будет этому препятствовать: или история резюме будет трекаться, или появятся сервисы "с репутацией", которые будут делать первичную оценку знаний, но скорее всего - что-то очень неожиданное.
Ух ты, вот тут интересно - а можно посмотреть?
На деле, в западных крупных фирмах так и устроено - после собеседования будет background check, где проверят резюме: действительно ли человек учился в том вузе или правда ли, что человек работал в определенном месте.
Но это сейчас стало тоже плохо работать, так как если кто-то работал в определенной компании, а в резюме декларирует определенные навыки, то невозможно заранее определить, правду человек пишет или нет.
Я знаю. О том и речь - HR не может отличить, так как никто не может. Но, если на вакансию пришло несколько сотен человек, то придется кому-то проигнорировать основную массу.
Другими словами - с текущим подходом к разбору резюме, эта задача не может быть решена в принципе.
Возможно... Но мой же посыл в том, что, если резюме кто-то просто скопирует и сменит имя, то, за неимением никаких других средств верификации, без собеседования никто физически не сможет ответить, была ли фальсификация или нет.
А потому и получается, что HR (у которых есть только резюме на руках) не сможет никак отличить самозванца от специалиста.
Ради интереса - а как это можно сделать? Допустим, что самозванец взял несколько реальных CV от специалистов, а далее просто поменял имя и отправил в разные компании.
Собственно, если нет быстрых пруфов в виде активности на GitHub или статей на том же Хабре, то как можно понять, что первое резюме честное и от профессионала, а три других содержат обман выше порога?
Вы про https://ru.wikipedia.org/wiki/Model_Context_Protocol?
А тесты? Вроде, изначально автор говорил про сложность найма опытного и высококвалифицированного профессионала в профессиональную команду, так что аргумент "скорее всего бизнес логика сделана через стили, а тестов нет" слабо подходит к теме.
А как тогда Space X смогли защитить у инвесторов, если поступательный прогресс не работает?
Инвестору показывают тренд прибыли/убытков/оборота и подобных вещей, чтобы видеть перспективу. Если у Вас есть текущий бюджет и примерный план в стиле "оставляем ту же команду, нанимаем еще 10% и повышаем расход на существующих на ставку инфляции", то это и будет ответом финансовому директору. Если же финансовый директор требует точно запланировать, например, затраты на исправления будущих уязвимостей, то здесь уже вопросы будут к нему :)
Ипотека - это типовой продукт. Мы говорим про IT, где именно создается новое решение. Поэтому, правильнее брать в пример тот же Space X, Tesla и так далее.
Релизы раз в неделю. Если продукт переписывают с нуля раз в неделю - то это странно.
И да, если вдруг станет выгодно деплоить сервисы в Kubernetes клиентов (так как рынок поменялся), а не хостить их на заранее выбранном сервисе - то, зачастую, выгоднее остановиться и начать делать решения для клиентов, а не продолжать следовать старому направлению, постепенно теряя доходы.
Это называется "корреляция". Например, выпускники сильных вузов чаще всего будут лучше в определенной профессии, чем выпускники слабых (при условии, что в вузе обучали именно эту профессию и так далее). Это не строгая зависимость, это просто корреляция.
Вроде как уже много лет назад поняли, что такой способ планирования нерационален. Намного эффективнее поступательный прогресс, когда небольшими изменениями продукт двигается в сторону, которую определяют раз в X месяцев (или раз в год).
Собственно, пример - Linux или Chrome. Они поступательно улучшаются, с частыми релизами.
Вы же предлагаете классический подход, когда сначала люди пытаются спланировать всё-всё очень надолго (да еще и со сроками, с учетом рисков и так далее), а потом пытаются уложить именно в эти сроки именно эти запросы, даже несмотря на то, что ситуация может измениться.
Еще пример из инженерии: для условного Space X технологические прорывы будут играть на руку, а для более классического SLS - нет. Но это не говорит, что рост технологии плох, это говорит о разных способах управления.
Это зависит от сложности запроса, а точнее - от того, насколько много уже готовых/похожих ответов есть на GitHub/StackOverflow.
Например, если задать вопрос "напиши перевод из двоичной системы в десятичную на питоне", то реализация будет идеальной. Но если вопрос будет в стиле "на С++ версии С++11 скорректируй модуль большого приложения А, с учетом требований Б и без явных проблем с памятью/производительностью", то вероятность ответа будет стремиться к нулю. Правда, во второй части LLM может неплохо сделать ревью кода, так что определенный процент рекомендаций будет даже полезен.
Собственно, из-за этого и разнятся отзывы об LLM - очень популярные задачи на очень популярных технологиях (и, желательно, без своих типов) генерятся очень хорошо, тогда как если у человека работа в другой области, то LLM превращается в просто слегка более умный autocomplete.
Почему? Есть как минимум несколько вариантов:
Телефон общается с пылесосом/базой напрямую, как в протоколе AirPrint (технология используется с 2010 года).
Пылесос дает возможность использовать "свой сервер" - это реализовано во многих играх, например.
Использовать аналог Ubiquiti's Remote Management feature - по сути, сервер компании работает как "прокси" в случае, когда вы с устройством в разных сетях. Иначе общение идет напрямую.
Все три решения крайне популярны и работают без особых проблем.
Это противоположные вещи. Если считать, что "рациональность" и "ум" коррелируют между собой, то тогда, при учете того, что "рациональный" == "умеющий в кооперацию", мы приходим к "умный" == "склонный к кооперации" == "сговорчивый".
Собственно, подобное работает и в реальной жизни, так как, если группа людей действует сообщая (при более-менее справедливом распределении благ), но она будет успешнее независимых одиночек.
Более того, если человек не умеет в кооперацию, то ему довольно сложно будет быть "умным", так как основная энергия будет тратиться на конфликты, которых бы избежал рациональный человек.
Собственно, пример из жизни: если взять двух хороших разработчиков, но один из них идеалист, а другой закроет глаза на мелкие неважные огрехи, то первому будет очень сложно будет добиться результата как тимлиду, так как очень много времени будет тратиться на споры об идеальном коде и так далее, тогда как второй (более сговорчивый) сможет выпустить продукт намного раньше. Если также принять во внимание то, что люди могут ошибаться (а такой факт сделал бы рационалист - как про других, так и про себя), то запросто может быть, что первая команда (с идеалистом) сделает продукт также с ошибками (если не с большим их числом), несмотря на более медленную скорость разработки.
Я подозреваю, что ожидания были "для достижения того же результата Вам теперь требуется вдвое меньше курсов, так как остальные знания Вы можете получить из LLM; а потому - вот Вам скидка".
В каждой работе есть некое "дополнительная ценность", за которую платят. Например, если сделать копию хабра и продавать доступ к ней в интернете, то этой самой дополнительной ценности не будет - хабр и так доступен.
В случае учебника, где автор берет результат работы нейросети, добавочная ценность будет околонулевая, так как ученик сам может спросить у нейросети. И, в отличии от классических поисковиков, это будет работать.
Пример с работой программиста некорректен, так как дополнительная ценность этого специалиста идет уже с учетом громадного числа инструментов - и IDE, и гугл, и разные линтеры, и LLM модели. Другими словами - с хорошими LLM, как и с хорошими IDE, ожидания от результата растут.
Мне казалось, что открытый код мало что может гарантировать, так как в нем могут быть баги.
Открытый код только снижает вероятность неожиданностей хотя бы потому, что многие люди на него смотрят, а потому:
Код выше побоятся аппрувить еще и по причине, что все увидят.
Код выше запросто исправит какой-то энтузиаст.
Намного сложнее становится вводить в заблуждение на тему корректности работы программы, а потому приходится исправлять ошибки.
Но "снижает вероятность Х" != "гарантирует отсутствие Х"
Меня пока смущает то, что решения ARM монолитные, в отличии от IBM-PC: насколько я понимаю, не получится купить отдельно материнскую карту, процессор и так далее.
Самый главный вопрос, ответ на который необходимо четко понимать: "какую проблему мы решаем?"
Если перемножение матриц будет постоянно использоваться, да еще и с серьезной математикой, а вдобавок еще и с большим потреблением памяти, то будет один выбор (скорее всего, тут будет Rust или иной язык, а также библиотеки оттуда).
Если планируется получить очень большой долгоживущий сервис с громадным объемом бизнес логики, но с малым числом слабонагруженных реплик в k8s, то, скорее всего, выбор падет на JVM, а далее уже следует просто прагматично подбирать пакеты.
Если планируется очень маленький сервис без жестких требований по части типов, то может подойти и Python, но тогда потребуется серьезнее подходить к оптимизации математики.
Собственно, далеко не всегда отдельная библиотека принесет пользу. Условные Eclipse Collections помогут в Java, но не будут иметь смысла в Kotlin.
И да, где-то подключение еще одного пакета будет целесообразным, а где-то - нет. Самое важное - какую конкретно проблему мы решаем?