Алгоритм топологической сортировки
Кратко, описал алгоритм топологической сортировки для ориентированного графа с реализацией на Java:https://dev.to/faangmaster/topologhichieskaia-sortirovka-4eee

Это третий алгоритм, который нужно знать на графах (два другие это DFS и BFS). Он встречается намного реже на собеседовании, но все же бывает. Но и на практике он также встречается, мне приходилось его реализовывать на работе для выполнения графа задач в rule engine.

Еще один подозрительный случай на собеседовании

Другой подобный случай я описывал тут: https://t.me/faangmaster/214

Я вчера собеседовал кандидата, уже на full loop (он прошел phone screen). Дал две задачи. Одна на two pointers, другая на dfs и бинарное дерево. Кандидат зачем-то писал очень подробные комментарии перед тем как написать код. Как будто он писал промпты. Как только я сказал ему не писать комментарии, чтобы не тратить время, я и так пойму, он не смог больше писать вразумительный код. Более того, он смог решить почти правильно задачу на dfs, но не смог продебажить код от слова вообще. Он не мог продвинуться ни на шаг в том как работает код на простом примере. Он конечно будет зареджекчен, но по осям verification, problem solving. Доказательст, что он читерил у меня нет. Но это уже второй случай за месяц из 8 собеседований, которые я провел за этот месяц.

Составил подборку из 100 задач на leetcode для сбалансированной подготовке к алгоритмическому собеседованию

Ранее я уже составлял подборку из easy задач на leetcode на основные темы для тех, кто только начинает подготовку к алгоритмическому собеседованию: https://t.me/faangmaster/171

Сейчас я подготовил подборку из 100 задач, которые включают как easy так и medium задачи на все ключевые темы необходимые для алгоритмического собеседования: https://dev.to/faangmaster/podborka-zadach-na-leetcode-dlia-podghotovki-k-alghoritmichieskomu-sobiesiedovaniiu-4n51

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

Подборку сгруппировал по темам. Dynamic Programming можете оставить напоследок, т.к. это самая сложная тема.

Шпаргалка по основным алгоритмам для алгоритмического собеседования

Написал шпаргалку с основными алгоритмами, которые необходимо знать для прохождения алгоритмического собеседование. Эти алгоритмы рекомендую знать на память и воспроизводить их менее чем за 5-10 минут без подсказок на листе бумаге или в текстовом редакторе. Эти же алгоритмы можете найти в других книгах или интернете и реализовывать так как вам удобно. Я привел свои реализации на Java.

Шпаргалка по основным алгоритмам для алгоритмического собеседования

Шпаргалка по Java для алгоритмического собеседования

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

Написал, основные конструкции, которые необходимо знать тут: https://dev.to/faangmaster/shparghalka-po-java-dlia-alghoritmichieskogho-sobiesiedovaniia-1bn6

Возможно, еще немного расширю позже. Пишите, что упустил или если есть ошибки.

Подборка фильмов, сериалов и документалок о программистах, BigTech, стартапах и их основателях

Поздравляю всех с наступающим новым годом! 🎄🎄🎄🎄🎄

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

1) Silicon Valley. Крутой комедийный сериал про стартаперов в Кремниевой долине. Кинопоиск 8.5, Imdb 8.5
2) Холивар. История рунета. Документалка от Андрея Лошака про историю рунета. Смотрится на одном дыхании. Есть на youtube: Холивар. Кинопоиск 8.2, Imdb 7.8.
3) Русские хакеры: Начало. Еще один шедевр документалистики от Андрея Лошака. Кинопоиск 8.4, Imdb 7.3.
4) Rise of the Billionaires. Отличная документалка про Безоса, Цукерберга, Маска, Брина, Пейджа и других. Про становление BigTech компаний. Смотрел ее в самолете, когда летел из Лондона в Сан-Франциско, чтобы поработать из штабквартиры фейсбука в Менло Парк. Зашло отлично. Imdb 7.8.
5) Социальная сеть. Хорошее кино про создание фейсбука от Девида Финчера. Кинопоиск 7.7, Imdb 7.8.
6) Пираты Силиконовой Долины. История противостояния Джобса и Била Гейтса. Кинопоиск 7.5, Imdb 7.2.
7) Социальная дилемма. Отличная документалка о влиянии социальных сетей на жизнь людей. Очень много интервью с сотрудниками Google, Facebook, Twitter, YouTube про их работу, разработки и почему они уволились. Кинопоиск 7.3, Imdb 7.6.
8) Игра в имитацию. Фильм про Алана Тьюринга, одного из основоположников компьютерной эры. В его честь есть премия в области Computer Science, аналог нобелевской премии для тех, кто занимается алгоритмами, структурами данных и другими разделами Computer Science. Кинопоиск 7.6, Imdb 8.0.
9) Стив Джобс. Фильм от Дэнни Бойла с Майклом Фасбендером в главных ролях. Кинопоиск 6.7, Imdb 7.2.
10) Джобс: Империя соблазна. Фильм с Эштоном Кутчером в главных ролях. Кинопоиск 6.5, Imdb 6.0.

Бонус, фильмы, рекомендованные подписчиками:
11) Кадры. Кинопоиск 7.0, Imdb 6.3
12) Кто убил BlackBerry. Кинопоиск 7.4, Imdb 7.4
13) Код на миллиард долларов. Кинопоиск 7.6, Imdb 8.0

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

На кодинг интервью в FAANG и другие компании, которые проводят кодинг собеседовая похожим образом, вы можете выбрать сами, на каком языке программирования писать код. Но это должен быть настоящий и востребованный язык программирования. Писать на псевдокоде нельзя. Также не стоит выбирать мертвые, редкие, специализированные, учебные или эзотерические языки программирования. Не стоит писать на брейнфаке, паскале, бейсике, аде, ассемблере или коболе. Наиболее частые варианты это Python, Java, JavaScript, C/C++, C#, Kotlin, Rust, Go, Objective C, Swift. Если вы собеседуетесь на мобильного разработчика, то стоит выбрать Java, Kotlin, Objective C, Swift. Если на frontend или full-stack, то подойдет и JavaScript. Если на back-end/infra, то Java, C#, C/C++, Rust, Kotlin, Python. Если на ML, то python.
Главное выбрать язык программирования, который вы знаете лучше всего и на нем же практиковались решать алгоритмические задачи.
Очень часто кандидаты выбирают python, несмотря на то, что это не язык, который они знают лучше всего. Они думают, что на нем лучше/легче решать такие задачи. Имхо это заблуждение и большая ошибка. Я очень часто наблюдаю на собеседованиях, как люди, которые пишут на python не знают элементарного синтаксиса, стандартных функций и того как они работают. Это приводит к смешным конструкциям в коде (ака "индуский код"), а также к неспособности правильно оценить временную сложность и сложность по памяти, т.к. кандидаты не знают как в реальности работают те или иные стандартные функции. Также, те кто пишет на python не знают как правильно сравнивать обьекты в python и это приводит к неправильным решениям или дополнительным предположениям, которые нужно накладывать на входные данные. По числу строк решения на python, не будут сильно короче, иногда они получаются даже длиннее, если человек начинает изобретать велосипеды по незнанию. Обьявления переменных будет короче и это единственный реальный выиграш в длине.
Поэтому я рекомендую использовать язык программирования, который вы знаете лучше всего и на нем же практикуйтесь решать алгоритмические задачи.

Наступит ли счастье, если вы пройдете собеседование в FAANG?
#мысли

Часть 1. Плюсы.

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

Начну с приятных моментов, которые и заставляют многих программистов туда стремиться:

1) Престиж компании. Вам будет приятно говорить друзьям, родственникам, бывшим коллегам, что вы там работаете. Или когда кто-то в компании случайно узнает, где вы работаете это будет вызывать интерес. Но это чувство достаточно быстро проходит. Это как после того как вы купили себе новый крутой телефон или машину. Вначале это приносит много положительных эмоций, но очень быстро это просто становится телефоном и все. Или как люди, которые недавно стали богатыми или просто получили какие-то деньги, сразу покупают броские брендовые вещи типа гучи или баленсиага с лейблом больше чем сама одежда. Но, что останется с вами навсегда, так это полезная строчка в резюме.
2) Большая зп. Зарплаты в FAANG самые или одни из самых больших в индустрии. Где бы не находился офис компании, они всегда предлагают компенсацию сильно выше рынка. Это вполне может быть в 2 или 3 раза выше, чем медианная зп по рынку на данной позиции.
3) RSU (стоки, акции). Существенная часть компенсации в таких компаниях это акции самой компании. Вы можете их сразу продавать, как только вы их получаете. По сути, это будет эквивалентно, просто, получению наличных. Или же держать их в ожидании роста. А акции FAANG компаний имеют тенденцию к быстрому росту. Например, когда я работал в Amazon, то акции, которые мне выплатили, выросли в 4 раза за время работы там.
4) Возможности карьерного роста будучи программистом, без конвертации в менеджера. В большинстве компаний, как только вы достигли уровня Senior/Lead, для дальнейшего роста нужно конвертироваться в менеджера. Не всем нравится заниматься менеджментом + далеко не все могут стать менеджерами, тем более хорошими. В FAANG есть куча уровней для чисто инженеров. Вы можете расти будучи чисто инженером, без прямых подчиненных. Число таких уровней варьируется от 6 до 8: от junior до distinguished и fellow. С зп отличающимися в 15-20 раз между самым низким и самым высоким уровнем. От $150 000-$200 000 до $2 500 000 - $3 000 000 в год (для США).
5) Возможность поработать с умными людьми, иногда даже выдающимися инженерами. В силу того, что FAANG привлекает много талантливых инженеров, среди ваших коллег будет много очень много умных и способных программистов. Среди них есть инженеры (особенно на высоких уровнях вроде principal, senior staff), у которых есть чему поучиться как в инжиниринге, так и в выдающихся софт скилах. Многие из них давно работают в этих компаниях и поучаствовали в создании самых передовых технологий.
6) Возможность поработать над большими и сложными проектами/продуктами. Вы можете попасть в команду, которая делает очень интересный, большой и важный продукт. Что значит интересный зависит, конечно, от вас. Если вы фронтендер это может быть разработка самого популярного фреймфорка react. Если мобильный разработчик, то может быть разработка мобильной версии youtube или инсты. Если занимаетесь бекендом, то какие-то продукты AWS или youtube и т.д. Но тут надо учитывать, что даже эти компоненты такие большие, что над ними работает гигантское число команд и вы будете работать над небольшой частью. Или над вспомогательными продуктами, которые никому не видны, но используются другими командами.
7) Куча других мелких бенефитов. Сюда относится бесплатная еда в офисе (у нас можно есть 3 раза в день и водить свою семью или друзей, а также снеки), компенсация транспорта, интернета и тому подобное.

Чуть позже напишу про минусы и реалии работы.

Задача на динамическое программирование: Longest Increase Subsequence

Записал разбор задачи на динамическое программирование: Longest Increasing Subsequence.

Задача. Дан массив целых чисел. Нужно найти длину самой длинной строго возрастающей подпоследовательности.

Ссылка на видео: https://www.youtube.com/watch?v=gHXsAouqHxg

Ссылка на leetcode: https://leetcode.com/problems/longest-increasing-subsequence/

Наступит ли счастье, если вы пройдете собеседование в FAANG?
#мысли

Вторая часть. Первая тут: https://t.me/faangmaster/254

Часть 2. Минусы.

Большинство минусов напрямую вытекают из плюсов.

1) Высокие ожидания. Работа в FAANG это далеко не пенсия или курорт-санаторий. Все плюшки и высокие зп платят за то, что вы будете перфомить как мало кто может. FAANG компании успешны, в основном, благодаря тому, что они привлекают лучших инженеров и ожидают, что они будут работать как лучшие инженеры в индустрии. Это добавляет достаточно много стресса в вашу жизнь, особенно, если вы страдаете от синдрома самозванца или очень чувствительны к чужому мнению или у вас синдром отличника.
2) Калибровки. Чувство того, что вас постоянно оценивают и страх underperforming'а. Этот минус связан с предыдущим. Все эти высокие ожидания они не на словах. Они формализованы в виде процеcса калибровки. Раз в год или полгода вам надо пройти через оценку вашего перфоманса, собрать фидбеки, описать свои достижения. Они будут сравниваться с формальными ожиданиями и с другими инженерами. По результатам вам будет выставлена оценка, как в школе. В зависимости от этой оценки вам могут повысить зп, увеличить бонус, дать новых акций. Но также вас могут отправить на pip (performance improvement plan) и даже уволить. Несколько процентов в год увольняют по перфомансу.
3) Высокая конкурентность. Помимо высоких ожиданий, ваши достижения будут сравниваться с другими инженерами того же уровня. А в силу того, что большинство инженеров очень высокого класса вам надо показать себя не хуже и даже лучше других. Это приводит к кому, что ваши коллеги действуют так, чтобы выглядеть лучше вас на калибровке.
4) Промоушены выше Senior уровня затруднительны. Вырасти из junior до senior относительно просто. Более того, от вас это ждут за конкретный, ограниченный промежуток времени. Типа 5 лет. Если вы не запромоутитесь, то вас уволят. Senior уровень считается терминальным и от вас необязательно ждут, что вы будете расти дальше. Но если вы хотите стать staff, principal, то там гигантская конкуренция и ожидания. Вам нужно к этому идти целенаправленно, работать очень умным способом, специально под промоушен. Находить специальные проекты, работать лучше подавляющего числа инженеров, показывать результаты и поведение под промоушен.
5) Золотая клетка. Из-за того, что у вас большая зп, вам сложно решить уволиться. Т.к. это будет скорее всего с понижением зп. Вы конечно можете пойти на 1-2 уровня выше в компанию попроще, но это сложнее и далеко не факт, что даже в таком виде вы получите больший офер. Поэтому многие остаются из-за зп, даже если им не нравится то, над чем они работают.
6) Высокие визовые и денежные риски в первый год-два работы. Если вы прошли собеседование в FAANG и вам надо переехать в другую страну, то вам надо получить визу и потратиться на переезд. Все это оплатит сама компанию. Но виза будет привязана к работодателю. И если вас уволят, то у вас будет очень короткий срок, чтобы найти новую работу в этой стране. Иначе вам надо будет выехать из страны. А сейчас найти работу программистом очень сложно и занимает много времени. Более того, деньги, потраченные за переезд и бонус за подписание контракта вам надо вернуть компании, если вы ее покинете раньше чем за 1-2 года. А так как первые 6 месяцев вы на испытательном сроке, то это добавляет гигантское количество стресса.
7) Куча внутренних тулов. Почти все тулы и технологии, которые вы будете использовать на работе - внутренние. Таких вы больше не встретите нигде. Иногда они становятся open-source и становятся общедоступными, но далеко не всегда. Вам придется потратить куча времени на их освоение, которое потом слабо транслируется на другие компании и технологии. Только принципы и подходы. Это может быть начиная системами контроля версий и заканчивая языками программирования. Например, Go и Hack это изначально внутренние языки в Google и Facebook, которые сделали общедоступными в какой-то момент. Это особенно чувствительно для начинающих программистов. Т.к.

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

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

P.S. Придумал такую аналогию для тех кто интерисуется футболом. Это похоже на то как игрок переходит из местного клуба в Барселону или Реал. У вас будут выше доходы, но и ожидания и конкуренция будет сильно выше. Если вы раньше в своем клубе были на 2 головы выше ваших одноклубников, то в топ клубе будет на так просто проявить себя и выиграть конкуренцию за место в составе. Или с переходом из обычной школы в профильный топ лицей или гимназию. Или в топ вуз.

Всех с пятницей. Сделал ролик с Тиньковым. https://youtu.be/uPhEJjfDXHQ?si=nCLULlvUJLihM_5t

Сделал короткий видос с рейтингом алгоритмов и структур данных по частоте встречаемости на собеседовании. Условно, Динамическое программирование очень редко (кроме google), поэтому можно и без него в faang попасть. https://youtu.be/6pE19OIrvSQ

Более полный список в моем посте https://t.me/faangmaster/25

Вопрос с собеседования по Java: что такое Java Memory Model и happens-before
#java #concurrency

Более подробно можно почитать в книге Java Concurrency in Practice by Brian Goetz. Которую, я уже рекомендовал в этом канале.

Кратко написал тут: https://dev.to/faangmaster/vopros-s-sobiesiedovaniia-chto-takoie-java-memory-model-i-happens-before-410g

Задача с собеседования: первый пропущенный положительный элемент массива

Задача. Дан неотсортированный массив целых чисел. Нужно найти первое пропущенное положительное число.

Например,
для [1,2,0] ответ 3.
для [3,4,-1,1] ответ 2.
для [7,8,9,11,12] ответ 1.

Решение должно работать за O(n) и с O(1) дополнительной памяти.

Ссылка на leetcode: https://leetcode.com/problems/first-missing-positive/description/

Решение. Описал тут: https://dev.to/faangmaster/zadacha-s-sobiesiedovaniia-first-missing-positive-28ic

Ситуация с хайрингом в Big Tech (и не только) в Европе и США на январь 2024
#мысли

В сентябре 2023 я писал пост с обзором состояния рынка труда программистов: https://t.me/faangmaster/178

На тот момент уже завершились основные массовые сокращения в большинстве крупных компаний, число вакансий при этом перестало лететь в пропасть и начало медленно восстанавливаться: https://t.me/faangmaster/210

График числа вакансий тут: https://www.trueup.io/job-trend

Что изменилось с того времени? Что по поводу новых сокращений? Что по поводу LLM?

Число вакансий особо не изменилось с тех пор. Оно продолжает расти, но очень медленно. Но что существенно изменилось, это то, что программисты уволенные во время крупных сокращений в Big Tech/FAANG успели найти себе работу (в основной своей массе). Поэтому конкуренция несколько упала. Ранее программистам приходилось конкурировать за небольшое число вакансий с бывшими программистами Google, Amazon, Facebook и т.д. Сейчас их на рынке осталось намного меньше. При этом сокращения все еще происходят, но пока это не очень массово. Не сравнимо с тем что было год назад.
Второе изменение - FAANG снова начал активно хайрить. После массовых сокращений и простоя в найме в более чем год, найм снова возобновился. Начиная с октября я провожу 8-10 собеседований в месяц. До этого я не собеседовал более года. Число вакансий не впечатляет, но существенное. Только в Facebook ~2 тысяч открытых вакансий. В Amazon оно измеряется в десятках тысяч. Далеко не все эти вакансии для программистов, но их достаточно большое количество.
Но есть особенность хайринга - очень мало вакансий для начинающих программистов. Во время сокращений больше всего пострадали позиции junior и middle. Во многих компаниях людей ниже уровня senior осталось менее 30%. Но и после возобновления найма, компании, в основном, нанимают людей с опытом. При этом интернов набирают в прежнем режиме. Я достаточно много интернов сейчас тоже собеседую. Т.е. позиции интернов не пострадали.
Тут можете почитать мое мнение про курсы программистов: https://t.me/faangmaster/85. Если, коротко, они создают избыточное предложение junior программистов, которые сейчас не очень востребованы.

Тут я писал про LLM и замену программистов: https://t.me/faangmaster/228, https://t.me/faangmaster/229
Если коротко, то пока технологий способных заменить программистов не существуют. Есть технологии, которые могут повысить их производительность. Но не ясно к чему приведет развитие в этой области в ближайшем или не очень будущем. В краткосрочной перспективе это будет зависеть от возможностей ChatGPT 5, и llama 3 от Meta и от возможностей AGI (https://www.theverge.com/2024/1/18/24042354/mark-zuckerberg-meta-agi-reorg-interview). Если результаты будут не впечатляющие, то думаю весь хайп начнет проходить и программисты перестанут бегать с горящей *опой.

Задача с собеседования в Facebook: Удалить минимальное число скобок, чтобы сделать скобочное выражение правильным

Задача. Дана строка состоящая из круглых скобок '(' и ')', а также английских букв в нижнем регистре. Нужно удалить минимальное число скобок, чтобы сделать скобочное выражение правильным.

Ссылка на leetcode: https://leetcode.com/problems/minimum-remove-to-make-valid-parentheses/

Решение описал тут: https://dev.to/faangmaster/udalit-minimalnoie-chislo-skobok-chtoby-sdielat-skobochnoie-vyrazhieniie-pravilnym-4be2

Код решения:

public String minRemoveToMakeValid(String s) {
    Stack<Integer> stack = new Stack<>();
    Set<Integer> toRemove = new HashSet<>();
    for (int i = 0; i < s.length(); i++) {
        char c = s.charAt(i);
        if (c == '(') {
            stack.push(i);
        } else if (c == ')') {
            if (stack.isEmpty()) {
                toRemove.add(i);
            } else {
                stack.pop();
            }
        }
    }
    while (!stack.isEmpty()) {
        toRemove.add(stack.pop());
    }
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < s.length(); i++) {
        if (!toRemove.contains(i)) {
            sb.append(s.charAt(i));
        }
    }
    return sb.toString();
}

Как проходят Code Review в Amazon и Facebook?

Code Review это неотъемлемая часть процесса разработки во многих компаниях, в том числе и в FAANG. Поделюсь личным опытом, на что обращают внимание при Code Review в двух из них и чем они отличаются.

Смотрите также мой пост про version control в FAANG: https://t.me/faangmaster/81

Amazon:
1) Наличие ошибок в коде. В большинстве FAANG компаний нет отдельных QA. Поэтому тестирование ложится на самих разработчиков. Они должны писать правильно работающий код и писать тесты. Code Review помогает посмотреть на этот код со стороны другими разработчиками и найти в нем ошибки.
2) Наличие тестов и покрытие тестами. Даже если у вас не найдут ошибки в коде, вам могут указать не нехватку тестов, не покрытии каких-то edge-case и т.д. И в процессе написания таких тестов вы сами сможете выявить ошибку если она там есть.
3) Форматирование и читаемость кода. У разных команд есть свой стиль форматирования кода и он может отличатся от других компаний и даже команд внутри Amazon. Обычно, команды договариваются заранее, что считать правильно отформатированным и читаемым кодом, а что нет. Наша команда это сделала на основе некоторых принципов описанных в Clean Code (не всех, но тех, которые мы посчитали логичными для себя). Автоформатеры кода также используются, но по моему опыту они не покрывают все случаи. Когда вы только начнете работать в вашей первой команде или смените команду, у вас будет гигантское число комментариев в Code Review из-за читаемости и форматирование кода. Помните, что код пишется и меняется очень редко, а читается в десятки раз чаще, поэтому его нужно писать читаемым.
4) Расширяемость и поддерживаемость кода. Можно ли легко расширить ваш код в будущем, если появятся новые требования без переписывания всего или значительной части вашего кода? Это условно может быть соблюдение SOLID, но не обязательно, т.к. ваш код не обязательно чисто ООП. Но тут главное не переусердствовать и не делать over-engineering. Очень часто изменения в коде делают итеративно, и не обязательно в первой его версии делать его расширяемым, особенно, если не видно необходимости в таком расширении.
5) Размер Code Change. В рамках одного Code Review рекомендуется делать маленькие изменения, которые легко детально посмотреть и понять. Если изменение огромное, то больше шансов, что его никто не будет детально смотреть и просто заапрувят неглядя. Поэтому качество таких Code Review будет страдать. Лучше ваше изменение разбить на много маленьких изменений в рамках одного стэка изменений.
6) Уточняющие вопросы. Code Review это также хороший способ понять, над чем и как работает тот или иной человек или команда. Если вы хотите в этом разобраться или быстрее заонбордится в команду, то делайте Code Review и задавайте вопросы, если что-то или все непонятно.
7) Каждое изменение не должно ничего ломать. Как я уже описывал тут (https://t.me/faangmaster/81) в FAANG используется trunk-based разработка. И поэтому каждое изменение идет сразу в trunk/master и сразу деплоится в prod. А т.к. обычно вы разбиваете работу над задачей на много маленьких Code Change, то каждое из них не должно ломать trunk и prod. Вы можете, например, в одном Code Change написать интерфейсы, во втором их реализацию, в третьем сделать вызовы вашей реализации.

Дополнение:
8) Есть ли код, отвечающий за мониторинг релиза. Есть ли эмитинг метрик, логов, алармы и т.д. Какие образом ваш релиз будет сапортится уже в продакшене.
9) Аффектит ли это изменение другие компоненты и команды. Иногда ваше изменение может заафектить другие компоненты или команды. В таком случае нужно добавлять людей из этих команд, в качестве reviewer. Или кто-то из вашей команды может на это указать.
10) Правильность подхода. Иногда reviewer может предложить альтернативный подход или вообще поставить под вопрос необходимость этих изменений или задачи в целом. Особенно это актуально, если у вас не было Design Review на эту задачу.

В Facebook, культура разработки другая. Тут основная заточенность на скорость разработки и impact, а не на культуру разработки. Поэтому пункты 2,3,4 не так важны. Очень часто код деплоится с минимальным числом тестов или вообще без них. Но тут скажем есть очень крутые авто-форматерры кода, универсальные для всей компании. Поэтому парится по поводу форматирование кода не надо вообще. Несмотря на меньшее покрытие тестами, число багов я бы сказал минимальное. За мой 17 летний опыт работы я понял, что качество кода и число багов больше зависит от качества разработчика, чем от культуры разработки. Если у вас в компании будут топ 0.1% разработчиков планеты, то они будут сразу писать правильный код, даже с минимальным числом тестов. Чем ниже уровень разработчиков, тем важнее культура разработки, чтобы предотвратить кучу багов.

Смотрите также: Design Review в Amazon, Version Control в FAANG

Пишите в комментария, как Code Review проходит у вас.

Hard задача с собеседования в Facebook: Remove Invalid Parentheses

Задача. Удалить минимальное число скобок, чтобы сделать скобочное выражение правильным. Вернуть все возможное валидные комбинации скобок, с минимальным числом удаленных скобок. Выражение состоит из круглых скобок и букв английского алфавита.

Примеры:

Input: s = "()())()"
Output: ["(())()","()()()"]

Input: s = "(a)())()"
Output: ["(a())()","(a)()()"]

Input: s = ")("
Output: [""]

Ссылка на leetcode: https://leetcode.com/problems/remove-invalid-parentheses/description/

Решение. Описал решение через BFS, которое легче для понимания, чем рекурсивное решение. 301. Remove Invalid Parentheses
Напишите, если кому интересен разбор рекурсивной версии.

Вопрос с собеседования на Java программиста: Какую коллекцию вы бы использовали в качестве Hash-таблицы в многопоточной среде и почему?

Это вопрос может иметь различную формулировку:
1) Какую коллекцию вы бы использовали в качестве Hash-таблицы в многопоточной среде и почему?
2) Что такое ConcurrentHashMap?
3) В чем преимущества ConcurrentHashMap?
4) Как работает ConcurrentHashMap?
5) В чем отличия HashMap, Collections.synchronizedMap(map), ConcurrentHashMap, Hashtable?

Ответ. В однопоточной среде можно использовать HashMap или LinkedHashMap (если надо сохранить порядок добавления элементов при итерировании). Смотрите мою статью про Map: Иерархия Map, HashMap.
Но даже в однопоточной среде мы может получить проблему в виде ConcurrentModificationException. Смотрите мою статью: ConcurrentModificationException. Дело в том, что итераторы реализуют стратегию fail-fast для не потокобезопасных коллекций. Если во время итерирования по коллекции (в данном случае по HashMap) мы произведем модификацию этой коллекции в том же потоке или в другом, то итератор в какой-то момент это обнаружит и бросит ConcurrentModificationException.
Например, такой код бросит ConcurrentModificationException даже в однопоточной среде:

Map<String, String> map = new HashMap<>() {
    {
        put("foo", "val1");
        put("bar", "val2");
    }
};
for (String key : map.keySet()) {
    map.remove("bar");
}

Для этого в однопоточной среде удаление нужно делать не напрямую методом remove, а с использованием итератора (map.entrySet().iterator(); iterator.remove();). А чтобы использовать HashMap в многопоточной среде, нужно использовать synchronized или локи перед тем как взаимодействовать с hash-таблицей. Причем, как перед модификациями, так и перед чтением, так и перед итерированиями, в том числе не явными.
Другой доступный вариант - это сделать все методы HashMap synchronized при помощи обертки:

Collections.synchronizedMap(new HashMap<>());

Но тут тоже надо помнить, что перед итерированием нужно получить лок на всей коллекции, иначе можем получить ConcurrentModficicationException.
Т.к. Collections.synchronizedMap() оборачивает все методы в synchronized, то методы put и get становятся блокирующими и только один поток может взаимодействовать в этой hash-таблицей одновременно, все остальные потоки, которые вызвали блокирующие методы будут ждать завершения операции. Это может ухудшить производительность вашей многопоточной программы.
Аналогичная ситуация и с классом Hashtable. У него также методы synchronized. И использование этой коллекции также может повлиять на производительность, а также не спасает по умолчанию от ConcurrentModficicationException без дополнительных локов.
Поэтому рекомендуется рассмотреть ConcurrentHashMap коллекцию. Она использует другой подход к блокированию коллекции под названием lock striping. Это позволяет не блокировать всю коллекцию. Множество потоков могут одновременно читать из коллекции параллельно, не ожидая друг друга. Более того, потоки, которые пишут и которые читают из коллекции, также могут получить параллельный доступ. Что еще круче - итераторы weakly consistent вместо fail-fast. Это предотвращает ConcurrentModficicationException при итерировании, но вы можете видеть не самые актуальные данные при итерировании. Более того, при чтении из коллекции вы будете видеть значение после последней завершенной операции записи. Если уже была инициированна другая операция записи, то вы можете при параллельном чтении не увидеть это значение. Это позволяет использовать ConcurrentHashMap более безопасно в многопоточной среде и получить существенно лучшую производительность. Но если нам нужна функциональность эксклюзивного доступа и более строкой консистенции данных, то она вам не подойдет.