Подборка статей, которые я уже написал и опубликовал в этом канале по system design
#systemdesign

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

1) Load Balancers 1
2) Load Balancers 2
3) Load Balancers 3
4) Consistent Hashing
5) Data Partitioning/Sharding
6) Design Web Crawler
7) Дизайн Uber/Яндекс Такси
8) Дизайн новостной ленты соцсети типа Twitter или Facebook
9) Availability
10) Consistency
11) Дизайн мессенджера Telegram
12) Обработка ошибок при вызове другой компоненты
13) Распределенный кэш. Часть 1.
14) Распределенный кэш. Часть 2.
15) Распределенный кэш. Часть 3.
16) Характерные числовые характеристики, которые нужно знать для System Design собеседования
17) Дизайн Google Maps

Подборка вопросов и ответов для подготовки к собеседованию на Java программиста
#java #interview #собеседование

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

Общие вопросы:
1) Методы класса Object
2) Иерархия и типы исключений
3) GC
4) Сравнение строк в Java

Коллекции:
5) HashMap
6) ArrayList vs LinkedList
7) Иерархия коллекций в Java
8) Иерархия Map
9) Maximum ArraySize

Многопоточность:
10) Перевод между банковскими аккаунтами (dead-lock).
11) Ping-Pong (wait-notify).
12) Приостанавливаемый поток.
13) Подборка вопросов по многопоточности
14) Напечатать последовательность чисел при помощи нескольких потоков на Java.
15) ConcurrentModificationException
16) Thread Safe Singleton
17) Обедающие философы
18) Реализовать потокобезопасную блокирующую очередь на Java ограниченного размера
19) Реализовать потокобезопасный неблокирующий стек на Java
20) Daemon потоки
21) Является ли immutable class в Java Thread safe?
22) Implicit Lock Reentrancy
23) Java Memory Model и happens-before
24) ConcurrentHashMap vs Collections.synchronizedMap vs Hashtable vs HashMap
25) Реализовать потокобезопасную неблокирующую очередь на Java

SQL:
26) Типы SQL joins
27) Плюсы и минусы индексов

Spring:
28) Что такое @Autowire в Spring? Как его использовать и как он работает?

Zuck про недавний релиз meta.ai и llama3
https://youtu.be/bc6uFV9CJGg

И директор по продукту рассказывает как тренировали llama3:
https://youtu.be/r3DC_gjFCSA

Вопрос с собеседования на Java программиста: Как выполнить код в отдельном потоке в Java?

Ответ на этот вопрос описал тут: Как выполнить код в отдельном потоке в Java?

Несмотря на то, что вопрос простой, лишь небольшая часть собеседуемых мной в один из крупнейших инвест банков знали про Callable, CompletionService, Future и т.д.

С будущих статьях также расскажу про CompletableFuture и виртуальные потоки.

Нужна ли сертификация Java программисту?

Краткий ответ - нет.
Раньше были официальные сертификаты от Sun. После поглащения Sun Oracle'ом эти сертификаты теперь есть от Oracle. Их несколько разных наименований, вроде Oracle Certified Associate Java Programmer и тому подобное.
На начальных этапах карьеры, я думал, что их нужно обязательно сдать. И даже купил литературу. Но выяснилось, что их нигде не требуют, и за 17 лет работы у меня их никто не спросил. Более того, я не знаю никого, кто бы их получил. Вопросы там не совпадают с теми, что спрашивают на реальных собеседованиях. Они, в основном, на редкие и тонкие места в синтаксисе. Стать хорошим программистом или научиться проходить собеседования они вам не помогут, а при найме их никто не спрашивает. Поэтому это достаточно бесполезная трата времени и денег.
Но если у вас куча времени и вы хотите заботать тонкие детали и аспекты синтаксиса, то можете заняться получением подобных сертификатов.
Из сертификатов, более полезным, я бы назвал сертификаты по AWS. Но их тоже не спрашивают при найме в Amazon или FAANG. Но они могут пригодиться при найме на позиции не в FAANG, где активно используют AWS, особенно, если ваша позиция Architect или хотя бы Senior.

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

К нам часто подаются разработчики из Яндекса и многие работают. У меня много бывших Яндексоидов среди коллег.
У кандидата были явные сложности с разговорным английским. У кандидата занимало много времени понять, что я от него хочу, потом много времени сформулировать, как он бы решал эту задачу и долго формулировал свои мысли во время написания кода. Также старался лишний раз не переспрашивать. Из-за этого решение заняло много времени и кандидат не смог до конца правильно решить и не успел протестировать.
На систем дизайне он не драйвил обсуждение, не погружался в детали и не мог порассуждать на тему трейдофов разных подходов. Вероятно, из-за языкового барьера. А поведенческое провалил, т.к. примеры из опыта были не валидными или демонстрировали его с негативной для данного уровня стороны. При этом решение алгосов было ~ок. Но по факту все 4 собеседования на full loop были провалены.
Поэтому убеждение, что нужно просто задрочить литкод, то тебя примут в FAANG - это заблуждение.

Нужно ли учить многопоточность в Java?

С многопоточностью в Java ситуация примерно такая же как и с алгоритмами.
И то и другое спрашивают в топ компании. И то и другое сложно в освоении. И то и другое редко используется на практике.
Типичное приложение на Java - это какой-то бэкенд, который работает в обертке какого-то контейнера, типа Tomcat. На каждый новый реквест он создает новый поток, в рамках которого работает ваша бизнес логика. В таком случае вам не нужно заботиться о создании потоков вообще. За вас это сделает контейнер. Более того, часто в рамках приложения у вас нет shared состояния/переменных. Все обьекты создаются и живут в рамках одного потока(thread confinment). Обычно оно на уровне SQL базы, доступ к которой происходит с ACID транзакциями. Поэтому 90% кода на Java не требует особых знаний по многопоточности. При этом, при приеме в Яндекс, Сбер, Одноклассники, Mail и т.д. вас обязательно спросят многопоточность на собеседовании. Дело в том, что в таких компаниях это используется несколько чаще, т.к. пишутся кастомные и более сложные вещи + нет времени на освоение многопоточности, а ошибки могут стоить очень дорого. Поэтому если вы хотите попасть в топ компании(не обязательно FAANG), то учите и многопоточность и алгоритмы.
В FAANG многопоточность не спрашивают, но и вероятность пройти собес в FAANG меньше.

Team Selection и on-boarding в Facebook

Как выглядел мой процесс on-boarding в Facebook?

Раньше Facebook набирал программистов просто в компанию, а не в конкретную команду. Также было и в моем случае. Я прошел собеседование в компанию в целом, а не в конкретную команду. Смотрите также: Как я готовился к собеседованию и попал Facebook? Сейчас все чаще набирают в конкретную команду, но не всегда.

Я прошел 5 собеседований (Screen: Coding, Full Loop: Coding, Coding, System Design, Behavioral). Получил offer в компанию, без указания конкретной команды.
Когда я начал работать - я не знал, в какой команде я буду работать.

Процесс on-boarding начался с bootcamp, который для меня продлился 2 месяца.
Все буткамперы разбиваются на маленькие группы по 3-4 человека - squad. У каждого squad есть bootcamp mentor. Это сотрудник компании с опытом работы от года в компании, который будет помогать вам во время пребывания в bootcamp и во время team selection. По-сути, играет роль вашего временного менеджера.

План on-boarding и Team Selection по неделям выглядел так:

Первая неделя: получение и настройка ноутбука (почти всегда это macbook pro) и рабочего телефона (тут на выбор iphone, galaxy или pixel). Большое число тренингов связанных с культурой работы в компании. Написание первого изменения кода (создание реальной новой страницы для сайта Facebook.com!). Знакомство с bootcamp mentor и squad. Выполнение первой кодинг таски Level 1. Все команды могут создавать простые задачи и помечать их как для bootcamp и аутсорсить их для буткамперов. Буткамперы могут брать такие задачи из общего пула и делать их. Они имеют 4 уровня: Level 1 - Level 4. Level 1 - изменить одну строчку, Level 2 - изменить ~функции, Level 3 - сделать мини фичу, требует обсуждения с создателем задачи, Level 4 - сделать полноценную фичу, работа над которой может занять 1 неделю.
Вторая неделя: Большое число тренингов по культуре компании и по внутренним тулам. Выполнение 1-2 тасок Level 2.
Третья неделя: Большое число тренингов по культуре компании и по внутренним тулам. Выполнение 1-2 тасок Level 3. Заполнение внутреннего профиля для поиска команды. Поиск и отклик на текущие открытые позиции.
Четвертая неделя и далее: вы работаете на разные команды, делаете для них таски уровня 3 или 4. Общаетесь с менеджером и потенциальными коллегами. Если вам нравится - говорите, что вы хотите работать в этой команде и вас принимают. Отказать вам не могут. Дополнительного собеседования не проводится. Но если другой буткампер раньше сказал менеджеру, что он хочет работать в этой команде, то позицию закрывают и вы уже не сможете попасть туда. Поэтому все равно конкуренция есть.
Я в итоге так поработал на 5 команд. Пару команд я упустил, т.к. другие оказались быстрее.

После этого вы присоединяетесь к команде и начинается on-boarding внутри конкретной команды. Об этом я напишу отдельным постом.

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

Когда я начал работать (это было 17 лет назад), у нас в компании использовали электронные письма, текстовые чаты и ip-телефонию для коммуникации. Тогда это был outlook, ICQ и физические ip-телефоны. Письма удобны, если вы хотите начать большое обсуждение на много человек или информировать о решениях, статусе и апдейтах. Чаты - для быстрого обсуждения с конкретным человеком. Я, кстати, не уверен, что 17 лет назад в ICQ можно было создавать группы, возможно нет (пишите в комментариях, если знаете). Для митингов мы использовали физические телефоны. Вскоре, появились виртуальные телефоны в виде приложения на компьютере. Также мы использовали Webex для тренингов или презентаций, которые мы хотели записать.
Через несколько лет вместо ICQ мы начали использовать Skype, но письма все также были основным средством ассинхронной коммуникации. В Skype уже точно можно было создавать группы, на десятки и сотни человек и получать тонну непонятных нотификаций, а также совершать видео звонки.
Примерно, 8 лет назад, я начал использовать Slack. Но он был также в дополнение к письмам в outlook.

Когда я пришел в Amazon, то мы также использовали стандартные письма и outlook, а также внутренний тул Amazon Chime. Это такой местный аналог Slack. Когда я уходил из Amazon, началась миграция на использование Slack.

Когда я пришел в Facebook, то пришлось привыкать к абсолютно новому способу коммуникации при помощи местного тула Workplace. Это комбинация Slack и Facebook в одном туле. Там можно совершать аудио и видео звонки, создавать конференции, стримить, есть группы, чаты, боты и многое другое. Письма в Facebook практически не используются. Вместо этого люди пишут посты, как в Facebook, а другие комментируют, репостят, лайкают и т.д. К этому пришлось привыкать дольше всего. Даже переход на другой язык программирования для меня прошел быстрее. Т.к. до этого я 13 лет для больших ассинхронных обсуждений использовал outlook. Тут же пришлось перестраиваться на использование что-то типа соцсети для работы. Это было очень не привычно.

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

Некоторые подходы к архитектуре приложений в Amazon

Описал некоторые, часто используемые подходы в Amazon: Некоторые подходы к архитектуре приложений в Amazon

Google I/O 24

Теперь все делают AI и вставляют его везде:

https://www.youtube.com/live/XEzRZ35urlk?si=hZee083i2C-iqZfw

Стоимость покупки недвижимости в Лондоне vs Москве

Лондон - это один из самых дорогих городов мира для жизни. Существенная часть этой дороговизны происходит из дороговизны недвижимости. Как для съема, так и для покупки. В тоже самое время зарплаты в Лондоне выше, чем во многих других городах и странах. Решил провести сравнение насколько реально дорогая недвига в Лондоне для покупки. Для сравнения я буду использовать Москву (где я жил и работал 12 лет). Если цифры для Москвы некорректны, пишите в комментариях, я проверю и поправлю расчеты, т.к. я не живу в Москве уже 8 лет и пользовался разными сайтами для получения цифр, а не из личного опыта.

Для сравнения я буду брать медианную стоимость жилья. Медианную стоимость я взял на текущую дату исходя из текущих предложений на https://www.cian.ru/ и https://www.rightmove.co.uk/.
Также буду сравнивать эту стоимость по сравнению с медианной зп Senior Java Developer. Значения по зп я брал с glassdoor и hh.

Медианная зп Senior Java в Лондоне - £90 000 в год (моя зп £480 000, но это самый верх рынка и таких людей очень мало, я же сравниваю среднее по больнице).
Медианная зп Senior Java в Москве - 300 000 рублей в месяц (напишите если эта цифра не валидна, 8 лет назад это было 150 000 рублей).

Чтобы сравнивать одно и тоже, сделаю расчет зп в месяц после налогов и переведу в доллары.
Медианная зп Senior Java в Лондоне в месяц после налогов: £5.2k/$6.6k
Медианная зп Senior Java в Москве в месяц после налогов: 261k рублей/$2.89k
Т.е. зп на руки на той же позиции отличается в 2.3 раза.

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

Москва:
Однушка: 12M рублей/$132k
Двушка: 17M рублей/$187k
Трешка: 25M рублей/$275k
Лондон:
Однушка: £350k/$444k
Двушка: £425k/$539k
Трешка: £600k/$762k

Перведем это в число зп в месяц на руки:

Москва:
Однушка: 46 зп
Двушка: 65 зп
Трешка: 96 зп
Лондон:
Однушка: 67 зп
Двушка: 81 зп
Трешка: 115 зп

Т.е. если рассматривать покупку на сбережения, без ипотеки, то в Москве это сделать проще на 20-45%.
Но с такой зп и с такой стоимостью недвиги накопить почти нереально. Поэтому все берут ипотеку. Интересней было бы посмотреть на ежемесячный платеж в пропорции к зп. Но тут все зависит от процентной ставки. Для Лондона я взял реальную среднюю ставку. Для Москвы я сделал расчет с двумя ставками: 5% (льготная ипотека для итишников, но она до 18M рублей) и 16.7%. Расчет делал на 25 лет и 20% начального платежа.

Москва:
Однушка: 135k рублей (16.7%)/56k (5%) рублей. Или в процентах от зп: 52%/21%
Двушка: 192k рублей (16.7%)/79k (5%) рублей. Или в процентах от зп: 73%/30%
Трешка: 282k рублей (16.7%)/Нет льготной ипотеки. Или в процентах от зп: 108%. Т.е. трешку даже в ипотеку нереально. Только смотреть низ рынка или пригород.
Лондон:
Однушка: £1.7k. Или в процентах от зп: 32%
Двушка: £2k. Или в процентах от зп: 38%
Трешка: £2.86k. Или в процентах от зп: 55%

Т.е. если есть возможность получить льготную ипотеку под 5%, то получается в Москве можно немного выгодней взять однушку или двушку. На такую трешку льготу получить не получится. Если льгот нет, то из-за процентной ставки получается, что в Лондоне купить квартиру проще.

Если интересно, то сделаю такое же сравнение для Амстердама и Берлина, другие крупные IT хабы Европы и туда едет много людей.

Какие AWS сервисы мы часто использовали, когда я работал в Amazon?

1) Dynamo DB - NoSQL база. Часто использовали ее как key-value storage. Время доступа к значению по ключу составляет несколько миллисекунд, при этом позволяет хранить большие объемы данных по сравнению с in-memory cache.
2) SQS - распределенная очередь. Подходит для асинхронной bulk обработки данных. Позволяет реализовать простейший back pressure механизм между двумя компонентами и сгладить пики производства данных producer и не перегрузить этими пиками consumer.
3) Amazon Redshift - Data Warehouse. Позволяет хранить и обрабатывать колоссальные объемы данных (Big Data). Позволяет делать анализ больших объемов данных, ETL и т.д.
4) RDS - распределенная SQL/реляционная база данных.
5) SNS - pub-sub сервис. Можно создавать топики и подписываться на них. Имеет куча интеграций, в том числе можно делать SMS и e-mail нотификации.
6) S3 - blob storage. Позволяет сохранять данные в виде файлов, и получать к ним доступ. Netflix использует S3 для хранения видео. Часто используется для хранения другой медиа информации, видео, картинки, аудио. Часто используется для хранения файлов и промежуточных выгрузок больших объемов данных для дальнейшей обработки.
7) SageMaker - позволяет создавать, обучать и деплоить в продакшен модели машинного обучения (ML).
8) Cloudwatch - позволяет мониторить ваш сервис в продакшене. Создавать и мониторить метрики, создавать дашборды и алармы и т.д.
9) EC2 - Самый частый сервис используемый в AWS. Позволяет вам арендовать сервера и деплоить на них ваши приложения. Позволяет делать auto-scaling в зависимости от нагрузки. Мы использовали не часто, т.к. тогда только шла миграция на EC2. Чаще использовали внутренние серваки.
10) Lambda - serverless вычисления. Вы можете просто написать какой-то код, и вам не нужно заниматься менеджментом серверов, на которых она должна выполняться. Часто используется как listener на какие-то события. Например, ее можно подписать на SNS топик и при получении нотификации Lambda будет выполнена. Или можно использовать для запуска кода по рассписанию для housekeeping работ. Очень дорогой сервис, поэтому использовали редко.
11) ElastiCache - распределенный кэш. Поддерживает Redis и Memcached.
12) Kinesis - стрим по типу Kafka. Можно дампить большие объемы данных из вашего приложения в S3, Redshift или Elasticsearch.
13) QuickSight - позволяет визуализировать данные и строить дашборды. Часто применяется для визуализации данных из Redshift.
14) Kafka - позволяет легко разворачивать и менеджить из коробки Kafka.
15) Elasticsearch - позволяет легко разворачивать и менеджить из коробки Elasticsearch. Позволяет индексировать данные и получать к ним быстрый доступ, делать поиск, строить дашборды и т.д.

AWS имеет куча других сервисов, в том числе и для Load balancing, API Gateway, Routing, авторизации и аутентификации и много чего другого. Но мы их использовали реже, т.к. были другие альтернативы, не открытые внешним клиентам.

Чем отличается Junior от Middle программиста?

Оба уровня являются начальными для программиста и в сумме на этих уровнях програмист находится от 2 до 10 лет. Обычно, рано или поздно он промоутится до Senior уровня. На котором он уже может находится очень долго, вплоть до конца карьеры. Хотя существенная часть senior программистов продолжает карьерный рост. Либо конвертируются в менеджеры или становятся Staff+/Architect в зависимости от того, как устроены роли в компании.
Но не опыт, или не только опыт, отличает Junior от Middle. Промоушены в IT не дают просто за выслугу лет. Хотя корреляция с опытом есть, т.к. нужно время, чтобы получить, а главное продемонстрировать свои скилы на следующий уровень.

Так что же отличает Junior от Middle?

1) Самостоятельность. С ростом от Junior до Senior растет самостоятельность программиста в решении задач. Junior программисту нужна большая помощь при работе над задачами, чем Middle программисту. Но многие программисты неверно трактуют самостоятельность. Многие просто перестают задавать вопросы и застревают при решении задачи, продалбывая сроки. Самостоятельность проявляется в том, что вы драйвите решение задачи самостоятельно. Сами определяете, что вам не хватает для решения задачи, что нужно уточнить или выяснить, что нужно самому покопать и т.д. Т.е. это не означает, что вы все знаете изначально и быстро сделаете задачу, никого не спрашивая. Это значит, что вы самостоятельно будете делать все необходимое для приближения решения задачи, в том числе, задавать вопросы, обсуждать, договариваться, выяснять, самому копать код, документацию или интернет. Junior программисту нужен постаянный гайденс, какие следующие шаги нужно предпринять, чтобы продвинутся в решении задачи.
2) Скоуп/размер задач. С ростом уровня, будет расти скоуп задач, над которыми вы работаете. Для Junior это какие-то микрофичи, багфиксы, root cause которых известен и т.д. Для мидла это среднего размера фичи, описание которой уже существует, багфиксы, для которых не известен root cause и фикс которых может потребовать обсуждений, алайментов или дизайна. При работе над фичей - требования определены или есть человек, который их определит, мидлу же нужно сделать небольшой дизайн и реализовать. Для Junior нужно не только детально поставить задачу, но и указать технический путь ее решения (дизайн или конкретный код, который нужно изменить).
3) Dealing with ambiguity(работа с неопределенностью). Этот скил растет при переходе между всеми уровнями. Junior практически не имеет этого скила. Ему нужно детально поставить задачу и указать технический путь ее решения. Мидл также работает с поставленной задачей, но он способен самостоятельно уточнять требования, обсуждать требования с разными людьми, делать небольшой технический дизайн. Начиная с уровня Senior и тем более с уровня Staff+ вам самому придется придумывать задачи/проблемы, но про это отдельно напишу.
4) Качество кода. Junior не имеет опыта ни в индустрии, ни в компании и команде. Его код может состоять из глупых велосипедов и антипаттернов. Чтобы стать мидлом вам нужно адаптироваться к стандартам кодирования в вашей команде и соответствовать среднему уровню. Вначале, вы будете получать множество комментариев на код ревью по качеству кода, вам нужно быстро обучаться и работать над тем, чтобы вы начали соответствовать по этому параметру вашей команде и получать комментарии по существу решаемой задачи и меньше общих замечаний по структуре кода. На уровне Senior вам же нужно задавать эти стандарты кода для команды.
5) Экспертиза в какой либо области в рамках команды. Обычно, Junior это не тот человек, к которому идут спрашивать что-либо. Даже по теме задачи, которую он решает. Мидл же углубляется как минимум в тему задачи, над которой он работает и может быть тем человеком, кто может ответить на те или иные вопросы по этой задаче или связанных с ней темам. Мидл становится person to go, по одной или более темам в рамках команды.

6) Getting things done. Junior, обычно, делает микрошаги, которые ему говорят и не овнит полностью задачу. Мидл же драйвит решение задачи и имеет послужной список из решеных на хорошем уровне, в разумные сроки, среднего размера для команды задач.

Это мои мысли на эту тему, пишите, что вы об этом думаете.

Задача с собеседования в Microsoft: Самое большое палиндромное число
Задача. Дана строка, состоящая только из цифр. Нужно вернуть наибольшее палиндромное число, которое может быть составлено, используя только цифры из данного числа. Необязательно использовать все цифры из заданного числа, но нужно использовать хотя бы одну цифру. Цифры можно использовать в любом порядке. Нельзя дополнять результат ведущими нулями (нулями в начале).

Ссылка на leetcode: https://leetcode.com/problems/largest-palindromic-number/description/

Пример:

Input: "444947137"
Output: "7449447"

Пример:

Input: "00009"
Output: "9"

Решение. Решение описал тут: Задача с собеседования в Microsoft: Самое большое палиндромное число

Странные тайтлы в инвест банках

Когда я планировал устроится на работу в один их крупнейших инвест банков, я не знал какие там есть роли и тайтлы у сотрудников. Тогда я привык к тайтлам типа Junior, Middle, Senior, Lead, Architect, Manager, Director и т.д. И когда я увидел у некоторых, людей, кто там работает, кого я знаю, тайтлы типа VP, я подумал нифига себе они устроились. Я знал, что инвест банки платят больше, чем средняя по больнице компания. Но для меня VP, это кто-то, кто репортит непосредственно c-team (CEO, CTO, CPO, CFO и т.д.). Т.е. тот, кто имеет в подчинение много тысяч человек и получает миллионы долларов.
Но к моему удивлению оказалось, что там этих VP жопой жуй. Там тайтлы устроены по другому.
Наглядно посмотреть соответствие тайтлов в Deutsche Bank, JP Morgan и Facebook можно тут: levels.fyi
По факту, оказалось, что VP - это Staff Software Engineer для разработчика или для менеджера - это самый низкий уровень менеджера.

Примерное соответствие тайтлов в Deutsche Bank:
1) Analyst - Junior
2) Associate - Middle
3) AVP - Senior
4) VP - Staff/Manager
5) Director - Senior Staff/Principal/Senior Manager
6) Managing Director - Distinguished Engineer/Fellow/Director of Engineering

Примерное соответствие тайтлов в JP Morgan:
1) Analyst - Junior
2) Associate - Junior
3) Senior Associate - Middle
4) VP - Senior
5) Executive Director - Staff
6) Managing Director - Senior Staff/Principal