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 более безопасно в многопоточной среде и получить существенно лучшую производительность. Но если нам нужна функциональность эксклюзивного доступа и более строкой консистенции данных, то она вам не подойдет.

С какими сложностями я столкнулся на своей первой работе программистом?

На свою первую работу программистом я попал очень давно(17 лет назад). Я попытался вспомнить свои ощущения и первые трудности, с которыми я столкнулся.
В следующих постах опишу трудности на первой работе в Европе, первой работе в FAANG и т.д.
Итак мои трудности на первой работе:
1) Дискомфорт и непривычность сидения на стуле по 8 часов в день в плотном окружении других людей и часто в тишине. До первой работы я был студентом. Когда ты студент, то у тебя график и ритм жизни другой. Ты можешь ходить или забивать на какие-то лекции или семинары. Но никогда нет такого, что ты 8 часов сидишь на одном месте. Более того, обычно там ты что-то слушаешь, а преподаватель что-то вещает. На работе же это похоже на то, как ты проводишь дома целый день за компом, только тебе нельзя прилечь и тебе в комнату пришло еще несколько десятков человек. Все это у меня вызывало сильный дискомфорт. Более того, даже после 17 лет это все еще не очень комфортно.
2) Два часа на дорогу каждый день. Когда я был студентом, то жил в общежитии в 2 минутах от учебных корпусов. До работы мне надо было ехать час в одну сторону. В сумме на работу и связанное с этим временем у меня уходило 11-12 часов в день. К вечеру я был полностью уставшим и разбитым морально. При этом моральных сил на физичискую активность оставалось мало. Что постепенно приводит к проблемам со здоровьем.
3) Сложности с тем, чтобы понять, какой код нужно изменить. До этого я писал только маленькие програмки или свои проекты, код которых был несколько классов. На работе же гигантская база кода, и без ее знания и навыков навигации по коду даже тривиальная задача становилась очень сложной. Очень часто задача сводилась к тому, чтобы поменять пару строчек, но чтобы понять какие строчки, приходилось сидеть несколько дней изучать существующий код.
4) Сложности с понимаем самой задачи. На работе используется большое количество аббривиатур и специфики для этого проекта, продукта. Вначале вообще понять, что говорят другие люди и в чем твоя задача очень сложно.
5) Сложности с дебагом кода. Когда у вас программа из 200 строчем ее легко дебажить, проверить ее работоспособность и найти ошибки. В больших проектах это намного сложнее. Иногда приходилось после измнения в пару строчек приходилось искать почему это не работает еще несколько дней.
6) Многие считают ваш код говном. Т.к. вы еще никогда не писали промышленный код и код внутри этой компании. И вцелом у вас маленький опыт в написании кода, то часто вы будете выдумывать странные для опытного программиста конструкции (индуский код). А про принятые стандарты форматирования и читаемости кода в рамках этой команды или компании я молчу. Т.к. это типично и для опытных программистов. Плохо, когда вам дают неконструктивный фидбек, типа твой код говно. Это не помогает никому. Это только создает конфликт, понижает вашу самооценку и желание работать и ничему вас не учит. На первых этапах хорошо иметь классного ментора.
7) Необходимость взаимодействия с людьми на темы, в которых вы мало разбираетесь. Т.к. вы плохо понимаете над чем вы и ваши коллеги работаете, не понимаете специфики и не ориентируетесь в code base, но решать задачу как-то нужно, то вам надо много узнавать от других людей. И общаться с ними на темы, которые вы не понимаете. Очень хорошо, когда вы найдете человека, который вам сможет все обьяснить на пальцах и понятным языком, но это очень редко. Большинство людей в IT не заинтерисованны в том, чтобы их поняли или не умеют это делать. Они чаще общаются как будто сами с собой. Не учитывая, какой уровень понимания у собеседника.
8) У вас низкая производительность и вас ставят на второй план. Т.к. у вас нет опыта, вы не разбираетесь в продукте/проекте над которым работаете, не ориентируетесь в коде, не выработали навыков работы с большими базами кода, то вам на простую задачу надо в разы больше времени и помощи от коллег. Поэтому вы начинаете отставать, становится скорее дополнительной проблемой, то вас будут чаще отодвигать на третьестепенные задачи.

Все это добавляет стресса, неуверенности в себе и создает синдром самозванца.

Это, что я вспомнил. Пишите, какие вы испытывали проблемы на вашей первой работе программистом.

Сколько я заработал на акциях за прошлый год?

Акции компании, в которой я работаю, недавно взлетели на 20% за один день. За год стоимость акций выросла в более чем 2.6 раза. Если учесть акции, которые я получил в этом году, рост акций, которые у меня были до этого и я их не продавал из-за низкой цены, то за календарный год я заработал $224 000. Это уже после уплаты 47% налога при вестинге акций. Но пока без учета capital gain. Для меня это рекордный год. Такого еще не было. Это все не учитывает также зп и бонусы.
Я думаю, те, кто пришел год назад, получили рекордный рост в первый год работы.

Мистическая жизнь программистов с Дэвидом Аттенборо https://youtu.be/ocwnns57cYQ?si=DQvBQV1KkFtQpr4a

Распределенный кэш в system design. Часть 1
#systemdesign

Начал писать серию коротких статей про распределенный кэш, в которых опишу основные понятия и концепции и рассмотрю пару реальных кэшей. Это все пригодится как на system design собеседовании, так и на любом собеседовании программиста уровня выше junior.

Первая статья: https://telegra.ph/Raspredelennyj-kehsh-02-13

Распределенный кэш в system design. Часть 2.
#systemdesign

Вторая часть про распределенный кэш в system design: https://telegra.ph/Raspredelennyj-kehsh-CHast-2-02-15
Первая часть тут: https://telegra.ph/Raspredelennyj-kehsh-02-13

Мои первые впечатления, когда я начал работать в Европе

Впервые в Европе я побывал 13 лет назад в качестве туриста. И как у многих, у меня во время отпуска возникла мысль, что было бы прикольно тут пожить и поработать. Но сильных причин переезжать у меня не было, более того, были причины остаться. В последующие несколько лет я много раз был в Европе в качестве туриста. Более того, меня несколько раз отправляли в командировки по работе в разные Европейские страны. Была даже ситуация, когда я жил целый месяц и работал в офисе клиента. Через 3 года у меня жестких причин оставаться не стало и вскоре я случайно попал на собеседование в Google, которое я завалил, т.к. не знал как к нему готовится (история про тот случай: https://t.me/faangmaster/6). С тех пор я начал изучать тему про собеседования в FAANG и загорелся желанием поработать в Европе (США я тогда исключил, т.к. хотел быстро, дешево и часто летать в Россию). И уже через год я получил offer в компанию в Германии (не FAANG) и решил попробовать. Далее кратко опишу впечатления в первые недели и месяцы работы в компании в Германии.
1) Общая эйфория и ощущение приключения. Первые несколько недель - несколько месяцев возникает чувство какого-то приключения, все кажется новым и интересным. Новая страна, новая компания, новые люди, новые проекты, новый язык. Чувство, что начал новую жизнь с нуля. Бытовые трудности есть, но вначале они сглаживаются чувством эйфории, а кажутся скорее квестом, чем какими-то трудностями.
2) Много английского. В первую неделю у нас был onboarding, на котором мы скорее развлекались, чем работали. При этом приходилось общаться с людьми со всего мира на английском почти непрерывно 8 часов в день. В обычной жизни программиста мы общаемся очень мало, даже на русском. В основном пялимся в экран. Но эта компания придумала очень интерактивный онбординг с большим количеством общения. Из-за этого у меня каждый вечер болела голова и даже сны снились яркие и на английском языке.
3) Сложности с поиском квартиры. В Германии очень непросто найти квартиру, особенно, хорошую квартиру. На хорошие варианты там целый конкурс со стороны потенциальный съемщиков. Все это сочеталось с остальными проблемами, которые нужно было решать параллельно с работой в новой компании в новой стране. Это добавляло стресса и напряжения.
4) Немецкий язык и бытовые проблемы. На работе мы общались на английском, но за пределами работы большая часть населения говорит только на немецком. А по приезду в страну нужно было регистрироваться в разных гос органах (Bürgerbüro, Finanzamt), открывать счет в банке, подключать интернет, искать квартиру, заключать договор и т.д. Очень часто в этих организация или не говорят, или не все говорят на английском. Более того порядок действий другой, часто устаревший и неудобный. Он может в себя включать взаимодействие через почту или телефон, а не через интернет. Я помню одноразовые коды для банковских переводов напечатанных на бумажке и пополнение счета телефона на кассе в магазине через специальный чек-ваучер. И время ожидания исполнения услуг ждать приходится долго. Но сочетание с эйфорией это несколько сглаживает негативное впечатление, но все в целом добавляет общего напряжения.
5) Стресс из-за испытательного срока. Кроме ментального перегруза от всего нового, нужно еще и работать. Более того, вы только начинаете работать и находитесь под наблюдением - на испытательном сроке, который длится 6 месяцев. Поэтому нужно работать и проявлять себя с лучшей стороны и более ярко по сравнению с тем, когда ты уже проработал несколько лет в компании, чтобы хорошо себя зарекомендовать.
6) Выходцев из постсоветского пространства достаточно много. Я очень быстро познакомился с достаточным числом коллег, с которыми мы общались на русском. И через некоторое время работа в плане языка уже не сильно стала отличаться от работы в России в международной компании. На митингах с коллегами - общаешься на английском, но это только часть твоего рабочего времени. Остальное время пялишься в экран или разговариваешь на русском на кухне со знакомыми.

7) Сама работа мало чем отличалась от работы в России в международной компании. Только коллеги со всего мира, и больше общения на английском. Но программисты далеко не 100% своего времени проводят в общении с коллегами. Поэтому какого-то космического уровня владения не требуется. Более того, для большинства иностранцев английский тоже не родной и какого-то неудобства ошибки или акцент не вызывают.
8) Очень много общения с иностранными коллегами на тему того, как что устроено в разных странах. Каждый рассказывает как то или иное устроено в их странах, своеобразный культурный обмен. Про еду, про то, как будет то или иное слово на их родных языках(особенно мат😀), про бытовые и бюрократические вещи. Выходцы из постсоветского пространства часто рассказывают как в Германии все неудобно в плане сервиса и услуг и как у них в стране можно все сделать одной кнопкой в приложении.
9) В квартире холодно. Если вы привыкли, чтобы в квартире было 25 градусов, то в Германии типичная температура в квартире это 19-21 градус. Более того, тут ты сам регулируешь батареи и чем большую мощность ты на них выставишь, тем больше придется платить за коммуналку. Этот момент доставлял больше всего дискомфорта и приходилось к этому долго привыкать.
10) Летом, в солнечные дни, в квартире жарко. Кондиционеров в квартирах практически не бывает. Из-за этого, если у вас неудачно выходят окна квартиры - она будет сильно прогреваться и в квартире будет жара, особенно, когда вы уже перестроились и привыкли к 21 градусу в квартире. То 28-30 будет невыносимым испытанием.
11) Сортировка мусора, бутылки. В Германии очень сложная сортировка мусора. Нужно держать много разных мусорных пакетов. Более того, нужно сдавать бутылки обратно в магазин в специальный автомат, который выдаст обратно чек, которым можно заплатить в магазине. Даже есть специальные контейнеры для одежды и обуви.
12) Другая еда, но во многих магазинах есть русский отдел. Приходилось привыкать к другим продуктам, нет гречки, привычной молочки и многих других продуктов. Но благо, во многих магазинах есть русский отдел с русскими или польскими продуктами.
13) Доходы/расходы не особо изменились по сравнению с Москвой. На тот момент это было так (8 лет назад). Сейчас может быть по другому. Я что в Москве получал ~3-3.5 тысячи евро на руки в месяц, что после переезда в Германию получал столько же. Сейчас цифры другие скорее всего. И расходы примерно того же порядка. Что-то дороже, что-то дешевле. Но примерно, в сумме примерно столько же расходов. Сейчас, возможно, ситуация другая.
14) Меньше стресса от мегаполиса. Я жил в не очень большом городе, на работу ходил пешком или на велосипеде. После Москвы город казался очень небольшим и спокойным. При этом даже средние и малые города имеют всю необходимую инфраструктуру. В России, если ты не Москве или Питере, то это вообще другая страна с другими стандартами жизни, а уж про города с населением меньше миллиона и говорить нечего. В Германии вся инфраструктура есть и в маленьких городах и даже деревнях. Хорошие дороги, транспорт, больницы, вокзалы, парки, магазины, рестораны, развлечения, торговые центры, икея, школы и даже международный аэропорт. Красивая архитектура, чистые улицы и т.д. Т.е. ты получаешь стандарты жизни как в Москве или лучше, но в городе с населением в 20 раз меньше.

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

Я работал в 5 компаниях в 4 разных странах. Онбордился сам и был ментором при онбординге много раз. Первые несколько месяцев в компании очень важны, т.к. вы на испытательном сроке и это время, когда о вас сложится первое впечатление. Я всегда успешно проходил испытательные сроки и никогда не было с этим проблем. Более того на всех перфоманс ревью я получал оценки выше среднего. Я напишу несколько постов на эту тему. Сейчас кратко дам некоторые советы, что делать и чего не делать при онбординге на личном опыте.

Что делать:
1) Сразу познакомьтесь со всеми коллегами и ключевыми сотрудниками, которые могут влиять на вашу работу. Я сразу стараюсь узнать у менеджера team/org map, т.е. какие сотрудники важны для моей работы и чем они занимаются. И сразу назначаю с каждым из них по отдельности встречи на 30 минут (1:1). На таких 1:1 я стараюсь познакомиться с человеком, узнать чем он занимается сейчас и чем занимался раньше, сам рассказываю про себя, про какие-то интересные компетенции, которые у меня есть. Это помогает преодолеть первый барьер и узнать по каким вопросам можно обращаться к человеку и чем будете полезны вы. На встречах нужно быть дружелюбным и открытым. Но не переходить к личным вещам и сразу лезть к человеку, это может отталкивать. Нужно оставаться профессионалом и просто показать себя как хорошего коллегу.
2) Делайте первые задачи, которые вам дают с полной и даже большей отдачей. В первые недели и месяцы вам будут давать (в идеале) задачи, которые помогут вам быстрее адаптироваться к работе в команде. Лучше, если это какие-то типичные задачи на разные части code base, чтобы вы быстрее освоились с кодом и стилем работы. Старайтесь их делать быстрее и лучше, чем вы обычно это делаете. Особенно, в сочетании с тем что вы новичек и от вас мало что ожидают, а вы делаете это быстро и хорошо, это создаст очень хорошее первое впечатление, которое будет длится очень долго и его испортить будет очень сложно.
3) Чтобы быстрее освоится с кодом и произвести хорошее впечатление - пишите документацию. Когда работаете над онбординг задачами, изучайте код, рисуйте диаграммы, пишите документы, если таких документаций еще нет. Это поможет вам, это поможет другим людям в будущем, кто будет онбордится. Обычно документация всегда неактуальна или отсутствует, т.к. ее рассматривают как второстепенную задачу, если вы при своей работе напишите такую документацию, особенно, если вас об этом никто не просил, это произведет хорошее впечатление и поможет вам быстрее освоится с кодом.
4) Изучайте код за свое время. Т.к. вы не знакомы с кодом, то существенная часть времени при работе над задачей уйдет на изучение кода, который другие коллеги уже знают. Обычно, они это время не учитывают, когда оценивают примерное время, которое они бы ожидали, нужно для выполнения задачи. Поэтому по возможности потратьте доп. время на самостоятельное изучение кода, чтобы компенсировать это отставание и начать деливерить как опытные коллеги как можно раньше.
5) Задавайте много вопросов. В первое время это ожидается и чем больше вопросов вы для себя проясните в начале, тем легче вам будет в дальнейшем. Но задавайте вопросы не ради того, чтобы просто задать вопрос, а чтобы прояснить что-то для себя и дополнить вашу картину и сложить пазл в голове. Это также сделает ваши вопросы со временем интересными и глубокими. Но не бойтесь, что в начале ваши вопросы тривиальные или глупые. Со временем они станут глубже, с улучшением вашего понимания. Это также произведет впечатление, как быстро и глубоко вы разобрались в проблеме или проекте.

6) Узнавайте много всего у ваших коллег напрямую. Обычно у вас 3 источника информации: коллеги, документация и код. Документация, обычно, или отсутствует или неактуальна. Код изучать долго. Поэтому если вы на чем-то застряли и не смогли за пару часов ответить на какой-то свой вопрос читая документацию или код - спросите у коллеги. Это позволит вам быстро разблокировать себя. Но потратьте какое-то время на попытку самостоятельно ответить на этот вопрос. Это позволит глубже погрузится в проблему и спрашивать более конкретные и глубокие вопросы. Тут нужно держать баланс. Если вы будете абсолютно все спрашивать, даже то, на что вам уже отвечали или что вы можете выяснить сами за 5 минут или пару часов, то это скорее начнет производить плохое впечатление.
7) Участвуйте в code review. Это позволит узнать над чем и как работают ваши коллеги, задать уточняющие вопросы, понять стиль кода, тестов и работы ваших коллег. Если вы опытный разработчик, то привнести что-то новое практически с первых дней работы.

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

Распределенный кэш. Часть 3

https://telegra.ph/Raspredelennyj-kehsh-CHast-3-02-21

Предыдущие части тут: часть 1, часть 2.

Что не стоит делать при онбординге в новую компанию?

В предыдущих постах я уже писал, что делать стоит: https://t.me/faangmaster/281, https://t.me/faangmaster/282

Я онбордил много людей, в том числе в FAANG. Также видел много случаев за 17 лет работы, когда сотрудники не проходили испытательный срок.
Вот основные ошибки:
1) Люди застревают подолгу и не просят помощи. Это очень частая ошибка, особенно, среди более опытных программистов. В предыдущей компании, они могли сами быстро что-то раскопать и сделать задачу, проект. Когда они приходят в новую компанию, еще ничего не знают про компанию, проект, code base и т.д. На испытательном сроке им дают не очень сложные задачи, с точки зрения коллег, кто уже долго работают в компании, и подолгу застревают на задаче и не просят помощи. А задачи, которые вы делаете на испытательном сроке создадут о вас первое впечатление и оно в таком случае будет негативным. Поэтому, если вы на чем-то застряли и не смогли сами найти ответ за пару часов - спросите своих коллег, это поможет вам быстро разблокироваться и сделать задачу.
2) Наоборот спрашивают все и даже самые элементарные вещи. Это больше характерно для начинающих программистов. Для них ожидаемо, что они еще не имеют никакого опыта и им нужен больший сапорт со стороны коллег. Но все же предполагается, что вы обучаемый, быстро схватываете и уже имеете представление о программировании и языке программирования, на котором пишите. Если на что-то вам уже отвечали, старайтесь это запомнить, а лучше записать. Чтобы не спрашивать одно и тоже каждый день. Если вы что-то можете загуглить сами за пару часов, найти в коде или документации, то попробуйте сначала это сделать сами. А потом уже спрашивать. Но не застревайте надолго. Потратьте на это 1-2 часа, если не получилось разобраться самим - спросите.
3) Отрицание всего, что и как делается в компании или команде. При переходе в другую компанию, вам, с большой вероятностью, покажется много, что делается в другой компании, непривычным. И первая реакция у вас будет негативной. Вы начнете все и всех критиковать, что может привести к конфликтам или напряженным отношениям. Лучше, если у вас возникает такая реакция - попытаться выяснить причины этого. Обычно, на то есть какие-то практические, исторические или иные причины. Или вы узнаете для себя что-то новое и поймете, что раньше вы делали хуже. Т.е. не сразу начинать с неприятия и критики, а с попытки узнать больше. Если же после этого вы все равно считаете что-то неправильным, то можете переходить к конструктивной критике. Но на практике я рекомендую подождать с этим до конца испытательного срока. На нем просто попытайтесь понять, почему что-то сделано так и не иначе и адаптироваться к новым условиям.
4) Конфликты со всеми, особенно, с менеджером. Переход в новую компанию, это всегда стрессовая ситуация. А т.к. все непривычно, то первая реакция - отрицание. Не стоит на этом эмоциональном фоне создавать конфликты, особенно, с теми, от кого зависит ваше успешное или нет прохождение испытательного срока. Если вам действительно не нравится работа в компании, вы можете просто уволиться.
5) Не соответствие уровню. Ожидания и возможность соответствовать этим ожиданиям может и часто отличается между компаниями. Если вы были Senior в одной компании, не всегда это транслируется в Senior в другой. Возможно, вам будет сложнее или легче этому уровню соответствовать в другой компании. Предотвратить не соответствие уровню должно собеседование. Но собеседования не идеальны и имеют погрешность. Иногда это приводит к тому, что человек просто не имеет еще должных навыков, чтобы соответствовать ожиданиям этого уровня в компании. А чтобы эти навыки получить времени испытательного срока не достаточно, поэтому часто это приводит к увольнениям. Поэтому старайтесь говорить правду на собеседовании про свой опыт или хотя бы не выдумывайте опыт, который сильно выше вашего уровня. Это увеличит шансы на правильное определение вашего текущего уровня и облегчит вам жизнь.

Подборка вопросов и ответов для подготовки к собеседованию на 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

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

Подборка алгоритмических задач с решениями и описание алгоритмов уже опубликованных в этом канале
#interview #собеседование #алгоритмы #подборка

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

Общие статьи:
1) Как выбрать язык программирования для алгоритмического собеседования?
2) Как решать алгоритмические задачи на подготовке, чтобы это было эффективно
3) Как не забыть решения задач и алгоритмы
4) Шпаргалка по основным алгоритмам для алгоритмического собеседования
5) Шпаргалка по Java для алгоритмического собеседования
6) Подборка из easy задач для начала подготовки к алгоритмическому собеседованию.
7) Сбалансированная подборка из 100 задач для подготовки к алгоритмическому собеседованию.

Two Pointers:
1) Проверка на палиндром.
2) Усложненная версия проверки на палиндром.
3) Merge Two Sorted Arrays
4) Самая длинная палиндромная подстрока
5) Удалить дубликаты в отсортированном массиве
6) Видео: Merge Intervals
HashTable:
7) Two Sum
8) Видео: Сгруппировать анаграммы
Stack:
9) Проверить скобочное выражение.
10) Удалить минимальное число скобок, чтобы сделать скобочное выражение правильным
Sorting:
11) Первый пропущенный положительный элемент массива
LinkedList:
12) Удалить n-й элемент с конца в односвязном списке
13) Deep Copy списка со ссылкой на случайный элемент.
BinarySearch:
Описание алгоритма BinarySearch.
14) Пропущенный элемент в отсортированном массиве.
15) Пиковый элемент.
16) Число итераций в бинарном поиске.
17) Первая плохая версия
DFS:
Описание алгоритма DFS.
18) Flood Fill.
19) Видео: Число Островов
BFS:
Описание алгоритма BFS.
20) Проверить полноту дерева.
21) Обход дерева по уровням.
22) Remove Invalid Parentheses
Топологическая сортировка:
Топологическая сортировка
23) Видео: Top k elements
Binary Tree:
Алгоритмы обхода двоичного дерева
24) Invert Binary Tree
25) BranchSums
26) Максимальная высота дерева
27) Максимальная сумма пути в бинарном дереве
28) Сумма элементов бинарного дерева поиска в диапазоне значение
Dynamic Programming:
Основные этапы решения задач на динамическое программирование Top-Down методом
29) Top Down подход на примере задачи про ступеньки
30) Задача на динамическое программирование. Разделение на слова.
31) Количество дождевой воды
32) Bottom-up подход: разменять деньги
33) Видео: Longest Increasing Subsequence

Подборка статей, которые я уже написал и опубликовал в этом канале по 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.

Как устроен onboarding процесс в Amazon?

В продолжении темы про испытательный срок и onboarding в компаниях.
Ранее я писал про рекомендации того, что делать стоит(https://t.me/faangmaster/281, https://t.me/faangmaster/282) во время испытательного срока и чего делать не стоит (https://t.me/faangmaster/284).

Сейчас расскажу, как устроен процесс onboarding в Amazon. Этот процесс в компании отлажен и многие вещи я считаю правильными и их можно переиспользовать в других компаниях. В Facebook процесс, частично, похож, но имеет отличия, о которых я расскажу отдельно.

1) Каждому новичку назначается onboarding buddy. Это ваш коллега из команды, обладающий значительным опытом работы в компании и, в частности, в вашей команде. Обычно он находится на том же уровне, что и вы. Его задача — помогать вам в период онбординга, отвечать на все ваши вопросы или направлять вас к нужному человеку, который сможет вам помочь. Кроме того, в течение испытательного срока он будет регулярно предоставлять менеджеру отзывы о вашем прогрессе. Это один из ключевых людей, от чьего мнения зависит ваше успешное прохождение испытательного срока.
2) Вам выдадут onboarding plan, в котором будут расписаны все тренинги, которые вам нужно пройти, все действия, которые вам нужно совершить с детальным расписанием. Вам нужно следовать этому плану. На первые дни и недели этот план очень подробный. Там указан детальный план того, что вам нужно делать по дням и неделям.
3) Первые пару недель выделяется на прохождения огромного числа тренингов. Тренинги, в основном, на культуру компании (так или иначе связанных с Leadership Principles, т.к. это очень важно для работы в Amazon), на различные внутренние тулы, т.к. вы больше таких тулов нигде не увидете. Вам нужно их изучать с нуля. Тренинги как online за компьютером, так и offline, с реальным лектором. Нам даже пришлось на несколько дней лететь в другой офис для прохождения части тренингов.
3) В первые пару недель вам нужно засетапить регулярный 1:1 с вашим менеджером, onboarding buddy, а также поговорить со всеми ключевыми сотрудниками и коллегами, с которыми вам нужно будет взаимодействовать. Это позволит с ними познакомиться, узнать кто чем занимается и рассказать о себе. Я в первую же неделю поговорил с 10 разными людьми, и даже с VP нашего орга.
4) В рамках тренингов вы засетапите ваш dev environment, чтобы подготовить все к началу процесса разработки. Сделаете тестовый code change, чтобы пощупать на практике все тулы по изменению кода, написанию тестов, созданию code review и деплоя в продакшен.
5) Когда вы пройдете большую часть общих тренингов для всей компании, вы начнете больше узнавать про работу вашей команды. Тут все зависит от вашей команды и onboarding buddy. В нашей команде мы организовали серию митингов, где коллеги рассказывали про разные части продукта, который наша команда разрабатывала, какие есть компоненты, за что они отвечают и как работают. Очень много всего связанного с бизнес логикой работы, очень много новой терминологии и т.д.
6) Параллельно с изучением того, что делает команда, вы начнете деливерить код для команды. Обычно, это начинается с простых задач, где вам надо поменять одну строчку в коде. Чтобы просто освоиться с новыми тулами. Далее чуть более сложные, где вам надо уже немного подумать над кодом и поменять больше, чем пару строчек. И постепенно, вам начнут давать уже типичные задачи на разные части code base, чтобы вы начали ориентироваться в разных частях того, что у вас есть в команде.
7) После 1-2 месяцев в команде вам дадут уже более сложную задачу, которая будет соответствовать вашему уровню. Вам скорее всего нужно будет провести какой-то research, поговорить с множеством людей, написать дизайн док, пройти его ревью и заимплементить его. Это очень важный этап, т.к. от него будет зависеть, пройдете ли вы испытательный срок или нет и какое о вас сложится первое впечатление.

8) Также после 1-2 месяцев вас начнут готовить постепенно к oncall. Вначале вы будете shadow, т.е. просто смотреть, что делает уже опытный сотрудник, будучи oncall и учиться. Далее вы будете oncall и вам будет помогать другой опытный сотрудник (reverse shadow). И через некоторое время вы станете самостоятельным в этом смысле и будете по расписанию осуществлять саппорт компонент, которые овнит ваша команда. Это тоже важный этап. Если у вас с этим возникнут проблемы, то могут возникнуть проблемы с прохождением испытательного срока.
9) После 3 месяцев вы уже пройдете все тренинги, станете oncall, разберетесь в основах того, что делает ваша команда, научитесь писать код, ревьюить код, писать и ревьюить дизайн доки. И скорее всего начнете уже работу над более или менее адекватным проектом, соответствующему вашему уровню.
10) После 6 месяцев (столько длится испытательный срок в европейских офисах) ваш менеджер, на основе фидбеков от вашего onboarding buddy и других коллег, а также успешности прохождения всех этапов onboarding примет решение, прошли вы испытательный срок или нет.

Пишите в комментариях, как это устроено у вас. Что из перечисленного вы считаете полезным, что нет. Что вы бы добавили.