В последнее время тема собеседований, особенно на Хабре, стала очень актуальна. В каждой статье кандидаты жалуются, что стало много собеседований и советуют друг другу ИИ‑инструменты, которые помогут сломать эту стену. С другой стороны, компаниям не нравится, что просто обычного разработчика средней квалификации уже сложно найти и надо потратить много времени на это.

Совсем недавно появилась статья: «Читерство в законе. Как пройти собеседование и устроиться на работу в дивном новом мире». Если коротко, то в ней говорится о том, что для того, чтобы устроится на работу необходимо специально тренироваться для прохождения собеседований. Все друг друга обманывают (как HR со стороны компании, так и сам кандидат).

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

C 2019 года мир привыкал к новой реальности и приспосабливался к удаленной работе. На дворе 2025 год и теперь вызов для распределенных команд — не просто организовать совместную работу вне офиса, но и подготовиться к блокировкам сервисов, к которым уже успели привыкнуть. Как организовать работу небольшой команды разработчиков (до 50 человек), если у вас нет отдела DevOps и бесконечного бюджета на on-premise и облака, а каждый новый день доступных сервисов становится всё меньше? В статье постараюсь ответить на этот вопрос.

Я Олег Юрчик — старший python-разработчик, сейчас работаю в Cloud.ru За последние два года я организовывал инфраструктуру для трех небольших команд (до 15 человек), а еще около двух лет держу домашний сервер с семейной инфраструктурой: файлохранилище, менеджер паролей, календарь, книгу контактов и так далее. Хочу поделиться, к каким решениям я пришел за это время, а также пошагово, но не вдаваясь в подробности, рассказать, как развернул собственную цифровую крепость.

Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке.

Сегодня мы поговорим на тему, связанную с корутинами, а именно погрузимся чуть глубже в недра компилятора Kotlin. На данную тему мы с Александром Гиревым готовили доклад на «Мобиус».

В рамках подготовки доклада нам пришлось заглянуть в святая святых для всех «андроидеров», а именно в исходники компилятора Kotlin. Ну что ж, поглядим, что мы там накопали. Поехали!

Предупреждение: в этом посте активно используется язык ассемблера x86_64, в котором я ни в коем случае не являюсь специалистом. Для написания статьи мне пришлось изучать приличный объём материалов, и, возможно (почти наверняка), в ней есть ошибки.

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

Для оптимизации хода освоения навыка формирования Требований к Информационной системе (далее - ИС), разберем сначала упрощенный процесс. Обсудим, как может происходить анализ системы и формирование требований к ней, используя прием реверс-инжиниринга. То есть, рассмотрим уже существующую систему и постараемся воспроизвести процесс формирования требований для ее создания

Чаще всего процесс формализации требований к целевой системе включает 3 этапа:

Пока вы печатаете визитки, кто-то рядом печатает деньги

Если бы в бизнесе вручали премии за выстрел себе в ногу — Kodak взяла бы два «Оскара»: компания дважды за свою историю упустила шанс стать лидером в области цифровой фотографии. Еще в 1970-х инженер Kodak Стивен Сассон изобрел цифровую камеру, однако руководство не стало развивать направление дальше. Затем компания проигнорировала новый рыночный сегмент в 1990-х и продолжала продавать пленку, пока цифровая фотография завоевывала мир. В итоге в 2012 году Kodak подала заявление о банкротстве.

Эта история — жизненный урок для компаний из любых сфер. Сколько раз компании пропускали рыночные сигналы, не видели возможности для трансформации и теряли бизнес, потому что не адаптируются к новым условиям. 

Меня зовут Руслан Галифанов, я основатель группы полиграфических бизнесов: цифровой типографии, сети копировальных центров и облачного сервиса автоматизации типографий.

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

Привет, Хабр!

Сегодня разберёмся, зачем Go-проекту слой Application / Use-Case: как он герметично изолирует бизнес-логику, позволяет переключаться между HTTP, gRPC, Cron-джобами и очередями, а заодно экономит тесты и нервные клетки.

Публикация приложения в RuStore — это больше, чем просто загрузка установочного файла на платформу. Чтобы избежать обрушения рейтинга, шквала негативных отзывов и экстренного отката версии, важно выстроить грамотный процесс: от тестирования до финального релиза.

Меня зовут Валентина Князева, я менеджер продукта в RuStore. В этой статье поделюсь тремя ключевыми инструментами, которые помогут сделать публикацию в нашем сторе надёжной, предсказуемой и удобной:

- альфа-тестирование с реальными пользователями;

- использование формата .aab вместо привычного .apk;

- автоматизация публикации через RuStore API.

В сентябре 2025 года Яндекс и ИТМО открывают онлайн-магистратуру «Фронтенд- и бэкенд-разработка». Анастасия Ждановская, руководитель программы со стороны Яндекса, рассказала, как устроена магистратура для начинающих и опытных программистов, что входит в программу, как создаются учебные материалы и как на неё поступить.

Всем привет! В данной статье я поделюсь своим опытом написания сервиса. Я не являюсь опытным или профессиональным разработчиком, я пишу свой проект и мои решения могут быть не самыми оптимальными. Эта статья состоит в основном из моих решений при написании сервиса, что могут быть не идеальными. Мой путь не является правильным и потому - судите "строго". Так же порекомендую прочитать предыдущие мои статьи.)

Когда Java-приложение внезапно начинает «подвисать», причина почти всегда кроется в прозаичных деталях: неоптимизированных циклах, неудачном выборе коллекций, забытом кэше или агрессивном GC. В этой статье — 10 практических техник, которые помогут выжать максимум из JVM без преждевременной микрооптимизации и шаманства. Только доказавшие свою эффективность подходы, которые реально работают в проде — от финтеха до высоконагруженных API.

Представим себе идеальный центр управления: метрики в норме, зеленые графики, контроль на всех уровнях. Но когда система начинает сбоить, кто берет управление на себя? Кто видит всплеск latency и не ждет, а действует?

Этот комикс — об инженерной миссии без паники, но с вызовом. Про то, как DevOps и SRE-специалисты справляются с аномалиями не на адреналине, а на архитектуре, процессе и взаимопонимании в команде. Про реальность, где высоконагруженные проекты — не просто строчка в описании вакансии, а зона личного влияния: ты действительно управляешь, решаешь, отстраиваешь.

Каждый день в Яндекс Картах строят миллионы пешеходных и велосипедных маршрутов. Несмотря на популярность, этот тип маршрутизации давно не менялся. В прошлом году мы решили его улучшить: проанализировали недостатки и узнали, что на самом деле нужно пользователям. Теперь мы готовы поделиться результатами крупного обновления наших маршрутов.

Меня зовут Антон Овчинкин, я руководитель разработки пешеходной и транспортной навигации в Картах. Я расскажу, как мы научили алгоритмы обходить промзоны, создали ML‑модель расчёта времени в пути с учётом светофоров и подъёмов, а ещё — как связана пешеходная маршрутизация и подсчёт калорий.

Привет, Хабр! Я Настя, редактор YouGile — мы делаем систему управления проектами. Когда-то мы выяснили, что первыми закрываются компании, где ставится много задач. Теперь поговорим, реально ли работать над несколькими задачами одновременно и что об этом говорят исследования.

Go — язык, который ценится за простоту и чёткость. Однако даже при минимальном синтаксисе здесь есть нюансы. Особенно это касается работы с функциями и методами. В этой статье хочу поделиться личными наблюдениями и выводами по нескольким ключевым темам: выбор типа получателя, использование именованных параметров результата, распространённые ошибки при возврате nil, проблемы с файлами в качестве входных данных и поведение defer.
ps. Обложку нейронка сгенерировала. Очень странно, но мне понравилось.

Привет, Хабр. Меня зовут Иван Фитискин, я senior-QA-инженер в Профи.ру. Работаю здесь уже семь лет, а пришёл сразу после университета — и сразу на должность тестировщика. Это с самого начала было моё: я люблю глубоко разбираться в процессах и докапываться до деталей. Это, наверное, больше соответствует моей личности. 

Но я всё равно остаюсь рядом с разработкой. Делюсь наблюдениями, как размываются грани профессии. Ну и немного ностальгирую.

При нагрузочном тестировании баз данных Tantor Postgres или других на базе PostgreSQL с использованием стандартного инструмента pgbench отсутствие фиксации деталей окружения (таких как конфигурация СУБД, характеристики сервера, версии ПО) часто приводит к нерепрезентативным результатам и необходимости повторных тестов. В статье рассматривается разработанный автором инструмент pg_perfbench, который призван решить эту проблему.