Куда бизнес смотрит?

— Посоветуй что-нибудь почитать для роста.
— Посмотри, что нужно будет завтра бизнесу.

Сейчас всё чаще бизнес смотрит, а кто-то уже двигается из клиентоориентированности в клиентоцентричность. Что это такое?

Клиентоориентированность — это как писать код, который решает текущие задачи пользователя.

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

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

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

Что стоит изучить: Apache Hadoop, Apache Spark, работа с SQL (PostgreSQL, MySQL) и NoSQL базами данных (MongoDB, Redis). Инструменты для обработки потоков данных, такие как Apache Kafka и RabbitMQ.

2. Машинное обучение и анализ данных
Персонализация и предсказательная аналитика играют большую роль в клиентоцентричной стратегии.

Что стоит изучить:
- библиотеки Python, таких, как TensorFlow, PyTorch и scikit-learn.
- методов анализа данных и использования инструментов, таких как Pandas и NumPy.
- библиотеки Matplotlib, Seaborn и Plotly для создания графиков и диаграмм.

3. Постоянное улучшение и инновации
Клиентоцентричные компании постоянно ищут способы улучшения.

Что стоит изучить: Использование методов автоматизированного тестирования (pytest, unittest) и мониторинга (Prometheus, Grafana).

4. Безопасность. Клиентоцентричные системы должны быть защищенными, чтобы клиенты могли доверять обработке своих данных.

Что стоит изучить:
- Понимание концепций безопасности, таких как OWASP Top 10.
- Использование инструментов и библиотек для шифрования данных (TLS/SSL, криптографические библиотеки).
- Реализация систем аутентификации и авторизации (OAuth, JWT).

Подписывайся👇
ЛСА | Лайфстайл айтишника [python]

Работать дома круто, но…

— А почему сегодня до 17 работаете?
— Ты что забыл? У продакта день рождения, идем отмечать!

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

Недостаток неформального общения с коллегами.
Кто бы что ни говорил, но общение с коллегами — это крайне важно. Регулярные встречи в онлайне, где вы обсуждаете текущие задачи и точки роста, — это хорошо, но совсем другое — сходить вместе за кофе/в курилку/в бар после работы. Имея регулярный живой small-talk с коллегами, шанс выстроить дружеские и открытые отношения намного выше, чем через экраны мониторов. А отношения в перспективе могут повлиять на карьерный рост.

Решение: приезжайте хотя бы пару раз в месяц в офис и на тусовки.

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

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

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

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

Подписывайся👇
ЛСА | Лайфстайл айтишника [python]

Чем отличается стажер-джун от джун+ в плане опыта?

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

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

- Разрабатывался одним разработчиком.
- Затрачено не больше двух месяцев.
- Количество кода не больше 10к строк.

Теперь рассмотрим критерии проектов, на которых можно вырасти в опыте до джун+:

- Над проектом работают три и более backend-разработчика.
- Проекту больше полугода.
- В проекте участвовали/участвуют senior-разработчики.
- Количество кода от 10k строк.

Что же получает разработчик во втором типе проектов через какое-то время:

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

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

Репост знакомым джунам приветствуется😉
ЛСА | Лайфстайл айтишника [python]

Я стажер, а вы должны меня учить

— Я не понимаю, почему функция ничего не возвращает!
— Это прикол? У тебя же нет return.

…пишет return после функции 🥲

ВНИМАНИЕ: это реальный кейс.

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

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

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

Как это могло произойти? Классные ребята очередями стоят и ждут ответов от HR, пока кто-то с нулевыми знаниями проходит эту игру.

ЛСА | Лайфстайл айтишника [python]

Женщина с резюме мужчины.

— Я думала в резюме указать, что я мужчина, чтобы приглашений было больше.
— Думаешь, это так работает?

В ИТ сексизма нет. По крайней мере, в наших командах.
Но мои субъективные цифры не радужные: за последние 3–5 лет девушек на тех. собеседованиях в нашу команду было лишь 5–10%, и из-за слабой подготовки никто не проходил.

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

Что думаете? 🤔

P. S.: Парни, никто не хочет попробовать поменять в своем резюме пол и проверить гипотезу?

ЛСА | Лайфстайл айтишника [python]

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

— У вас в резюме написано, что вы участвовали в open source, это правда?
— Да, контрибьютил в две либы, сейчас пришлю ссылки на issues.

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

Когда работодатель увидит в вашем резюме опыт участия в open source проектах, то он подумает, что вы:

1. Реально что-то знаете;
2. Активный и инициативный;
3. Можете разобраться в legacy проектах;
4. Умеете работать с GitHub;
5. Способны найти ошибки в чужом коде и исправить их;
6. Готовы объяснять свое решение и дорабатывать его после code review;
7. Способны самостоятельно решать задачи;
8. Умеете взаимодействовать с другими разработчиками и доводить задачи до конца;
9. Осознаннее 99% соискателей;
10. Тот, с кем точно стоит пообщаться.

У нас есть одна идея, связанная с open source, которая точно взорвёт ваше резюме. А пока мы всё подготавливаем, порекомендую вам сервис для закрытия первых тасок в open source продуктах — https://goodfirstissue.dev

ЛСА | Лайфстайл айтишника [python]

Жду того, кто пройдет собеседование в Сбер.

— Почему такие слабые кандидаты?
— Видимо, сильные летом отдыхают.

Я ищу к себе в команду крепкого мидла и вот что часто вижу:

1. Поверхностные знания инструментов, которые кандидат указывает в своем опыте.
Если вы указали Kafka в резюме, то будьте готовы разговаривать про нее глубже, чем написано на get started.
2. Страх алгоритмов.
Мы честно даем легкие задачки по алгоритмам. Последние разы была типовая задача на два указателя, но кандидаты начинают волноваться и забывать, как думать. А мы это и проверяем.
3. Отсутствие уточняющих вопросов по задаче на проектирование сервиса.
— При нажатии на кнопку в интерфейсе мы должны формировать тяжелый отчет и отправлять клиенту на почту. Как будем решать задачу?
Здесь мы проверяем, как человек думает, а не ждем быстрый и единственно правильный ответ.
4. Софты.

Вакансия в мою команду Сбера:
https://hh.ru/vacancy/102375567?from=share_ios

Для обхода HR-скрининга сразу пишите мне @nestnestnest в формате:
1. Самое ценное ваше (не команды) достижение.
2. Ссылка на резюме.
3. Почему хотели бы работать в нашей команде.

Репост приветствуется.

ЛСА | Лайфстайл айтишника [python]

Ох уж эта капча…

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

Чтобы спарсить самый популярный в РФ сервис по поиску работы, не забудьте использовать прокси и часто менять IP. Это первое, что хочется сказать вам.

А ещё мы собрали для вас 60 наиболее востребованных навыков, которые хотят видеть от python-разработчиков работодатели в 2024 году.

Мы очень надеемся, что те 15 часов, которые мы потратили на написание кода парсера, чистку данных и приведение их в удобный формат, не прошли даром.
И те, кто сейчас задаются вопросом:
«А что я должен освоить, чтобы быть востребованным разработчиком?», скажут нам спасибо. А мы будем искренне рады за то, что помогли вам.

Получить документ с информацией о 60 ключевых навыков, которые ждут компании от middle python-разработчиков, можно в нашем боте:
https://t.me/developers_lifestyle_bot?start=skill_60

ЛСА | Лайфстайл айтишника [python]

20 новых слотов на диагностику

— У меня в окружении нет опытных разрабов. Потихоньку разберусь сам.
— Записывайся к нам на диагностику.

Неадекватные руководители, слабые техлиды, отсутствие команды, синдром самозванца и отличницы, слабые софты, доход ниже рынка.

Такие проблемы озвучили 10 участников канала на one-to-one встречах с нами. Об этих историях никто не напишет на лендингах, потому что они живые и настоящие.

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

Поэтому выделили еще 20 бесплатных слотов на диагностику.
Записаться тут:
https://python.forkway.io/diagnostic/?utm_source=telegram

ЛСА | Лайфстайл айтишника [python]

Как формируется костяк команды

— Во сколько релизим?
— В 10 утра. У нас осталось 4 часа.

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

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

Но были и те, кто наотрез отказывался работать выше нормы.
— Какая мотивация работать, если за это никто не заплатит?
— Я свои задачи закрыл, мне доделывать ничего не надо.

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

Ответственность за результат и вовлеченность = карьерный и личностный рост.

А вы встречали рассвет за написанием кода?

ЛСА | Лайфстайл айтишника [python]

Софт и хард скиллы, что нужно для роста зарплаты разработчика

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

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

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

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

3. Управление временем и задачами: про навык адекватно оценивать задачу, правильно расставлять приоритеты и эффективно управлять временем, часто не могут даже senior разработчики. А ведь это помогает завершать задачи в срок, что положительно сказывается на общей производительности команды и компании.

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

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

ЛСА | Лайфстайл айтишника [python]

Observability: инструменты и тренды

— Какие инструменты ты используешь для мониторинга системы?
— Обычно Prometheus для метрик и ELK для логов, а ты?

Prometheus — метрики, ELK — логи, Jaeger — трассировки. OpenTelemetry становится стандартом для объединения метрик, логов и трассировок. Не забываем и про Sentry — инструмент для отслеживания ошибок в приложениях.

Для понимания актуальных трендов в observability смотрите свежие обзоры, такие как «State of DevOps».

* На 29 странице отчёта State Of DevOps Russia 2024 расписаны популярные инструменты Observability в российских компаниях.
* Также стоит посмотреть на список решений, предоставленных CNCF https://landscape.cncf.io/guide#observability-and-analysis--observability.

Интересно ли узнать про практики сбора метрик и как начать реагировать на проблемы заранее, не дожидаясь, когда придут пользователи? Сталкивались ли вы с ситуациями, когда алёрты просто пропускались? Про что вам хотелось бы узнать подробнее?

ЛСА | Лайфстайл айтишника

Кейс: двойная оплата при плохом интернете

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

После пары быстрых фриланс правок в коде появились следующие конструкции:
1. (На фронте) Блокировка кнопки после нажатия: предотвращает повторные клики, но мешает повторить попытку при сбое.
2. (На беке) Отслеживание времени: игнорирование запросов, поступающих в короткий интервал, но это ненадежно при легитимных повторных попытках.

Как думаете, как можно было бы ещё закостылить решение?

Позже в комментариях напишу, как в итоге решили проблему.

ЛСА | Лайфстайл айтишника

Идемпотентность — любимый вопрос на собеседованиях

В продолжение вчерашнего кейса, как в итоге решили проблему:

Когда клиент нажимает "Оплатить", он отправляет уникальный код (например, ABC123 или UUID) вместе с запросом на сервер.

1. Первый запрос: Сервер видит новый код ABC123, выполняет оплату, сохраняет результат вместе с кодом.
2. Повторный запрос: Сервер видит тот же код ABC123, возвращает сохраненный результат, не проводя оплату повторно.

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

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

ЛСА | Лайфстайл айтишника

Секция system design

Хотите прокачать свой навык прохождения system design или посмотреть, как это делают другие? Тогда читаем дальше😉

Если вы будете проходить собеседование на позицию senior dev и выше в какую-нибудь BigTech компанию, то с большой вероятностью у вас будет секция system design.

Что такое system design? Это процесс проектирования системы, который включает в себя анализ требований, определение компонентов, их взаимодействие и выбор технологий для реализации. Саму секцию можно разделить на несколько этапов: сбор и анализ требований, разработка высокоуровневой архитектуры, детализация компонентов и взаимодействий, а также оценка рисков и возможностей масштабирования.

Проходили подобные секции?
Сегодня предлагаю потренировать свой скилл или даже научиться в прохождении данного части собеседования. Но формат будет у нас нестандартный, и вот как предлагаю провести его:
1. В 15:00 я выложу задачу отдельным постом.
2. В комментариях к посту я буду модерировать процесс и выступать стейкхолдером, а также направлять и помогать двигаться в нужном направлении.
3. Чем больше разных предложений и вопросов будет, тем интереснее будет получаться :)

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

ЛСА | Лайфстайл айтишника

Все мы писали парсеры.. Приступим к system design 

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

Обсуждаем решение в комментариях к посту, а рисовать можно в draw.io https://drive.google.com/file/d/1NXkfZltpnxNJprKgSPPhiw36lAMg5ioM/view?usp=sharing  (если возникнут трудности с подключением, пишите).

Допущения:
* Используемые языки для парсеров: Python, R, JS, PHP.
* Один парсер может запускаться одновременно во множестве инстансов, чтобы обрабатывать в параллель множество страниц конкретного сайта.
* Парсеры могут работать продолжительное время, вплоть до нескольких часов.
* Общее количество парсеров не превышает 1000.
* Парсеры собирают только текстовые данные.
* Объём ежедневно собираемых данных — до 10Gb.
* Данные хранятся в течение 3 лет.

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

ЛСА | Лайфстайл айтишника

Парсерам быть или не быть?

Давайте сегодня вместе разберём данный кейс.

Начнём с общей HLD схемы. Основные внутренние компоненты:
— Пользовательский интерфейс (UI): Предоставляет интерфейс для настройки и управления парсерами.
— Планировщик задач (Scheduler): Отвечает за расписание и запуск парсеров.
— Система выполнения парсеров (Executor): Запускает парсеры в контейнерах.
— Хранилище данных (Data Storage): Сохраняет собранные текстовые данные.
— Мониторинг и логирование (Monitoring & Logging): Отслеживает работу системы и парсеров.

Внешние компоненты:
— ML dev: Получают доступ к данным для дальнейшего анализа.
— Администраторы: Через UI управляют работой парсеров
— Web: ресурсы для парсинга

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

ЛСА | Лайфстайл айтишника

Как правильный вопрос может уменьшить объём работы?

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

Поэтому, задав вопрос: «Кто пользователь UI, кто будет запускать парсеры?», мы получаем ответ, что это администраторы продукта.

Соответственно, им мы можем предложить какой-нибудь стандартный интерфейс, например Airflow закрывает большинство наших требований.

Таким образом, мы только что сэкономили несколько месяцев работы команды с компетенциями: front dev, back dev, test, design.

Как может выглядеть наш стек для данной задачи:

airflow-scheduler — Планировщик отслеживает все задачи и DAG, а затем запускает экземпляры задач после выполнения их зависимостей.

airflow-webserver — Веб-сервер с UI. UI ограничемся этим.

airflow-worker — Воркер выполняет задачи, заданные планировщиком. Запускает парсеры.

airflow-triggerer — Инициатор запускает цикл событий для отложенных задач.

postgres — База метаданных для работы Airflow.

redis — Выступает в качестве брокера для пересылки сообщений из планировщика в воркер.

S3/minio — Для хранения сырых данных.

docker — Каждый парсер заворачиваем в docker образ для возможности запуска из воркера airflow. В целевой картине воркеры могут через API kubernetes запускать поды с парсерами.

Prometheus, Grafana — Для работы с метриками.

OpenSearch, Fluentd и Kibana — Для работы с логами.

Будем продолжать раскапывать этот кейс?

Следующим шагом было бы разумно рассмотреть процесс поставки новых парсеров и отключение старых.

ЛСА | Лайфстайл айтишника

Как понять, когда стоит обновить версию приложения?

Нашёл интересную визуализацию версионирования по Semantic Versioning (SemVer), кратко:
* MAJOR — несовместимые изменения.
* MINOR — новые функции, совместимые с предыдущими версиями.
* PATCH — исправления багов.

ЛСА | Лайфстайл айтишника

Мы ищем разработчика в команду Сбера (только Москва, гибрид)

https://hh.ru/vacancy/117571552

Если кому релевантно, пишите в лс @nestnestnest