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

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

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