„Chillin‘“ at Amazon
618 subscribers
27 photos
1 video
7 files
370 links
Amazonian SDE is sharing, 'cause sharing is caring 👨‍💻

note: I do not represent any of my employers in this channel
Download Telegram
#distributed #systems
A Distributed Systems Reading List

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

https://dancres.github.io/Pages/
„Chillin‘“ at Amazon
#mock #interview #feedback Как обещал, даю отзыв по mock interview. Что было хорошо: - Прежде чем преступить к задачке, ты начал с уточняющих вопросов, спросил про input/output, написал пару тест кейсов, подумал об edge кейсах. Как ни странно, но эта стадия…
#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
„Chillin‘“ at Amazon pinned «Начинаю путаться в тэгах. Пиню для себя и других Про жизнь в Амазон: #LifeAtAmazon Architecture: #systems #design #architecture #systems_design #db #distributed Language specific: #python #go Other: #ML, #myTechNotes, #DeepDive About interviews: Время…»
В субботу, в 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/

Также ниже прикрепляю свой рабочий черновик с диаграммой
#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
Прикольная статья про парня, который упрямо пытался найти уязвимость в Youtube и в итоге сделал это

https://bugs.xdavidhu.me/google/2021/01/11/stealing-your-private-videos-one-frame-at-a-time/
Forwarded from ДевОпс Інженер 🇺🇦 (Oleg Mykolaichenko)
Что там случилось с Elasticsearch?

Супер кратко:
Elastic поменял лицензию для продуктов, и они перестали быть open source. Комьюнити это не понравилось.
Теперь вышел Amazon, у которого война с Elastic, и сказал - мы форкнем, и будем дальше развивать Elasticsearch + Kibana с ALv2 лицензией.

Итого, факты:
- Elastic announced moving Apache 2.0-licensed source code to be under Server Side Public License
- Elasticsearch 7.11 будет уже под SSPL, т.е. не open-source
- Elasticsearch 7.10.x, который еще ALv2 - будет получать секьюрити апдейты до May 11th, 2022
- AWS will step up to create and maintain a ALv2-licensed fork of open source Elasticsearch and Kibana

Кто бы мог подумать 🤔

https://aws.amazon.com/blogs/opensource/stepping-up-for-a-truly-open-source-elasticsearch
Forwarded from Aigerim
Всем привет! Каждый раз когда читала success stories наших участников очень радовалась за каждого и думала когда же я тоже буду делиться с хорошей новостью с вами. Вот и наступил этот момент, получила оффер от Майкрософта 😊😊😊 Прежде хочу благодарит вас всех за все!!! А особенно хочу выразить огроменную благодарность @sergi_sema ты красавчик и крутой человек!!! Спасибо за такую классную группу!!!

Коротко о моем пути:
Начинала год назад когда HR Google написала интересует ли меня работа в Google
3 года опыт работы, являюсь Андроид Девелопером
Решила 333 задач(Easy 101, Medium 222, Hard 10)
~20мок интервью с участниками этой группы
Провалила 2 тел.интервью(Google, Amazon) и не доходила до онсайта

Google Tokyo
Когда получила письмо от HR Google Tokyo где спрашивали интересует ли меня работа в Google, тогда и я начила готовиться. Первый колл был с HR была обычная беседа обо мне и в конце согласились что процесс начнем через 2 недели. За 2 нед. только успела подготовиться по Algorithms & Data Structures. 1 раунд был с той же HR и в течении часа спрашивала вопросы именно по Algorithms & Data Structures и на след день написала что прохожу на тел.интервью, сразу попросила месяц чтобы подготовиться и месяц решала задачи литкода. На тел.интервью спросили хард задачу по графам, кстати задачу потом не нашла в интернете. И получила фэйл и как сама ожидала. Я прекрасна знала что не готова, но мне хотелось узнать формат, примерно какие вопросы спрашивают, и узнать себя также как буду вести себя в экстренных случаях.

Amazon Madrid
После Google стала решать задачи ежедневно, и пришлось совмещать основную фуллтайм работу с подготовкой. Было сложно как и всем, себя заставлять 🙂 И в апреле в линкедине увидела хайринг ивент Амазона и подавала через сайт без рефералов, через 2-3 дня ответили, прошла ОА. Вопросы ОА можете найти в литкоде в разделе discussion. Через месяц в мае был тел.интервью где 20мин спрашивают поведенческие вопросы, на 30мин задачу решать. После того как завершили часть behavioral questions, и интервьювер стал обьяснять задачу и прекрасно с ней я бы справилась если бы в тот момент мой интернет не подвел бы меня((( Пришлось перенести интервью на завтра и спросили dp задачу и там я и провалила, и поняла для себя что нужно больше решать задачи по dp. В ноябре обратно через сайт подавала на другую позицию и локацию, прошла ОА, потом HR попросила чтобы на след.неделе запланировать день на тел.интервью но я просила дать мне 2 недели, затем HR пропала. Но HR появилась неделю назад и вот назначили на 11.02.2021 тел.интервью.

Microsoft Prague
С Майкрософтом все как-то быстро получилось и до сих пор не верится что получила оффер. Подавала в начале этого года тоже через сайт без рефералов. Ответили быстро и попросили пройти ОА через кодилити(спрашивают 3 задачи). Сказали прошла на тел.интервью и назначили колл c HR. Но потом другой HR написал что у них через неделью хайринг ивент и спросили хочу ли я участвовать в нем. Хотя я к онсайту не была готова, т.к по system design и OOP design я ни разу готовилась. Но рискнула и согласилась, и пришлось готовиться неделью по system design и OOP design. Онсайт состоял из 4 раунда:
1 - раунд по Algorithms & Data Structures задача медуим + поведенческие вопросы
2 - раунд по OOP design, дали уже готовый дизайн и попросили рефакторить его + поведенческие вопросы и вопросы по ООР
3 - раунд system design + поведенческие вопросы
4- раунд поведенческие вопросы
Все интервьюверы были классные и дружелюбные, поддерживали как могли.
На след.день уже написали что фидбек отличный и уже готовы предложить оффер, а на этой неделе уже отправили детали оффера.

Ресурсы:
Algorithms & Data Structures:
https://www.coursera.org/learn/algorithms-part1
https://www.coursera.org/learn/algorithms-part2
https://algs4.cs.princeton.edu/cheatsheet/
https://leetcode.com/problemset/all/
https://www.educative.io/courses/grokking-the-coding-interview
https://www.educative.io/courses/grokking-dynamic-programming-patterns-for-coding-interviews
Forwarded from Aigerim
Gracking the Coding Interview - Gayle Laakmann McDowell

System Design
https://www.educative.io/courses/grokking-the-system-design-interview

Behavioral Questions
https://www.youtube.com/channel/UCw0uQHve23oMWgQcTTpgQsQ
https://www.youtube.com/channel/UCaO6VoaYJv4kS-TQO_M-N_g/featured

Learnt lessons:

Ничего не откладывайте на завтра, на следующий месяц, на след.год.
Всегда помните что вы никогда не будете на 100% готовы, поэтому начинайте уже подавать в компании. Даже если получите фэйл, то такой огроменнный опыт вам никто не даст, даже моки которые проводим мы между собой. Не ждите пока вы не решите 1000 задач в литкоде.
Найдите себе teammate, с которым вместе будете готовиться и контролировать друг-друга. Мы @Emil_dev вместе готовились, при фэйл подбодривали друг друга, и контролировали процесс друг-друга
В реальных интервью не создавайте атмосферу экзамена между учеником и учителем, а постарайтесь создавать атмосферу обычного рабочего процесса, где интервьювер является вашей коллегой, потому что они смотрят еще на вашу способность collabaration
Если у вас технические проблемы во время интервью, это ок, не переживайте))

Готова ответить на любые вопросы кроме ТС и конкретных задач на собеседованиях - все под NDA.

И мои коллеги в группе пока не распространяйте новости плз😂😂😂