Подборка постов в канале со случаями на собеседованиях:

Обновление подборки

1) Случай на собеседовании в FAANG
2) Еще один подозрительный случай на собеседовании
3) Классический случай на кодинг собеседовании в FAANG
4) Новая галочка про подозрение в читерстве на собеседовании в FAANG
5) Кандидаты из Google
6) Опытный кандидат с претензиями
7) Собеседовал недавно разработчика из Яндекс
8) Собеседовал сегодня еще одного кандидата из Google
10) Собеседовал сегодня кандидата из Сингапура
11) Собеседовал только что многократного победителя соревнований на Kaggle
12) Еще один подозрительный случай с собеседования
13) Уверенные пользователи ChatGPT кучно пошли
14) У подозрительного кандидата и резюме подозрительное

Сложнее ли собеседование в Facebook по сравнению с собеседованием в Amazon?

Медианный начальный офер в Facebook в 1.5-2 раза больше, чем в Амазон. Более того, в Facebook стоки(акции) выплачивают раз в три месяца, начиная с первого года. Т.е. через 3 месяца после старта вы получите свои первые акции. В Амазоне только через год и 5% от изначального офера(второй год 15%, 3 и 4 по 40% и раз в полгода). Более того в Facebook раз в год дают много рефрешеров(новых акций). Т.е. в плане денег Facebook несравнимо лучше, чем Амазон.

Сложнее ли собесы в Facebook, чем в Amazon?

Сложнее, но не в разы. Более того, я бы сказал, что сложность самих задач на алгосах и систем дизайне отличается не очень сильно.
Сильнее отличается оценка перфоманса кандидата на этих задачах. У вас может быть даже один и тот же вопрос на систем дизайне и при одном и том же ответе вы можете пройти в Амазон, но не пройти в Facebook. Систем дизайн длится 45 минут в Facebook. На уровни Staff+ таких собесов будет 2. В Амазон систем дизайн разделен на сам систем дизайн и на Leadership Principle. Т.е. он длится 20-25 минут.
Поэтому то, как отвечать, чтобы пройти, будет отличаться. В Facebook вы должны драйвить обсуждение, подходить к задаче целостно. Формально предложить, обсудить и зафиксировать функциональные и не функциональные требования. Предложить дизайн, который покрывает все требования. Найти и обсудить трейдофы, углубится в самые ключевые аспекты и т.д.
В Амазоне же намного более слабый перфоманс позволит вам пройти.
Аналогичная ситуация и с остальными собесами(кодинг и поведенческое). Поэтому просто решать более сложные задачи на литкоде, чтобы пройти в Facebook будет недостаточно. И вообще, средний перфоманс кандидатов на кодинге сейчас и 7-10 лет назад вырос в несколько раз. Когда я впервые пытался попасть в FAANG 9 лет назад такого рода собесы были тайной, покрытой мраком. Была только книга Cracking the Coding Interview. Многочисленных курсов и литкода с тысячами задач тогда не было. Сейчас задачами с литкода мало кого удивишь. Но перфоманс по разным аспектам играет ключевую роль(problem solving, coding, verification, communication).

Почему все Big Tech/FAANG компании делают AI

Значит ли это, что они уверены в том, что это точно взлетит и принесет огромные прибыли?

Краткий ответ: Нет.

Но тогда, не рисковано ли вкладывать десятки миллиардов долларов с непонятными перспективами?

Разгадка тут кроется в том, что современные IT-гиганты хорошо выучили уроки Кодак, Ксерокс, IBM и Yahoo. Эти некогда крупнейшие, очень успешные и инновационные компании превратились в свою тень, т.к. вовремя не переключились на другие перспективные направления. У них все было хорошо, их продукт был лучшим на рынке, а все инновации, которые в том числе придумали в этих компаниях(цифровая камера, мышь, пользовательский графический интерфейс, продвинутый поисковый движок) они игнорировали или деприоритезировали. Что привело к упадку.

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

Подборка постов в канале про релокацию, жизнь и работу в Европе

Обновление подборки.

Релокация:
1) Планируете переехать в другую страну для жизни и работы?
2) Плюсы работы и жизни в Лондоне
3) Минусы жизни в Великобритании
4) Через сколько лет можно получить гражданство разных стран Европы?
5) Небольшая подборка компаний в Европе, которые нанимают людей из постсоветского пространства
6) Что лучше: большая зп в абсолютных значениях или лучше меньше зарабатывать и жить в стране с меньшими ценами?
7) Стоимость жизни в Лондоне и сколько нужно зарабатывать, чтобы хорошо тут жить
8) Что сейчас происходит на рынке труда программистов США и Европы?
9) Мои первые впечатления, когда я начал работать в Европе, Часть 2
10) Global Talent Visa UK
11) Число вакансий в tech индустрии медленно, но растет
12) Ситуация с хайрингом в Big Tech (и не только) в Европе и США на январь 2024
13) Мои первые впечатления, когда я начал работать в FAANG
14) Стоимость покупки недвижимости в Лондоне vs Москве
15) Что сейчас с хайрингом в FAANG?
16) Как FAANG компании делают бэкграуд чек

Подборка постов в канале про онбординг, уровни, LLM vs программист и прочее

Онбординг:
1) С какими сложностями я столкнулся на своей первой работе программистом?, Часть 2
2) Как быстро адаптироваться в команде и компании?, Часть 2
3) Что не стоит делать при онбординге в новую компанию?
4) Team Selection и on-boarding в Facebook
5) Как устроен onboarding процесс в Amazon?, Часть 2

Уровни:
1) Чем отличается Junior от Middle программиста?, Часть 2.
2) Чем отличается Senior программист от Middle?
3) Странные тайтлы в инвест банках
4) Распределение по уровням в FAANG
5) Структура FAANG/Big Tech компании
6) Какие бы советы я дал Junior программистам, чтобы быстрее стать Middle разработчиками?
7) Какие бы советы я дал Middle программистам, чтобы быстрее стать Senior разработчиками?, Часть 2.
8) Неоднозначность в тайтлах выше Senior

Прочее:
1) История о том, как я провалил собеседование в Google.
2) С чего начать поиск работы в IT?
3) Минусы работы в IT/программистом
4) Стоит ли целенаправленно готовиться к собеседованию в FAANG, если у вас нет технического образования и вы учитесь на курсах и хотите стать программистом?
5) С чего начать изучать программирование в 2023?
6) Что я думаю про курсы по программированию, которые рекламируют на каждом углу?
7) Подборка фильмов, сериалов и документалок о программистах, BigTech, стартапах и их основателях
8) Примеры внутренних тулов и библиотек Facebook, которые стали общедоступными
9) Нобелевскую премию по химии в 2024 году получил сотрудник Google

LLM vs программисты
1) Заменяют ли программистов в топ компаниях на нейросети?, Часть 2
2) Заменят ли программистов нейросети в ближайшем будущем? Update, Часть 2
3) Реальный импакт LLM на программистов
4) Почему все Big Tech/FAANG компании делают AI

Индекс по каналу

Кто я: я программист с более чем 17 годами опыта работы в IT. Из них более 7 лет я проработал в двух FAANG-компаниях. Есть опыт жизни и работы в 4 странах. Из языков программирования лучше всего знаю Java. Провел более 100 собеседований в FAANG компании.

Про что я пишу: Разбираю задачи с собеседования по Java (включая многопоточность), задачи с собеседования в FAANG по алгоритмам и System Design. Пишу про то как работают процессы в FAANG-компаниях, про культуру инжиниринга, уровни и личный опыт работы в них. Пишу про релокацию, работу в Европе, работу в FAANG, собеседования в FAANG и много другое.

Мои статьи https://dev.to/faangmaster
Мой youtube: https://www.youtube.com/@faanger

Подборки постов:

1) Гайд по подготовке к собеседованию в FAANG: Как подготовиться к собеседованию в FAANG/Big Tech
2) Подготовка к System Design с нуля и для разных уровней

Подборки с моими разборами большого числа задач с собеседований:
3) Разобрал 24 темы и реальных задач с System Design собеседований в FAANG
4) Разобрал все основные алгоритмы и 44 задачи с собеседований на алгоритмы в FAANG
5) Разобрал 30 вопросов и задача по Java и Многопоточность

6) Подборка постов в канале с рекомендациями по подготовке к собеседованию
7) Подборка постов в канале о работе в FAANG
8) Подборка книг для Java программиста
9) Ресурсы для подготовки к собеседованию по алгоритмам
10) Подборка постов в канале со случаями на собеседованиях
11) Подборка постов в канале про релокацию, жизнь и работу в Европе
12) Подборка постов в канале про онбординг, уровни, LLM vs программист и прочее

Очередной мастер ChatGPT на собеседовании

Вчера собеседовал кандидата (University Grad) на позицию джуна. Резюме идеальное. В нем известный универ в США, изучал всякий ML, роботов и LLM. За плечами 2 интернатуры (В Интеле и в Амазоне).
На собесе вначале начал рассказывать неправильное/неоптимальное решение, но когда начал писать реализацию начал смотреть в сторону и писать строку за строкой, смотря на другой монитор. Решение было оптимальным и вообще другим по сравнению с тем что он описал. Когда я попросил его описать еще раз, он долго тупил и пытался понять, что он написал.
На верификейшне он не нашел ошибки. У него была одна маленькая ошибка (очепятка при переписывании) и одна существенная (т.к. задача была модифицированная по сравнению с тем что есть на литкоде). Засабмитил фидбек сегодня. И забавно было увидеть, что на втором кодинге фидбек примерно такой же (я не вижу чужие фибдеки, пока не засабмичу свой).

Product/Feature Operational Readiness в Amazon

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

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

Документ заполняется перед самым запуском в проде. К тому времени дизайн и реализация уже сделаны. Код, обычно, уже в проде, но еще не включен. Регулируется это при помощи feature-switch/kill-switch.

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

Какие, основные, пункты/вопросы в этом документе?

1) Краткое описание фичи. Что за фича, зачем она нужна, как работает. Описание должно быть простым, чтобы его можно было понять, если вас разбудят в 3 часа ночи и вы понятия до этого не имели о чем эта фича. Т.к. часто нужно поддерживать функционал, которые ты не очень глубоко знаешь, который был разработан другими коллегами.
2) Ссылка на дизайн док. Позволяет быстро найти дизайн фичи и ознакомиться с ним.
3) Ключевые бизнес метрики/KPI. Какие бизнес-показатели необходимо мониторить при работе данного функционала и почему. Нужно указать ссылку на метрику или дашборд. На графике обязательно, помимо самого показателя, должен быть указан трешхолд, при превышении или недостижении которого автоматически должна создаваться таска для саппорта (alert) или sev. График должен легко читаться, даже если вас разбудят в 3 часа ночи.
4) Операционные метрики. Ссылка на дашборды и метрики технического характера. Они также должны легко читаться, иметь трешхолды и алерты. Смотря на график должно быть понятно о чем график и когда все плохо и когда все хорошо. Эти графики помогают во время саппорта проводить быстрые инвестигации инцидента.
5) Ссылки на runbooks. Ссылки на ранбуки, в которых описана последовательность действий, которые нужно совершить во время того или иного инцидента. Эти ранбуки должны быть простыми и детальными, чтобы их мог выполнить кто угодно без подготовки в 3 часа ночи. Шаги должны быть направлены на митигацию инцидента, а не на поиск и устранение root cause. Обычно, это какие-то rollback, рестарты или killswicth. Эти ранбуки должны автоматически попадать в дескрипшен саппорт таски или sev, которые создаются алертами.
6) Список dependency и влияние их отказа на систему. Обычно, продукт или фича зависят от других компонент. Нужно описать, что произойдет при частичном и полном отказе этих зависимостей. Есть ли circuit breaker для каждой из dependency, есть ли retry, если ли throttling/rate limiting и т.д.
7) Как выключить фичу? Есть ли killswitch и как быстро выключить функционал.
8) Ссылки на алерты. В каких случаях автоматически будет создана таска саппорта или инцидент. На каких метриках это базируется, какие трешхолды. Какое описание таски будет создано. Какие ранбуки будут прикреплены.
9) Ссылки на тесты. Unit тесты, интеграционные, end-to-end, перфоманс, load тесты, стресс тесты и т.д.

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

Как был устроен 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).