#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

Если думаешь, что это будет интересно кому-нибудь из твоих друзей, то можешь 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

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

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

we start in 5 mins

#DeepDive #aws #networking #myTechNotes

Note 1.

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

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

#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

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

#distributed #systems
A Distributed Systems Reading List

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

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

#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

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

Про жизнь в Амазон: #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

В субботу, в 10 утра по Алматинскому времени, будет последний мок в этом сезоне! :)) Дальше праздники заканчиваются и я возврщаюсь к работе.

Ну а в целом, всех с Наступающих НГ!

С новым годом, друзья!

Наш следующий Mock интервью начнется через 20 минут!

Topic: Technical Mock Interview #3 (Algorithms, Data Structures)
Time: Jan 2, 2021 10:00 AM Amsterdam, Berlin, Rome, Stockholm, Vienna

Join Zoom Meeting
https://us05web.zoom.us/j/83992975676?pwd=a3FXbHRiR014eGFRVitrVnNBZUQ1UT09

Meeting ID: 839 9297 5676
Passcode: FRwB0q

#mock #interview #feedback

Вчера утром была последняя, за мой заканчивающийся отпуск, сессия с mock interview. Участие в mock interview, уверен, уже очень полезно для собеседника. Но, чтобы принести чуть больше пользы тем кто ко мне обращается, я, как обычно, делюсь письменным отзывом с детальной аналитикой.

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

Видеозапись mock interview: https://www.youtube.com/watch?v=y8G9vLm4gEI
Решение кандидата: https://pastebin.com/yzvSVD57

Что понравилось:
- У тебя есть базовый материал, ты понимаешь принципы оценки производительности своего алгоритма, и можешь продумывать code flow
- Предложил простое и посложнее решение и попробовал реализовать

Что улучшить:
- Не спеши!: Не спеши с решением пока не изучил задание полностью и не уделил достаточно времени на продумывание тестовых кейсов. Твой алгоритм будет работать немного криво если в данных присутствуют отрицательные числа. Т.е. точно также как ты допустил, что в данных может быть 0, точно также может быть и -1. Если бы ты подумала об этих случаях, то мог бы оценить свое предложение на правильностью
- По окончанию написания софта, очень важно его тестировать: Не спеши говорить, что ты закончил, пока не удостоверишься, что твое решение правильное. В идеале когда ты говоришь, что ты дорешал, то ты должен быть уверен, что твое решение верно. В твоем случае, ты провел тестирование своего решения только после просьбы собеседника и, к общему сожалению, в процессе ты обнаружил что решение имеет баги
- Оценка решения на сложность была не достаточно точной В конце интервью ты сказал, что твое решение не использует дополнительной памяти, так как пере-использует существующий список. Что будет если у тебя на вход приходят список чисел от 1 миллиона до 2х миллионов? В твоем решении ты расширяешь список, и тем самым задействуется больше памяти
- почитай про re-sizing array. Это не происходит бесплатно.
- nit-pick: Кстати, не до конца было ясно зачем нужно расширять список, когда можно просто игнорировать значения выше длины списка
- Поработай над читабельностью кода: например, a[a[1]] и a[1] читается не очень комфортно. Не стесняйся добавлять комментарии, выносить в отдельные функции

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

Next steps:
- Поработай над своим подходом: видно, что у тебя есть базовые знания, но из-за спешки ты допустил очень много ошибок. Если решаешь задачки на LeetCode, то обрати внимание на показатель Acceptance Rate, который, если не ошибаюсь, показывает как часто у тебя получается решить задачку с первой попытки так, что все тейст кейсы проходят успешно.
- Потренируй свой навык объяснения того что ты делаешь (и почему!). Лучше всего, имхо, это делать на популярных алгоритмах (сортировки, поиска и тд), либо на задачах (leetcode, hackerrank alike).
- (без фанатизма) Учись писать читабельный код: используй понянтые для читающего названия, добавляй комментарии, если это улучшает читабельность кода

__________
share if you think it can be useful for your friends
Мой телеграм: https://t.me/webapparch

#myTechNotes #aws #network #DeepDive

Note 3.

Продолжаю копать тему сетей, чтобы не работать со всем этим как с black-box.

Поигрался с AWS VPC:
- Private Subnet для сервков с приложениями
- Public Subnets с bastion host, чтобы запрыгивать через ssh на серваки с приложениями
- NAT Gateway, чтобы позволить ходить из сервков с приложениями в интернет за обновлением софта
- Routers, чтобы поставить коммуникацию между Subnets
- Internet Gateway, чтобы можно было ходить в интернет,

И самое главное, накинул на это все несколько Network Access Control Lists Rules, дабы обезопасить доступ к тому или иному сервису.

Проблема:
Проблема наступила когда я пытался подключиться через ssh без открытия обратных ответов к ephemeral ports моей домашней машины. Вроде бы указал, чтобы TCP трафик на порт 22 ходил в обе стороны (т.е. Outbound, Inbound traffic). Но не тут-то было...


Learnings:
До 2021 я не особо задумывался как происходит подключение через ssh, https, etc, с точки зрения портов на машине клиента. Пришлось поразбираться и я обнаружил (сейчас уже конечно это кажется очевидным), что при отркытии TCP соединении клиент использует один из ephemeral портов, чтобы получать ответы от сервера. Это позволяет нам открывать сразу несколько соединений с сервером как для ssh (Порт 22) так и для http/https соединения (порты 80/443). Открыв ephemeral ports, все сразу завелось!)


Ссылки
Как всегда, делюсь ссылками, которые помогли мне понять все это простым языком. Если тебе интересно и не хочешь тратить время на поиски-и-происки, забирай!

В целом о TCP Ports:
- https://www.youtube.com/watch?v=mykX2YONRwE
О "Well-Known Ports":
- https://www.youtube.com/watch?v=RDotMcs0Erg
Об "Ephemeral Ports":
- https://www.reddit.com/r/aws/comments/cyzzyy/eli5_what_are_ephemeral_ports/
- https://www.whizlabs.com/blog/ephemeral-ports/

Также ниже прикрепляю свой рабочий черновик с диаграммой

#systems #design #performance

Уау!

Пару недель назад разбирался с concurrency и прочими вещами. Вышел курс от MIT на тему оптимизации производительности ПО.

Сохраняю для себя, чтобы покопать тему еще глубже в следующий отпуск!

https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-172-performance-engineering-of-software-systems-fall-2018/lecture-videos/index.htm

#team

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

Я всегда был за идею в Informal Leadership. Другими словами, чтобы что-то изменить в команде, тебе не нужно быть менеджером или тим лидом. Наоборот, чем раньше ты начнешь предпринимать попытки влияния на культуру команды в сторону улучшения, тем раньше ты станешь на шаг ближе к тому, чтобы стать более крутым инженером.

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

И да, крутая культура, точно того стоит!

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

Супер история о том, как Амазон чуть не умер и переехал с серверов Sun на Linux. Это — история зарождения Amazon Web Services — облака, на котором сегодня работает добрая половина интернета.

Рассказывает один из непосредственных участников.

Самые впечатляющие моменты:

❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;

❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;

❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;

❧ заморозка развития сервиса привела к падению продаж → пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;

❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;

❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.

Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.

https://twitter.com/DanRose999/status/1347677573900242944