Как пройти техническое собеседование в Big Tech? ❔

Нашел статью инженера Datadog Lambros Petrou по подготовке к собеседованиям. Кто не знает, Datadog это сервис мониторинга, чем-то похожа на Grafana. Lambros Petrou успел поработать в Meta и Amazon, и решил свои опыт подготовки вынести в отдельную статью.

Приведу краткую выжимку, советую почитать всю статью.

Интервью процесс 🎲
Большинство процессов интервью в MAANG подобные компании похожи между собой. Есть небольшие различия в подходе и сложности задач.

Процесс состоит из следующих этапов:
2-3 секции с написанием кода
1-2 секции с проектированием систем, обычно для инженеров уровнем Senior и выше
1-2 секции поведенческих вопросов

Обычно каждая встреча занимает 45 минут, в некоторых компаниях на одно собеседование выделяется час.

Coding 👩‍💻
Именно этот тип интервью раздражает многих разработчиков. Если только вы не работаете в сфере, где нужно решать алгоритмические задачи изо дня в день.

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

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

Практикуйтесь ежедневно или несколько раз в неделю в течение 2–5 недель в зависимости от ваших навыков.

System Design 🖌
Подготовке к этому типу собеседований сложнее, чем к алгоритмам.

Что рекоммендует автор?
1. Изучать стэк технологий вашей компании. Интересоваться у коллег архитектурными решениями. В частности автор многое понял, просто разбираясь как устроен AWS.
2. Читать инженерные блоги BigTech компаний
- https://aws.amazon.com/builders-library/
- https://engineering.fb.com/
- https://blog.cloudflare.com/
3. Прочитать кабанчика https://www.amazon.co.uk/Designing-Data-Intensive-Applications-Reliable-Maintainable/dp/B08VKMNDBN/
4. Просмотреть видео разбора интервью https://www.youtube.com/playlist?list=PLeNDQKdre0oEzLXh8Ksl2Ocoeltx0gD8-
5. Прочитать https://www.amazon.co.uk/gp/product/1838430210

Еще ресурсы для подготовки
- https://blog.pragmaticengineer.com/preparing-for-the-systems-design-and-coding-interviews/
- https://www.youtube.com/playlist?list=PLeKd45zvjcDFUEv_ohr_HdUFe97RItdiB
- https://www.hiredintech.com/classrooms/system-design/lesson/52
- https://github.com/shashank88/system_design
- https://github.com/checkcheckzz/system-design-interview

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

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

Готовьтесь не только к приятным вопросам, но к негативным тоже. Как справились с конфликтом работе? Как завалили проект? Каких навыков вы хотели бы улучшить?

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

Посмотрите видео https://www.youtube.com/watch?v=PJKYqLP6MRE

➡️Ссылка на оригинальную статью
https://www.lambrospetrou.com/articles/big-tech-software-interviews/

Google сокращает персонал рекрутинга 🍴

Google увольняет сотни сотрудников в своей глобальной рекрутинговой организации. Это связно с масштабными планами компании сократить объем найма в ближайшие кварталы.

«Мы продолжаем инвестировать в лучшие инженерные и технические умы, одновременно значительно замедляя темпы найма персонала», — написал Кортни Менчини, представитель Google. «Вместе с этим снизился объем запросов к нашим рекрутерам. Чтобы продолжить нашу важную работу по обеспечению эффективности нашей работы, мы приняли трудное решение сократить размер нашей команды по подбору персонала».

Напомню, что в январе родительская компания Alphabet анонсировала планы уволить 12 000 сотрудников, порядка 6% персонала. Несмотря на сокращения, доход компании за второй квартал этого года увеличился на 7%.

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

⬅️ Ссылка на статью
https://www.cnbc.com/2023/09/13/google-is-cutting-hundreds-of-jobs-in-its-recruiting-organization.html

Немного про английский 🌴

Я всегда думал, что мой английский на хорошем уровне. За моей спиной было обучение в КТЛе, СДУ и Назарбаевском университете. Я сдавал IELTS, плюс проводил собеседование и выступал в Яндексе на английском. Я спокойно читал документации, смотрел доклады и лекции зарубежных спикеров. Иногда даже читал художественные книги на английском.

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

Я считаю, что reading и listening у разработчиков всегда на достаточно хорошем уровне. Поэтому следующие советы больше затрагивают speaking и writing аспекты английского.

IELTS

IELTS не является показателем знания английского, как и ЕНТ/ЕГЭ реальными знаниями по предметам. Но подготовка и сдача этого экзамена помогает закрыть все базовые пробелы.

Вообще я считаю IELTS идеальной точкой старта, если не знаете как улучшить свой английский и/или планируете в скором времени уехать за границу.

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

Github

Я в свое время участвовал в Google Summer of Code. Я был и студентом и ментором в этой программе. Суть в том, что студенты отбираются на опенсорс проект и в течении лета реализуют небольшой проект.

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

Я думаю в целом участие в open source проектах, баг репорты, фича реквесты и код ревью помогают прокачать writing.

Native speaker

Моя супруга сейчас готовится к сдаче IELTS и у нее был страх разговаривать на английском. Мы искали репетитора, чтобы преодолеть этот страх. Для меня было откровением узнать, что можно найти репетитора не только на площадках типа как skyeng.

В каждой стране есть студенты, которые хотят закрыть свой студенческий долг, есть обычные работники, которые ищут дополнительный заработок. Среди можно найти человека, нативного спикера, который за денежку готов с вами разговаривать о чем угодно. Их можно найти простым поиском в гугл, например "Sydney english tutor" и дальше уже определиться по цене и по времени.

К примеру супруга платит 40 AUD за час общения с практикующим хирургом 😐. Можно обсуждать, что угодно, главная задача - перебороть страх общения. Основное отличие от руссоговорящего репетитора - невозможность переключиться на русский, начинаешь осознавать, что худо бедно, но собеседник понимает тебя. Плюс перенимаешь некоторые фразочки, например австралийцы не говорят «afternoon», а используют сокращение «arvo».

❓ А что вам помогает улучшить английский?

7 навыков топ инженеров 🔴

Как топовые инженеры перформят на высоком уровне? Выжимка из статьи "7 simple habits of the top 1% of engineers".

Используйте код стайл

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

Эта одна из причин, почему Google и Meta могут релизить большие куски кода быстро, при этом исходники остаются читаемыми. Если в вашей команде нет инструмента для проверки стандартов кода, стоит инвестировать время и силы во внедрении такового.
- Google style guide https://google.github.io/styleguide/
- Meta style guide for open source project https://github.com/facebook/hhvm/blob/master/hphp/doc/coding-conventions.md

Пишите эстетичный, простой код

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

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

Избегайте сюрпризов

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

Тесты также дают уверенность в новых изменениях.
- Unit тесты - для классов и методов
- Интеграционные тесты - для взаимодействия между компонентами
- End-to-end тесты - для проверки системы с позиции пользователя

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

Общайтесь чаще

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

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

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

Будьте непредвзятыми по отношению к коду

Через 20 лет большинство вашего кода будет или переписано или не будет использоваться или станет тех долгом.

Код несовершенен. Никому по сути не важен сам код, а важна польза которую он несет.

Не завязывайтесь на коде и не воспринимайте фидбек по коду, как что-то личное.

Пишите код быстро…и медленно

Лучшие инженеры, которые завершают проект в сжатые срокие…пишут код медленно. Звучит противоречиво?

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

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

Код для человека, а не для компьютера

«Каждый дурак может написать код, который поймет компьютер. Хорошие программисты пишут код, который смогут понять люди» - Мартин Фоулер

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

Код - для ваших пользователей, будь то ребенок в смартфоне или разработчик, который вызывает ваш API.

Не стоит слепо следовать правилам

Не всегда получиться следовать гайдам, в том числе и в этой статье.

Даже если вам придется отойти от правил при написании кода, не забудьте задокументировать причину. Иначе возможно кто-то в будущем попробует исправить это, потратит 20 часов на кодинг и только потом выяснит истинную причину костыля.

⬅️ Ссылка на оригинальную статью
https://engineercodex.substack.com/p/7-simple-habits-of-the-top-1-of-engineers

Staff Engineer в Мета с зарплатой $800K ⬆️

Вышла статья инженера Rahul Pandey про то, как он за 4 года вырос из senior до staff инженера (E5 to E6) в Meta и его совокупный доход за последний год достиг более $800K.

Автор в статье делиться опытом каждого года, прочитайте на досуге. Я лишь скопирую самое интересное.

● Самый большой скачок в зарплате произошел при переходе от Senior до Staff.

● Важно первый год посвятить изучению кода и проекта, даже если очень тяжело. Автор работал 50+ часов в неделю и это дало свои результаты, в следующем году он уже брал тимлидские обязанности.

● Чтобы получить повышение - недостаточно один-два раза на ревью показать результат “выше ожиданий”. Нужно постоянно показывать высокую эффективность, на это может потребоваться время.

● Если планируете расти внутри компании, закладывайте как минимум 2 года. Поэтому важно выбирать правильную компанию, в которой можно несколько лет посвятить своей карьере.

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

● Нужно понимать как работают акции и опционы. Слишком много разработчиков закцикливаются только на зарплате. Автор закрыл 2021 год с доходом в 800 тысяч долларов в Meta, и почти 600 тысяч долларов из них составили акции компании.

⬅️Ссылка на оригинальную статью.
https://www.jointaro.com/blog/how-i-became-an-800k-engineer

Kudos 👍

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

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

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

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

Недавно слушал подкаст основателя https://karmabot.chat/ и одна из озвученных мыслей была, что не стоит недооценивать силу благодарности. Признание - одна из причин, почему сотрудник захочет продолжить работу в компании в будущем. Мы не только выбираем продукт и зарплату, нам также важен коллектив и отношения в команде.

Конечно не стоит этим перебарщивать. Иначе “благодарность” потеряет свою ценность.

🦆 Минутка добра. Попробуйте в течении следующей недели поблагодарить своего коллегу, найдите причину для этого, даже не самую вескую. Я уверен, что это зарядит его энергией как минимум на ближайшие пару спринтов.

Логи или трейсы? 🚂

Нашел пищу для размышлений, идея следующей статьи заставила меня призадуматься, не преуменьшаем ли мы роль трейсинга.

Обычно, когда случается проблема, мы первым делом смотрим логи. Логи являются основным источником информации, а остальные инструменты только дополняют их.

Но не все согласны с такой позицией, как и автор данной статьи. Приведу выжимку из статьи, чем же трейсы лучше логов.

Смешанные вывод

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

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

Взаимосвязи

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

Трейсы в свою очередь поддерживать родитель-ребенок зависимость. Родительский трейс гарантировано будет раньше дочернего. В интерфейсе удобно видеть родительский трейс и последовательные дочерние трейсы.

Таймер

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

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

Запросы

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

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

ИМХО

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

⬅️ Ссылка на оригинальная статью
https://andydote.co.uk/2023/09/19/tracing-is-better

Каналу один год! 👉

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

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

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

Краткая статистика по каналу:
● Более 200 публикаций
● В среднем каждую публикацию читает 1000 человек
● Среди подписчиков 75% муж и 25 жен пола

Амбиции растут соразмерно количеству читающих людей. Одна из целей - собрать все знания и весь опыт в одном месте, и запустить платформу для подготовки к тех собесам. Посмотрим как пойдет, вообщем stay tuned.

Еще раз спасибо, что читаете канал, мои братья и сестры по клавиатуре

Сильно не отмечайте сегодня 😅

Заруинил карьеру ❌

Мне один коллега как-то поведал историю, которая произошла в Сиднее. Не буду афишировать названия компаний, просто расскажу суть.

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

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

❓ Бывали ли у вас ситуации, когда кто-то вмешивался и как-то нехорошо влиял на вашу карьеру?

Душный пост про интерпрайз ☢️

Чем старше становлюсь, тем чаще приходит ощущение, что в IT все двигаются на ощупь.

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

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

Да, иногда получается. Но никто точно не знает, будет ли фунционал успешным или неуспешным. А самое интересное, что у интерпрайза короткая память. Через полгода никто и не вспомнит, как менеджер потратил силы команды и ресурсы компании в пустоту.

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

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

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

🚀 Алгоритм Маска

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

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

Вот сам алгоритм, он кстати применим и к разработке:

Подвергайте все сомнению

Каждое требование, каждая задача должно иметь конкретное имя. Всегда должен быть ответственный человек, не принимайте коллективную подпись «департамент HR» или «отдел безопасности».

Избавляйтесь от ненужного

Удаляйте ненужные процессы, все можно вернуть обратно. Если после удаления процессов, хотя бы 10% не вернулось обратно, значит слишком мало удалили.

Упрощяйте и оптимизируйте

Частая ошибка - это оптимизировать процесс, которые не должен существовать вовсе.

Ускоряйте цикл разработки

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

Автоматизируйте

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

➡️ Ссылка на оригинальную статью:
https://world.hey.com/dhh/the-musk-algorithm-977bf312

━━━

🤔 Мое мнение

За каждым процессом, за каждым проектом стоят обычные люди.

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

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

❓Хотели бы вы работать на Илона Маска?
- Если да, поставьте 👍
- Если нет 👎

🇦🇺FYI

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

Примерно такие сообщения я периодически получаю: "Hey Tim, wdyt about implementing xxx feature, afaik you are responsisble for yyy service".

Сейчас уже нахватался опыта и теперь сам их активно использую. Составил список самых часто используемых акронимов из моей повседневной деятельности.

TIA - thanks in advance - заранее благодарю
FYI - for you information - к твоему сведению
AFAIK - as far as I know - насколько мне известно
AFAIU - as far as I understand - насколько я понимаю
LGTM - looks good to me - выглядит ок для меня
SGTM - sounds good to me - звучит ок для меня
NIT - needs Improvement or nitpick - маленькое замечание, незначительная поправка
IDK - I don’t know - я не знаю
WDYT - what do you think - как ты думаешь…

✔️ Сохраните пост на будущее, чтобы влиться в команду как родной.

❓Загадка, как по вашему расшифровывается акроним YAGNI?

🎁Mock интервью в обмен на рассказ

Если вы сейчас в процессе интервью в Big Tech, то прочитайте до конца, для вас есть предложение.

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

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

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

Вообщем будем вместе читать успешный успех и учиться на ошибках.

✔️ Если хотите рассказать про свой опыт, напишите мне в личку. При желании оформим анонимно.

✔️ Перешлите друзьям и коллегам, которые сейчас активно готовятся.

✔️ Поддержите пост ⚡, если интересна такая рубрика и стоит ее развивать.