Но с точки зрения внешнего злоумышленника как это эксплуатировать?
Ответ здесь тот же, как и на "зачем токены и куки имеют ограниченный срок действия?" Вероятность утечки ссылки на приватный документ за 3-5 лет слегка выше, чем она же за одну неделю.
Если кратко: на остров ведет один мост, но он принадлежит Министерству Обороны (как и земля на острове, прилегающая к нему). В "дальней" части острова живут гражданские (там же еще поля, например). Людям без пропуска проезжать через военную базу нельзя.
Вдоль берега идет коса, по которой можно добраться до поселка, не заезжая на территорию с военными. По ней не рекомендуется передвигаться без проводника, без контроля времени (чтобы не попасть в прилив) и так далее. Но эта дорога отмечена на картах.
Но разве это не базовое требование почти на все вакансии? Собственно, если необходимо отсортировать автомобили по скорости и вывести 10 самых быстрых, то это необходимо делать в условной базе с индексом (или в горячем сервисе, который вернет, как и база, первые 10 элементов в массива/дерева/списка, а не будет запрашивать всё, потом сортировать и так далее)?
Собственно, все собеседования в стиле system design требуют таких предположений. Ну а Live Coding неявно подразумевает, что навык может быть применен и вне собеседования..
Быстрее то может и будет, но надо не такты процессора оптимизировать а архитектуру и "работу", количество вычислений
Мне казалось, что для программиста это уже базовое правило по-умолчанию, которое даже произносить не надо. Ну то есть это где-то на уровне "надо проверять написанное".
Собственно, сейчас же в школах/вузах рассказывают про алгоритмы, а на собеседованиях спрашивают про всякие там сортировки и хеш таблицы. Логично, что люди с этими знаниями, дальше их применяют в работе.
Бизнесу нужна автоматизация любой ценой, и повышение надёжности процесса её просто убьёт.
Разве это так? Мне казалось, что цель у менеджера - нанять сотрудника посильнее, плюс тратить поменьше времени: как своего, так и в целом.
Более того, если на закрытие вакации потребуется Х месяцев, когда у конкурентов оно Х/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 - по сути, сервер компании работает как "прокси" в случае, когда вы с устройством в разных сетях. Иначе общение идет напрямую.
Все три решения крайне популярны и работают без особых проблем.
Это противоположные вещи. Если считать, что "рациональность" и "ум" коррелируют между собой, то тогда, при учете того, что "рациональный" == "умеющий в кооперацию", мы приходим к "умный" == "склонный к кооперации" == "сговорчивый".
Собственно, подобное работает и в реальной жизни, так как, если группа людей действует сообщая (при более-менее справедливом распределении благ), но она будет успешнее независимых одиночек.
Более того, если человек не умеет в кооперацию, то ему довольно сложно будет быть "умным", так как основная энергия будет тратиться на конфликты, которых бы избежал рациональный человек.
Собственно, пример из жизни: если взять двух хороших разработчиков, но один из них идеалист, а другой закроет глаза на мелкие неважные огрехи, то первому будет очень сложно будет добиться результата как тимлиду, так как очень много времени будет тратиться на споры об идеальном коде и так далее, тогда как второй (более сговорчивый) сможет выпустить продукт намного раньше. Если также принять во внимание то, что люди могут ошибаться (а такой факт сделал бы рационалист - как про других, так и про себя), то запросто может быть, что первая команда (с идеалистом) сделает продукт также с ошибками (если не с большим их числом), несмотря на более медленную скорость разработки.
По сути, Вы говорите о https://gdpr-info.eu/art-17-gdpr/ / https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-erasure/
Ответ здесь тот же, как и на "зачем токены и куки имеют ограниченный срок действия?" Вероятность утечки ссылки на приватный документ за 3-5 лет слегка выше, чем она же за одну неделю.
Есть видео, где описывается эта дорога: https://www.youtube.com/watch?v=mM7C_Pw7OL8 , а также есть статья на Википедии: https://ru.wikipedia.org/wiki/Брумвей
Если кратко: на остров ведет один мост, но он принадлежит Министерству Обороны (как и земля на острове, прилегающая к нему). В "дальней" части острова живут гражданские (там же еще поля, например). Людям без пропуска проезжать через военную базу нельзя.
Вдоль берега идет коса, по которой можно добраться до поселка, не заезжая на территорию с военными. По ней не рекомендуется передвигаться без проводника, без контроля времени (чтобы не попасть в прилив) и так далее. Но эта дорога отмечена на картах.
Но разве это не базовое требование почти на все вакансии? Собственно, если необходимо отсортировать автомобили по скорости и вывести 10 самых быстрых, то это необходимо делать в условной базе с индексом (или в горячем сервисе, который вернет, как и база, первые 10 элементов в массива/дерева/списка, а не будет запрашивать всё, потом сортировать и так далее)?
Собственно, все собеседования в стиле system design требуют таких предположений. Ну а Live Coding неявно подразумевает, что навык может быть применен и вне собеседования..
Мне казалось, что для программиста это уже базовое правило по-умолчанию, которое даже произносить не надо. Ну то есть это где-то на уровне "надо проверять написанное".
Собственно, сейчас же в школах/вузах рассказывают про алгоритмы, а на собеседованиях спрашивают про всякие там сортировки и хеш таблицы. Логично, что люди с этими знаниями, дальше их применяют в работе.
Разве это так? Мне казалось, что цель у менеджера - нанять сотрудника посильнее, плюс тратить поменьше времени: как своего, так и в целом.
Более того, если на закрытие вакации потребуется Х месяцев, когда у конкурентов оно Х/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 - по сути, сервер компании работает как "прокси" в случае, когда вы с устройством в разных сетях. Иначе общение идет напрямую.
Все три решения крайне популярны и работают без особых проблем.
Это противоположные вещи. Если считать, что "рациональность" и "ум" коррелируют между собой, то тогда, при учете того, что "рациональный" == "умеющий в кооперацию", мы приходим к "умный" == "склонный к кооперации" == "сговорчивый".
Собственно, подобное работает и в реальной жизни, так как, если группа людей действует сообщая (при более-менее справедливом распределении благ), но она будет успешнее независимых одиночек.
Более того, если человек не умеет в кооперацию, то ему довольно сложно будет быть "умным", так как основная энергия будет тратиться на конфликты, которых бы избежал рациональный человек.
Собственно, пример из жизни: если взять двух хороших разработчиков, но один из них идеалист, а другой закроет глаза на мелкие неважные огрехи, то первому будет очень сложно будет добиться результата как тимлиду, так как очень много времени будет тратиться на споры об идеальном коде и так далее, тогда как второй (более сговорчивый) сможет выпустить продукт намного раньше. Если также принять во внимание то, что люди могут ошибаться (а такой факт сделал бы рационалист - как про других, так и про себя), то запросто может быть, что первая команда (с идеалистом) сделает продукт также с ошибками (если не с большим их числом), несмотря на более медленную скорость разработки.