G R O M O V
681 members
6 photos
22 links
Канал Громова про программирование, карьеру и бизнес.

Чат канала - t.me/gromov_chat

Автор - @oleggromov
Сайт - https://oleggromov.com
Твитер - https://twitter.com/oleggromov
Download Telegram
to view and join the conversation
Дописываю статью о том, как торговаться на собеседованиях 💸
В ней будет про рычаги для торга, осведомлённость о рыночных условиях и тактические фишки, помогающие организовать процесс правильно - чтобы уже компании старались заинтересовать вас, а не наоборот.

Что ещё добавить? Может быть, у вас есть истории из жизни или вопросы, на которые хотелось бы получить ответ?

Пишите в чат!
Move Fast and Break Things 🤯

Есть в Фейсбуке такой девиз. Это даже звучит логично и отсылает к одному из прошлых постов про проклятие знания наоборот. Действительно, в огромной компании с тысячами разработчиков, где постоянно что-то меняется и ежедневно мёржится наверное сотня тысяч комитов, сложно понять системы, с которыми работаешь. Надо брать и делать, а когда поломается - чинить.

А я от этого вот прям страдаю. Лучше всего я работаю в условиях, когда моя модель мира достаточно точна для оценки сложности задач и понимания, “куда забить гвоздь”. А тут ровно наоборот. Ничерта не понятно, ещё и меняется всё постоянно. А некоторые решения приняты и вовсе бог знает кем неизвестно когда.

Для справки: мы делаем десктопное приложение на электроне с redux-saga для сайд-эффектов, которое смотрит в локальную sqlite, которая в свою очередь синхронизируется с внешним миром через написанный на C транспорт и C++ прослойку в nodejs. Не сказать, что я не понимаю код - понимаю. Но не вижу big picture за всем этим, особенно когда нужно сделать что-то нетривиальное.

При этом стандартная (и даже логичная) позиция коллег: move fast and break things. Ну то есть лезь напролом и чини, когда сломается. Это действительно позволяет достигать хоть какого-то результата. Немного tech debt тут и там - и готово. В целом работает, хотя и приходится заставлять себя.

Но вот о чём это заставляет меня задуматься: кажется, что всего 5-10% разработчиков в компании процентов на 80 понимают системы, с которыми работают. Остальные плетутся где-то в хвосте, ещё больше спутывая и без того запутанные следы здравого смысла. И бог бы с ним, с кодом - гиганты заплатят со своих сверхприбылей, кто-то придёт и перепишет через пару лет.

Любопытно, какие результаты даёт эта культура. “Топ” техлидов, которые всё выдумывают, и толпу пилящих скучные фичи аутсайдеров? Провоцирует ли она понимание архитектуры или подталкивает к бездумному говнокодингу, лишь бы работало? Понимает ли кто-то целиком весь “звездолёт” - да и нужно ли это кому-то?

Или я вообще где-то по пути свернул не туда и вместо принятия чуть ли не экспоненциально растущей сложности систем вдруг решил, что в индустриальном программировании может быть как в сайд-проекте?
Я променял прекрасные статичные сайты на django-монстра 😱

Мой нынешний сайт oleggromov.com сгенерирован самописным генератором Feisty. У него есть крутая фишка: он поддерживает произвольную вложенность в yaml-шаблонах страниц, в которые можно включать либо md-файлы с контентом, либо другие yml. Благодаря этому каждая страничка собирается из небольшого дерева на файловой системе.

Кроме вложенности, крутота ещё в том, что контент разбит на произвольное количество мелких частей - и это очень удобно при вёрстке нелинейных страниц со всякими врезками, списками и прочим. Весь HTML, кроме базового форматирования, отдельно от контента.

Но у статики есть косяк, который я не могу побороть даже концептуально: отсутствие user-generated контента. Хочу я, чтобы комментарии посетителей оставались со мной навсегда - и для SEO, и чтоб владеть своими данными, и, потенциально, для email-рассылок. А никак. Есть только какая-то чепуха вроде комментариев в issues на гитхабе и какой-то треш вокруг всего этого - но это ж не серьёзно, плюс, опять же, данные мне не принадлежат.

И что же делать? Писать нового франкенштейна 🙂 Конечно же, Wordpress или {{ your_favorite_cms }} я брать не буду, потому что мне нужны мои любимые чанки - их я сделал как разложенные на строчки таблицы узлы дерева, каждый из которых доступен по своему пути. А Postgres замечательно индексирует их с помощью расширения ltree. Например, чтобы получить about.experience.klarna.period, можно сделать select * from chunks where path <@ ‘about.experience’.

К тому же комментарии, ради которых это все затевается, прекрасно ложатся в эту древовидную структуру. Красота да и только! Покажу вам потом, когда готово будет.

А пока вопрос на миллион: не порю ли я фигню? Нет ли какого-то более-менее адекватного способа прикрутить комментарии к статичному сайту? Ну, например, пересобирать страницу в момент отправки комментария каким-то третьим сервисом? Может, идея для стартапа? 😄
В мире и так чёрт знает что творится (я остаюсь в стороне от политической повестки, чтобы поберечь свои и ваши нервы, а не потому, что меня это не волнует или не касается), а тут ещё и Mozilla объявила о реструктуризации/сокращениях. По-видимому, под удар попала и команда MDN.

https://twitter.com/jasnell/status/1293524408628203523
🔥 Канал для тех, кому нужны смысл и цели

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

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

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

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

Кроме этого канала, у меня есть:

- Твитер twitter.com/oleggromov - на английском. С недавних пор там снова есть жизнь, и большая часть ежедневного теперь там. Подписывайтесь, если читаете на английском.

- Сайт gromov.com - на английском. Пока там редирект на старый сайт, но скоро запустится новый - с длинными гайдами на тему технологий и карьеры и блогом.

Ну и этой осенью запущу YouTube-канал - тоже англоязычный.

А пока до связи, и приятного чтения! 🤘
G R O M O V pinned «🔥 Канал для тех, кому нужны смысл и цели Привет, с вами Громов. Это канал для тех, кому, как и мне, нужны смысл и цели - в программировании, карьере, предпринимательстве, личном и профессиональном росте, переездах в другие страны, жизни. Примерно раз в неделю…»
Чудеса, в Microsoft объявили конец поддержке IE11 в собственных веб-приложениях.

Помню еще время, когда IE6 казался (и был) современным браузером, IE5.5 for Mac - волшебное словосочетание, как потом от IE6 с радостью открещивались, а потом то же самое с IE9 и YouTube, кажется.

И вот, последняя веха в битве движков. Chromium победил всех, получается? Сколько там у Gecko осталось, процентов 10 рынка?

И радостно, что не придется больше чинить поломанный CSS в IE, и грустно, что тот, у кого больше всего денег (от гугла и apple) и больше всего пользователей, как следствие, в итоге побеждает.
Про мотивацию и impact в Фейсбуке

В Фейсбуке к мотивации, как и приблизительно ко всему остальному в разработке, свой подход. Есть магическое слово, универсальное мерило успеха продуктов и программистов - impact. То есть влияние, положительное. Делать нужно только то, что принесёт пользу - продукту, инфраструктуре, коллегам, вам.

Новая архитектура, которая ускорит обработку сообщений на 10% - impact, тащи! Сделать десяток новых фич, которые помогут продукту занять запланированную нишу на рынке? Impact, вперёд! Вкрутить UI-библиотеку, чтобы интерфейс наконец стал непротиворечивым - impact, конечно же.

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

Чтобы такой подход полетел, важно не только делать что-то полезное, но ещё и рассказывать об этом коллегам и начальникам и демонстрировать положительный результат. Причём всё время, а не только в преддверии PSC (performance summary cycle - период длиной в полгода, в течение которого на вас собирают фидбек, выставляют оценки и дают повышения).

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

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

Но разве идея оценки через призму impact не слишком "левая"? Может быть, но однозначно хорошее в ней тоже есть.

Искать проблемы, заслуживающие внимания, качественно решать их и убедительно об этом рассказывать - это вполне универсальный рецепт успеха в любом окружении. А если за это ещё и платят, то вообще отлично. Конечно, в сравнении с менее продвинутыми компаниями, а не с идеальными условиями (да-да, я тоже согласен с Талебом по поводу зарплаты).

А вы хотели бы, чтобы вашу работу оценивали через impact?
🏖 С последним днём лета!

Не знаю, насколько легко вы отключаетесь от работы, но у меня с этим проблемы. Я обычно так влипаю в свои задумки, что занимаюсь ими всё свободное время. Либо, наоборот, не занимаюсь вообще. И, хотя второй вариант меня вполне устраивает теоретически, мне сложно смириться с тем, что вот прямо сейчас - по любой причине - я не двигаюсь к своей цели.

Основная причина этому - сильное желание кое-что поменять, ну и нетерпеливость. Но, безотносительно причины, позволить полностью отключиться от работы и избавиться от чувства вины мне удаётся с трудом. Но гениальное решение есть!

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

Исчерпывающий список аттракционов для тихого семейного отдыха получился. Едва ли я успел расслабиться - но точно отвлёкся от впечатавшийся в подушечки пальцев рутины.

А как ваше лето? Получилось отдохнуть без экстрима?
Зачем программисту копаться в мозгах

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

Отвечу длинно. Попробуем смоделировать профессиональную жизнь, используя две ортогональные оси. Для простоты назовём их "польза" и "удовольствие".

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

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

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

Заветный угол, разумеется, правый верхний. Находясь в нём, вы приносите большую пользу обществу через своё занятие и при этом искренне наслаждаетесь процессом как в моменте, так и в долгосрочной перспективе. Это место, которое я бы назвал "ваше место", и мне кажется, что отыскать или создать его непросто.

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

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

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

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

Когда я рассказываю, как отношусь к работе в корпорации или как я отдохнул и отвлёкся, я хочу не только "подумать вслух" или выплеснуть эмоции, что, безусловно, полезно лично для меня. Я стараюсь привлечь ваше внимание к тому, что вы - не бездумная, бесчувственная машина. Не работник с 9 до 5 по звонку, не Software Development Engineer at Google в апогее траектории своей карьеры.

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

https://oleggromov.com/u/programmer-occupation-psychology.png
Сразу в продакшн

Я задумывал намного больше проектов, чем начинал, а начинал намного больше, чем заканчивал. Спад примерно экспоненциальный. Можно найти массу причин этому феномену, но одна из них - элементарное отстутствие удобного деплоя в продакшн одной командой.

Простой пример - любое объектное хранилище, например Google Storage или Amazon S3. У обоих есть CLI-тулзы, с помощью которых деплой статического файла действительно выполняется одной командой. Второй настраивается edge-кэш - и ваш файлик готов к миллионам скачиваний.

А как же приложения посложнее статики? Когда мы говорим про рабочее окружение, в CI/CD-инфраструктуру вкладываются огромные силы и средства, и деплои для разработчиков, как правило, просты и прозрачны. Смёржил свой пул-реквест в master, и погнали. А под капотом: несколько окружений, тысячи тестов, инкрементальные выкладки и A/B-тесты, миграции схемы БД и данных.

Хоть DevOps-подход и популярен, сложно представить себе разработчика на развесистом проекте (особенно с микросервисами), который и код пишет, и всю инфраструктуру вокруг настраивает, и работает при этом не 16 часов в день. В крупных компаниях есть целые команды, которые если и не настраивают каждую сборку, то, как минимум, собирают и поддерживают инструменты для деплоя.

А вот в сайд-проектах всё совсем по-другому, и помогать вам некому. Инструменты автоматизации можно либо взять существующие (GitHub Actions, например), либо сделать самому. Какой бы подход вы ни выбрали, постарайтесь сделать так, чтобы ваш код попадал в продакшн максимально просто и быстро. Это увеличит шансы вашего проекта быть запущенным и позволит вам не прокрастинировать из-за очередной хитрой выкладки, а делать что-то полезное.

Первое, что я делаю в своих проектах - это автоматизация настройки серверов и деплоя. После серии экспериментов с Google Cloud и их встроенными инструментами, я ушёл на DigitalOcean и "ручную" настройку через Ansible. Для моих миниатюрных проектов получается и дешевле в рантайме, и не сложнее, а скорее более гибко и надёжно, чем с гуглом.

Когда деплой автоматизирован, разработку я веду в 2 окружениях параллельно: локальном, где я пишу код, и продакшене, куда попадает каждый комит в master. Тестирования, которое могло бы заблокировать выкладку, у меня конечно же нет - я не фейсбук для таких мер. Из тестов - только юнит-тесты на какие-то критические и непонятные куски кода. Для сайта, когда он будет готов, я наверное добавлю интеграционное тестирование для проверки наличия страниц и корректности кэширования, но тоже в продакшене.

Большим проектам и командам такой процесс, разумеется, не подойдёт - слишком много рисков и точек отказа, но для моих микропроектов с одним разработчиком - в самый раз. А вы свои сайд-проекты тоже деплоите в прод одной командой?
FizzBuzz Enterprise Edition

Уверен, что вы слышали про FizzBuzz - простейшую задачку для собеседований, которую, по слухам, проваливает немалое количество кандидатов, стремящихся в тот самый кровавый энтерпрайз.

Так вот, есть даже целый почти соревновательный жанр, где разные авторы конкурируют за самую эзотерическую реализацию нехитрого алгоритма. Лучшее решение из увиденных мной пока написано на джаве: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

На скриншоте только один из сотен классов - покопайтесь в репозитории для вдохновения! Можно даже пару-тройку шаблонов проектирования по нему выучить 😉
Как я целеполаганием прокрастинацию победил

Полгода назад, занимаясь Quiken, я активно фигачил. Практически каждый вечер садился и писал код, переписывал код, настраивал деплои, фоновые таски, экспериментировал с дизайном и UX, рисовал логотип, промо-картинки, писал описания в Chrome Store. И так три месяца подряд. Это было непривычно: мне редко удавалось настолько сконцентрированно работать над чем-то "своим", не считая разве что литкода и подготовки к вступительным по математике.

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

Когда активная работа над Quiken завершилась, я взялся за новый сайт. Долго думал, зачем он мне. Увязывал в одну стратегию телеграм, длинные статьи и блогинг; публикации на других сайтах и тактики продвижения; съёмки видео. Пришёл к определённым решениям по технологиям, взялся за прототипы, проверил и подтвердил жизнеспособность всех идей. Всё шло хорошо.

А потом на полной скорости влетел лбом в уже ставшую непривычной стену прокрастинации.

Отвлёкся на основную работу; домашние дела; потом поехали отдыхать; копался в мозгах, пытаясь найти новые ориентиры и ценности; искал детский сад для ребёнка; потом заказал в Японии гитару, о которой мечтал с юности, и выбирал усилитель для занятий дома. Месяцы шли, а я всё никак не садился за работу, проводя всё больше времени в размышлениях и без какого-либо результата.

Неприятнее всего, что подобный режим, когда много запланировал, а потом только думаешь и почти ничего не делаешь, угнетает психологически. Вроде бы и цели есть, и всё понятно - но ничего не получается. Несложно попасть в downward spiral (это как по-русски?) и утонуть в море вины, жалости к себе и отвращения к работе.

Побарахтавшись чуть-чуть, я стал выплывать. Сначала вернулся к выработанному принципу "деплоить в продакшн сразу же": настроил Ansible, серверы на Digital Ocean, миграции - чтобы каждый комит в master одной командой релизить на живой сайт. Это немного помогло, так как я взялся за работу, но код самого сайта я всё равно не писал. Прокрастинация не уходила.

Тогда я заподозрил целеполагание. Как и многие из вас, я привык ставить цели в контексте работы. Иногда организуя их в иерархию objectives and key results, иногда опираясь на SMART-методологию: чтобы был срок, чтобы было точно понятно, что делать - а потом оценивать результат по заранее определённой шкале. И, кажется, эта привычка сыграла со мной злую шутку.

У меня не так много времени, чтобы заниматься своими проектами; внимания, силы воли и даже желания часто тоже не хватает. И получается, что я не достигал практически ни одной из своих целей, прикреплённых к календарю и выраженных количественно. От этого пропадает уверенность в себе и адекватности целей, и приходит тот самый ступор, заставляющий смотреть сериалы даже тогда, когда отдыхать уже не хочется.

Обнаружив неладное, я попробовал изменить подход к планированию. Вместо намерения достигать определённого результата к определённому сроку решил сконцентрироваться на соблюдении определённого расписания. 2-4 часа в будни должно уходить на свои проекты, включая сайт, канал и прочее. Разумеется, это получается не всегда: я стараюсь садиться за работу каждый день, но не винить себя, когда не выходит.

Привычное планирование с таким подходом почти невозможно, но в моих нынешних начинаниях так много неопределённости, что придерживаться планов всё равно не получается. И если поначалу ослабить хватку контроля страшно, спустя какое-то время становится намного легче жить и работать.
В эту пятницу в 17 часов по Москве поговорим про собеседования в большие компании с ребятами из g-mate. Я расскажу про свой опыт с Яндексом, Toptal и Facebook и постараюсь дать рекомендации, которые вы сразу сможете применить на следующем собеседовании. Вебинар будет длиться всего час, так что плотность информации будет высокой. Регистрируйтесь!

Ещё я давно хотел сделать форму для вопросов и актуальных тем, чтобы у канала была более широкая повестка. Вот она: предложить тему для обсуждения.

Ответить подробно на большинство вопросов мне наверное не удастся, потому что вебинар короткий, но я обязательно коснусь каждого в постах на канале. Буду благодарен за ваши идеи и предложения!
Нашёл классный ресурс с “дорожными картами” для разработчиков: https://roadmap.sh/
Особенно полезно и интересно будет тем, кто только начинает или недавно начал, либо тем, кто меняет специализацию. Конечно, это не полная энциклопедия всех возможных навыков (кайф начинается, когда совмещаются специализации - например, backend и devops), но вам наверняка будет интересно сравнить свои знания с commmunity-driven эталоном.
Как разработчику успешно пройти собеседования в FAANG

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

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

📝 Делайте резюме под каждую позицию. Упоминайте только релевантный опыт, а для позиций уровня senior и выше описывайте не только свои достижения в разработке, но и в организации командной работы и найме, достижении бизнес-целей.

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

👩‍💻 Подготовьте связный рассказ о себе и своём опыте. Он точно пригодится на поведенческих интервью, а сокращённая версия с примерами успешных проектов и вашими пожеланиями к новой работе - для вводного рассказа о себе на каждой секции. Репетируйте вслух и с диктофоном.

🦾 Отведите несколько месяцев на подготовку к алгоритмическим задачам. Прорешайте не меньше 30-50 задач на Leetcode по разным темам, найдите или придумайте обобщённый алгоритм решения задач и придерживайтесь его. Старайтесь начинать писать код только когда алгоритм решения задачи известен, включая edge-кейсы и его сложность.

📣 Говорите во время решения задач. То, как вы размышляете, не менее важно, чем то, насколько быстро и верно вы находите решение задачи. Ведите диалог с собеседующим, чтобы получать постоянную обратную связь. Если вы не уверены, уточните, что правильно поняли задачу.

⚙️ На system design интервью обозначьте общую архитектуру решения и постарайтесь углубиться в область, в которой вы разбираетесь лучше всего. Ведите себя как техлид, уточняющий требования у заказчика, и двигайтесь от общего к частному. Держите в голове план решения задачи и следите за временем.

🤝 Для позиций высокого уровня ваши софт-скиллы важнее, чем умение писать код. Прокачивайте умение работать в команде - обсуждать, спорить, договариваться. Учитесь презентовать и продавать свои идеи, быть услышанным, принимать чужую точку зрения. Развивайте эмпатию, не поддавайтесь эмоциям и учитесь ладить с другими и собой.

🇬🇧 Учите английский язык. Вашего уровня будет достаточно для прохождения собеседований примерно тогда, когда вы сможете понимать на слух большую часть выступлений с профильных конференций и сможете убедительно рассказать о своих проектах. Продолжайте учиться - выразительность и точность никогда не будет лишней, особенно если вы не носитель языка.

💰 Собеседуйтесь в несколько компаний и старайтесь получить несколько оферов. Это поможет торговаться (в пределах рынка и вилки зарплат на данной позиции) и чувствовать себя спокойнее. Будьте открыты к предложениям рекрутеров, держите их в курсе процесса и сообщайте о получении других оферов.

🤯 Будьте готовы к отказам и не принимайте их слишком лично. Несмотря на стремление объективно оценить каждого кандидата, иногда процесс даёт сбой - и вам попадается собеседующий не в настроении или неудачная задача. Крупные компании придерживаются правила "лучше не нанять хорошего разработчика, чем нанять плохого", поэтому иногда отказывают даже лучшим.

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