Incident management в Amazon

В любых софтверных сервисах и продуктах случаются outages, полные или частичные. Когда сервис падает и становится недоступным или часть функционала перестает работать.
Как в Amazon реагируют на такие ситуации, как обнаруживают, что делают во время инцидента и после него?
В Amazon все разработчики без исключения участвуют в так называемом oncall. Т.е. по очереди дежурят в поддержке работы сервисов, которые они разрабатывают. Обычно это длится одну неделю раз в в 1.5 - 2 месяца. В течении этого времени они реагируют на тикеты и таски связанные с саппортом продукта и участвуют в их митигации (именно митигации, а не починке root cause). Все сервисы производят огромное число метрик, на которые созданы alarms, которые в случае проблем автоматически создают таски. Например, это может быть AWS Cloudwatch. Тикеты и таски имеют свой severity. Самые важные автоматически приходят на рабочий телефон и очень громко звенят(paging). В том числе это может произойти ночью. В таком случае нужно принять этот paging в течении короткого промежутка времени и надо начать смотреть тикет. Если это не сделать, то такой alarm начнет будить вашего менеджера, потом менеджера его менеджера. Вплоть до CEO если это очень серьезный инцидент и никто не реагирует.
Далее oncall смотрит тикет и принимает шаги по митигации (stop the bleeding, не починки). Например, делает rollback до последней стабильной версии, восстановление из backup, перезагрузку кластера и тому подобное.
При этом активно комментирует все свои действия в тикеты, т.к. часто это может повлиять на другие компоненты и сервисы, которые активно пишут, что они тоже заафекчены. Иногда перебои в Amazon приводят к outage в других продуктах. Например, однажды outage в AWS S3 привел к недоступности видео в Netflix. Иногда происходит мониторинг медиа типа twitter, на предмет жалоб на outage. Как только инцидент был замитигирован(stop bleeding) начинается формирование документа COE ревью, который призван помочь в предотвращении таких инцидентов в будущем. Одна из особенностей как митигации так и COE ревью - no blame culture. Т.е. не заниматься поиском виноватых людей, а поиском дыр в системе, процессах, которые позволили этому случиться. Про COE ревью детально напишу в следующих постах.

COE Review в Amazon

В продолжении к посту: https://t.me/faangmaster/217

После серьезного инцидента, как правило, пишется документ под названием COE Review. Серьезность инцидента зависит от того, какой был impact, какой сервис был заафекчен, какая функциональность перестала работать и т.д. Обычно это делается для инцидентов уровня LSE (Large Scale Event), Sev0, Sev1, Sev2, Sev3. Sev0 - это, обычно, значит, что перестала работать функциональность, которая непосредственно влияет на конечного пользователя (Tier0 сервис). Sev3 - непосредственно влияния на конечного пользователя нет, но могут быть отсроченные небольшие эффекты на пользователя или небольшие потери для бизнеса.
На написание и ревью документа отводится ограниченное количество дней. У документа есть owner, который работает над документом, но ему могут помогать и другие люди.
Основная цель документа - понять, что и почему произошло и что можно сделать, чтобы это не произошло в будущем (prevention).
Из чего состоит документ:

1) Into. Краткое summary. Описывается на абзац, что произошло, какой impact в цифрах (например, сервис был offline 2 часа, что привело к потере ~40 миллионов долларов прибыли), как обнаружили, как замитигировалли, какой root cause.

2) Impact. Более детально описывается влияние данного инцидента. Приводится расчет убытков, приводятся метрики, графики с детальным анализом, запросы и т.д.

3) Timeline. Описывается последовательность событий с временем, что происходило, какие были предприняты меры. Когда случился сбой, когда он был обнаружен, когда стало понятно как митигировать, какие шаги по митигации были предприняты и т.д.

4) Detection. Описывается как было обнаружено, что что-то не так. Какие метрики, alarms позволили это обнаружить. С какой задержкой это было обнаружено.

5) Mitigation. Какие шаги были предприняты, чтобы замитигировать проблему (stop the bleeding). Сколько это заняло времени и почему.

6) Five whys. Позволяют ответить на вопрос, что послужило реальной причиной (root cause).

7) Monitoring/Detection Improvement. Что можно сделать, чтобы быстрее в следующий раз обнаружить подобную проблему (улучшить метрики, алармы, добавить независимые методы детектирования и т.д.)

8) Mitigation Improvement. Что можно улучшить, чтобы быстрее митигировать проблему (улучшить или добавить автоматические системы, которые задетектируют проблему и автоматически сделают rollback, улучшить качество runbooks, добавить метрик, dashboard’ов и т.д.)

9) Root Cause Fix. Что нужно сделать, чтобы починить root cause.

10) Prevention. Какие шаги нужно предпринять, чтобы это не случилось в будущем.

Все это описывается, проходит цепочка ревью (внутри команды, внутри организации, в целом в компании), происходит публикация. Другие люди, могут найти этот документ в общей системе по ключевым словам и прочитать то, что произошло и как это можно починить, чтобы использовать в своих целях. Далее все эти action items реализуются разработчиками. В Amazon этому уделяется серьезное внимание, но и процесс очень сложный и бюрократический. В Facebook он намного более легковесный.

Задача с собеседования: Число островов
#dfs #алгоритмы #собеседование

Записал еще один видос с разбором задачи на dfs: https://youtu.be/dXeoNguCK2k?si=2Wj0m5PgNwbAl7Ce
Видео длинное, потому что я написал несколько вариантов решения (рекурсивное, со стеком, с и без visited)

Хорошее видео для тех, кто хочет написать свой LLM(то что использует ChatGPT) с нуля: https://youtu.be/kCc8FmEb1nY?si=65pUV5i45MTX_U8T
Автор канала один из основателей OpenAI и долгое время работал в Tesla AI.

Сделал еще один ролик для youtube про ресурсы для подготовки в виде топа: https://youtu.be/DnQdKvlosKk?si=5j3UN6RSz-wngo2z

Для тех, кто интерисуется шахматами.
Недавно, 14 чемпион мира по шахматам Владимир Крамник опубликовал статистику игр Хикару Накамуры на платформе chess.com. Из нее следует, что Хикару набрал 45.5 очков из 46 в 46 играх. Все это с намеком на то, что Хикару читер. Я написал небольшую програмку, которая проводит симуляцию и рассчитывает вероятность того, что в большой выборке игр можно найти последовательности из 46 и более побед при заданной вероятности выиграша. С параметрами: выборка 10 тысяч игр, вероятность выиграша (88%, Хикару играл с противниками на ~350 пунктов ниже) и ищем серии из 46 и более выиграшей подряд. У меня получилось вероятность этого около 96%. Но она быстро падает с уменьшением вероятности выиграша в каждой игре. Что думаете вы? Код выложил тутhttps://github.com/faangmaster/kramnik/blob/main/Main.java

Развитие истории можно посмотреть по последним роликам в каналах Хикару https://youtube.com/@GMHikaru?si=ddMRyd-avgVNR0h5 и LevitovChess https://youtube.com/@LevitovChess?si=eB5u3O1kAzDZSP22

Основные ошибки на собеседовании в FAANG

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

1) Отсутствие должной подготовки. Некоторые кандидаты вообще не готовятся к подобным собеседованиям. Это заметно на phone screen, а также на system design если они прошли phone screen. Это несмотря на то, что мы описываем весь процесс до самого собеседования и даже присылаем материалы для подготовки. Мы хотим, чтобы кандидат показал свой лучший перфоманс на собеседовании, свой максимум. Пройти такое собеседование без подготовки практически не возможно. Только если вы уже готовились к нему когда-то ранее, или у вас бэкграунд топового олимпиадника + большой практический опыт в создании high load систем. Или вы гений с IQ 150-160. Поэтому если вы действительно хотите собеседование пройти - нужно уделить время подготовке.

2) Кандидаты не задают уточняющие вопросы, не уточняют требования. Все задачи обычно формулируются так, чтобы они не были однозначными, особенно system design. Ожидается что вы будете задавать уточняющие вопросы, уточнять требования или выдвигать свои предположения и спрашивать, могу ли я это предположить для решения задачи. Некоторые кандидаты ничего не уточнят и сразу начинают решать. Очень часто это приводит к тому, что они решают другую задачу, не которую хотел интервьюер. Это приводит к потере времени и негативному фидбеку по communication оси.

3) Кандидаты не могут без компьютера продебажить свой код и найти в нем ошибки. После того как код написан, мы просим протестировать код путем подбора примеров (test cases) и в ручном режиме пройтись по коду и проверить правильно ли он сработает или нет. Некоторые кандидаты не способны проверить работоспособность своего кода без запуска его на компьютере. Даже если им указываешь на конкретный пример, на котором это работать не будет, они все равно не могут понять почему. Из-за этого они получают слабый рейтинг по оси verification

4) Не реагируют на подсказки и наводящие вопросы. Иногда кандидаты вообще не реагируют на интервьюера и продолжают погружаться в свои рассуждения и мысли. Интервьюер делает подсказки не для того чтобы вас отвлечь и мешать вам думать и решать задачу. Он это делает, когда видит, что вы застряли или вы думаете куда-то не туда. Кандидаты, которые могут быстро среагировать на наводящий вопрос или подсказку могут быстро разблокировать себя и решить задачу.

5) Нерационально расходуют время. На кодинг собеседовании иногда кандидаты начинают тратить время на совершенно второстепенные проверки в коде, писать зачем-то комментарии к коду, рассуждать подолгу над именами переменных. Расходуют на это почти все время и не могут приступить к решению собственно самой задачи. Обычно, никакие проверки на input делать не надо. Это можно просто коротко спросить интервьюера, могу ли предпологать, что input валиден? ответ будет да в 99% случаев и просто можно его не проверять. Комментарии писать тоже не нужно, просто озвучивайте свои мысли по ходу написания. Интервьюер поймет что и зачем вы написали. Впечатлять интервьюера ненужными комментариями в коде не надо.

6) На system design кандидат не драйвит обсуждение. На system design кандидат должен быть тем, кто драйвит дискуссию. Это не собеседование, где интервьюер у вас должен спрашивать вопрос-ответ. Тут вы должны проявить себя в качестве лидера и вести дискуссию. Как на реальной работе, когда вы дизайните систему или API, вы должны описать и продать свой дизайн, а не у вас его выуживать в час по чайной ложке. Если вы будете работать в режиме вопрос ответ, то в лучшем случае скажут что вы не соответствуете уровню, на который вы собеседуетесь.

7) На поведенческом собеседовании не могут привести примеры из опыта, соответствующие вашему уровню. Если вы аплаитесь на senior или staff, но во всех ответах на вопросы вы приводите примеры, которые этому уровню не соответствуют это может послужить причиной или реджекта или в офере на более низкий уровень. Примеры проектов, которые вы лидели, примеры конфликтов, которые вы разрешили должны соотвествовать. Если это проекты или конфликты уровня staff, то они должны затрагивать множество команд, а не 2-3 человека в рамках одной команды.

Заменяют ли программистов в топ компаниях на нейросети?

С момента релиза ChatGPT 30 ноября 2022 года (ровно год назад) шум на тему того, что программистов (и не только) заменят на нейросети в ближайшее время достигли невероятного уровня.

Более того, эта тема стала очень чувствительной, особенно, в среде программистов. Люди стали делиться на два лагеря: тех кто считает, что ChatGPT заменит всех и очень быстро и скептиков. Обсуждение этой темы достигает накала сравнимого с обсуждением политики или религии.

Я бы хотел напомнить про такую штуку как "цикл хайпа". Вначале популярность новой технологии растет экспоненциально и достигает "пика чрезмерных ожиданий". За ним следует резкое падение, которое называется "избавление от иллюзий". Далее плавный и медленный рост - "преодоление недостатков". И наконец "плато продуктивности", когда ей все пользуются для реальных повседневных дел и воспринимают ее как данность (как смартфон сегодня, чего не было еще 20 лет назад).

Вот так выглядят сейчас google тренды для ChatGPT: Google Trends ChatGPT. Очевидно, что мы сейчас или только на начальном этапе экспоненциального роста популярности или достигли пика чрезмерных ожиданий. Этот хайп проявляется и в том, что капитализация Open AI 80 миллиардов при обороте в 1.3 миллиарда. Т.е. коэффициент ~60. Для обычных IT гигантов типа Google, Facebook, коэффициент ~10. Т.е. ожидания от компании космические. Оправдает ли она их - не известно.

Будет ли дальнейший рост хайпа, имхо, зависит от ChatGPT 5. Слухи ходят разные, в частности, про Q* алгоритм и достижение AGI. Если это оправдается, то хайп продолжит расти. Возможно, до релиза 6 и начнет резко падать, если он будет мало отличаться от 5 (но это не точно). Или начнет падать уже после релиза версии 5, если она будет отличаться от 4 как айфон 15 от айфона 14.

Реальных приложений ChatGPT и LLM, которые могли бы заменить программистов не существует на данный момент. Все что есть - это более умный код комплишен (вроде copilot или внутренние и обученные на коде компании на основе LLM). ChatGPT для этого вообще не применим, т.к. он не обучен на базе кода вашей компании. Вам нужно обучать на вашей базе самостоятельно, что достаточно дорого или использовать copilot. Это все имеет некоторую пользу и буст продуктивности, но меньше, чем появление хороших IDE (сред разработки) типа Intellij IDEA. Заменила ли IDEA программистов? Нет, их стало больше, они просто стали более продуктивными и несколько понизился уровень входа в программирование. Можно еще напрямую просить ChatGPT написать вам какой-то код. Это подходит для hello world проектов, где весь проект это десяток классов. Или сгенерить какой-то стандартный код, который можно загуглить. По сути, это google + stackoverflow + github только в профиль.
Но это не значит, что это не может заменить программистов в будущем.
Текущий уровень - более умный кодкомплишен и улучшение функции "поиска". В таком виде это способно повлиять на стиль работы программиста, немного понизить уровень вхождения, но никак не заменить.
Даже если ChatGPT 5 достиг AGI, то это будет означать, что его способности превысили уровень среднего человека по основным интеллектуальным задачам. Но это не позволит никого заменить. На работе, требующего умственно труда, нужно быть не средним, а в топ 0.1%. Средние способности очень низкие. Обычно у человека средние способности по большинству тем, но сильно выше среднего в области, где он работает. Средний человек не знает полностью таблицу умножения. Для профессионального математика этого не достаточно.
Я думаю, что они научили ChatGPT 5 математики выше среднего уровня с чем были проблемы у ChatGPT 4. Это позволит утверждать, что он достиг AGI. Но это не сингулярность, когда начнется экспоненциальный самостоятельный рост, skynet и восстание машин из пепла ядерного огня. Случится ли это? я не знаю, возможно, но не сейчас. Будем подождать.
Но это не значит, что этим нет смысла заниматься. На основе LLM можно придумать множество приложений, которые будут полезны во многих областях.

На данном уровне технологий LLM не способно заменить программистов, но из-за того, что это произошло очень быстро, возник страх, что новые открытия в этой области будут происходить также быстро, что и может привести к замене всех и вся. Произойдет ли это и как скоро сложно сказать, может никогда, а может через 1 год. Открытия не прогнозируемые.

Но надо сказать, что ChatGPT основан на Transformer (буква T в названии), который был предложен в 2017 сотрудниками Google. А он в свою очередь базируется на эмбедингах, которые были предложены еще раньше (идея вообще древняя, но word2vec появилась в 2013). Поэтому инновации не такие быстрые как можно было бы предположить. Open AI смогли обучить это все на больших данных масштаба интернета за эти 5 лет с 2017 года. Т.е. скачек произошел после масштабирования. Как и с нейросетями и deep learning в начале десятых, которые базировались на алгоритмах придуманных десятилетия назад, но с появлением интернета и больших баз их стало возможно обучить на быстром современном железе. Будет ли качественный скачек в ближайшие 1-2 года? Может да, а может и нет.

В текущем виде, вам нужно все равно заниматься промт инжинирингом, ревью, допиливанием, переписыванием сгенерированного кода, его деплойментом и мониторингом. Т.е. в лучшем случае он даже не покрывает coding часть работы программиста. Что далеко не самая большая часть работы программистов, особенно высокого уровня. Поэтому говорить, что текущая версия ChatGPT заменит программиста, для меня звучит как stackoverflow или мышка заменит программиста. Но еще не вечер и булки расслаблять рано.

Задача с собеседования: top k элементов в массиве

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

https://www.youtube.com/watch?v=lJqjJjHiodk

Сколько я заработал и потратил за 1 месяц?

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

Сколько я потратил?

1) Квартира. £2447/$3092/285,191 рублей
2) Коммуналка. £473/$597/55,125 рублей
3) Транспорт/парковка. £424/$535/49,487 рублей
4) Подписки, лицензии, покупка контента. £440/$555/51,355 рублей
5) Еда, повседневные покупки. £389/$491/45,326 рублей
6) Доставка, рестораны. £818/$1033/95,314 рублей
7) Подарки родственникам, финансовая помощь. £857/$1082/100,000 рублей

Это основные рассходы.

Итого: £5848/$7385/681,789 рублей.

Сколько я заработал?

1) Зп: £6389/$8072/744,352 рублей
2) Получил акций стоимостью $38,000(до вычета налогов почти $74,000). Но это за 3 месяца. Поэтому если разделить на 3, то $12,666. Т.е. £10,026/$12,666/1,168,723 рублей.

Итого: £16,415/$20,738/1,913,075 рублей. Курс брал текущий.

Доход уже после вычета налогов. Остаток в кеше около 10 тысяч фунтов после всех рассходов на жизнь(чистые сбережения).
До вычета налогов доход почти в 2 раза выше. Около 32 тысяч фунтов в месяц.

Для тех кто думает, что недвига в Лондоне стоит каких-то космических денег

Если сравнивать квартиры примерно одного уровня скажем в Лондоне и Москве, разница максимум в два раза. Например, зашел на cian, чтобы поискать что-то похожее на то что у меня. Все что нашел ~140 кр аренда. Ипотека соответственно еще больше. Вот пример аналогичной недвиги в Москве: https://www.cian.ru/rent/flat/295714613/ У меня 3 комнаты, 2 балкона с видом на реку. При этом внешне дома и дворы выглядят намного лучше + консьерж+бесплатный фитнес, бесплатный бассейн, джакузи и сауна. В квартире на циане ничего из этого нет, поэтому что-то аналогичное или не найти или еще дороже будет.
Просто зачастую начинают сравнивать однокомнатную хрущевку в человейнике на окраине Москвы, с трешкой в хорошем районе со всей инфраструктурой. Типа, да я в Москве или своей деревне сниму миллион метровый особняк за такие деньги. Нет, не снимете.

Почему решив 1500 задач на leetcode вы не сможете получить офер в FAANG

Свой первый офер в FAANG(в Amazon) я получил не решая задач на leetcode вообще. Готовился я туда в 2015, 2016 годах и про leetcode не знал вообще. Тогда он не был чем-то большим и известным. Я готовился по книгам. В частности по Cracking the Coding Interview.
На leetcode свою первую задачу я решил 6 лет назад. И активно использовал его года 2-3. Это помогло мне получить офер в Facebook. Но тогда я еще решал задачи на algoexpert.io. Надо сказать, что собеседование в Facebook сложнее, чем в Amazon в среднем. Но и компенсация выше.

Стоит ли решать 1500 задач на leetcode и поможет ли вам это получить офер в FAANG?

Я думаю, что это неэффективная трата времени. Это не гарантирует, что вы пройдете собеседование.
Во-первых, coding собеседования это только половина собеседований, которые нужно пройти, если вы не интерн. Есть еще system design и поведенческое собеседование. На уровень staff нужно пройти два system design. Leetcode вам в этом не поможет, от слова совсем. А решив 1500 задач на leetcode вы потратите коллосальное количество времени на один аспект собеседования и не уделите должное внимание остальным аспектам.
Во-вторых, это не гарантирует, что вы пройдете coding собеседование. На coding собеседовании оценивается problem solving, coding, communication и verification/testing. Leetcode не поможет вам в communication вообще. И скорее всего не поможет в verification/testing. Т.к. там автоматическая система проверки и вам не надо вручную проверять ваш код и глубоко в него погружаться. Более того, в зависимости от того как вы решали эти 1500 задач, далеко не факт, что вы делали это оптимальным способом, за нужное время и не просто копипастили решения и сабмитили просто поверхностно разобравшись с чьим-то решением. Поэтому само число почти ничего не гарантирует. При идеальной подготовке вам может хватить 100-200 правильно подобранных задач + правильный подход к обучению, чтобы получить офер в FAANG. Возможно, не в Google или Facebook, где собесы сложнее, но в Apple, Amazon, Uber, Microsoft, Lyft.

Как решать алгоритмические задачи на подготовке, чтобы это было эффективно

1) Составьте список задач, которые вы хотите решить (план). Этот план должен быть индивидуальным в зависимости от ваших целей и текущего уровня. Если вы только приступаете, то этот список должен включать задачи на все основные темы: two pointers, arrays, strings, hashmaps, queues, stacks, binary search, sorting, topological sorting, priority queue, binary trees and tree traversal, binary search tree, trie (prefix/suffix tree), graphs (dfs, bfs), dynamic programming. А также включать на группу тем задачи разного уровня сложности. Начиная от easy и много задач medium, можно добавить пару hard. Если вы не начинающий, то это могут быть задачи только medium на конкретную тему или темы, которую вы хотите прокачать. Если вы хотите прособеседоваться на горизонте 3-6 месяцев в конкретную компанию - просто отфильтруйте на leetcode по компании и частоте и решите первые 100 задач по частоте для этой компании. Книга Cracking The Coding Interview и сайт algoexpert.io по сути уже являются такой подборкой + с очень хорошими разборами решений. И подойдут для начинающих. Я могу тоже набросать такой план с задачами с leetcode в следующем посте.
2) Попробуйте решить задачу сначала самостоятельно. Не открывайте сразу решение. Т.к. сразу прочитав решение, вы не научитесь решать задачи самостоятельно. Более того, у вас оно быстро испарится из памяти + вы не вникните в детали и сложности решения. Потратьте 30 минут - 1 час на самостоятельное обдумывание задачи, даже если у вас не будет продвижения, вы осознаете в чем сложность задачи и у вас возникнет эмоциональный отклик на эти моменты. И когда вы будете смотреть решение, у вас будут моменты типа: "ага, вот как можно преодолеть то, на чем вы застряли и не могли придумать как это решить". В таком случае вы лучше запомните решение, и это знание будет индивидуальным, т.к. вы особенно хорошо запомните моменты, с которыми именно у вас возникли проблемы. Вы запомните, то чего не хватило вам при ваших размышлениях. Это и есть рост. Эти 30 минут-1 час, когда вы думаете и не можете решить являются ключевыми и самыми ценными в вашем росте. Именно после того, как вы сами подумаете, вы поймете в чем конкретно сложность задачи именно для вас, у вас возникнет эмоциональная привязка к задаче и разобравшись в решении, вы закроете ваши индивидуальные пробелы. Делая так, вы можете сократить число задач, которые вам надо решить на подготовке для выработки скила в несколько раз.
3) Если у вас собеседования по алгоритмическим задачам на горизонте 3-6 месяцев, то при решении задач моделируйте условия собеседования при решении задачи. После прочтения условия, попробуйте его переформулировать своими словами (если собеседование будет на английском, то переформулируйте условие задачи своими словами на английском). Подумайте какие уточняющие вопросы вы бы задали на реальном собеседовании (на leetcode задачи формулируются однозначно, поэтому представьте, что части условий нет и вам надо их уточнить). После решения задачи, попробуйте не сабмитить сразу свое решение, пройдитесь по коду на примерах и продебажте ваш код. Какие будут значения переменных на каждой итерации цикла или рекурсивном вызове, какой будет результат работы вашего кода. Если он работает не правильно, поправьте ошибки сами до сабмита кода.
4) Делайте упор на решении medium задач. На реальном собеседовании большинство задач будет medium уровня leetcode. Если вы только начинаете готовиться, то начинайте конечно с easy, но как только на какую-то тему вы easy решаете легко, переходите на medium, решать 300 easy задач смысла никакого нет, роста у вас не будет.

Как не забыть решения задач и алгоритмы
В дополнение к прошлому посту.
Кроме комбинации самостоятельного решения и обдумывания + последующий разбор оптимального решения я рекомендую следующие методики для закрепления и запоминания. Это работает для меня, для себя вы можете придумать что-то другое:
1) писать решения и просто стандартные алгоритмы ручкой на бумаге. Это позволяет выработать мышечную память + избавиться от всевозможных подсказок в виде подсветки синтаксиса, подчеркиваний, тултипов и т.д. это будут ваши чистые остаточные знания, а не чьи-то знания из интернета
2) Расскажите самому себе, коллеге, другу, жене, мужу решение задачи, которую вы решили сами или не могли решить и смогли разобраться с решением.
3) периодически повторяйте алгоритмы и задачи. Память устроена так, что забывание максимально вначале. Потом оно замедляется. Вначале повторяйте чаще, после реже и реже. Я многие задачи перерешивал 3-5 раз. А алгоритмы выписывал на бумажке более 10-20 раз. Сейчас я этого не делаю, но могу написать без подготовки любую основную сортировку или dfs/bfs за 3 минуты если меня разбудить ночью.

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

Мем прям про меня😀

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

Статьи, которые были на medium, мигрировал на dev.to. Напишите, если есть какие-то проблемы с форматированием или ссылками после миграции.

Общие вопросы:
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

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