Современные языковые модели, такие как ChatGPT, Claude, Gemini, Grok и так далее, способны генерировать тексты, которые часто кажутся уверенными, логичными и достойными доверия. Однако за этим часто скрывается одна из главных проблем нейросетей — галлюцинации. Галлюцинации — это уверенные, но ложные утверждения, которые модель выдает как факты. Они могут проявляться в виде несуществующих цитат, выдуманных терминов, неверных интерпретаций, ошибочных чисел или ссылок на несуществующие источники. Например: при запросе о биографии известного ученого модель может уверенно сообщить о его работе в MTI и сослаться на несуществующую публикацию в Nature с точной датой и названием. Другой распространенный случай — цитирование выдуманных законодательных актов с номерами и датами принятия, которые выглядят достоверно, но фактически не существуют. Подробное и обоснованное описание создает иллюзию достоверности, делая галлюцинации особенно критичными при использовании ИИ в науке, образовании или, например, в медицине.

Вас спрашивали на интервью «Почему люди внезапно увольняются?» или «В каких случаях допустимо опаздывать на работу?»

Знайте, это – проективные вопросы. Замаскированная ловушка. Из-за неё вы расскажете о себе больше, чем хотите.

Хотя речь вроде о других, при ответе вы опираетесь на личный опыт. Отталкиваетесь от своих убеждений. На основании сказанного интервьюер делает вывод о ваших мотивах и поведенческих паттернах.

Мне кажется, что проективные вопросы – это «имба». Соискателю заглядывают в душу, а он и не замечает. Такие вопросы противоречат принципам открытости и взаимного уважения. И хотя они вредят карме компаний, их всё равно задают.

Мы с коллегами так не делаем. Ниже делюсь мнением, как из-за таких вопросов не потерять оффер.

Магии не существует, а есть способы планирования, которые помогают работать эффективнее и продвигаться в больших и сложных делах. Мы собрали 42 способа, инструмента, подхода к планированию: как базовые, так и новаторские. Разберем, как ими пользоваться и насколько они хороши.

Вам не нужно изучать какую‑либо теорию, кроме этой статьи, чтобы начать собеседоваться. После прочтения смело приступайте к решению типовых System Design задач.

Изучая System Design, вы часто видите только теоретические материалы. В этой статье я постарался показать в том числе практическую реализацию многих вещей, чтобы вы не просто готовились к собеседованиям, но и знали, как эти вещи используются в реальном мире.

Хабр, привет. На связи Оксана Рубанова, разработчик на платформе Optimacros.

Бывают моменты, когда от тебя ничего не зависит, случается что-то плохое просто потому, что оно иногда случается. А бывают моменты, когда понимаешь, что ты – часть / причина этого плохого, но не понимаешь, как до этого докатился, с чего все началось и главное, как теперь это исправить, учитывая масштаб бедствия (и не важно, личная это сфера или рабочая).

Так что ту часть проблем, на которую я имею влияние, я захотела проанализировать и улучшить.

В статье поговорим про:

1. Теории накопительного эффекта и разрушенных окон и их влияния на нас

2. Проблему внутреннего тестирование на проектах и идею, как его можно усилить

3. Рабочий эксперимент с командой, длинною в месяц

4. Результаты участников по итогам челленджа

5. Мои выводы со стороны организатора

Всем привет. Меня зовут Михаил Потапов, я - главный системный аналитик компании "Ростелеком Информационные Технологии". В компании занимаюсь разработкой отчетности для сегмента B2B и проектированием хранилища данных, на базе которого эта отчетность функционирует. Работоспособность каждого отчета напрямую зависит от корректно выстроенных SQL-запросов к базе данных Oracle, поскольку при работе с большими объемами данных скорость выполнения запросов может существенно снижаться. Снижение скорости сильно затрудняет работу с отчетами для конечного пользователя, а в некоторых случаях и вовсе делает ее невозможной.

В этой статье мы рассмотрим основные принципы оптимизации запросов в Oracle SQL, которые помогут ускорить работу с базой данных и повысить эффективность работы. Сразу отмечу, что статья рассчитана на junior и middle-специалистов, которые пишут сложные запросы к базе данных, работают с большими объемами данных и при этом ранее с вопросом оптимизации не сталкивались. Статья не содержит подробное руководство к действию, но описывает базовые основы "культуры кода", соблюдение которых позволит снизить нагрузку на БД и даст возможность более эффективно извлекать из нее данные.

Привет, Хабр! Меня зовут Денис Зеленых, я дизайнер, арт-директор, а также ревьюер в Яндекс Практикуме. В этой статье хочу поделиться универсальными рекомендациями по написанию промтов для нейросетей.

Прочитал и посмотрел почти все статьи и видео по Obsidian, которые вышли недавно (в среднем не более 1-2 ух месяцев назад). Дал каждому источнику субъективную оценку и написал короткий комментарий.

Меня зовут Женя, я главный разработчик в компании ITFB Group. По долгу службы я общаюсь с большим количеством разработчиков: собеседую, помогаю в развитии, выступаю наставником, иногда оказываю психологическую поддержку. Кому-то советую книги, предлагаю использовать те или иные популярные процессы или просто стараюсь подсказать что-то, что опытный инженер считает фундаментальным. 

Пройдя путь от начинающего до немного продвинутого инженера, я выделил несколько важных советов и решил оформить их в пост. Не претендую на сакральность, но считаю, что вещи, описанные ниже, могут быть весьма полезны разработчикам любого уровня, особенно в неспокойные моменты карьерной жизни.

Вот один из карьерных путей в разработке ПО:

1. Проведите несколько первых лет в небольшой компании, не понимающей технологий. Теперь вы единственный программист или один из немногих.

2. Случайно создайте очень плохую систему, но чтобы компания этого не понимала. Вы тоже пока этого не понимаете.

3. Потратьте кучу времени на эксплуатацию этой критичной для бизнеса системы, которую, похоже, понимаете только вы. Начните считать, что система, возможно, неидеальна из-за того, что постоянно ломается.

4. Освойтесь в устранении неполадок и в возврате системы в строй. Получите несколько повышений в зарплате и должности, пока в ней не появится слово «Senior»; скорее всего, это произойдёт не позже чем спустя три года после того, как вы начнёте устранять неполадки системы.

5. Оставайтесь в компании много лет, солидную часть своей карьеры, пытаясь устранять ошибки, которые совершили в первоначальной системе.

6. Каждые несколько лет получайте ещё одно повышение и красивое дополнение к названию должности.

Для всех джунов в разработке и тех, кто хочет ими стать.

Так бывает в жизни, что периодически каждый оказывается в роли джуна. Это не только про начало карьерного пути, но и про новые навыки: изучить новую технологию, язык программирования. А вдруг кто-нибудь из вас захочет резко сменить карьерный вектор и залететь в ИТ, например, из HR, как это сделала я?

Привет! Меня зовут Даша, я iOS-разработчик в Точке.

Так сложилось, что я побывала по обе стороны баррикад, причём, как ни забавно, в обратном порядке: пришла в разработку из HR. 

Изначально я была IT-рекрутером: брала джунов в Точку и помогала командам выстроить процесс их адаптации так, чтобы они смогли вырасти в дальнейшем. А потом, по законам кармы, сама оказалась в роли джуниор iOS-разработчика и попробовала всё ранее придуманное на своей шкуре. 

Жизнь длинная, и всё бывает: ещё вчера ты был уверенным в себе профессионалом, а сегодня стал беспомощным младенцем. И это не очень приятное ощущение. Хочется как можно быстрее превратиться обратно в самостоятельного человека. 

Лови 9 советов, которые помогут тебе сделать это легче.

Эффективно управлять можно только той собственностью, которую мог бы создать сам.
Кто не может создать, – будет только разрушать!
И.А. Дедюхова, Кодекс Хамурапи

Краткое содержание

Новый директор себе в подчиненные и советники пригласит своих «проверенных людей». Увеличение штата топ-менеджеров в условиях фиксированного ФОТ повлечет за собой сокращение рядовых сотрудников на значительный процент.
Новый директор в первую очередь будет сокращать те подразделения, работу которых он не понимает. Под прессом психологического давления руководители этих подразделений возмут на себя обязательства самостоятельно разработать планы по сокращению и принять на себя все риски их реализации.
Сокращения пройдут под флагом повышения эффективности, но для «непонятных директору» подразделений не смогут сформулировать критерии этой эффективности, кроме «минимизации затрат». Цель по минимизации затрат без дополнительных обоснованных ограничений – это цель по уничтожению, и не имеет отношения к настоящей оптимизации.
Отсекая непонятные ему части компании (выводя в аутсорс и т.п.), директор попытается превратить компанию в ту, работу которой он полностью способен понять, которой он в полной мере способен управлять.
Проблему нехватки знаний в технической области новый директор и его команда компенсируют «помощью» от западных консалтинговых компаний. Это приведет к ситуации внешнего управления, причем без всякой ответственности за диктуемые извне решения.
Внешняя и внутренняя отчетность о работе компании до самого конца не будет показывать никаких признаков проблем, т.к. тому, кто принес плохие вести не выдают премию, а рубят голову.