„Chillin‘“ at Amazon

Начинаю путаться в тэгах. Пиню для себя и других

Про жизнь в Амазон: #LifeAtAmazon

Architecture:
#systems #design #architecture #systems_design #db #distributed

Language specific:
#python #go

Other:
#ML, #myTechNotes, #DeepDive

About interviews:
Время от времени, преимущественно во время отпуска, провожу Mock интервью.
Все, связанное с интервью, выкладываю по тэгам: #interview #mock #systems_design

Если у тебя будет скоро интервью и тебе нужен Mock Interview, то можешь написать, мне. И если у меня будет получаться по времени, то сможем организовать. Имей в виду, что mock интервью я записываю на видео и выкладываю для других. Также рекомендую посмотреть предыдущие записи, чтобы не допускать примитивные ошибки: https://www.youtube.com/playlist?list=PL3tja-7IZ-wXHY-lvb32-zGnRJaS5yCkU

#mock #interview #feedback

Праздники праздниками, а social contributions - эт святое. Как обещал, даю отзыв по mock interview.

Disclaimer: все ниже сказанное не отражает мнение моего работодателя, а является моим личным мнением

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

Что можно улучшить:
- Делай только то, что нужно: Когда ты хотел оптимизировать свое решение в самом конце, то возможно ты пытался сделать то, чего от тебя не требовали. Если бы ты знал, что объемы маленькие (скажем 1000 человек), то эту оптимизацию можно было бы проигнорировать. А в ином случае, на огромных данных, ты бы сразу понимал, предлагая решение, что его нужно улучшать. Совет: Поэтому, на этапе уточнения лучше всего проговорить заранее о потенциальных объемах данных. Понимая задачу, тебе будет легче подобрать правильное решение, не усложняя задачу.
- Всегда оценивай сложность алгоритмов Важно, на этапе прояснения деталей проговорить о сложности алгоритма, не дожидаясь вопроса от интервьюера. Это не просто покажет твою зрелость, но и даст тебе понимание, что твое решение вписывается в картину ожидаемого объема данных.
- Думай об edge-cases Во время продумывания тест кейсов, в дополнение к простым общим тест кейсам, подумай а об edge cases. Например, то, о чем ты подумал к концу собеседования, где у тебя один сотрудник рапортует другому: в одном path.
- Сразу пиши правильно (но без фанатизма) Например, выбор имен (dsf, children), в задаче об организационной структуре, мог бы быть проделан получше. (nitpick/для fresh-grad position это менее важно)

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

Next steps:
- Подумай и потренеруй как ты подходишь к прояснению деталей: сделай для себя некий чек-лист того о чем ты хочешь спросить и что проверить.
- Учись называть переменные правильно (не для интервью, а для себя!)

Если думаешь, что это будет интересно кому-нибудь из твоих друзей, то можешь share.

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

#distributed #systems
A Distributed Systems Reading List

Сохраняю на потом

https://dancres.github.io/Pages/

#myTechNotes #concurrency #DeepDive

Note 2.

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

Вроде бы все хорошо, тепло и спокойно. Но мне, как ни странно, начали лезть в голову мысли о том, что я не до конца понимаю что такие Concurrency. Крейзи, правда? В общем, вчерашний вечер потратил на то, чтобы лучше разобраться в этом всем.

Я не до конца понимал как работают thread-ы (Потоки/треды). Раньше было понимание, что треды исполняются как то параллельно, что и дает нам ускорение вычислений. Но что меня смутило, так это то, что Треды у нас находятся внутри одного процесса, и выполняются на одном процессоре. А раз так, то откуда мы получаем ускорение, если процессор не может выполнять более одной инструкции в один момент времени.

Как оказалось, у устройства процессов, тредов, и корутин очень много общего. ОС постоянно бегает по всем процессам и постепенно продвигает их вперед. Все происходит настолько быстро, что человеческому глазу ничего не видно. Через какое то время умные люди придумали использовать треды, чтобы не переключаться между тяжелыми процессами. Переключение между тредами происходит намного быстрее, так как часть контекста они разделюят друг с другом, памяти выделяется меньше, и подмены переменных происходит меньше. Корутины - эта та же самая идея, когда Runtime проверяет в цикле доступность отдельных процедур, продвигая их вперед. Это еще более мелкая абстракция, которая работает внутри одного треда.

Откуда же приходит ускорение и в каких случаях?

Я в очередной раз убедился в том, что Concurrency works best with I/O bound tasks. Если при определенной процедуре CPU ничего не делает (is Idle), а просто простаивает (например, спит, ждет ответа от запроса к сайту, или ждет когда подгрузятся данные), то ничего полезного не происходит. Таким образом, мы можем "попросить" программу пойти дальше, чтобы исполнить что-нибудь другое в программе (другую корутину/тред).

С другой стороны, в случае же с CPU Bound tasks, наш процессор работает на всю мощность и переключаться между контекстами Корутин огромного преимущества не дает.

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

Я уверен, что я еще буду возвращаться к этой теме в будущем, с performance tests и более сложными use-cases. Также хочу посравнивать concurrency модели в Golang, Python, и Kotlin. Но, на пока, более чем достаточно.

Если тебе тоже интересно почитать на эту тему и не хочешь тратить много времени на поиск полезных ресурсов, то рекомендую след:

Очень крутой, простой, и короткий курс на Coursera:
- https://www.coursera.org/learn/golang-concurrency

И статьи
- https://www.reddit.com/r/golang/comments/ddc1j3/what_is_the_point_of_concurrency/?sort=top
- https://eli.thegreenplace.net/2018/measuring-context-switching-and-memory-overheads-for-linux-threads/
- https://medium.com/@ankur_anand/illustrated-tales-of-go-runtime-scheduler-74809ef6d19b

__Если у тебя есть чем поделиться, дополнить, поправить, пиши, смело!__

#DeepDive #aws #networking #myTechNotes

Note 1.

Из простого в AWS Networking, чтобы научить instances общаться между собой внутри одной Подсети используется Layer 2 Data Link (OSI Model), а для общения с внешним миром или между Подсетями, Layer 3 Networking.

В зависимости от кейса, мы подключаем и настраиваем нужный для нас эллемент: Subnet (switches) для общения внутри подсети, router/igw - между подсетями и со внешним миром (Global internet).

we start in 5 mins

О, Prometheus подогнали

https://aws.amazon.com/blogs/aws/join-the-preview-amazon-managed-service-for-prometheus-amp/

#mock #interview #zoom

Если думаешь, что это будет интересно кому-нибудь из твоих друзей, то можешь share.

Меня просили постримить mock интервью. Пока времени, чтобы разобраться как стримить не было, поэтому вышлю ссылку на зум встречу. Если интересно, подключайся.

Встреча будет идти 40 минут, из которых 30-35 минут на интервью и минут 5-10 на вопросы. Кстати, это ограничено функционалом зума.

> If you have a Basic/Free, Pro, or other paid account (that’s the vast majority of you out there), you can have up to 100 video participants (including the host) in any of your meetings. These participants have two-way video, audio, and collaboration features. Note that if you have a free account, you have unlimited 1-1 meetings and minutes, but your meetings with more than two participants will automatically end after 40 minutes.

Topic: a mock interview on algorithms #2
Time: Dec 23, 2020 10:00 AM Amsterdam, Berlin, Rome, Stockholm, Vienna (это завтра 15:00 по времени Алматы/Астаны)

Join Zoom Meeting
https://us05web.zoom.us/j/84415934093?pwd=eHIrMzZqOHpvSUFJdEZ2SGpvbEpSUT09

Meeting ID: 844 1593 4093
Passcode: fQiSj9

Друзья, те кто подали заявку на мок с указанием телефонных номеров, нужно чтобы вы указали логин или ссылку. По добавлению номера, у меня ничего не появляется. Мб синхронизация. Завтра ещё раз попробую конечно, но если не получится, то соррян )

#mock #interview #feedback

Как обещал, даю отзыв по mock interview.

Что было хорошо:
- Прежде чем преступить к задачке, ты начал с уточняющих вопросов, спросил про input/output, написал пару тест кейсов, подумал об edge кейсах. Как ни странно, но эта стадия про которую много кто забывает. В твоем случае, тот факт, что ты не кинулся сразу в решение, уже было плюсом, который я у себя отметил.
- На протяжении всего интервью ты объяснял что ты делаешь. Мне как интервьюеру было очень комфортно

Над чем нужно поработать:
- Следи за временем. Ты потратил минут 20 на сбор информации и тебе не хватило времени на написание самой задачки. Например, у тебя ушло около минуты чтобы нарисовать дерево - можно подумать о какой нибудь другой структуре.
- Следуй инструкциям собеседника. Мы договорились в самом начале, что на вход поадется Tree Node (вершина дерева), а во время имплементации ты почему то использовал employee-id
- Не используй повторяющиеся данные, если в том нет необходимости. В твоем случае это было: dict key == dict.child.id . Когда я переспоросил намерено ли это было, ты сказал, что да, и мы двинулись дальше.
- Ограничения/Restrictions: Когда собираешь данные, то можно уточнить про ограничения
- Сложность решения/Complexity: Когда предлагаешь решение, то отлично было бы оценить его на асимптотическую сложность

Резюме:
"В общем и целом", у тебя хорошее начало. Имхо самый важный этап - сбор информации. И то, что у тебя он есть, это очень хорошо. Если попрактиковать еще побольше и "заучить" порядок вопросов/действий на этом этапе, то успешное прохождениее интервью почти гарантировано. Это не просто помогает тебе лучше понять задачку, но и показать собеседнику свою зрелость.

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

next steps
- Когда решаешь задачки на лит-код, хакер-ранк, и тд, то старайся у себя в голове проигрывать весь наш сценарий и свои действия. База у тебя уже есть, теперь нужно tune it.
- У меня не было возможности понять как хорошо ты знаком с различными структурами данных и твое умение оценивать слжоность алгоритмов. Если понимаешь, что там есть пробелы, то тоже почитай.

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

Как всегда, первый блин комом :))

Провел первый (и единственный mock interview, так как никто больше не записался), но был не полностью подготовлен. Как оказалось, Zoom пишет только если подключаться через десктопный клиент. Я подключился через браузер и поэтому видео не полностью удалось.

Параллельно решил записать пользуясь QuickTime player, но там пишется только мой звук, собеседника не слышно

Я постараюсь как то это обыграть и нарезать, чтобы было полезно, так как обещал поделиться с другими, но если не получится, то соррян.

Эх, надеюсь, что хотя бы собеседнику было полезно


З.ы. пока располагаю временем на ещё один другой mock. Если кому нужна помощь/интересно то, записывайтесь по той ссылке, что я писал выше

"Computers perform repetitive tasks; people solve problems" (c)

Пару мыслей от себя:
- Даже среди программистов есть те, кто про это забывают
- Особенно среди программистов автоматизировать не всегда правильно

#team

Привет-привет! 👋 В общем, последнюю неделю очень много чего посмотрел и почитал на тему team dynamics. Из того, чем стоит поделиться это наверное выступление бывшего директора из Google, который расскзывает о том, что отличает высоко-продуктивную команду от не очень

Очень-очень рекомендую посмотреть! Но если со временем тоска, то вкратце: не отвелкайся на ненужные/неприоритетные задачи, не отвелкай других, не спамь сообщениями, если не нужно, и инвестируй в других членов команды, чтобы они тоже становились более эффективными.

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

Это одно из тех видео, что я буду пересматривать еще не один раз и тебе рекомендую! ✌

https://www.youtube.com/watch?v=fBr8BKPW5tc&feature=youtu.be

Рекомендую к прочтению тем, кто пробовал NoSQL: https://medium.com/@nabtechblog/advanced-design-patterns-for-amazon-dynamodb-354f97c96c2 — эта статья буквально расширила границы моего сознания!

Здесь рассказывается про то, как проектировать таблицы в NoSQL БД на примере (и с большой привязкой к) AWS DynamoDB.

Расширение сознания вызвано тем, что основной рассмотренный прием — это хранение в одной таблице совершенно разных данных, относящихся к одном объекту, чтобы ускорить к ним доступ. В реляционных СУБД в одной таблице лежат данные «одной грани» каждой сущности, и это логично, привычно и оправданно. А вот идея хранить в одной таблице разные по сути данные звучит провокационно, однако статья вполне обосновывает такой подход.

В конце статьи дан пример, как шесть таблиц реляционной СУБД упихали в одну NoSQL таблицу, обеспечив доступ к разным «срезам» с помощью глобального индекса (Global Secondary Index). И это звучит обоснованно и модно 😉

Почитать про основные аспекты NoSQL и конкретно DynamoDB можно в первой части статьи: https://medium.com/@nabtechblog/advanced-design-patterns-for-amazon-dynamodb-c31d65d2e3de

#python #memory
Относительно простым языком написано про управление памяти в Python.

Ещё много что остаётся вне статьи, но даже прочитать только про это уже даёт чуть больше понимания что происходит с памятью.

Нужно это знать программисту/инжинеру или нет, решать тебе!

https://m.habr.com/ru/company/domclick/blog/530804/

#mock #interview #algorithms #волонтерство

Ок, вижу, что есть желающие. Высылаю ссылку на формочку, чтобы я смог распланировать время

Не обещаю, что получится поговорить со всеми, так как в планах еще и отдохнуть.

Постараюсь созвониться по принципу FIFO (first in first out), но, если у кого-то что-то срочное, то пишите в комментах

https://forms.gle/aQTtE27NvhVLS4WV8

#python #подборка #неБлагодари

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

1. Clean code in Python: https://www.youtube.com/watch?v=n_Y-_7R2KsY
2. Type-checked Python (Instagram) + MonkeyType: https://www.youtube.com/watch?v=pMgmKJyWKn8
3. Про Hypothesis и Contracts: https://www.youtube.com/watch?v=MYucYon2-lk
4. Loop like a native: while, for, iterators, generators: https://www.youtube.com/watch?v=EnSu9hHGq5o

Раз мне тоже можно голосовать, то сам я проголосую за последнее ☺️ дабы у меня была отговорка отдохнуть 🥳 да, и это, с новым наступающим... 🎉🎉🎉