Решаем алгоритмические задачи — 2 ✔

Давайте попробуем задачку посложнее.

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

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

Каково максимальное количество друзей, которые не будут грустить этим вечером?

Если разберётесь — оставляйте ответ в комментариях!

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

15 февраля в 14:00 в этом канале мы проведём прямой эфир, где разберёмся, в чём польза алгоритмов и решим вместе задачи, которые мы публиковали в канале, а ещё обсудим:

✨ с чего начать изучение новичку;
✨ стоит ли учить алгоритмы с помощью паттернов;
✨ к чему быть готовым на алгоритмической секции собеседования.

Гость эфира: Фёдор Мушенок — наставник в Практикуме в направлении анализа данных.

Подключиться к эфиру можно по ссылке.

Если у вас есть вопросы, обязательно пишите их в комментарии и приходите на эфир, мы ответим на них ✨

В 14:00 подключайтесь к эфиру «Алгоритмы на собеседованиях: нужны ли они?» в этом канале и задавайте ваши вопросы в комментариях ✨

Чем заняться на долгих выходных⭐

Послушать «Что дальше?» — подкаст о том, как перепридумать себя.

Из маркетолога в музыканты, из журналистки в тренеры AI — наши герои превращают хобби в источник дохода и осваивают профессии, которых не было ещё пару лет назад.

Вместе со студией «Норм» рассказываем, как совершить карьерный поворот в любом возрасте и с любым опытом: сколько это стоит, какие есть подводные камни, где искать вдохновение и силы.

🎧Слушать подкаст

Культура работы с Git: код-ревью и пуллреквесты

Продолжаем серию статей «Культура работы с Git» от Юлии Волковой. В предыдущих постах рассказали про именование веток и о правильных сообщениях к коммитам.

Код-ревью — один из важнейших аспектов работы с Git. Это не только про код, это ещё и про взаимодействие внутри команды. Речь не только о том, чтобы отлавливать баги или спорить о стайлгайдах.

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

Код-ревью помогает:
🎯быть в курсе контекста по разным задачам в проекте;
🎯совместно принимать решения: от стайлгайдов и выбора библиотек до архитектуры;
🎯улучшать качество кода и вырабатывать более оптимальные решения;
🎯ещё на этапе разработки нового функционала оценить масштабируемость, поддерживаемость решения, учесть возможные риски и corner cases;
🎯обратить внимание на необходимость переиспользования каких-то компонентов или утилит;
🎯быстрее знакомить новых сотрудников с проектом;
🎯обучаться и улучшать свои навыки - как хард-скиллы, так и софт-скиллы.

Как видите, код-ревью — это ещё и про коммуникацию, общение и взаимодействие внутри команды. А ещё про ценности: например, обмен знаниями, обучение, взаимопомощь, стремление сделать лучше.

🔖Посмотрите небольшой доклад «Код-ревью с уважением» Ангелины Купцовой с митапа SPB Frontend, чтобы узнать о теме больше. И советую почитать статью «Что такое код-ревью» от Доки.

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

Культура работы с Git: пуллреквест — о чём спросить команду ❓

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

🎯В какую базовую ветку (base branch) делать пуллреквест? Уточните, потому что далеко не всегда это main (master). Зависит от того, как построен процесс работы с ветками в вашей команде: это может быть, например, ветка develop или release.
Про подходы к организации веток я подготовлю отдельный пост.

🎯Кого ставить в ревьюеры? Иногда это почти вся команда, а иногда конкретный человек, например, тим- или техлид.

🎯Сколько аппрувов получить, прежде чем замержить ветку? Стоит спросить, потому что не всегда это ограничение автоматизировано в репозитории.

🎯Есть ли какие-то соглашения по именованию веток и коммитов? О цели и возможной пользе разных подходов мы подробно говорили ранее в этом посте.

🎯Нужно ли сквошить (squash) коммиты? Некоторые команды в конце работы над пуллреквестом обязательно объединяют все изменения в один коммит — так проще ориентироваться в истории.

🎯Что использовать — merge или rebase? Одни команды не накладывают ограничений, другие выбирают тот или иной способ. У каждого подхода есть плюсы и минусы, подробнее об этом рассказывают в статье на Хабре.
Если в вашей команде есть соглашение использовать именно git rebase, то рекомендую статью Как ребейзить ветку и не думать ни о чём, чтобы лучше разобраться в алгоритме действий.

⤵️ Впереди вторая часть и ещё несколько важных вопросов.

Культура работы с Git: пуллреквест — о чём спросить команду, часть 2 ❓

Спросите об этом заранее — это даст вам максимум контекста и поможет быстрее освоиться в команде и процессах.

🎯Какая автоматизация настроена в ветке на разные события (новый коммит, мерж изменений)?
Эту информацию вы можете получить и сами, например, детальнее рассмотрев блок Checks в интерфейсе GitHub (аналогичные есть и других сервисов, например у GitLab или Bitbucket), либо заглянув в файлы автоматизации, если они хранятся в вашем репозитории. Например, это будет файл с названием .gitlab-ci.yaml, либо yaml файлы в директории .github — читайте подробнее по ссылкам.

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

🎯Как и куда выкладываются изменения, когда ветка замержена, на какое окружение?

Иногда публикация изменений может быть автоматизирована. Когда вы пушите новый коммит или мержите ветку, на какое-то окружение (например, dev или staging) выкладываются изменения, чтобы уйти на проверку QA инженеру. Уточните, нужно ли нажимать Deploy вручную или выполнить какие-то команды, чтобы внести изменения.

🔖Сохраняйте себе, пишите вопросы и делитесь мыслями в комментариях. Автор поста Юлия Волкова обязательно придёт их почитать и ответить!

#дайджест февраля 📱

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

Месяц получился почти тематическим: на Хабре мы рассказывали о требованиях к начинающим специалистам, а в телеграм-канале много говорили про Git.

🕚Джуниоры-тестировщики в 2024 году: какие нужны скилы и как проходит процесс найма — рассказываем, как обстоят дела в найме начинающих QA-инженеров: важны навыки программирования, какие ошибки встречаются при трудоустройстве и почему софтскилы могут быть важнее хардов.

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

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

🕚Что ждёт мобильную разработку в 2024 году — рассказываем о трендах мобильной разработки и пытаемся предсказать, как будет (и будет ли) меняться сфера в этом году.

🕚Git: вопросы для самопроверки — помогаем разобраться, знаете ли вы основные команды, практики, которые вокруг них существуют, и алгоритмы решения типовых ситуаций.

🕚Культура работы с Git: именование веток — рассказываем, каким рекомендациям следовать в именовании веток, чтобы команде было приятно и легко работать.

🕚Культура работы с Git: код-ревью и пуллреквесты — объясняем пользу код-ревью и делимся списком вопросов о работе с пуллреквестами, которые стоит задать новой команде.

Пусть начало весны станет поводом для позитивных перемен! Начинать с понедельника или первого числа — это не только клише, но и рабочая стратегия 🩷

Знакомимся! Олег — выпускник курса «Python-разработчик» в Практикуме. Сейчас он руководит разработкой в beeline cloud и сам набирает сотрудников в команду.

Он расскажет, как нашёл первую работу в IT после курсов, а также поделится:
🔸какие требования он предъявляет к соискателям,
🔸на обращает внимание при проверке тестовых заданий,
🔸как подготовиться к собеседованию,
🔸как повысить шансы на мэтч с интервьюером.

Слово Олегу!

Привет! Меня зовут Олег Завитаев, я руковожу разработкой в beeline cloud — облачном провайдере для b2b.

Моя команда занимается всей внутрянкой, которая сопровождает путь клиента, — от первого звонка до выставления счёта.

В IT я попал не сразу. Получил экономическое образование и не придумал ничего лучше, чем найти работу по профессии 😅 Семь лет строил карьеру, но в конце концов разочаровался и выгорел.

Я начал искать себя на Stepik и Coursera, прошёл первые курсы по вебу. В Практикуме изучил бесплатные части сразу нескольких курсов и остановился на Python'е.


Учиться было весело: я врывался во все студенческие активности и проекты, помогал сокурсникам в чате. Параллельно потреблял про Python всё, до чего мог дотянуться.

Спойлер: это помогло на интервью 😉

После диплома получил оффер с первого клика — редкая удача.

Что помогло? Вместо стандартного «Здрасьте, хочу у вас работать» в 4 утра написал в телеграм лиду, приложил ссылку на pythonanywhere.

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

После этого я весь день готовился к собеседованию по первой ссылке из поисковика — «100 вопросов по питону на вакансию джуна».

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

В сентябре 2022 года стал лидом и теперь сам собеседую разработчиков к себе в команду.

⬇️На что лиды обращают внимание в тестовых и на собеседовании — расскажу в следующих постах.