Как был устроен oncall, в нашей команде в Amazon

Все разработчики нашей команды по очереди выполняют саппорт наших компонентов. Дежурство длится 1 неделю и повторяется примерно каждые 1,5–2 месяца. Таким образом, за год приходится дежурить до 8 раз (то есть 2 месяца из 12 посвящены поддержке).

Ops Review
Дежурство начинается с митинга под названием Ops Review, на котором вся команда разработчиков собирается вместе. Предыдущий oncall рассказывает, какие тикеты были закрыты на прошлой неделе, какие остаются открытыми, а также делится тем, что было сделано для улучшения ситуации с тикетами. Во время митинга открываются основные дашборды и метрики, чтобы убедиться, что всё в порядке.
Отдельно мы трекаем тикеты, которые повторяются часто, и добавляем их в список задач для поиска долгосрочных решений. Цель — сделать так, чтобы подобные тикеты либо не появлялись вообще, либо возникали реже.

Тикеты
Наши компоненты генерируют огромное количество различных метрик. Код эмитирует эти метрики в специальную внутреннюю систему, похожую на AWS CloudWatch (иногда мы использовали и её). Это могут быть как бизнесовые, так и операционные метрики. Для их мониторинга у нас были созданы дашборды и, что особенно важно, настроены алармы.
В определённых условиях, если метрика отклоняется от ожидаемого поведения, автоматически создаётся тикет, который попадает в ticket queue текущего oncall. В описании тикета указана причина его создания, метрика, которая вызвала срабатывание, и runbook — инструкция, что делать в этой ситуации. Однако иногда runbook отсутствует, и тогда приходится самостоятельно разбираться и искать root cause.
Помимо стандартных тикетов, система может создавать инциденты (sev) с разными уровнями приоритетов. Например:
Sev 0 — упал критически важный компонент, затрагивающий всю компанию. Это обычно становится очевидно не только нам, но и СМИ.
Sev 1 — отказ критического компонента для конкретной функциональности и т.д.
Как только создаётся инцидент (sev), текущего oncall не только уведомляют тикетом, но и пейджат. Это значит, что рабочий телефон начинает орать, и oncall обязан принять пейджинг в течение нескольких минут — даже если это случилось ночью. Если кнопку принятия не нажать, пейджер переадресует вызов на вашего менеджера, затем на менеджера вашего менеджера и так далее, вплоть до CTO или CEO компании, если это sev 0.
При работе над sev вначале важно митигировать проблему, а не искать и устранять root cause. Нужно очень быстро сделать rollback, рестарт, восстановление из бэкапа, выключить какую-то функциональность и т.д. Как только митигация сделана, на следующий день уже можно заняться рук козом.
Если над sev вам нужно работать в том числе и ночью, то над обычными тикетами вы можете работать только днем. Вы можете искать их причины, устранять их. Иногда алармы слишком чувствительны и нужно изменить их настройки, чтобы он не срабатывал без существенной причины. Иногда алармы часто повторяются и вы можете придумать решение, которое это предотвратит.
Тикеты могут быть созданы автоматически по метрикам или исключениям, которые бросает код. Но также их можно создать руками. Если другие команды что-то от вас хотят в плане поддержки они могут руками создать тикет.

Какой был опыт использования Scrum в Amazon

В Amazon каждая команда решает, будет ли она использовать какую-либо методологию или нет. Наша команда и смежные команды использовали Scrum, но не в чистом виде.
В Amazon, как и в других FAANG компаниях, ключевыми процессами являются: планирование в начале года и performance review в конце по результатам. Execution можно организовать как угодно.
Scrum, в чистом виде, плохо подходит под performance review программистов. Если программисты будут просто брать высокоприоритетные задачи из общего пула, которые относятся к разным проектам и целям, то очень сложно будет описать цельную историю достижений. Поэтому в FAANG компаниях программисты работают над конкретным проектом. Они или делают его от начала до конца (анализ, дизайн, реализация, тестирование, мониторинг и т.д.) или если это большой проект, то либо драйвят весь проект, но конкретные куски могут делать другие программисты, или делают подпроект в рамках большого проекта. В таком случае очень легко написать нарратив достижения.
Кроме того, у команды нет внешнего или даже явного внутреннего заказчика. Обычно, стейкхолдерами могут быть другие команды, которые зависят от вас, или этот проект родился внутри самой команды или пришел от высшего менеджмента. Конкретными стейкхолдерами могут выступать TPM'ы вашей или других команд, менеджемент, разрабы из других команд и т.д. Поэтому демо раз в две недели для получения фидбека и перестройки требований не происходит. Но демо у нас были раз в две недели или раз в месяц. Мы приглашали TPMов, менеджеров или разрабов из других команд. Это помогало для knowledge sharing, повышения visibility вышей работы и получения фидбека.
Различные церемонии в рамках скрама также играли роль knowledge sharing, получение фибдека, обсуждения потенциальных зависимостей между проектами и рисков.
Еще одна плюшка от скрама - это создание чувства упорядочения. Я это почувствовал только в ретроспективе, когда перешел в Facebook. В Facebook совершенно другая культура работы, не похожая на остальные компании. Сначала может быть сложно понять, как вообще организовать свои задачи — полный хаос и необходимость перестроить все привычные подходы к работе.

Как конкретно был организован процесс в нашей команде в Amazon?

Церемонии:
1) Backlog Grooming. Делали оценку сложности задач и их приоритетов. Обычно, вначале создатель таски, описывал о чем задача и зачем нужна, далее делалась оценка сложности. При необходимости задача разбивалась на несколько, если сложность не помещалась в один спринт.
2) Sprint Planning. Оценивалась капасити команды в зависимости от числа разрабов, которые будут работать во время спринта. В рамках оценки капасити учитывалось, что один разраб будет oncall, также закладывалось часть капасити на технический долг и улучшения operational excellence. Обычно, это было 20%. Еще 20% на oncall. Далее формировался спринт из высокоприоритетных задач. Каждый разработчик, по сути, добавлял следующие задачи, над которыми он планирует работать в рамках своего проекта. С учетом oncall и работы над техническими задачами.
3) Stand Ups. Тут все как обычно, что было сделано, что планируется сделать, какие риски и блокеры. Если возникали длинные дискуссии, то выписывали их отдельно и обсуждения шли только между заинтерисованными участниками.
4) Demo. Кратко презентовали свои достижения в рамках спринта. Приглашали менеджеров, разрабов или лидов из других команд, TPMов.
5) Retro. Кратко, обсуждали плюсы и минусы, составляли action items по улучшению. По факту, просто сеанс психотерапии.
Scrum Master у нас менялся раз в 3-6 месяцев. Это, просто, был один из разрабов команды.
Раз в месяц у нас был roadmap review с менеджером. Про roadmap напишу отдельным постом.

Плюсы от того, что у нас был Scrum:
1) Knowledge sharing. Вся эта куча митингов помогала понять, над чем работают коллеги. В Facebook это работает по другому, тут нужно следить за постами в десятках групп, подписываться на конкретных разрабов и т.д. Тут используется Facebook Workplace, что является, смесью соц сети, slack и zoom.
2) Обсуждение зависимостей от проектов и рисков. Вытекает из предыдущего пункта. В Facebook нужно, снова таки, следить за постами, документами, code change и проактивно во всем этом участвовать и вникать, чтобы что-то узнать.
3) Упорядочение работы. Несмотря на то, что разрабы работают над своими задачами и проектами, вы можете спланировать, что сейчас я буду работать над этой задачей. А не над всеми задачами сразу.
4) Чувство командной работы. Хотя вы работаете над своим проектом, вы можете получить фибдек и помощь от коллег.

Минусы:
1) Много митингов. Много времени тратится на церемонии, которое можно было бы потратить на работу, которая отразится на вашей оценке перфоманса.
2) Много бюрократии в случае смены планов. Разбиение на спринты хоть и упорядочивает вашу работу, но, обычно, ваши планы могут поменяться за эти две недели. И, часто, задачи в рамках спринта приходится менять. В Facebook можно хоть каждый час менять свои планы и приоритеты.
3) Оценка капасити — это бесполезная штука. Велосити команды нестабильное, и почти никогда задачи, добавленные в спринт, не выполняются полностью. Обычно задачи просто перекочёвывают из одного спринта в другой. Это добавляет чувство вины за то, что не сделал то, что запланировал. А вот в Facebook всем пофиг. Там планирование раз в 6 месяцев, есть performance review, а в крупных проектах — milestones. Как вы их разбиваете на подзадачи и в каком темпе их делаете — вообще не важно. Делайте так, как вам удобно.

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

Прошло уже 2 года с момента релиза ChatGPT

Кратко мои мысли:

ChatGPT постепенно заменяет следующие продукты:
1) Google Search. Может случиться история, похожая на то, как сам Google заменил Yahoo. Пока до этого далеко. Но угроза есть.
2) Google translate(и подобные).
3) Stackoverflow.
4) Спелчекеры. Подобные Grammarly.

LLM появляются в виде доп. функционала в разных приложениях. Например, в среде разработки.

LLM повлияли на число вакансий программистов, но не из-за их замены, а из-за того, что все компании начали делать AI. При ограниченном бюджете открывают больше вакансий для работы над AI, по сравнению со всем остальным(ML позиции).

Текущее состояние LLM не способно заменить программистов. Из-за отсутсвия агентности и галлюцинаций. Более того, LLM не пригодны для использования в простейших автоматизациях из-за галюцинаций.

На сколько я напрограммировал в 2024?

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

До уплаты налогов:
£547k/$698k/69 миллионов рублей.

После уплаты налогов(приблизительно, еще надо capital gain tax вычесть):
£301k/$384k/38 миллионов рублей

Или в месяц после уплаты налогов на руки:

£25k/$32k/3.1 миллионов рублей.

Подавляющая часть этих доходов за счет стоков(RSU), которая выплачивает компания. А они сейчас ушли в космос.

За 4 года работы в компании в общей сложности я заработал ~$1.7 миллиона долларов до уплаты налогов.

Вроде и не плохо, но знаю случаи коллег из США, кто начал работать пряма с универа в компании и к 30 думает уже на пенсию выходить. У меня пока так не получается...

О недвижимости в UK

Начну с того, что тут есть несколько форм собственности:

1) Leasehold. Почти все квартиры в Англии попадают под эту категорию. По факту, вы не владеете в полной мере недвижимостью. Вы владеете долгосрочной арендой. Новые квартиры сейчас идут с lease на 999 лет (так называемый virtual free hold), более старые могли быть на 250 и 125 лет. Когда срок истекает - квартира переходит во владение владельцу земли (freeholder). Это пережитки феодализма. Землей владели лорды (landlords) и вы могли у них взять землю в аренду. Вы имеете право продлевать аренду на 90 лет. Но это стоит денег и может сильно зависеть от того, сколько аренды осталось. Если осталось менее 80 лет, то продление будет стоить больших денег (в основном из-за так называемого marriage value (после продления рыночная стоимость недвижимости растет и часть этой суммы вам надо заплатить лендлорду)). Кроме того, при такой форме собственности вам надо раз в год платить ground rent (несколько сотен фунтов в год), и service charge (несколько тысяч в год за содержание дома в надлежащем состоянии, уборку в подъезде, дворе, за бассейн, сауну и т.д. если они есть в доме). Это все в дополнение к обычной коммуналке (за свет, воду и т.д.). Таже leasehold ограничивает вас в том, какие изменения вы можете делать в квартире и даже можете ли вы содержать домашних животных. В случае нарушения - у вас могут забрать квартиру и если у вас есть ипотека - вам все равно придется ее выплачивать. Обычно, косметический ремонт разрешается. На более серьезные изменения нужно запрашивать разрешение от landlord. И на многие вам могут ответить отказом. Если вы хотите переделать электрику, водопровод и т.д.
2) Share of Freehold. Обычно, это тоже квартиры, но в более мелких домах на меньшее число квартир. В этом случае землей владеете вы, но совместно с остальными жильцами этого дома. Достаточно редко встречается.
3) Freehold. Вы владеете землей и домом. Под это попадают почти все частные дома. У вас нет ни ground rent, ни service charge. Вы можете делать более серьезные изменения внутри дома и сада. Иногда разрешения все же нужны, но их нужно получать у государства. Особенно, если хотите менять фасад.


Новые дома и квартиры.

Тут также есть новостройки. Это могут быть и квартиры в новых домах, но также это могут быть и частные дома (на наш язык это таунхаусы или коттеджи). На стадии котлована и дешевле их купить нельзя (я по-крайней мере про это ничего не знаю). Вы покупаете уже готовый дом или квартиру уже с ремонтом, техникой и кухней. Иногда вам могут даже предложить набор остальной дизайнерской мебели за деньги.
Новые квартиры и дома стоят тут дороже вторички. И как только вы ее покупаете и начинаете в ней жить - цена тут же падает (так называемый new build premium). Почти как с новыми автомобилями. Но зато, вы будете в ней жить первым, у вас будет 10 лет гарантии (серьезные поломки вам починят бесплатно). Новые дома идут с очень хорошим ремонтом и энергоэффективностью (EPC).

Дома
Очень многие в Великобритании живут в частных домах. Даже в городах типа Лондона. Тут существенная часть спальных районов - это частные дома. Чтобы было понятно, по нашим понятиям это ближе к таунхаусам или коттеджам. Но они могут достаточно старыми и с маленькой площадью. У них есть своя парковка и небольшой задний двор/сад. Типичный дом - это дом с тремя спальнями (4 комнаты по нашему) и двумя санузлами. При это площадь может быть 80-85 квадратных метров. В нем обычно 2 этажа. Иногда бывает 3. Дома стоят дороже квартир, т.к. это freehold. Цена на дома обычно только растет. За исключением новых домов. Там может быть небольшое проседание в первые 5-10 лет, но дальше они растут и достаточно быстро.

Квартиры.
Часто, в многоквартирных домах есть консьерж, бесплатный спортзал. В некоторых есть бассейн, сауна, джакузи. Но из-за этого service charge может достигать 4-5 тысяч в год. Цена на квартиры растет, но медленней. Если это новая квартира, то проседание может длиться дольше и существеннее, чем на дома. Если lease остается меньше 90 лет, то цена начнет падать.

The Leasehold and Freehold Reform Act 2024
В королевской речи 2024 анонсировали существенный пересмотр leasehold в пользу leaseholders. Но его внедрение займет еще пару лет. Он позволит продлевать lease не на 90 лет, а до 990 лет. Также он отменяет marriage value, что удешевит продление lease для квартир с lease меньше 80 лет. Также он позволит сделать премиум продление, которое сократит ground rent до нуля.

Цены и ипотека.

Медианные цены на разную недвигу в Лондоне и ориентировочный месячный платеж при 20% первоначальном взносе и 25 лет сроке ипотеки.

Квартиры:
1) Студия. £375k, £1.7k в месяц.
2) Двушка (1 bed). £425k, £1.9k в месяц.
3) Трешка (2 beds). £600k, £2.7k в месяц.

Дома:
1) 4-комнатный дом (3 beds). £700k, £3.1k

Есть также опция купить дом или квартиру в соседних городах. Там цены в 1.5-2 раза дешевле!
Только придется ездить на поездах. Поезда при это скоростные и очень комфортабельные. Можно за 20 минут-час доехать до центра Лондона из такого пригорода.
Пример дома за £400k в часе езды от центра Лондона: дом.

Какую систему контроля версий использует Meta?

Как это не странно, но это не Git. Она использует Mercurial.

Почему?
Вначале она использовала Git. Но по мере роста code base и за-за того факта, что Meta использует монорепу, перфоманс Git оказался недостаточным и не приспособленным для гигантской монорепы.
Facebook попытался пообщаться в командой Git, но ответ был - дробите на маленькие репозитории.
После общения с Mercurial Facebook слелал форк кода и сделал его масштабируемым до невероятного размера репозиториев + сделала куча своих тулов для работы с ним. Сейчас это все работает очень быстро и нажатием пару кнопок в UI, в 99.9% не нужно знать никаких ручных команд.

Такие ситуации, одна из причин, почему FAANG делают всю инфру с нуля и сами. Чтобы не зависеть от сторонних компаний и разрабов.


Какую систему контроля версий вы используете?

Процесс изменения и деплоя кода в FAANG

Расскажу на примере моей текущей компании.

1) Открываешь среду разработки на своем рабочем маке. У нас это VS Code с кучей кастомных плагинов.
2) Подключаешься к рабочему серверу в облаке. Код локально клонировать нельзя. После подключения к серверу, в среде разработки вы будете видеть свежую версию кода монорепы. И процесс изменения кода ничем не уступает наличию кода локально. Занимает весь процесс несколько секунд. Т.е. вам не надо клонировать, запускать комадны, ждать. Все происходит за секунды по нажатию кнопки.
3) Меняете код. Тут все как обычно. Так же пишите и запускаете тесты. Автоматически, через браузер доступна тестовая версия приложения с вашими изменениями, т.е. можно потыкать UI. Также локально можно запустить тесты только для заафекченного кода.
5) Создаете локальный коммит. В FAANG используется trunk-based-development. Никаких бранчей создавать не нужно. Если вы решили отсоединиться от рабочего сервера, то локальные коммиты не будут потеряны, они синхронизируются в специальное облако с коммитами. Когда вы подключитесь к другой машине, вы увидите свои локальные коммиты.
6) Создаете code review. Напрямую запушить можно только в экстенных случаях. Код проходит ревью и из код ревью тула его можно залендить. Для этого code review должно быть зааксепчено и все проверки должны быть пройдены(запускается линтер, тесты и куча других проверок).
7) Код попадает в trunk и начинается деплоймент, который проходит несколько стадий. В среднем через часа 4 код будет в проде. Т.е. каждый ваш коммит оказывается в проде через несколько часов.

Расходы на жизнь в Лондоне

1) Аренда. Медианная цена: Студия - £1.6k, Двушка (1 bed) - £2.1k, Трешка (2 beds) - £2.9k
Цена ориентировочная, есть дешевле и дороже. Можно за £2.5k найти хорошую 2 beds.
2) Коммуналка. £300-£500 в месяц.
3) Еда и покупки. £300-£500 на человека
4) Доставка и рестораны. £200-£500 в месяц на человека в зависимости от частоты.
5) Машина (страховка, бензин, обслуживание и т.д.). £300-£400 в месяц.
6) Общественный транспорт. £200-£400 (если живете далеко и часто ездите на поезде).
7) Спортзал. 0-£100. Часто он есть бесплатный в доме.
8) Одежда, мебель, электроника, отпуск, покупка машины. Стоит ~также как если бы вы жили в Москве.
9) Ипотека: https://t.me/faangmaster/503. При 20% первоначальном взносе и 25 лет срока ипотеки платеж ~такой же как и за аренду.
10) Мед страховка. Медицина тут бесплатная, но она хуже, чем частная. Очень похоже на Москву. Частная - нужна медстраховка. Работодатели ее предоставляют. Если хотите сами купить, что £100-£300 на семью в месяц.

Станете ли вы богатым человеком, работая в IT?
#мысли

Краткий ответ: скорее нет, чем да.

С большой вероятностью вы станете middle class. Вы сможете не переживать о ценах на еду, пару раз в год кататься в отпуск в любую точку мира, периодически обновлять электронику. Вы сможете позволить себе недвижимость, но в ипотеку. Сможете позволить себе машину среднего класса. Ваше состояние за жизнь будет ~$100k-$1M (стоимость недвиги, машины, сбережений, инвестиций и т.д.).

Небольшой процент станет upper middle class. Это будет касаться сотрудников части FAANG-компаний, менеджеров высшего звена в компаниях поменьше, или успешных бизнесменов средней руки. Но это 1-5% от всех людей, кто работает в IT. Тут я говорю про людей с состоянием за жизнь ~$1M-$10M.

Ничтожно малая часть станет действительно богатыми людьми. Тут я говорю про людей, с состоянием от $10M-$30M. Это успешные крупные бизнесмены, топ менеджмент в крупных или FAANG-компаниях.

Стоит ли сразу создавать свой стартап и заработать десятки или сотни миллионов долларов?
Вероятность успеха стартапа очень низкий. При этом большинство, условно, успешных стартапов не позволяют обеспечить высокий доход, который бы превосходил доходы в крупных компаниях в найме. В подавляющем числе случаев, стартап получает посевные инвестиции, команда из 5-10 человек делает MVP (разработка уровня hello world, но зато с нуля), проедает эти инвестиции, зарабатывая порядка зп в обычном найме. И далее закрывается. Часть выходит на самоокупаемость и продолжает работать в том же авральном режиме, зарабатывая ~ денег в найме. И только малый процент или доли процентов позволяют выйти в категорию upper middle class и выше.

Пишите, что вы думаете в комментариях.

Куда не плюнь, попадешь в CEO с гениальный новым подходом к собеседования

Когда открываю линкедин, постоянно в ленте попадаются "гениальные посты" от очередного CEO.
Если в линкедине поискать по слову CEO и посмотреть, сколько людей с таким тайтлом, то их будет 11 миллионов. При этом число программистов в мире ~30 миллионов.
Т.е. на трех программистов приходится один CEO.

Большинство этих CEO - создатели очередного врапера (на чужую технологию), сделанного на коленке. Сейчас все делают враперы на LLM.
Сейчас сильно развит рынок посевных инвестиций, поэтому достаточно написать хорошую презентацию и уверенно ее презентовать.

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

К чему это приводит? Приводит это к тому, что такие стартапы собеседуют, кто в лес, кто по дрова. Задают рандомные, неоткалиброванные, вопросы и нанимают случайных людей. Вместо этого, можно просто бросать кости или задавать вопрос в стиле: "Я загадал актера, угадай с трех попыток".

Сегодня видел пост от такого CEO, который писал, что его куда-то не взяли, потому что он не знал как работают логические операции (and, or). А сейчас он такой успешный CEO в области AI (очередной врапер), и все эти технические вопросы знает chatGPT и собеседовать нужно не по техническим вопросам, а по вопросам маркетинга и продаж (я не уверен, что он сам в маркетинге разбирается). А технические вопросы нужно спрашивать с возможностью использовать LLM/chatGPT.

Простая задача с собеседования в Google: Merge Strings Alternately
Задача
Даны две строки. Необходимо смержить эти строки в одну. При этом символы в результирующей строке должны чередоваться: один символ из первой строки, затем один символ из второй строки, и так далее. Если строки разной длины, то оставшиеся символы из более длинной строки должны быть добавлены в конец результирующей строки.

Примеры:
Для строк "abc" и "pqk" результирующая строка будет "apbqck".
Для строк "abc" и "p" результирующая строка будет "apbc".

Ссылка на leetcode: https://leetcode.com/problems/merge-strings-alternately

Решение.
Решение описал тут: https://dev.to/faangmaster/prostaia-zadacha-s-sobiesiedovaniia-v-google-merge-strings-alternately-1aa3

Код решения:

public String mergeAlternately(String word1, String word2) {
 StringBuilder sb = new StringBuilder();
 int i = 0;
 while (i < word1.length() || i < word2.length()) {
  if (i < word1.length()) {
   sb.append(word1.charAt(i));
  }
  if (i < word2.length()) {
   sb.append(word2.charAt(i));
  }
  i++;
 }
 return sb.toString();
}

Временная сложность: O(N+M), где N - длинна первой строки, M - длинна второй строки.
Сложность по памяти: O(1), если не считать память на результирующую строку. Если считать, то O(N+M).

Как проще получить повышение? Сменой работы или промоушен на текущем месте работы?

Я делал и так и так. Если у вас уже достаточно опыта работы для следующего левела и ваш скоуп полностью или частично пересакается с более высоким левелом, но вас по тем или иным причинам не промоутят на текущем месте, то намного проще получить новый левел через собеседование.
Очень часто получить повышение сложнее, чем пройти собеседование на более высокий левел. На собеседовании ваш левел, в основном, зависит от вашего резюме и от поведенческой части собеседования. Т.е. вам достаточно поговорить 45 минут про свой опыт, чтобы убедить интервьюера, что вы перфомите на следующий уровень. От технической части это тоже зависит. В основном, от system design или его аналога на собеседовании в другие компании (не Big Tech). Но к этому тоже можно подготовиться.
Работая внутри компании на более низком уровне, для вас изначально есть скоуп на этот более низкий уровень. И от вас ожидают, что вы будете с ним хорошо справляться. Поэтому вы будете перегружены задачами своего, более низкого левела. И даже если вы будете с ними справляться очень хорошо, то вас не повысят, вас будут рассматривать как хорошего/лучшего сотрудника на своем уровне. Для промоушена вам надо показать, что вы работаете и работаете хорошо на следующем левеле. А по умолчанию вам такой скоуп не дадут, т.к. есть люди, более высокого левела, от которых ожидается, что они будут работать над этим скоупом. Поэтому вам надо или этот скоуп создать самому, который гармонично появится из вашей работы на текущем левеле, или вам этот скоуп даст ваш менеджер. Для второго нужно, чтобы ваш менеджер в этом был заинтерисован, чтобы такой скоуп был и именно для вас, и менеджер был бы убежден, что вы с ним справитесь. Т.е. нужно, чтобы сошлось много звезд на небе. Для первого (создать свой скоуп), также не очень просто. Поэтому промоушены очень часто затруднены, особенно, выше левела senior.
Но если вам повезло с менеджером, который умеет и заинтерисован в вашем проумешене. Или вы создали скоуп на следующий левел (часто, это проще если команда/отдел быстро растет, много инвестиций в эту область от компании) и достигли результатов. А также есть позиция/бюджет для человека более высокого уровня, то вас повысят. Но это не всегда и не у всех срастается. В таких случаях, стоит рассмотреть вариант повышения через собеседование в другую компанию.
Я на практике, видел, как люди уходили из Amazon в Microsoft с повышением на один левел и возвращались через пару лет еще на +level. Т.е. они за два года получали +2 левела просто через 2 собеседования.

Что вы думаете об этом пишите в комментариях.

В Мета будет очередной раунд сокращений 10 февраля

В этот раз это сокращение будет на основе перфоманса сотрудников. Сейчас как раз начался процесс PSC (перфоманс ревью). Планируется уволить ~5% по его результатам. Т.е. это затронет несколько тысяч сотрудников (3-4 тысячи). Из них, вероятно, 1-2 тысячи - это разрабы.
При этом в течении 2025 планируется нанять им замену! Т.е. в 2025 появится огромное число вакансий!

Что я думаю об этом?
Это происходит неявно весь 2024 год. Это так называемый silent layoff. В 2024 много нанимали и много увольняли по результатам первоманса. При этом не предлагали pip, а просто сразу severance package (компенсацию). Сейчас это объявили официально. Думаю, чтобы повлиять на цены акций. Кост каттинг всегда положительно сказывается на цене акций + по официальной версии это делается для повышения performance bar для работы над AGI (общий ии).

Каким образом происходит кост каттинг, если на замену уволенным нанимают новых сотрудников?
Старые сотрудники получили много акций по низкой цене во время сильного падения в 2022 году. Сейчас эти акции выросли в 6 раз! Соответственно, куча людей получает гигантскую компенсацию. Поэтому выгодно этих уволить и нанять новых, которым платить initial offer.

Есть вероятность, что большинство новых вакансий будет не 1-1 в тех же командах, а просто будут открывать больше вакансий для работы над AGI. Также новые вакансии скорее всего будут для senior+ сотрудников.

Кофе и продуктивность

Кофе я начал пить, когда работал в Amazon, примерно 6–7 лет назад. До этого я практически его не употреблял. Сначала это происходило время от времени, потом дошло до 1–2 чашек в день, а через пару лет — до 3–5 чашек ежедневно. В определённые периоды я пил даже более пяти чашек в день. В результате у меня сформировалась сильная зависимость. Это негативно сказалось на моей продуктивности, которая стала нестабильной. Чтобы поддерживать её хотя бы на каком-то уровне, мне приходилось постоянно пить кофе. Начались проблемы со сном, повысилась тревожность.

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

Однако положительные изменения начались довольно быстро. Почти сразу после отказа от кофе снизилась тревожность. Через пару недель исчезла головная боль, а спустя три недели полностью восстановился сон и способность концентрироваться. Продуктивность стала стабильной в течение всего дня. Кроме того, я заметил, что повысились интеллектуальные способности: например, в шахматах мой рейтинг (ELO) вырос на 160 пунктов всего за три недели без дополнительного изучения. Просто стало легче видеть тактические ходы.

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

Кандидаты задают странные вопросы

Сегодня провел очередное собеседование. Мы всегда оставляем 3-5 минут на вопросы со стороны кандидата. Достаточно часто встречается такой вопросы: "Какая ваша роль в компании?", "Как проходит ваш день?", "Чем вы занимаетесь в компании?", " В какой команде вы работаете?".

Как по мне, это бесполезные вопросы для кандидата. Ответы на эти вопросы ничего не дают кандидату. Мы не собеседуем в конкретную команду. Team matching происходит после, если кандидат успешно пройдет собесы.
И не понятно, что отвечать, как проходит мой день. Он ничем не отличается от того, что делают другие люди в этой роли (поел, посмотрел мемы и поехал домой. Шучу. Или нет...). По всей видимости, это какие-то рекомендуемые интернетом нейтральные вопросы. Эта часть никак не оценивается. Поэтому я бы спрашивал то, что меня действительно волнует. Прямой негатив , возможно, не стоит выливать. Но задать вопрос, который бы пролил свет на потенциальный консерн, я бы задал.

Структура coding interview в FAANG, оценивание и ошибки

В FAANG-компании на позицию Software Engineer для всех уровней есть coding interview(3-4 таких собеседования), system design (0-2 собеседования в зависимости от левела) и поведенческое (1-2 в зависимости от левела или расспределенное по всех раундам, как в Amazon).

Coding Interview обычно 3. Одно - screen и два на full-loop.

Все собеседования длятся 45 минут.

Структура:

1) Приветствие. 2-3 минуты. Интервьюер кратко представляется, сообщает структуру собеседования.
2) Решение coding задач. Обычно, это одна задача, иногда две. В Meta спрашивают всегда две задачи. Длится эта часть обычно 35-40 минут. В Amazon она длится 20-25 минут, т.к. там выделяется еще 15 минут на поведенческую часть (Amazon Leadership Principles).
Это основная часть, все оценивание происходит тут.
3) Вопросы со стороны кандидата. 2-5 минут. Эта часть не влияет на оценивание, если, конечно, не создаст red flags, вроде оскорблений, неэтичного поведения и т.д.

Оценивание и ошибки в процессе решения задач.

Решение задачи состоит из 4 этапов:
1) Получение задачи и уточнение условий. Вам сообщают задачу. Часто пропуская некоторые условия или нечетко их формулируют. От вас ожидается, что вы уточните условия, сделаете предположения и их подтвердите. Или как минимум переформулируете задачу, чтобы удостовериться, что вы поняли задачу правильно. Тут оценивается прежде всего communication. Типичная ошибка - ничего не уточняя, сразу начинают ее решать. Часто это приводит к тому, что они решают другую задачу, не ту, которую имел ввиду интервьюер. Или решают ту, но получают плохую оценку по communication.
2) Обсуждение возможных решений и их сравнение. Тут нужно брейнстормить идеи решения, сравнить их между собой(space and time complexity) и выбрать оптимальный. Нужно подумать про возможные edge-cases и как ваш алгоритм будет их хэндлить. Тут оценивается problem solving скил и communication. Типичная ошибка - человек молчит и застревает. Проговаривайте мысли вслух, это позволит интервьюеру понять, где вы застряли и подсказать вам. Если вам надо состедоточиться и подумать самостоятельно 2-5 минут это нормально. Скажите это, подумайте и потом начните обсуждения. Еще типичные ошибки - кандидаты придумывают первое решение, которое пришло в голову и не пытаются его проанализировать и попытаться улучшить. В идеале вам нужно придумать решение, оценить space and time complexity, найти потенциальные улучшения, найти другое решение. Если решение оптимальное сходу, то проанализоровав space and time complexity можно показать, что принципиально лучше не сделать. Еще одна небольшая ошибка, это кандидаты не анализируют edge cases, где могут быть проблемы у вашего решения. Не валидация инпута, как многие думают, а где при валидном инпуте могут быть проблемы у алгоритма.
3) Coding. После обсуждения и согласования решения вам нужно конвертировать это в реальный код. Тут оценивается coding, вашу способность конвертировать идеи в работающий код. Также оценивается структура и читаемость кода. Сильно заморачиваться не надо, но делать его нечитаемым не стоит. Частые ошибки: незнание базового синтаксиса, незнание простейших библиотечных функций, не уделение внимания граничным условиям, edge cases. Опять же это не про валидацию инпута. Вы можете спросить интервьюера, можно ли считать инпут валидным и в 90% он скажет, что да. Нужно смотреть edge cases, когда ваш код может не работать при валидном инпуте. Еще типичные ошибки: не умение реализовывать базовые алгоритмы, не умение трансформировать мысли в код.
4) Verification. Оценивается verification скил. Тут требуется проверить, что ваш код работает правильно, найти и исправить ошибки если есть. Код нужно проверять руками, без запуска. Нужно подобрать примеры и пройтись строка за строкой и убедиться, что на этих примерах это будет работать правильно. Также нужно устно сказать, какие еще тест кейсы вы бы использовали в реальном юнит тесте. Типичные ошибки: кандидаты не умеют дебажить код руками, делают проверку слишком high level, без деталей, и упускают баги.

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

По таймингу, на обсуждение и решение - 2-10 минут на задачу. Код - 5-10 минут. Верификация - 5.
Если задача сложная и у вас 35-40 минут на задачу, то 10-15 минут обсуждение и решение. 10-15 минут на кодинг и 5-10 на проверку.

Че там по замене программистов AI?

Прошло больше 2 лет с момента релиза ChatGPT. Появились тулы для програмистов, такие как GitHub Copilot, Cursor, Devin. Сэм Альтман последние два года кормит всех завтраками, что вот вот зарелизятAGI.
За последние несколько недель снова поднялся хайп после релиза DeepSeek и заявлений Зака, что в 2025 в Мета заменят мидлов на AI.

Мои мысли по этому поводу:

1) На данный момент нет технологий, которые могут заменить даже Junior программистов. Программист это больше, чем написание кода с детальным описанием. Текущие тулы приближаются по написанию кода к Junior программистам. Но им все также нехватает агентности. Devin обладает примитивной агентностью, но ему все также далеко до кожаного программиста.
2) Заявления Зака это такие же заявления, как и заявления Альтмана. Они призваны нагнетать интерес к AI и влиять на стоимость акций компании. Более того, заявление скорее касается того, что AI будет кодить как мидл. Но агентности как у мидла у него гарантированно не будет. Он должен быть интегрирован со всеми тулами, быть в них очень эффективным. Более того, он должен обладать самостоятельностью и проактивно вступать в дискуссии с други людьми и агентами. Т.к. нужно много согласовывать, обсуждать и договариваться. Кроме того, куча информации и идей находится по прежнему в головах людей, а не в документации.
3) DeepSeek это про удешевление. Модель R1 хоть и опережает другие модели в бенчмарках, но не сильно. Они сильно лучше в плане ресурсов, необходимых для обучения и во время выполнения(inference/test time).
4) Текущие модели это скорее похоже на долгосрочную память в мозге и про интуитивное мышление. Обученная модель - это очень эффективный способ задампить весь интернет на один жесткий диск. А ее запуск - восстановление данных. Своего рода неточный, но эффективных архиватор. Данные хранятся не в исходном состоянии, а в виде весов огромной матрицы. Своего рода каждое новое понятие не заново с нуля описывается, а то, как оно связано с другими понятиями в разных контекстах. Это похоже на долговременную память человека. Человек тоже хранит много знаний в виде прочности связей между нейронами. А то как выполняется модель, похоже на то, как человек говорит первый попавшийся интуитивный ответ(как у Канемана в книге: "Думай медленно, решай быстро"). Это примерно, как быстрая система мозга.
5) Текущие модели все еще не умеют думать. У мозга есть вторая функция, кроме как давать интуитивные ответы из памяти - это думать медленно и более глубоко (как в известном примере про цену мяча и биты). Сейчас появляются технологии вроде Chain-of-Thought и другие reasoning модели на основе reinforcement learning, деревьев и метода Монте Карло. Но это все еще далеко от мозга.
6) Большие результаты на бенчмарках падают при смене имен переменных. Модели все также не умеют думать и просто натренированны на примерах готовых решений под эти тесты. Если поменять имена переменных в задачах, то результаты падают на 10-30%. Если еще больше шума внести, то результаты будут еще хуже.
7) Человек учится на порядки эффективней. LLM нужно скормить весь интернет, чтобы она решала задачи как человек. Человек же учится на данных, которые на порядки меньше в размерах. Соответственно, архитектура обучения мозга сильно лучше и нужно совершить еще ряд прорывов для улучшения архитектуры. А это все плохо предсказуемо. Последний крупный прорыв был в 2017 году с открытием Attention, что и привело к созданию ChatGPT. Может в версии 5.0 будут такие открытие, но есть сомнения.
8) LLM не имеет тех же механизмов памяти как человек. У человека есть краткосрочная и долгосрочная память. Есть механизм, который переносит часть памяти из краткосрочной в долгосрочную. Есть механизм забывание неважной информации. У LLM этого нет. Она обученна один раз на всем интернете. У нее есть контекст, но она не переобучивается на лету и не забывает ненужную информацию. Я знаю, что есть работы на эту тему, но на практике пока это не реализовано и не протестировано.