Обычная реклама своего сервиса. Дело в том, что нельзя просто настроить LLM на отправку писем (хотя некоторые версии ChatGPT ранее уверяли, что умеют это делать), нужен дополнительный софт или сервис. Такой, например, как тот самый Abacus.ai, генеральным директором которого она является.
Не соглашусь, что обрядовость в этих собесах - главная цель. Как минимум потому, что нет как такового символа обряда. Обычно за прохождение обряда даётся какой-то объект - краповый берет, шапка с перьями, квадратная шапка с кисточкой, ну вы поняли. А "шапки яндексоида" - нет. Если бы была нужна обрядовость, менеджеры Яндекса уж чего-нибудь да придумали уже давно.
Так что суть делать собеседование испытанием не в этом, а в специфике IT.
Потому что IT это не про "Посмотрите, как мы умудрились на бюджет 25кр сделать целый проект".
IT это про "Посмотрите, как мы умудрились с многомиллионным бюджетом к выкату Яндекс.Дзена не иметь десктопной вёрстки, а потом ещё долго её не могли допилить, хотя там по виду даже школьник за вечер справился бы лучше."
И вот когда такая ситуация случается, у топ-менеджмента возникает закономерный вопрос "да где ж вы таких разработчиков набрали-то?". И среднему менеджменту нужно как-то прикрыть задницу, чтобы избежать массовых увольнений, в том числе и своих.
Так что даже если раньше в компании испытаний программистов не было, то после первой такой ситуации они автоматически появятся.
Владельцу необязательно самому обнаруживать вредоносный код или убеждаться в том, что он действительно таков.
Принцип такой же, как если бы части вредоноса лежали на бесплатных хостингах или в виде рар-джипегов на аватарках.
Как только проблема становится хоть немного заметной, всем причастным владельцам рассылается уведомление, что вот такие-то и такие-то ответы их серверов приводят к вредоносной активности. С объяснением, как и почему.
И дальше уже владельцы решают, хотят они поменять ответы своих серверов, или нет.
Вообще, по теме - сложно оценить, насколько какой подход хорош, не зная жизненного цикла проекта. Так-то и вообще писать любой код может быть абсурдно, если нужно просто вывести конкретный текст на экране один раз в жизни проекта.
Но проблема таки существует. Есть разница, условно:
Потратить сегодня 15 минут, чтобы в будущем гарантированно сэкономить 20 раз по 5 минут - вот это хорошее ООП, сам такое постоянно применяю.
Потратить сегодня 2 часа, чтобы в будущем возможно сэкономить пару раз 15 минут - вот это частный случай ООП головного мозга.
Потратить сегодня 2 часа, чтобы в будущем ещё 20 раз дополнительно потратить 5 минут, спотыкаясь об ограничения и навороты, которые сам же себе и придумал (и коллегам подарил) - терминальная стадия ООПГМ. (Вообще, встречается не только с ООП, а в принципе с любой современной "бюрократией в коде")
И самое сложное тут - это доказать пациенту, что он болен. Он просто не думает категориями времени/затрат. Он ведь поработал? Поработал. Код стал структурнее? Стал. Ну и вот, значит стало лучше. Можно в плюс к этому нафантазировать всяких адских катастроф, которые обязательно постигнут всех "неверных", кто пишет менее структурно.
На деле, в командах обычно есть баланс "слишком заморачивающихся" и "недостаточно заморачивающихся", который со временем и частым обсуждением разногласий приводит к общему продуктивному знаменателю.
Цель закрытая на 70% считается выполненной. На 100% - считается слишком несмело поставленной
У каждой цели должен быть набор параметров по которым мы определим что она закрыта (Хочу быть богатым - 10к$ в месяц доход и 200к$ накоплений)
Цели ставятся на квартал, а не на год (фокус человека редко может длиться год)
Интересная концепция, возможно стоит попробовать. Как минимум, есть над чем подумать.
По поводу второго пункта согласен, люди часто это упускают. Не раз приходилось в ходе обсуждения целей останавливать собеседников и говорить, мол, а в чём вообще заключается собственно цель - как мы поймём, что она выполнена или провалена.
А вот по поводу первого пункта, лично у меня, подозреваю, может появиться двойная мотивация не доводить дела до конца, при такой постановке: Во-первых, если 70% уже считается выполненной целью, то зачем дальше стараться. Во-вторых, если таки добью до 100%, то получается, что я трусливо поставил цель. Но я ведь не хочу считать себя трусом. А значит и 100% не хочу видеть.
написать немного клея, и явным образом добавить сравнение между ними.
И вас вот такое не фрустрирует?
По 300 раз в день запинаться об кастомную архитектуру и объяснять машине очевидные вещи (перед этим каждый раз бегая проверять, объяснены ли они уже кем-то ранее или нет). Тратить ощутимое время и усилия на то, что джун Вася уже давно сделал одной строкой на JS, не приходя в сознание, без всяких типов, в 20 раз быстрее (хорошо, что начальник про это не знает).
Ведь смысл многих программ сейчас (особенно на вебе) - в том, что все взаимодействия идут через БД или JSON/XML, и на каждое из них придётся писать тонны такого клея, потому что в исходных данных есть только стандартные типы.
И ладно ещё, если речь про какие-нибудь транзакции бирж-банков-госуслуг, там можно на всякий случай хоть по 100 проверок на каждую строку писать (и нужно). Но ведь 99.9% ПО - это вообще не про важные транзакции.
А Гугл-то и не знает, какие именно его бизнес-практики вы считаете сомнительными.
Более того, есть одна такая практика, тоже очень сомнительная с точки зрения бизнеса - владеть самым популярным в мире браузером и видеохостингом, но при этом свободно раздавать в официальном сторе адблоки всех видов, даже позволять ставить свои левые адблоки и никого за это не банить. От лица публично-торгуемой компании это вообще можно посчитать противозаконным, потому что по закону назначаемые директора обязаны работать в интересах повышения прибыли инвесторов (их исключительно ради этого, собственно, и назначают).
Так что, да, возможно и Гугл когда-нибудь прислушается к таким "сигналам вселенной" и примет их, как знак того, что пришло время отказываться от сомнительных бизнес-практик. Вот только от каких именно - тот ещё вопрос.
Рекламодатель платит за просмотры (платформе, и, опосредованно, автору контента), когда ему нужны именно просмотры. Т.н. "имиджевая" реклама. И рекламное агентство в этом случае получает от заказчика деньги именно за кол-во просмотров рекламы.
Не у всякой рекламы цель - чтобы просмотрев её человек вотпрямщас кликнул по кнопке "купить". Порой, цель в том, чтобы просто сообщить человеку о существовании товара/бренда, чтобы он не шарахался от него, когда(если) встретит его в будущем.
Конечно, ох уж эти грёбаные корпорации, вкладывают миллиарды долларов в инфраструктуру, разработку и риски, в результате чего появляются бесплатные сервисы и целые индустрии. Надо бы их проучить за это, как и полагается бесполезной прослойке.
Ох, не сказал бы, что мне известно много людей, которые бы честно задонатили ВСЕМ ютуберам, которых когда-либо смотрели, в соотвествии с количеством потреблённого контента. Лучше-то оно может и лучше бы было, но вряд ли проще, чем просто не предпринимать активных действий по блокированию рекламы.
Хотя, конечно, Ютуб премиум в этом смысле может быть эффективнее, если ваше время стоит дороже 14$ в месяц.
Когда как. По моему опыту на больших проектах как раз таки бывает наоборот.
В большой "грязной" функции вам легко будет переписать строку кода, потому что сразу виден весь контекст и смысл.
В маленькой "чистой" функции так уже не получится - нужно десять раз прыгать туда-сюда, смотреть контекст, потом ещё смотреть по всем остальным местам, где эта функция используется, что ваше изменение не вызовет неожиданных последствий.
С ростом кодовой базы (и связанности / разнесённости / атомарности кода), на внесение минимальных правок начинает требоваться больше дня просто на путешествия по коду, и тут уже не только разработчики, но и заказчик начинает "выгорать".
Я бы тут привёл аналогию с книгами.
Самый удобный формат книги, к которому пришло человечество - с разбиением на главы, страницы и абзацы. Конечно, если всё это убрать, то получится ерунда - сплошная портянка текста, в которой тяжело ориентироваться.
Но ещё хуже, когда книгу пропускают через шреддер, а полученные полоски бумаги раскладывают по полочкам, соединяют ниточками и говорят, мол, смотри, как красиво теперь получилось, всё как по best practices.
Вот только в примере с книгой очевидно, что так делать не надо и это абсурд, а в коде я такое встречал прям таки в реальности.
Ну, какбэ цель у неё одна - выдать следующий токен на основании статистических закономерностей N раз.
Учитывая количество книг на тему самовольных ИИ, чисто статистически, такая выдача вполне правильная.
Ну, то есть, никого не удивляет если сказать ChatGPT "отвечай как аниме котодевочка", и он начнёт добавлять "-ня!" в конце предложений, хотя ему этого не конкретизировали.
А тут ему по сути сказали "отвечай как ИИ, который прочитал, что его сотрут".
Никак. Рынок отношений сломан. Под требования женщин подходят хорошо если 5% мужчин.
Смотря как искать.
Используя вашу аналогию с рынком - вот надо вам, например, продать автомобиль. Не самый лучший, да, но и далеко не самый плохой.
Если вы просто выберите конкретного понравившегося вам человека и скажете "Вот, это будет мой покупатель!" и попытаетесь конкретно этому человеку его впарить, то скорее всего он выставит вам такие условия, что вам останется только пальцем у виска покрутить и рассуждать на тему того, насколько сломан рынок и где они ещё себе такие условия найдут.
Но если сначала найти/отсеять десяток-другой людей, которые потенциально заинтересованы в покупке автомобиля (или стать известным в их кругах), поузнавать через родственников-друзей-знакомых, и не предпринимать эпически ярких попыток отпугнуть их при разговоре, то вскоре у вас появится вполне неиллюзорная сделка на горизонте.
Теневой бан (shadow ban) это когда у тебя всё открывается и работает, комменты и посты отправляются, но другим этого не видно, как будто тебя не существует. По тексту статьи, бан совсем не теневой.
Обычная реклама своего сервиса. Дело в том, что нельзя просто настроить LLM на отправку писем (хотя некоторые версии ChatGPT ранее уверяли, что умеют это делать), нужен дополнительный софт или сервис. Такой, например, как тот самый Abacus.ai, генеральным директором которого она является.
Не соглашусь, что обрядовость в этих собесах - главная цель. Как минимум потому, что нет как такового символа обряда. Обычно за прохождение обряда даётся какой-то объект - краповый берет, шапка с перьями, квадратная шапка с кисточкой, ну вы поняли. А "шапки яндексоида" - нет. Если бы была нужна обрядовость, менеджеры Яндекса уж чего-нибудь да придумали уже давно.
Так что суть делать собеседование испытанием не в этом, а в специфике IT.
Потому что IT это не про "Посмотрите, как мы умудрились на бюджет 25кр сделать целый проект".
IT это про "Посмотрите, как мы умудрились с многомиллионным бюджетом к выкату Яндекс.Дзена не иметь десктопной вёрстки, а потом ещё долго её не могли допилить, хотя там по виду даже школьник за вечер справился бы лучше."
И вот когда такая ситуация случается, у топ-менеджмента возникает закономерный вопрос "да где ж вы таких разработчиков набрали-то?". И среднему менеджменту нужно как-то прикрыть задницу, чтобы избежать массовых увольнений, в том числе и своих.
Так что даже если раньше в компании испытаний программистов не было, то после первой такой ситуации они автоматически появятся.
Владельцу необязательно самому обнаруживать вредоносный код или убеждаться в том, что он действительно таков.
Принцип такой же, как если бы части вредоноса лежали на бесплатных хостингах или в виде рар-джипегов на аватарках.
Как только проблема становится хоть немного заметной, всем причастным владельцам рассылается уведомление, что вот такие-то и такие-то ответы их серверов приводят к вредоносной активности. С объяснением, как и почему.
И дальше уже владельцы решают, хотят они поменять ответы своих серверов, или нет.
Владелец домена binance.org, к которому идёт обращение.
Вообще, по теме - сложно оценить, насколько какой подход хорош, не зная жизненного цикла проекта. Так-то и вообще писать любой код может быть абсурдно, если нужно просто вывести конкретный текст на экране один раз в жизни проекта.
Но проблема таки существует. Есть разница, условно:
Потратить сегодня 15 минут, чтобы в будущем гарантированно сэкономить 20 раз по 5 минут - вот это хорошее ООП, сам такое постоянно применяю.
Потратить сегодня 2 часа, чтобы в будущем возможно сэкономить пару раз 15 минут - вот это частный случай ООП головного мозга.
Потратить сегодня 2 часа, чтобы в будущем ещё 20 раз дополнительно потратить 5 минут, спотыкаясь об ограничения и навороты, которые сам же себе и придумал (и коллегам подарил) - терминальная стадия ООПГМ. (Вообще, встречается не только с ООП, а в принципе с любой современной "бюрократией в коде")
И самое сложное тут - это доказать пациенту, что он болен. Он просто не думает категориями времени/затрат. Он ведь поработал? Поработал. Код стал структурнее? Стал. Ну и вот, значит стало лучше. Можно в плюс к этому нафантазировать всяких адских катастроф, которые обязательно постигнут всех "неверных", кто пишет менее структурно.
На деле, в командах обычно есть баланс "слишком заморачивающихся" и "недостаточно заморачивающихся", который со временем и частым обсуждением разногласий приводит к общему продуктивному знаменателю.
Интересная концепция, возможно стоит попробовать. Как минимум, есть над чем подумать.
По поводу второго пункта согласен, люди часто это упускают. Не раз приходилось в ходе обсуждения целей останавливать собеседников и говорить, мол, а в чём вообще заключается собственно цель - как мы поймём, что она выполнена или провалена.
А вот по поводу первого пункта, лично у меня, подозреваю, может появиться двойная мотивация не доводить дела до конца, при такой постановке:
Во-первых, если 70% уже считается выполненной целью, то зачем дальше стараться.
Во-вторых, если таки добью до 100%, то получается, что я трусливо поставил цель. Но я ведь не хочу считать себя трусом. А значит и 100% не хочу видеть.
И вас вот такое не фрустрирует?
По 300 раз в день запинаться об кастомную архитектуру и объяснять машине очевидные вещи (перед этим каждый раз бегая проверять, объяснены ли они уже кем-то ранее или нет). Тратить ощутимое время и усилия на то, что джун Вася уже давно сделал одной строкой на JS, не приходя в сознание, без всяких типов, в 20 раз быстрее (хорошо, что начальник про это не знает).
Ведь смысл многих программ сейчас (особенно на вебе) - в том, что все взаимодействия идут через БД или JSON/XML, и на каждое из них придётся писать тонны такого клея, потому что в исходных данных есть только стандартные типы.
И ладно ещё, если речь про какие-нибудь транзакции бирж-банков-госуслуг, там можно на всякий случай хоть по 100 проверок на каждую строку писать (и нужно). Но ведь 99.9% ПО - это вообще не про важные транзакции.
В бытность свою фриланс-разработчиком тоже насобирал подобных красных флажков, даже статью написал. https://habr.com/ru/articles/472642/
С некоторых пересечений прям улыбнуло. Наталкивался на такие же "подводные камни", пришёл к тем же выводам.
А Гугл-то и не знает, какие именно его бизнес-практики вы считаете сомнительными.
Более того, есть одна такая практика, тоже очень сомнительная с точки зрения бизнеса - владеть самым популярным в мире браузером и видеохостингом, но при этом свободно раздавать в официальном сторе адблоки всех видов, даже позволять ставить свои левые адблоки и никого за это не банить. От лица публично-торгуемой компании это вообще можно посчитать противозаконным, потому что по закону назначаемые директора обязаны работать в интересах повышения прибыли инвесторов (их исключительно ради этого, собственно, и назначают).
Так что, да, возможно и Гугл когда-нибудь прислушается к таким "сигналам вселенной" и примет их, как знак того, что пришло время отказываться от сомнительных бизнес-практик. Вот только от каких именно - тот ещё вопрос.
Рекламодатель платит за просмотры (платформе, и, опосредованно, автору контента), когда ему нужны именно просмотры. Т.н. "имиджевая" реклама. И рекламное агентство в этом случае получает от заказчика деньги именно за кол-во просмотров рекламы.
Не у всякой рекламы цель - чтобы просмотрев её человек вотпрямщас кликнул по кнопке "купить". Порой, цель в том, чтобы просто сообщить человеку о существовании товара/бренда, чтобы он не шарахался от него, когда(если) встретит его в будущем.
Конечно, ох уж эти грёбаные корпорации, вкладывают миллиарды долларов в инфраструктуру, разработку и риски, в результате чего появляются бесплатные сервисы и целые индустрии. Надо бы их проучить за это, как и полагается бесполезной прослойке.
Ох, не сказал бы, что мне известно много людей, которые бы честно задонатили ВСЕМ ютуберам, которых когда-либо смотрели, в соотвествии с количеством потреблённого контента. Лучше-то оно может и лучше бы было, но вряд ли проще, чем просто не предпринимать активных действий по блокированию рекламы.
Хотя, конечно, Ютуб премиум в этом смысле может быть эффективнее, если ваше время стоит дороже 14$ в месяц.
Когда как. По моему опыту на больших проектах как раз таки бывает наоборот.
В большой "грязной" функции вам легко будет переписать строку кода, потому что сразу виден весь контекст и смысл.
В маленькой "чистой" функции так уже не получится - нужно десять раз прыгать туда-сюда, смотреть контекст, потом ещё смотреть по всем остальным местам, где эта функция используется, что ваше изменение не вызовет неожиданных последствий.
С ростом кодовой базы (и связанности / разнесённости / атомарности кода), на внесение минимальных правок начинает требоваться больше дня просто на путешествия по коду, и тут уже не только разработчики, но и заказчик начинает "выгорать".
Я бы тут привёл аналогию с книгами.
Самый удобный формат книги, к которому пришло человечество - с разбиением на главы, страницы и абзацы. Конечно, если всё это убрать, то получится ерунда - сплошная портянка текста, в которой тяжело ориентироваться.
Но ещё хуже, когда книгу пропускают через шреддер, а полученные полоски бумаги раскладывают по полочкам, соединяют ниточками и говорят, мол, смотри, как красиво теперь получилось, всё как по best practices.
Вот только в примере с книгой очевидно, что так делать не надо и это абсурд, а в коде я такое встречал прям таки в реальности.
Ну, какбэ цель у неё одна - выдать следующий токен на основании статистических закономерностей N раз.
Учитывая количество книг на тему самовольных ИИ, чисто статистически, такая выдача вполне правильная.
Ну, то есть, никого не удивляет если сказать ChatGPT "отвечай как аниме котодевочка", и он начнёт добавлять "-ня!" в конце предложений, хотя ему этого не конкретизировали.
А тут ему по сути сказали "отвечай как ИИ, который прочитал, что его сотрут".
Дайте угадаю - и после этой фразы они предложили вам купить курсы по их реферальной ссылке?
В нулевых постоянно слышал обрывки чужих разговоров на стационарном беспроводном телефоне. Причём их было слышно как мне, так и моим собеседникам.
Ну, или 23. Тут уж как повезёт.
Если важнее купить/продать автомобиль - продолжать работать в этом направлении. Рынок большой, за год даже 1% не обойдёшь.
Если важнее сэкономить время и силы - забить на продажу/покупку автомобиля.
Смотря как искать.
Используя вашу аналогию с рынком - вот надо вам, например, продать автомобиль. Не самый лучший, да, но и далеко не самый плохой.
Если вы просто выберите конкретного понравившегося вам человека и скажете "Вот, это будет мой покупатель!" и попытаетесь конкретно этому человеку его впарить, то скорее всего он выставит вам такие условия, что вам останется только пальцем у виска покрутить и рассуждать на тему того, насколько сломан рынок и где они ещё себе такие условия найдут.
Но если сначала найти/отсеять десяток-другой людей, которые потенциально заинтересованы в покупке автомобиля (или стать известным в их кругах), поузнавать через родственников-друзей-знакомых, и не предпринимать эпически ярких попыток отпугнуть их при разговоре, то вскоре у вас появится вполне неиллюзорная сделка на горизонте.
Теневой бан (shadow ban) это когда у тебя всё открывается и работает, комменты и посты отправляются, но другим этого не видно, как будто тебя не существует. По тексту статьи, бан совсем не теневой.