Минусы жизни в Люксембурге

Плюсы жизни в Люксембурге

Минусы, по моему мнению:

1) Мало опций для работы программистом. Из крупных работодателей, которые платят хорошо программистам и для работы нужен только английский, там только Амазон. Был еще микроофис Майкрософта, но не уверен, что он еще не закрылся. Остальные компании или меньше платят или еще требуют знание других языков (французский, например). Поэтому с большой вероятностью при смене работы вы потеряете в зп.
2) Мало разнообразия. Этот минус вытекает из того, что город и стана маленькие. Первые пару лет вам будет, что посмотреть и чем позаниматься. Далее все начнет приедаться и вы будете ходить в одни и теже заведения, посещать одни и теже ярмарки, спортзалы, магазины, кинотеатры и т.д. Если вам критично разнообразие, то это быстро надоест.
3) Дорогое жилье. Цены на недвигу большие, по сравнению с другими европейскими странами. Сравнимы с ценами на недвигу в Лондоне. Поэтому придется брать ипотеку на большие сроки (лет 25). Хотя из-за того, что ставка по ипотеке небольшая, месячный платеж будет не сильно больше арендной платы.
4) Хоть английский язык присутствует, его меньше, чем в Англии, США или Австралии. Вы все равно будете натыкаться на людей, которые не говорят на английском. Это могут быть коммунальные службы, например. Для получения гражданства, вам надо будет сдать экзамен по люксембургскому языку. Это что-то среднее между французским и немецким. Поучить годим вам его придется.
5) Рельеф. Город очень холмистый. По факту, в нем два уровня. Между ними есть лифт или крутой спуск/подьем. Поэтому приходится часто подниматься в гору, что достаточно утомительно, особенно, если тебе нужно в ближайший магазин и приходится делать для этого кардио.

Дожили, Meta открыла офис в Индии

Сейчас пошли кандидаты из Индии, которых собеседуют в новый офис Мета в Индии. Прособеседовал несколько таких кандидатов подряд.

Гайд по выживанию массовых сокращений(layoffs) в Meta

Я пережил 3 массовых сокращений в Meta. За три волны сокращений уволили 25%-35% сотрудников.

Вот мои рекомендации, которые могут помочь пережить массовые сокращения:

1) Работайте над наиболее приоритетными направлениями в компаниями. Обычно, компания публикует свои приоритетные направления, в которые она будет инвестировать в ближайшее время. В первые две волны сокращения сильнее задели менее приоритетные направления разработки. В FAANG компаниях достаточно распространённая практика смены команды, поэтому если вы чувствуете, что ваша область стала менее приоритетной для компании - меняйте команду.
2) Поддерживайте хорошие отношения с менеджером. Третья волна сокращений была по перфомансу. Ваша оценка очень сильно зависит от вашего менеджера. Предварительную оценку выставляет он, таже он подготавливает ваш пакет документов, представляет ваш пакет и отстаивает вашу оценку. Если у вас плохие отношения, то желания отстаивать вашу оценку у него будет меньше. Речь тут не про неформальные отношения или дружбу, а про продуктивные рабочие отношения и мнения менеджера о вас, как о сотруднике.
3) Реагируйте на actionable feedback от менеджера. Если на ваших регулярных 1:1 менеджер дает вам конструктивный фидбек и говорит конкретные действия, которые нужно сделать для исправления - рассматривайте это как ваш самый важный текущий приоритет. Если менеджер дал конструктивную критику, нужно собраться и показать, что вы среагировали и сделали, чтобы это исправить и показали результаты менеджеру на последующих 1:1.
4) Делайте, что говорит ваш менеджер. Менеджеры в фангах это не тех лиды. Если они что-то говорят, что вам нужно сделать - обычно это значит, что к ним кто-то пришел, убедил, что это супер важное, а вы по тем или иным причинам это не делаете или не рассматриваете это как ваш главный приоритет.
5) Перед началом работы над задачей или проектом спросите себя, какой будет импакт от этой работы? Выясните, как численно можно измерить результат работы до того, как к ней приступить. Сделайте метрики (засетапьте пайплайны, дашборды), которые покажут, как было и как стало. Я называю это Impact Driven Development по аналогии с TDD. Только тут вначале нужно сделать метрики и работать над их улучшением. Этот подход помогает приоритезировать проекты и быть уверенным, что вы его можете измерить и показать результат другим людям.
6) Повышайте свою визибилити для скипов. На калибровках будет не только ваш менеджер, но и скипы (менеджеры вашего менеджера). Нужно быть уверенным, что ваши скипы знают про вас и про вашу работу. Старайтесь посещать митинги, где есть скипы, презентовать свою работу и работу вашей команды, задавайте вопросы, показывайте свою квалификацию вашими ответами и экспертизой перед скипами.
7) Документируйте обсуждения, алайменты, договоренности с другими людьми и командами. Пишите документы, посты, отправляйте письма и сообщения с результатами обсуждений. Убедитесь, что эти доки, письма, посты видят ваш менеджер и ваш скип. Если вам надо что-то обсудить с человеком из другой команды/орга, подготовьте заранее док с вопросами для обсуждения. По результат обсуждения дополните его митинг ноутсами и описанием решения или промежуточными результатами, открытыми вопросами и следующими шагами. Добавьте для визибилити свой менеджмент и менеджмент второй стороны.
8) Пишите и публикуйте дизайн доки. Все технические решения документируйте в виде дизайн дока, публикуйте это в виде поста, сообщения или письма. Добавьте туда для визибилити свой менеджмент.
9) Собеседуйте, будьте ментором, интерн менеджером и т.д. Одна из осей на перфоманс ревью - people. Чтобы получить хорошую оценку по этой оси можно много собеседовать людей, стать ментором, bootcamp ментором или ментором для стажеров.

10) Овните sev. Sev - это серьезный инцидент. Старайтесь овнить хотя бы 1-2 сева за 6 месяцев. Напишите хороший sev review и презентуйте его. Часто на этих ревью будет ваш скип. Даже если вы были причиной этого sev, если вы напишете хороший sev report, и презентуете его перед скипом - это будет вам в плюс к оси Engineering Excellence.
11) Старайтесь не быть в хвосте по числу изменений кода в команде/орге. Напрямую это не влияет, но нахождение в хвосте будет вызывать вопросы у менежера, а работаете ли вы вообще и насколько интенсивно. Он у вас начнет спрашивать, вы начнете оправдываться, что текущая работа не подразумевает написание кода, но осадок в подсознании у менеджера останется. Поэтому если сильно код менять не надо в текущий момент, делайте время от времени косметические изменения в коде.
12) Бегите от менеджера, который не умеет/не хочет отстаивать оценки своих подопечных. Это вы можете узнать у своих коллег и на своем личном опыте после первого перфоманс ревью. Часто, бывшие программисты, которые стали менеджерами, не умеют в калибровки и отстаивание своих сотрудников. Но не всегда. Если это ваш случай, то с большой вероятностью, на сокращениях он не будет упираться и отстаивать вас, когда сверху спустили цифры и нужно кого-то найти. Другие менеджеры будут вас отстаивать, а каким-то менеджерам будет пофиг. Тогда из его команды и найдут, кого уволить.

Задача с собеседования в Google: Maximal Square

Задача:
Дан двумерный массив, состоящий из нулей и единиц. Нужно найти площадь квадрата максимального размера, состоящий только из единиц.
Пример:

{"1","0","1","0","0"},
{"1","0","1","1","1"},
{"1","1","1","1","1"},
{"1","0","0","1","0"}

Ответ: 4. Тут есть несколько квадратов со стороной 1 и 2 клетки. Есть два квадрата со стороной 2 клетки. Т.е. размер стороны квадрата, максимального размера - 2. Площадь максимального квадрата - 4.

Ссылка на leetcode: https://leetcode.com/problems/maximal-square/description/

Решение. Описал тут: Задача с собеседования в Google: Максимальный Квадрат

Логическая задача с собеседования

В FAANG/BigTech давным давно спрашивали логические задачи, сейчас уже нет.
Но в другие компании все еще спрашивают.
Я помню в Яндекс лет 10 назад мне загадывали загадки(я не отгадал), не знаю как сейчас.

Вот задача, которую у меня спросили на собесе в крупный инвест банк лет 10 назад (если что я решил и прошел собес).

Задача следующая: есть 25 лошадей. На ипподроме 5 дорожек. Надо определить 3 самые быстрые лошади за минимальное число заездов. Время замерять нельзя. Мы только знаем, кто в каком порядке финиширует. Можно считать, что время за которое каждая лошадь пробегает дистанцию не меняется от заезда к заезду.

Пишите ваши решения в комментариях.

Написал численную симуляцию и проверку решения задачи про забеги лошадей

Задача: https://t.me/faangmaster/555

Код проверки выложил тут: Численная проверка решения головоломки про топ 3 из 25 лошадей
Сделал 2 почти одинаковых варианта. В первом - время забега - случайное целое уникальное среди всех лошадей. Вторая - вещественное случайное.

Если вы считаете, что у вас есть контрпример - можете вернуть его в методе Horses.init() и проверить на нем.

Пишите в комментариях, если есть ошибки в коде.

Какие самые тупые вопросы(не технические) вам задавали на собеседованиях?

Из того, что у меня спрашивали:
1) Кем вы видите себя через 5 лет?
2) Есть ли у вас хобби?
3) Есть ли у вас друзья?
4) Готовы ли вы много работать?

Плюсы работы в Facebook

По моему мнению:

1) Компенсация. За время работы в компании я заработал ~$2.1М gross. Если бы я был в США эта цифра была бы в 1.5 раза больше. Мало кто платит столько разрабам. Правда, надо сказать, что вне повезло с качелями в цене стоков в 2022-2024.
2) Хорошая строка в резюме. Позволяет проще попадать на собесы в любые компании.
3) Scale. Опыт деливери фичей, инфры для такого масштаба пользователей, обьема данных, нагрузки.
4) Опыт работы с большим числом умных коллег. Такой концентрации умных людей я не видел нигде. Ни в одной другой компании или даже в топ вузе. Это имеет свои плюсы и минусы, но плюсы в этом тоже есть.
5) Относительная свобода в работе. В компании часто используется bottom up подход. Не везде и не всегда, но все же. Менеджер не занимается технической частью, он скорее занимается people частью, карьерным ростом сотрудников. От разрабов зависит очень многое, не только execution. Но и планирование, сетинг целей и метрик, алайнменты, дизайн и т.д. Это имеет и свои минусы, я об этом напишу в минусах.
6) Крутые внутренние тулы. Они делают разработку очень быстрой и простой. Вам, часто, не нужно тратить время на сетап энвайронмента, скачивание кода, долгую компиляцию. Есть куча внутренних библиотек, фреймворков, инфры, которая делает деливери решений очень простым и быстрым. Не нужно с нуля придумывать стек, сетапить, писать куча бойлерплейт кода. Часто это как соеденить несколько кусков лего, чтобы все заработало на масштабе миллионов или миллиардов пользователей. Внутренние тулы хорошие, но не идеальные. В этом есть свои минусы.
7) Лайтовый oncall. Он есть, и его напряжность варьируется от команды к команде. Но в среднем по больнице, он лайтовей, чем в Амазоне.
8) Лайтовые процессы или их отсутствие. Это позволяет быстро разрабатывать и шипить код. В командах, обычно, нет ни скрама, ни канбана. Sev-review также лайтовый, по сравнению с Амазоном. Но у этого тоже есть свои минусы. Я об расскажу в минусах.

Coffee badging

Это новый, относительно свежий, buzzword. Обозначает ситуацию, когда сотрудник приходит на работу на короткий промежуток времени(попить кофе, поболтать с коллегами), чтобы был засчитан день работы из офиса.
Явление появилось после обьявления RTO(return to office) policy.

Я постоянно практикую это. У нас сейчас гибридный график-3 дня из офиса, 2 удаленно.
Наличие сотрудника в офисе трекается и засчитывается по сканирыванию баджа(пропуска).
Поэтому я часто появляюсь на работе на 3-4 часа, пообедаю бесплатно, поговорю с коллегами, немного поработаю и домой.

Практикуете ли вы coffee badging?

Минусы работы в Facebook

Плюсы тут: https://t.me/faangmaster/561

Минусы, по моему мнению:
1) PSC (перфоманс ревью). Сейчас все в работе крутится вокруг этого. Так было и раньше, но в последние пару лет это стало основным и практически единственным, вокруг чего строится вся работа и жизнь в компании. Все сотрудники выстраивают свою работу так, чтобы оптимизировать метрики для PSC. Это влияет на коллаборацию, командную работу (которая практически отсутствует), усиливает конкуренцию между сотрудниками . Я называю это PSC Driven Development.
2) Хаос. Из-за отсутствия формальных процессов и бюрократии, нужно постоянно прикладывать дополнительные усилия, чтобы держать себя и других в курсе о том, что происходит, кто, что делает и т.д. Часто разные команды из одного или разных отделов решают одну и туже задачу, конкурируют между собой. Иногда, другие люди начинают решать уже решенную проблему и изобретать велосипеды, хотя над этим уже 5 лет работает целый отдел. Вначале, разраб, особенно ниже senior может чувствовать себя несколько потерянным в таком энвайронменте. Если вам раньше давали задачу и говорили, что делать, то тут этого практически нет. Каждый день, кто-то придумавает что-то новое и нужно постоянно прикладывать усилия, чтобы держать себя в курсе всего.
3) Очень высокая конкуренция. Это вытекает из высокого среднего уровня сотрудников, PSC Driven Development и потенциальных бенефитов. В основном, тут разрабы, которые привыкли быть лучшими, конкурировать с другими. Очень много людей с синдромом отличника, нарциссов, необходимостью быть лучшим. И среда внутри компании это все поощряет при помощи оценки перфоманса и гигансткой компенсации, бонусов, рефрешеров и т.д. Эта конкуренция чувствуется во всем. Особенно, это усилилось за последние пару лет.
4) Стэк технологий. Я люблю Java, но в Meta ее практически нет. Только в мобильной разработке. В бэкенде и инфре она есть но очень мало. Поэтому приходится писать на разных других языках (hack, python, c++).
5) Частые реорги, смены скоупа и менеджеров. Это связано с тремя факторами: культура компании (move fast, bold prioritization), болтанка последних двух лет и PSC Driven Development. Из-за культуры компании приоритеты команды, отдела могут смениться очень быстро, даже быстрее чем за 6 месяцев. Это может произойти за месяцы или даже недели. Если кто-то поймет, что нужно работать над чем-то другим, а текущий скоуп не имеет смысла. Directors/VP для своего PSC могут решить резко сменить структуру отдела, перераспределить скоуп для повышения эффективности. Могут быстро похоронить проекты, над которыми работают целый команды или отделы. Из-за массовых сокращений у вас может исчезнуть или смениться менеджер. Все это усилилось в последние пару лет. Из-за такой болтанки вы можете просесть на PSC. Но это никого волновать не будет. Работали над проектом, который быстро стал никому не нужен, потом начали работать над другим с другим менеджером, который вас не знал до этого и не успели себя проявить и достичь хороших результатов на новом проекте - плохой рейтинг на PSC.
6) Внутренние тулы. Это наверное самый лайтовый из минусов. Он применим ко всем фангам. Хотя тулы и крутые, их нигде больше нет. И опыт их использования вам напрямую не поможет в других компаниях. В среднестатистической компании другой стэк тулов и технологий. Обычно, разработанный кем-то другим и ставший open source. Также из-за этого использование google+stackoverflow или LLM сейчас не очень эффективно. Т.к. комьюнити этих тулов маленькое и находится внутри компании. Если раньше вы могли что-то загуглить, то в фангах это не работает. Надо выяснять внутри. LLM чуть-чуть помогают, но они все равно натренированные на внутренних доках и вопросах-ответах, которых мало, они не полны и устарели давно. Поэтому надо задавать вопросы в группах, которые занимаются разработкой тулов, искать во внутренних доках или копать код самому.

FIRE movement

Это аббревиатура: Financial Independence, Retire Early. Что означает финансовую независимость и ранний выход на пенсию.

Движение стало популярным в десятые, особенно среди программистов США.

Основная идея в том, чтобы откладывать существенную часть зарплаты и инвестировать(индексы, акции, депозиты и т.д.). За 10-20 лет накопить существенную сумму и жить на проценты, не работая.

Ориентировочно, нужно накопить столько, чтобы жить на 4% в год от накопленной суммы.
Например, если вы хотите жить на 300 тысяч рублей в месяц, не работая, вам нужно накопить 300k×12/0.04=90 миллионов рублей. Причем, существенная часть этой накопленной суммы будет сренерирована не зарплатой напрямую, а сбережениями, которые были инвестированы в фондовый рынок.

В России, правда, фондовый рынок или банковская система менее надежна, поэтому это слабо применимо. Или инвестировать в недвижимость и зарабатывать на аренде и перепродаже.

Если суммы недостаточно, можно переехать в другую локацию, где дешевле, и жить там.

https://en.wikipedia.org/wiki/FIRE_movement

Non-lucrative residence visa (NLV)

Это тип визы в Испанию, которую можно получить, если у вас есть доход вне Испании (удаленка, сдача в аренду и т.д.) или просто достаточно сбережений.
Сколько нужно сбережений или дохода: ~€27k в год + ~€7k на каждого члена семьи.
После 5 лет можно получить ВНЖ, а через 10 гражданство.
Подходит тем у кого есть пассивный доход, достаточно сбережений или удаленка.
Больше деталей тут: Non-lucrative residence visa (NLV)
Также есть Digital Nomad Visa, но предназначена конкретно для удаленщиков.

Очередное видео от одного из основателей Open AI, про использование LLM

Andrej Karpathy выпустил очередное видео, где рассказывает про разные функциональности LLM и как они в реальности работают. И как использовать LLM эффективно, зная их внутреннее устройство. https://www.youtube.com/watch?v=EWvNQjAaOHw

Собеседовал сегодня очередного кандидата из Google

По моему опыту, особого смысла проводить кодинг собеседование для кандидатов из Google нет. Пока не встречал кандидата, кто бы его не прошел. Я бы оставил для них только собеседование по System Design и поведенческое. Эти два собеседования они иногда не проходят.
Про кандидатов из других компаний такое сказать не могу. Кандидаты из Amazon, Microsoft, Yandex хоть и чаще проходят, чем в среднем, но в существенном проценте случаев заваливают кодинг собеседование.

Отличие в процессах и методологиях в FAANG по сравнению с другими компаниями

1) Реальный CI/CD. После того как вы запушите свой код, он окажется в проде в течении нескольких часов. Никаких ручных процессов, версионирований, долгих релиз циклов. От написания кода до релиза на миллиард пользователей проходит несколько часов. Есть исключения(особенно в мобильной разработке), есть A/B тестирование, есть прогрессивный роллаут, но чаще сам код в проде через несколько часов.
2) Нет QA, или почти нет QA. Написание тестов (unit, integration, perfomance, stess, load, e2e, chaos engineering) лежит полностью на разработчиках. Есть исключения, но большая часть команд не имеют выделенных QA.
3) Менеджеры это не тех лиды и не занимаются разработкой и технической частью. Менеджеры занимаются оценкой перфоманса сотрудников, их карьерным ростом, конфликтами между командами/отделами, участвуют в планирование, статус репорте и овнят роудмап. Но не занимаются дизайном, архитектурой, разработкой, раздачей тасков, микроменеджментом.
4) Саппортом занимаются разработчики. Есть исключения, есть SREs(Site Reliability Engineers), но все разработчики занимаются саппортом своих компонент/кода(oncall). Вас может разбудить ночью аларм на рабочем телефоне(пейджинг), если какие-то метрики просели, упала какая-то критическая функциональность. Вам нужно быстро среагировать и начать митигировать проблему.
5) Очень много индивидуальной работы. Очень мало командной работы. Связано с тем, как устроен процесс оценки перфоманса сотрудников. Разрабы работают над проектом от начала до конца. Они не могут просто брать самую приоритетную таску из бэклога из разных проектов. Иначе будет сложно описать нарратив, что этот разработчик сделал то-то с таким импактом. Поэтому все работают индивидуально над своими проектами. Они коллаборируют с другими, но имеют выделенный кусок работы, с понятным импактом. Поэтому Scrum/Kanban в чистом виде не особо применим.
6) Нет выделенных Архитекторов. Поэтому все разработчики на всех уровнях делают дизайн/архитектуру. Конечно, ее масштаб и импакт будут разными в зависимости от вашего уровня. Это может быть просто дизайн локальной для команды фичи или дизайн архитектуры, которая затрагивает десяток команд и несколько отделов.
7) Мало сторонних, открытых библиотех, фреймворков, тулов, технологий. Обычно, все или почти все разработанно внутри. Вплоть до языков программирования и систем контроля версий. Поэтому, приходится разбираться в этом с нуля. Нельзя просто загуглить ответ на любой вопрос по этим тулам. Нужно искать внутри, смотреть код, общаться с разрабами.

Как leetcode изменил coding собеседования в FAANG?

FAANG/BigTech компании используют алгоритмические задачи на coding-собеседованиях уже более 20-30 лет. Этот тренд был задан Microsoft в 90х годах. Потом его подхватили новые интернет-компании вроде Google, Amazon, Facebook и т.д. Вначале, единственный способ пройти такого рода собеседование - быть топовым олимпиадником, заботать книги вроде: "Искусство программирования" Д. Кнут, "Алгоритмы: построение и анализ" Т. Кормен, "The Algorithm Design Manual" Скиена.

В 2008 году появилась книга - "Cracking the coding interview", которая сделала подготовку проще и более доступной для бОльшего числа людей. Но все равно, вы скорее тренировались решать типовые задачи. Общее число задач, которые предлагались на собеседованиях, было сильно больше. Книга помогала освоить принципы решения, но не конкретные задачи.
В 2015 году появился Leetcode, который изначально состоял из задач из книги Cracking the coding interview. Далее туда стали добавлять сливы задач с реальных собеседований. И к 2018-2020 база задач уже не сильно отличается от баз задач внутри FAANG/BigTech компаний.
Во время собеседования интервьюер может спрашивать задачи только из официальной внутренней базы. Число задач в ней ограничено и задачи меняются в ней очень медленно.
По мере роста компаний, выросло и число собеседований, а как следствие и число сливов задач на leetcode. Поэтому на leetcode есть существенная часть задач, которые спрашивают на реальном собеседовании.
Это привело к кому, что такого рода задачами уже практически никого не удивить. А большинство кандидатов, которые успешно проходят собеседование - просто знают все задачи наизусть. Достаточно знать наизусть 50 первых по частоте задач для конкретной компании, чтобы с большой вероятностью получить эти задачи на собесе и просто воспроизводить их из памяти.
Проведя более 100 кодинг собеседований, я уверен, что почти все, кто его прошел успешно, просто, воспроизводил решение из памяти.