courses

В Google дежурному SRE ставят предел: не больше двух инцидентов за 12-часовую смену. На каждый, вместе с поиском причины, исправлением и постмортемом, уходит около шести часов. В большинстве предложений о дежурстве таких норм обычно нет, там «по очереди» и сумма — например €300 в неделю. Разбираем, как перевести это в ночи без сна и о чём договориться прежде, чем сказать «да».

Стив Хьюинь 17 лет проработал в Amazon, дослужился до главного инженера и провёл почти тысячу собеседований. По его наблюдениям, кандидат тратит на техническую подготовку 95% времени и только 5% на всё остальное. А те, кто не получил оффер, редко проваливались из-за техники: подводило то, как они себя подавали. Разбираем, сколько алгоритмов действительно хватит для собеседования на сеньора и куда деть остальное время.

После перерыва в карьере есть три пути: вернуться джуном, пойти на оплачиваемую программу для возвращающихся (returnship) или сразу откликаться на свой уровень. Разбираем, кому что подходит и когда шаг вниз всё-таки оправдан.

«Начинает казаться, будто я знаю, что делаю, — верный признак, что дело неладно». Чарити Мейджорс, сооснователь Honeycomb, так описывает момент, когда ей пора менять роль. Если вы который год на одном грейде, знаете проект наизусть, а все места над вами заняты, рука сама тянется к вакансиям с тайтлом повыше. Впрочем, новая должность  не единственный способ снова оказаться там, где вы чего-то не знаете.

«Если рядом с вами нет джунов, вы не сеньор». Эту фразу Жером Петаццони, в прошлом инженер Docker, услышал на конференции в 2014 году и пересмотрел своё отношение к наставничеству. Сейчас нечто похожее может быть указано прямо в карьерной лестнице компании. Но чтобы менторство засчитали, о нём лучше договориться заранее, пока джуны ещё не пишут вам в одиннадцать вечера.

Что будет, если AI ошибётся в вашей задаче, и сколько времени уйдёт, чтобы эту ошибку найти? Если начальство попросило «внедрить AI везде», начинать надо именно с этого вопроса.

Заметки полезны — они помогают довести идею до нужного результата: найти справку, восстановить ход исследования, объяснить решение команде или использовать старую мысль в новом тексте. Для каждой из этих задач нужен свой маршрут. А значит, прежде чем выбрать приложение, стоит разобраться, какие записи у вас появляются, куда переходят и в какой момент становятся полезными.

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

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

Представьте, что дизайнера в команде нет, а экран надо выпускать. Саппорт пишет, что люди не находят нужную кнопку, тимлид просит переделать форму по-человечески, а в тикетах раз за разом возникает: «Не понимаю, что здесь нажать». 

Вы сильный сеньор, коллеги приходят за советом, руководитель зовёт поговорить: «Хотим попробовать тебя тимлидом». Звучит как признание. Возможно, ещё и денег добавят. Отказываться неловко — вдруг это тот самый карьерный шанс, который нельзя упускать?

Сколько раз за вчерашний день вы что-то проверяли? Календарь, почту, два мессенджера, баланс карты, не забыли ли продлить подписку. Каждая такая проверка занимает секунды, и поэтому времени не жалко. Но к вечеру из этих секунд набирается второй рабочий день — только без зарплаты и выходных.

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

Вы садитесь за свой проект в десять вечера, потому что днём было некогда. Правите баг, замечаете второй, к полуночи переписываете модуль, который вообще-то работал. А наутро вспоминаете про дедлайн, который сами себе и поставили. Кажется, это уже не совсем хобби.

Есть ловушка, в которую легко попасть после нескольких лет карьеры в IT: вроде бы проходишь курсы, собираешь сертификаты, постоянно учишься и добавляшь в резюме новые технологии, но на собеседовании показать всё равно нечего. Попробуем разобраться, что с этим делать.

Сначала в календаре появляется ежедневный статус, потом еженедельный синк, потом встреча «по итогам», встреча «перед встречей», отчёт, презентация и пара уровней согласования сверху. У каждого из пунктов когда-то была причина, но вопроса жива ли она, с тех пор никто не задавал.

Коан: «Незаменимость — единственный технический долг, которым принято гордиться».

Slack, Jira, код, потом письмо, созвон, ещё пять вкладок после него — и вот уже обед. А главная задача, ради которой вообще открывали ноутбук, не сдвинулась ни на шаг. Куда уходит время?

Пару лет назад «добавить AI в продукт» почти автоматически означало, что в команде нужен ML-инженер. Сегодня под AI понимают совсем другие задачи: поиск по документации, чат-ассистента, автоматизация обработки писем, генерация отчетов или создание внутреннего помощника. 

Знакомый записался на ML-курс за две тысячи евро, а в LinkedIn постоянно рассказывают, что без AI через пару лет никто не будет нужен. Вы тоже смотрите программу обучения, где первым пунктом идет линейная алгебра, затем статистика, потом оптимизация. И если в этот момент возникает желание закрыть вкладку — вы не одиноки.

Вы только что обновили README, добавили схемы в Confluence и закрыли самые частые вопросы. Но через пару дней кто-то из коллег всё равно пишет: «А как правильно?» Обычно после такого предлагают лучше  документировать — и начинают добавлять страницы. Есть другое решение.

Семь лет коммерческой разработки, десятки успешно закрытых задач, сложные фичи, оптимизация производительности. И тут на собеседовании просят: «Спроектируйте систему для сервиса бронирования». Через несколько минут становится не по себе. Кажется, вы чего-то не знаете, хотя опыт объективно большой.

Зарплаты не растут, проекты выбирают новые технологии, а вместо разговора об опыте на собеседовании спрашивают: «Почему вы до сих пор не перешли на что-то современное?» Самая плохая реакция здесь — убедить себя, что рынок скоро передумает. 

Принято считать, что если человек стал сильным разработчиком, то навык чтения чужого кода придёт сам собой. Практика и исследования говорят об обратном.

Новый вариант регистрации показывает по дашборду +3% к конверсии. Продакт уже пишет в чат: «Катим?». Аналитик отвечает уклончиво: «результаты многообещающие». Все смотрят на вас. 

Каждую неделю в IT появляется новый «обязательный» навык. Вчера все учились писать промпты, сегодня поднимают MCP-серверы, а завтра в ленте кто-то расскажет про ещё один агентный фреймворк. Пропустишь пару новостей и уже кажется, что через полгода останешься за бортом.

Проблема может быть совсем не в алгоритмах. Рассказываем, почему сильные инженеры из сервисных компаний нередко теряются на продуктовых интервью и как понять, что докручивать — стек и алгоритмы или product sense.

Вы тоже считаете, что квантовые компьютеры — просто дорогие игрушки, которые заработают (в лучшем случае) через тридцать лет? Если так, давайте разбираться. Спойлер: если нет — пора изучать. 

В среде разработчиков все еще силен красивый, но опасный миф: «Хороший код говорит сам за себя, а лучшее резюме — идеально зеленая сетка коммитов на GitHub». В идеальном (академическом) мире этого, возможно, хватило бы. Но в реальности, где за сильные позиции в стартапах борются тысячи талантов, молча писать код — это сознательный отказ от половины карьерных возможностей.

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