❤️‍🔥Первое место на собеседованиях занимает вопрос "Можем ли мы перейти на ты?". Второе место - "Что можешь рассказать о себе?".

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

Возможно будет неожиданно, но у собеседующего вас человека может не быть вашего резюме! Рекрутёр не знает с чем вы работали, а задавать Веб-разработчику вопросы про перемножение матриц нет смысла, как и спрашивать DBA про модель OSI.👍

Воспринимайте этот вопрос так:

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

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

✏️ Даже если у вас нет опыта, составьте рассказ так, чтобы интервьюеру было легко определить вашу область знаний. Если же у вас есть хороший опыт, то полезно будет добавить и бизнес-ценность вашей работы.

Вот моё описание, с которого я начинаю собеседования, даже если я нахожусь в роли интервьюера:

У нас около 3 млн товаров, которые разделены на категории. У каждой категории есть категорийные менеджеры, их около 120 человек. Для категорийных менеджеров мы разрабатываем внутренний сервис для работы с товарами. У нас есть порядка 50 микросервисов, позволяющие управлять ценами, акциями и складскими остатками в магазинах по всей Росиии.

📣 Благодаря такому описанию, дальше интервьюеру будет понятно, в какую область разработки стоит погружаться в общении.

🦞 Эпоха C и C++ уходит?

Белый Дом призвал переходить на безопасные языки. В качестве альтернативы для небезопасных C и С++ предложили использовать Rust и даже Python!

Проблема у С и С++ в том, что около 70% уязвимостей связаны с работой с памятью (Microsoft, Chrome). Создатель C++, Бьёрн Страуструп, в очередной раз напомнил, что C++ - это не C. Также он отметил развитие языка с 1979 года. Ранее, в 2023 году он уже упоминал примерно тоже самое, когда Агенство Нац Безопасности США рекомендовало отказаться от языков C и C++.

Для меня, использование Rust в замену C и C++ кажется очевидным. А что с Python? Язык развивается, например в язык Mojo (в нём можно использовать эмодзи как расширение файла: main.🔥). Кстати, давал комментарии по этому языку для tproger. Уже вышла полная статья, с моим, и не только моим мнением, почему Mojo не заменит Python.

Пишите в комментарии, хотите ли пост про работу с памятью и почему нам в Python не страшны заявления США 🔽

🤔Привет! Я узнал, что в телеграмме есть другие каналы, и не все мои подписчики успевают посмотреть все мои посты.

Проверьте, что вы не пропустили посты в этом месяце:

💋Шпаргалка по методам списков в Python
💋Как объяснить модель OSI 7 летнему ребёнку?
💋Как я стажёров собесил
💋Маршрутизация: продолжение поста про модель OSI
💋Развитие медийности
💋3 МАРКЕРА ТОКСИЧНОСТИ
💋Квиз: что выведет код на картинке?
💋3 главных софт-скилла для программиста
💋Как я работаю над задачами
💋Как отвечать на первый по популярности вопрос на собесах
💋Эпоха C и C++ уходит?
💋Что вас ждёт на майские?

Хороших праздников! ⛺️

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

Прочитал «Подготовка к сложному интервью System Design» от автора Алекс Сюй. Считаю эту книгу обязательной к прочтению!

⭐ В 15 главах рассматриваются классические задачи на проектирование архитектуры различных компонентов или целых приложений. За прошедший год работы я сам реализовывал 4 задачи из представленных в книге!

В этом посте я описал классическую задачу, с которой вы столкнётесь в любой компании как Веб-разработчик. Если вам нужны ещё практические кейсы или интересно как создать с нуля Twitter(X), YouTube или даже Google Drive, то срочно читайте книгу Алекса Сюй 🔥

📚 Обновлённый список обязательных к прочтению книг:

🟢 До выхода на работу:
• Грокаем алгоритмы
• Карьера программиста

🟢После выхода на работу:
• Паттерны проектирования
• Подготовка к сложному интервью

🟢Чтобы поднять грейд:
• Книга с кабанчиком
• Погружение в рефакторинг

Agile 🔤🔤 Scrum

Как думаете, какой подход лучше: Agile или Scrum? Вопрос странный, ведь Agile - это философия, а Scrum - инструмент.

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

🛠 Scrum же - это инструмент для соблюдения принципов Agile. Работая по Scrum, мы одновременно работаем и по Agile.

📌 Классическая структура scrum:

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

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

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

Поздравляю, теперь вы не просто братки, а целая Agile-бригада 😎

⭕️ Пишите на Go и засматриваетесь на другие языки, однако Rust слишком сложный? Есть решение!

Язык borgo сочетает в себе простоту Go и безопасность Rust! Язык свежий, репозиторию чуть больше года, но уже имеет почти 3 тысячи звёзд!

Из интересного:
✔️ Полная поддержка библиотек Go
✔️ Замена для nil из Rust
✔️ Удобная обработка результата работы функции
✔️ Обработка ошибок всего одним оператором
✔️ Написан на языке Rust

И хотя обновлений нет уже 8 месяцев, я буду следить за этим проектом ✔️

🤙 Традиционная пятничная загадка...

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

Как думаете: какое минимально количество банок надо открыть, чтобы разобраться? 🤔

📌 Как писать хороший код? Правило 7 элементов

Вы наверняка слышали уже такие утверждения:

🔵В функции должно быть не больше 5 аргументов.
🔵Сохраняйте код простым.
🔵Одна функция - одна задача.
🔵Не делайте более трёх уровней вложенности.
🔵🔵🔵

Задумывались ли вы, почему так и зачем нам соблюдать эти правила? Джордж Миллер, в 1956 году провёл интересный эксперимент. Работая в лаборатории Bell, он изучал память операторов. Он обнаружил, что человек способен удерживать в памяти одновременно всего 7 ± 2 элемента. Это могут быть как числа, так и буквы или даже слова.

⏩На работе вы будете работать не один, а в команде. Другие люди должны понимать ваш код. Чтобы сделать понимание кода проще, следуйте правилу, что в одном контексте должно быть не более 7 отдельных элементов.

➡️ Пользовательские истории (User Story) - отличный способ рассказать о своём опыте!

В разработке есть такое понятие, как User Story. Оно описывает проблемы или желания клиентов простой формулой:

Я как (...), хочу (...), чтобы (...).

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

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

Расскажите о своём опыте работы, используя пользовательскую историю:

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

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

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

Музыкальные инструменты - это устройство ввода, как клавиатура или мышь у компьютера. Колонки (а иногда и само устройство) - это устройство вывода.

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

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

🎵 А у вас музыка вызывает чувства? Скиньте в комментарий трек, который вызывает больше всего эмоций! Мой уже там.

3️⃣ вещи, про которые вам стоит помнить

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

1️⃣ Тесты
Я совершенно ничего не изучал про тестирование, и на первой работе не было тестов совсем. Сейчас, в крупном проекте, тесты обязательны и приходится тратить дополнительное время, чтобы написать их правильно.

2️⃣ Контейнеризация
Когда я писал для себя, то всегда запускал проекты "как есть", даже без виртуального окружения. В нормальном проекте такой подход приведёт к плачевным результам!

3️⃣ Документация
В моём коде почти никогда нет комментариев, и я редко пишу документацию. В командной разработке эти элементы необходимы.