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

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

На свою первую работу программистом я попал очень давно(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