#mock #interview #coding #structures #internship

https://www.youtube.com/watch?v=2ImGTffHWbs

#mock #interview #behavioral #arerightalot
https://www.youtube.com/watch?v=aM4nZ3Rjs_o

#interview

Interview preparation materials. Nice!

https://techinterviewhandbook.org/

#interview #mock
🥳🥳🥳 Еще очень крутые новости с утра!

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

#coding #algorithm #dynamic #programming #interview

Замечательное объяснение подхода решения задач через Динамическое Программирование!

Если знаете еще хорошие ресурсы (видео, статьи), то поделитесь в комментах, для меня и других

https://youtu.be/aPQY__2H3tE

#interview #behavioral #levels

Хороший текст про уровни в Google, похожее в Амазон.
Примерный маппинг уровней в Гугл с уровнями в Амазон
- L3 at Google is ~L4 at Amazon
- L4 at Google is ~L5 at Amazon
- L5 at Google is ~L6 at Amazon
- L6 at Google is ~L6 at Amazon - да, все верно, в Амазон L6 - это много.

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

I'm a staff engineer at Google. My take on it is a little different than the others here.

The normal levels are 3/4/5, with 5 being Senior Engineer. It is normal for you to progress up level 5, Senior. What that level means is this: Google has something that needs to be done, and knows that you can take care of it on your own with no problems. In other words, Google knows what the problems is, knows what the answer is, and trusts you to get it done and take care of the details.

The next level is 6, Staff Engineer. What this means is: Google knows what the problem is, but does not know what the answer is, but trusts that you will figure out how to solve the problem. Levels above 6 are more concerned with identifying problems/goals, and figuring out which ones to tackle (in addition to the things in all the other levels).

So, in my opinion, the best way to become a staff engineer is to have a track record of solving problems that other people don't immediately know the answer to. If there are issues out there, where people are scratching their heads and thinking, "I'm not really sure how we should go about that.", and you are consistently solving those problems, then that is where you want to be for getting to level 6, Staff. People will be saying, "I'm glad that person X did it, because I didn't know how to solve the problem."

Additionally, at level 6, you should have a broad view of how things work at Google and what teams are working on what projects in your department.

First you have to get to level 5, Senior. That's where people are looking at an issue and thinking, "I generally know how to tackle that, but it is complex and involves a lot of work and a lot of experience." Tackling those problems is how you get to level 5. People will be saying, "I'm glad X did it, because it looked complex, like it would take a lot of hard work."

To get to level 4, people should be thinking about you: "I'm glad X is working on this for me, because they didn't need much help or guidance and figured out a lot of it on their own."

To get to level 3, people should be thinking about you: "I'm glad X is here, because they understand how computers really work, they learn fast, they are passionate about technology, they can take charge, they communicate well, they are friendly and fun to be around, and they can see the underlying abstract patterns that are obscured by many surface details."

Source: https://www.quora.com/How-does-one-become-a-Staff-Software-Engineer-at-Google-What-might-a-new-grad-entering-the-company-do-to-grow-their-career-to-reach-that-level

#interview #coding #algorithms
Blind 75 LeetCode Questions - LeetCode Discuss
https://leetcode.com/discuss/general-discussion/460599/blind-75-leetcode-questions

#interview #algorithms #patterns
https://www.youtube.com/watch?v=cpgAULF6Vpw&list=PL7g1jYj15RUOjoeZAJsWjwV8XUo9r0hwc

#coding #algorithms #patterns #interview
https://link.medium.com/CggXN7Q8emb

#interview #coding

Для тех, кто начал втягиваться в интервью, статья описывающая подход поиска решения:

https://malisper.me/an-algorithm-for-passing-programming-interviews/

#behavioural #interview #amazon

https://interviewing.io/guides/amazon-behavioral-interview/

#interview #coding

В различных пабликах вижу вопросы типа: «когда мне дали задачку Х, я сразу решил задачку оптимальным способом. Что я мог сделать иначе/лучше?»

Во время интервью вы должны показать, что вы не просто умеете решать задачки, знаете алгоритмы и структуры данных, а что вы умеете применять правильные решения в нужных ситуациях, и без over-engineering.

Поэтому, прежде чем писать решение задачки, даже если оно простое, очень важно собрать информацию о задаче.

Часто задачку дают, не дав всю информацию до конца, и кандидат либо уточнит заранее, либо сделает собственные допущения - то есть, сделает то что надумал у себя а голове, а не то, что просит его собеседник. Для Миддлов и выше это красный флаг, если человек рвётся в бой.

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

На интервью важно показать, что ты не просто решаешь задачки, а показать как ты решаешь технические проблемы: как собираешь требования, как проясняешь неясности, как дизайнишь решение, и как удостоверяешься, что решение точно работает. И только потом пишешь код.

Все это можно перевести на язык Лидерских принципов в Амазоне: Are right a lot, Deep Dive, Think Big, Earn trust, Customer Obsession, and etc.

Фреймворк по которому я работаю:
1. Сбор информации: уточняющиеся вопросы о задаче, о том где и как ее применяют, об ограничениях, размерах, и типах данных (int, star, negative positive, uppercase lowercase, punctuation, etc)
2. Поняв задачу в деталях, я предлагаю несколько тест кейсов, чтобы удостовериться наверняка, что я понял задачу точно. Я покрываю такие вопросы как какие данные приходят на вход и какие на выход, то есть как устроен API. В этом есть несколько плюсов: ты даешь возможность собеседнику подсказать тебе если ты что то недопонял и что ты ты точно понимаешь и осознаешь крайние случаи
3. Поняв задачу, включая тест кейсы, предлагаешь решения и их сложности, и проверяешь у собеседника, что это вписывается в его ожидания. Тем самым, показав свою зрелость, ты даёшь собеседнику возможность повысить тебе сложность раньше, и тем самым повысить свои шансы на то, что он тебя уже будет планировать на Bar Rasing level
4. Только после того как ты поймёшь, что ты понял задачу, написал тест кейсы, проговорил это все с интервьюером, и он дал тебе зелёный свет писать код, то только тогда можно писать код.
5. Следующий пункт очень важен: написав решение задачки, ты используешь выше-приведённые тест кейсы, чтобы прогнать их через своё решение, где шаг за шагом ты объясняешь значение каждой переменной и как они меняются. Это даёт сигнал собеседнику, что ты умеешь проверять свои решения и исправлять ошибки если таковы имеются.

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

Удачи на интервью!

Вопросы пишите в комментариях.

#coding #interview
Know Thy Complexities!
https://www.bigocheatsheet.com/

#amazon #leadership #principles #interview #behavioural

В этой статье очень неплохо описывают про поведенческую часть (aka Leadership Principles) в Амазон

Единственное дополнение наверное это в ответах нужно показать размер/сложность/scope задачи, которая будет соответствовать уровню на который вы подаетесь. Если ВКРАТЦЕ:
L4 - делаю сам маленькие компоненты очень хорошо, учусь влиять на команду
L5 - делаю сам средние компоненты, влияю на Команду, учусь влиять на другие команды, учусь создавать видение для своей
L6 - лидирую крупные/сложные задачи (по меркам сложности для одной команды), требующие нескольких человек для реализации и взаимодействия с другими командами. Создаю техническое видение продукта и работаю на bottlenecks в достижении намеченных целей

https://www.levels.fyi/blog/amazon-leadership-principles.html

#systems #design #interview

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

Технические интервью это практически всегда про problem solving. А с чего начинается решение проблемы? С ее четкой формулировки.

Как нам говорили в школе на уроке по геометрии: «сбор данных - это 50% процентов успеха решения задачи»

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

1. Кто конечный пользователь? Какие потребности у него есть, и какие проблемы сервис должен решить?
2. В какой географической зоне будет использоваться сервис, и какие могут быть особенности этой зоны (например, языковые или культурные различия)?
3. Какой объем данных нужно обработать, хранить или передавать? Это поможет определить, насколько задача масштабируема.
4. Какие прочие ограничения существуют?

Чем выше ваш уровень, тем выше от вас будут ожидать наличие навыков работать с неопределенностью

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

А как вы выстраиваете ваши интервью? Какие еще вопросы можно задать?

#interview #coding
Для тех кто застрял на легких задачках в ЛитКоде и думает что программирование (или дорога в FANG) это не его: Попробуйте изменить подход.

1. То как решаешь задачки. 20-20-20. Решай задачу 20 минут, если не решил, то иди в дискуссии и изучай как другие решают это задачу, стараясь понять решение. Последние 20 минут используй на то, чтобы решить задачку еще раз несмотря в решение. Это самый эффективный способ решения задач. Важно соблюдать это правило и не тратить часы чтобы решить самостоятельно. Не забывай про цель - цель не доказать что ты всемогущий/-ая, а набить руку и визуальную библиотеку
2. Введи отдельно сессию, где ты разбираешь сложные алгоритмы. Старайся понять какую проблему они решают и как. Это может быть книга Сэджвика или Ютуб каналы, где разбирают как решать задачи, или курс по Алгоритмам от MIT. Где что то непонятно, подключай коммьюнити или GPT. Цель: углубиться в сложные алгоритмы и перестать их бояться.
3. Решай Моки - набивай опыт по прохождению интервью с людьми. Прохождение интервью с человеком может быть легче, так как задача собеседника направлять кандидата если тот застрял. Умение слушать собеседника - это то чего ты не получишь просто решая задачи на ЛитКоде. Более того, интервью это про беседу - коммуникацию с другим человеком.

В конце концов, тебе может повезти и у тебя никто не будет спрашивать Харды и ограничатся Медиум задачами.

Удачи в подготовке к интервью!

#systems #design #interview

☄️☄️☄️5 Top GitHub repos to help you ace systems design interviews:

1. https://github.com/binhnguyennus/awesome-scalability
2. https://github.com/karanpratapsingh/system-design
3. https://github.com/checkcheckzz/system-design-interview
4 https://github.com/mehdihadeli/awesome-software-architecture/blob/main/docs/systems-design/systems-design.md
5. https://github.com/black-shadows/System-Design

Covers algorithms, system design, data structures, and more