Девман для питонистов

Нужно ли учиться код-ревью❓ Сначала разберёмся, что такое хорошее код-ревью. Это не попытка «кодить руками» разработчика — «замени на», «добавь синглтон», «перемести код в эту функцию». Хороший ревьюер формулирует проблему, которая мешает код читать или пользоваться. Он задаёт наводящие вопросы: «Функция так названа, а по коду делает другое — это так?». Автор сам должен понять замечание, провалидировать его и применить. Критерий качества один: ты не диктуешь решение, а показываешь проблему. ✅Кому и когда это реально нужно: — Тимлиду, который даёт обратную связь авторам кода; — Программисту в команде с перекрёстным ревью; — Каждому, кто работает с нейросетями и по сути становится их тимлидом. ❓Как этому научиться?  1️⃣ Делать ревью. Чем чаще, тем лучше. Ревьюить код нейросети – отличный вариант для начала.  2️⃣ Делать ревью — необходимо, но недостаточно. Чтобы замечать больше проблем, нужно качать насмотренность. Нужен либо огромный собственный опыт, либо чужой.  Где набраться чужого опыта: — Книги про чистый код, паттерны проектирования и около того. Обращать внимание на кейсы: что доставило проблемы, как исправили; — каталог улучшений Devman; — код-ревью, полученные от старших товарищей – свои и чужие, если есть возможность посмотреть. 🎯 Главная трудность — не формулировки, а умение проблему увидеть и осознать. Начинающие обычно говорят: «Я так не делаю, я делаю по-другому», но не понимают, что будет плохого, если оставить текущую реализацию. А это и есть суть ревью. 👉 Статья «Грейд разработчика приходит с годами, но иногда годы приходят одни: зачем вам код-ревью» 👉 Пост «Секретный ингредиент уроков Девман –  код-ревью» ✅Итого: навык сам не появится, если его не качать. Нужна практика + насмотренность. Ну а все курсы Devman заканчиваются код-ревью действующего разработчика — так накопленный опыт команды достаётся вам. Сдавайте уроки — мы уже заждались! Мы в Макс

Без точного названия сложно понять для чего нужен токен. Речь идёт одновременно и про переменные в коде, и про переменные окружения. А если, например, API поддерживает несколько видов токенов, то тем более в названии каждого из них необходимо указать специфический тип. Если внутри программы используется только один вид токена, то давать переменной специфичное название не обязательно, а вот переменная окружения всегда должна называться специфично. Код из нашего примера может выглядеть так: from environs import Env def main(): env = Env() env.read_env() geocoder_token = env.str('YANDEX_GEOCODER_TOKEN') Также хотели бы ответить на комментарии к посту: 1️⃣ Нужно ли задавать значение по умолчанию? Если такое значение существует или является необязательным, то да, нужно задать. В других случаях, как правильно отметили в комментариях, должно быть исключение, говорящее о невозможности работы программного обеспечения. Лучше узнать об ошибке при деплое, чем через неделю удивиться, что пользователи не могут пользоваться сервисом и уже ушли к конкуренту! 2️⃣ Нужно ли вынести чтение переменных окружения из `main`? Если речь про вынос из main без обертки, то однозначно нет. Т.к. чтение переменных окружения будет запускаться при импорте модуля. Чтение настроек приведет к ошибки на этапе инициализации модуля. Такие исключения тяжело перехватывать и обрабатывать, поэтому так делать не рекомендуется. Сначала инициализация: какие функции объявлены, какие модули импортированы, потом исполнение, включая чтение переменных окружения и непосредственный вызов функций. 3️⃣ Нужно ли убрать строку `env = Env()`? По официальной документации, текущий двустрочный вариант рекомендуется для Django. Способ чтения зависит от того, с каким фреймворком используете библиотеку environs. 💙Спасибо вам, что делились своими вариантами в комментариях! Мы в Макс

🤔 Давайте вместе разберемся, что не так с этим кодом? from environs import Env def main(): env = Env() env.read_env() token = env.str('TOKEN') 👉 Чтобы понять, что можно исправить, загляните в типичные улучшения Девмана. ➡️Пишите в комментариях, что можно исправить! Мы в Макс

Используйте в названиях правильный регистр букв. UPPER_CASE — для глобальных констант CamelCase — для названий классов snake_case — для всех переменных, функций, методов, аргументов, полей Код из нашего примера может выглядеть так: CONSTANT_NUMBER = 15 _some_variable = 'value' class SomeClass(): ... def do_function(): ... Да, кажется, что придираться к выбору регистра — перебор. Но эта та деталь, которая на порядок снижает сложность понимания при чтении кода, а значит и вероятность ошибок при доработках! Если модуль предназначен для импорта с помощью from M import *, PEP 8 советует явно указать, какие глобальные переменные модуль экспортирует. Для этого добавляют префикс из одного подчёркивания (_internal_var) к именам «внутренних» глобальных переменных. Так вы контролируете, что именно будет доступно при импорте. И спасибо всем за активность в комментариях - вы нашли больше, чем было запланировано!😁 Мы в Макс

🤔 Давайте вместе разберемся, что не так с этим кодом? constant_number = 15 class some_class(): ... def DO_FUNCTION(): ... Some_VARIABLE = 'value' 👉 Чтобы понять, что можно исправить, загляните в типичные улучшения Девмана. ➡️Пишите в комментариях, что можно исправить! Мы в Макс

Продолжаем отвечать на вопрос «Какие навыки нужны разработчику, чтобы писать код нейросетями?» Мы уже рассказали про: — Нужно ли писать промпты — Нужно ли создавать ИИ-агентов — Про вайбкодинг ❓Часть 4. Мышление Классический подход к разработке кода — продумать все корнер-кейсы, разработать алгоритм, проанализировать входные и выходные параметры. Интерпретатору Python не надо сообщать что и зачем вы делаете — просто пишите команды, которые надо исполнить. Достигнет ли ваше ПО результата зависит от того, как правильно разработали и реализовали алгоритм. 🌟Но ИИ может круче, если описать что нужно получить и зачем. Нейросеть спросит обо всех важных моментах и предложит решения. При наличии инструментов для тестирования и проверки, ИИ сможет самостоятельно проверить результат. Критерии качества кода должны включать как функциональные требования, так и общие требования к чистоте кода и архитектуре (да-да, то самое ревью Девмана). 👉 Укажите какую задачу нужно решить и зачем, а не давайте простые команды. Процессы с ИИ сложно тестировать и отлаживать. Причем как элемент в составе ПО, так и как инструмент для написания кода. Отладка принтами уже не поможет, к сожалению😢 👉 Заранее продумайте как вы будете дебажить работу ИИ С ног на голову меняется процесс разработки — старые подходы начинают рушиться. Скорость написания кода возрастает настолько, что если не подготовиться, то тимлид погибнет в код-ревью. Ну или ваша собственная работа превратиться в постоянное ревью и уточнение задачи. От написания кода избавит, но вряд ли даст ускорение больше, чем на 10-30% (если повезет). 👉 Перестраивайте процессы, внедряйте новые инструменты ❓Наверно, сразу ответим еще на такой вопрос — а когда Devman будет учить кодить с помощью ИИ? — Уже есть курс для тимлидов, сеньоров и архитекторов, кто готов выстраивать у себя в отделе/компании AI-first процессы разработки и инфраструктуру под них — А вот как учить начинающих разработчиков и с нуля мы пока не придумали. Дело в том, что сейчас структура ИТ-команд поменялась абсолютно. В каждой компании выстраивается своя инфраструктура и процессы ИИ-разработки, создается экосистема инструментов для ИИ. Причем каждый проект требует донастройки. Как все это впихнуть в курс не на 10 лет для новичков — пока не придумали, но стараемся! ➡️Расскажите в комментариях, каких знаний и навыков работы с ИИ вам не хватает? Какую помощь хотели бы получить? Мы в Макс

Продолжаем отвечать на вопрос «Какие навыки нужны разработчику, чтобы писать код нейросетями?» Мы уже рассказали про: — Нужно ли писать промпты — Нужно ли создавать ИИ-агентов Сегодня поговорим про вайбкодинг! ❓Часть 3. Про вайбкодинг и «что-то еще» Надо ли уметь вайбкодить? Если речь про «иди, сделай за меня» в один промпт (даже со скиллами и MCP-серверами) — это плохой вариант. В 9/10 случаях руками быстрее. Даже если на старте будет что-то путное, доработать продукт, не сломав еще что-то нейросеть не сможет. ✔️ Подойдет для прототипов. Например, как в уроке по FastAPI с генерацией фронта сайта. ✔️ С натяжкой работает для автотестов. ✔️ Ограниченно работает для обновления версий библиотек. ✖️Нейросеть не умеет чинить сложные баги — процесс не сходится: чинит одно и ломает то, что работало. Сложные баги не решаются в один шаг. Сначала надо сформулировать гипотезы, потом проверить их и локализовать проблему, найти варианты решения, в итоге выбрать оптимальный. В итоге, если делать в один шаг, проект застревает на фазе «почти готово» и вы либо дорабатываете вручную, либо переписываете с нуля. Использование ИИ как ассистента не дает кратного прироста эффективности. То время, которое тратилось на разработку кода, теперь тратиться на ревью, рефакторинг и доработку кода ИИ. Причина — отсутствие в контексте какую проблему и для кого решаем + отсутствие четких критериев результата на каждом этапе разработки веб-приложения от принятия архитектурных решений, до покрытия кода автотестами. Другой подход — выстраивание системы, где ИИ берет на себя не только разработку кода, но и проверку его качества, тестирование. Недавно для него даже появился термин «Агентная разработка». Человек все еще нужен, но как архитектор и «руководитель». Не надо отдавать ИИ все задачи целиком. Самые сложные решения и задачи остаются под ответственность архитектора, а ИИ выступает как ассистент. 👉 Знаете как проверить качество результата — можно делегировать ИИ 👉 Объясните ИИ в чем ценности результата для пользователя Нужно ли уметь «что-то еще»? Да, крайне полезны навыки менеджмента и преподавания. ✏️Пример из обучения. Ученик не может выполнить задачу или выполняет плохо. Нужен дебаг. А теперь ученика заменяем на ИИ — ситуация очень похожая и методы отладки похожие, часто через диалог с агентом. А вот от дебага программного кода отличается значительно и общим подходом, и инструментами. ✏️Пример из управления. Недоверие к результатам нейросети — важная и частая проблема. Именно недоверие заставляет все перепроверять, а проверка съедает все сэкономленное время. Хороший управленец знает куда смотреть, чтобы быстро проверить качество результата задачи, отданной сотруднику. А отличный управленец еще при постановке задаче научит сотрудника, куда смотреть и как самостоятельно проверить результат перед сдачей. 👉 Навык делегирования позволит эффективно ставить задачи ИИ и получать стабильно желаемый результат. Предел сложности Если говорить про код, то нельзя с помощью ИИ сделать проект сложнее того, что и так можешь сделать. Потому что его надо отревьюить. На чистоту кода и на архитектуру. Чем меньше опыта у ИИ разработчика, тем больше граблей он соберет. Возможно, через год ситуация изменится и ИИ получит потрясающие навыки код-ревью и проектирования, но пока что эта ответственность на разработчике. 👉 Искусственный интеллект работает как линза. Он масштабирует результаты, действуя по принципу: умножает то, что уже есть. Усиление сильных сторон: Профессионалам ИИ помогает ускориться в разы. Он берет на себя рутину, генерирует идеи, анализирует массивы данных и позволяет сосредоточиться на ключевых задачах. Усиление слабых сторон: Если исходная база знаний или навыков слабая, ИИ не компенсирует её, а начинает выдавать «галлюцинации» и логические ошибки. Пользователь без опыта теряет способность перепроверять информацию, что приводит к ухудшению итогового результата. 👇 Ставьте огоньки и ждите продолжение! Расскажите в комментариях о своем опыте вайбкодинга! Мы в Макс

Продолжаем отвечать на вопрос «Какие навыки нужны разработчику, чтобы писать код нейросетями?» ❓Часть 2. Надо ли создавать ИИ агентов? Обязательно. Просить ИИ написать код просто в режиме чата неэффективно совсем. Что такое ИИ агент Агент = обычный ИИ + инструменты. Инструменты позволяют работать с файловой системой, git, открывать сайты, лазить в БД и т.д. Часть инструментов можно найти готовыми, а часть — придется написать самим. Старожилы нашего канала точно смогут написать недостающие скрипты на Python для агента! Вообще и нейросеть сама может написать разово, а потом пользоваться скриптом на постоянке. Отревьюить не забудьте😁 Ничего страшного в «создании агентов» нет — сейчас множество платформ создаст их за вас, вы и не заметите. Мы работаем с OpenCode. Можно вести разработку с помощью агентов в VSCode. Вариантов все больше, холиварить не будем — на вкус и цвет все фломастеры разные. В итоге платформа предложит вам готовые скиллы, MCP сервера и много всяких плюшек для работы с агентами. ❌ Не плодите субагентов В какой-то момент контекст кончится и агент или вы сами подумаете, а чего бы субагентов не добавить. Без крайней нужды не стоит! Использование субагентов радикально снижает качество работы нейросети. Использование субагентов требует очень зрелой продвинутой инфраструктуры. Управление контекстом субагента — задача со звездочкой. А ИИ без корректного контекста — это обезьяна с гранатой. Для новичков это точно антипаттерн. Если проблема именно в переполнении контекста — сохраните важные результаты в файлы и начните новый сеанс с агентом. Разбейте задачу на этапы. Подсушите исходные данные или выберите другой их формат, чтобы ужать объем. Если бюджет позволяет, подключите ИИ с большим лимитом контекста. 👇 Ставьте огоньки и ждите продолжение! Расскажите в комментариях о своем опыте работы с ИИ-агентами! Мы в Макс

Получили интересный вопрос по ИИ от Ольги. Давайте вместе разбираться! Какие навыки нужны разработчику, чтобы не тормозить при внедрении ИИ в разработку Сразу оговоримся — речь не про обучение нейросети на своем сервере, а использование универсальной LLM модели вроде DeepSeek или ChatGPT. Часть 1. Писать промпты? Да, промпты точно нужно уметь писать. Но не в том смысле, что надо владеть неким тайным кунг-фу, магической структурой или писать «пиши код как сеньор». Достаточно ясно и сухо изложить суть проблемы и желаемый профит, а формулировать задачу и ее результат должна нейросеть. ✍️ Не пишите инструкцию Надо излагать ценность и проблемы, мешающие ее получить, а не писать ИИ инструкцию что делать. Это базовый прием, повышающий качество работы. Пример ❌Плохо: Напиши скрипт, который конвертирует svg картинку в png. ✅Хорошо: Напиши скрипт, который поможем мне встроить иллюстрации в статью. У меня есть объемные svg файлы. Нужны png. Какие вопросы хочешь обсудить? ✍️ Не пытайтесь решить сложную задачу в один промпт Нейросеть, как и человек, так не умеет. Точнее то, что она сделает, вас не порадует. Разбейте задачу на этапы, результат каждого из которых можно проверить и оценить. ✍️ Следите за контекстом, избегайте автоматической саммаризации При заполнении контекста включается саммаризация — данные обобщаются и схлопывается, часто «выплескивая младенца из корыта». Именно в этот момент ИИ начинает чудить. Поможет сохранение промежуточных результатов, чтобы при достижения критического значения просто начать новую сессию. А важное от неважного отделите вы. Управление контекстом — это ключевой вид активности. Разработчик перестаёт тратить время на написание кода (этим занимается нейросеть), но сосредотачивается на управлении контекстом: накопление, актуализация, регламенты, инструменты навигации. Без этого далеко не уплыть. 📌Да, есть приёмы, которые делают промпты эффективнее, а работу ИИ стабильнее. Приведем пару лайфхаков: ✅ Мотивация ИИ "спереди" ИИ не читает красивые документы по проекту, которые вы для него заготовили? Что ж, добавьте желтушные заголовки: Пример Прочитай файл RULES.md, чтобы узнать о правилах и не переделывать работу. ИИ не человек, но его отличная имитация. Так что представьте, что работаете со стажёром, который не ест, не спит и офигенно быстро соображает. Но только в рамках сессии😄 Замотивируйте его прочитать все ваши инструкции! ✅ Мотивация ИИ "сзади" Кто самые четкие сотрудники? Правильно, тревожные перфекционисты с синдромом отличника. Наделите нейросеть неврозом и она будет внимательнее: Пример Веди себя как перфекционист, который боится облажаться. ❓А у вас какие любимые приёмы для промптов? А с нас ещё про ИИ агентов, вайб-кодинг и какие ошибки совершают разработчики при внедрении ИИ. В один пост не уложились🤷‍♀️ 👇 Ставьте огоньки и ждите продолжение! Мы в Макс

Что не так с регулярками (regex)❓ Все хвастаются, что знают регулярки (regex). Даже на собесах про них спрашивают. Но никто не говорит, что с ними не так. Исправляем ситуацию. На первый взгляд регулярки — это простая и мощная утилита: скопировал, вставил, шустро работает, мало кода. ❗️Но дьявол кроется в деталях: 1️⃣Ты вставляешь выражение в код 15 минут, а через месяц не можешь прочитать. ❓Что делать: 👉 разбить выражение на простые строки с комментариями, используя re.verbose() import re pattern = re.compile(r""" \b # Граница слова (?P<year>\d{4}) # Год (4 цифры) - # Разделитель (?P<month>0[1-9]|1[0-2])# Месяц (01-12) - # Разделитель (?P<day>0[1-9]|[12]\d|3[01]) # День (01-31) \b # Граница слова """, re.VERBOSE) 2️⃣ Тестирование и доработка регулярных выражений превращается в ад — максимум времени и минимум стабильности. ❓Что делать: 👉 использовать для тестирования сервисы вроде https://regex101.com/, 👉 написать автотесты. 3️⃣ После того, как готовы автотесты, все проверено и доработано возникает вопрос — а зачем? Это было уже совсем не быстро, дешево, сердито! ✅Выход: 👉 Сразу ищите готовую библиотеку, которая закроет вашу проблему: phonenumber для валидации номеров или urlparse для работы с URL адресами. ❌ Не заменяйте регулярку на 100500 if-else. Это убьет читаемость и стабильность кода! 🤔А регулярки то нужны вообще? Да. Для очень простых случаев вроде [a-zA-Z0-9]+. А еще они часто под капотом тех самых библиотек, при написании которой были вбуханы ресурсы на отладку и тестирование, а вы используете готовый результат. Очень редко, но все-таки приходится писать свои сложные регулярки, но тогда готовьтесь — по трудозатратам придется написать библиотеку. Чистого всем кода! Мы в Макс

Неправильная форма числа ведёт к обманутым ожиданиям и ошибкам. Если related_name в ManyToManyField указан в единственном числе, то запросы с его участием будут выглядеть странно и неожиданно. Код из нашего примера может выглядеть так: owners = flat.owners.all() 💙Спасибо вам, что делились своими вариантами в комментариях! Мы в Макс

🤔 Давайте вместе разберемся, что не так с этим кодом? owners = flat.owner.all() 👉 Чтобы понять, что можно исправить, загляните в типичные улучшения Девмана. ➡️Пишите в комментариях, что можно исправить! Мы в Макс

⚡️Обновили урок из мини-курса «API веб-сервисов» Урок 5 из модуля «API веб-сервисов» долгое время был одним из самых любимых и популярных. Ученик парсил данные по API и прикидывал какую зарплату станет получать после курса на HH.ru и паре других сервисов. И сейчас это более чем актуально, ведь около 67–75% компаний и рекрутеров используют технологии искусственного интеллекта и автоматизированные ATS-системы (Applicant Tracking Systems) для первичного отбора и скрининга резюме. Уже видели мемы про разговор ИИ-рекрутера и ИИ-кандидата? ИИ пишет резюме, ИИ фильтрует резюме. А API позволяет легко подключить бота, парсить вакансии и откликаться на них. В итоге количество откликов зашкаливает, просмотреть всех в принципе невозможно, найм превращается в безумие! ❗️HH в конце прошлого года принял важное решение — закрыть публичное API, чтобы снизить накал страстей. По факту API работал до апреля текущего года. И наш урок тоже. Нам пришлось все-таки искать другую площадку, на которой можно парсить зарплаты. Обновили урок «Прикиньте будущую зарплату» — hh.ru заменен на habr.career. Навыки по работе с API те же, но размах не тот, конечно. ➡️ А вы проходили мини-курс API веб-сервисов? Какой ваш любимый урок? Делитесь в комментариях!

✅Как внедрить ИИ и получить прибыль, а не убытки? В апреле мы выступали для бизнес-клуба «Гермес»! Собрали главные тезисы и кейсы из выступления в статью! ➡️ Читайте и делитесь своими кейсами использования ИИ в комментариях!

Пока нейросети захватывают мир, холивар на тему Django vs FastAPI так и не решен Часто видим одну и ту же боль: у вас здоровенный монолит на Django, куча легаси или сложная админка. Но задачи по API становятся всё более капризными: нужна строгая типизация, авто-доки и нормальная валидация. DRF не предлагать — с ним еще хуже, чем без него, уже тошнит от сериализаторов-мутантов. Переписывать всё на FastAPI (и плодить зоопарк микросервисов на ровном месте) — неоправданный суицид. ❓Что делать? ✅Затаскивайте в проект Django Ninja. 💥Главная киллер-фича — нативная дружба с Pydantic (а в последних версиях — и с Pydantic v2). ✍️Типовые проблемы → Решения Ninja: Проблема: Данные приходят грязные, строки вместо чисел, даты в диком формате. Ninja: Просто описываете модель Pydantic’ом. Всё. Автоматическая валидация, coercion типов и JSON Schema. Проблема: Вложенные объекты валидировать больно. Ninja: Схемы вкладываются как матрёшки, глубоко и без боли. Проблема: OpenAPI/Swagger документация вечно устаревшая. Ninja: Доки генерируются автоматически из ваших type hints. Код = Документация. Никакой магии и декораторов-уродцев. ⚔️Django Ninja vs FastAPI: война, которой нет Зачем Ninja, если есть FastAPI и SQLAlchemy?. Ответ прост: экосистема и реальный мир. ✅ Когда вы выбираете Ninja вместо FastAPI: Монолит Django: У вас уже есть модели Django ORM, админка, система аутентификации. Ninja просто садится сверху как современный API-слой, не требуя переписывать бизнес-логику. Сложная аутентификация: Бесшовная интеграция с сессиями Django, куками и встроенной User моделью. Не нужно городить велосипеды на JWT, если используются сессии. Синхронность: Django ORM в основе своей синхронна. FastAPI с async SQLAlchemy требует дисциплины и легко ловит «зеленые потоки» на продакшене. Ninja работает в родной среде без сюрпризов. Батарейки в комплекте: Кэширование, очереди (Celery), ORM с Signals — всё это стабильно работает в Django и ломается, если начать переезжать фрагментами. 🚀 Для сложных веб-сервисов: профит в скорости разработки Вам не нужно спорить с тимлидом о том, какой ASGI сервер выбрать или как подружить Alembic с продакшен-миграциями. У вас уже есть панель администратора на сотню таблиц — просто навесьте на неё Ninja-эндпоинты и получайте JSON со скоростью FastAPI. Да, он реально быстрый, по бенчмаркам не уступает, а где-то и обгоняет благодаря оптимизациям. 📝 Синтаксис, который вы полюбите: from ninja import NinjaAPI, Schema class ItemIn(Schema): name: str price: float quantity: int = 1 # дефолтные значения! api = NinjaAPI() @api.post("/items") def create(request, payload: ItemIn): # Поля payload.name, payload.price уже провалидированы return {"success": True, "id": 1} ‼️Риски Основной django-ninja — стабильный продукт, который прекрасно работает. С 2024 года активность единственного мейнтейнера Виталия Кучерявого в основном репозитории по код-ревью и слиянию pull request'ов почти остановилась. На GitHub накопились десятки PR, включая исправления критических ошибок и улучшения производительности. В 2025 году появились форки батарейки. Если в процессе работы вы упретесь в баг, имейте в виду, что есть форк  Django Shinobi как более оперативно обновляемая альтернатива в той же экосистеме. Вердикт: Если Django для вас — готовый авианосец, а не помеха, Django Ninja превращает его в современный быстроходный катер. Это не «замена FastAPI ради замены», а эволюционный скачок для экосистемы Django. ✍️Мы уже дискутировали на эту тему в видео-формате. Если не смотрели, то вот ссылки: — Ютуб — Рутуб — VK

Пользуетесь ли Макс?

⚡️Мы завели канал в Макс! Подписывайтесь на нас по ссылке, чтобы не потеряться! Канал в Телеграм мы продолжим вести. Также напоминаем, что у нас есть группа в VK. Расскажите, пользуетесь ли Макс? Выбирайте ответ в опросе!

Самопрезентация: что и как рассказать о себе на собеседовании Самопрезентация — неотъемлемая часть собеседования. На любом из этапов отбора, вас могут попросить коротко рассказать о себе и своем опыте. Кажется, что рассказать о себе не так уж и сложно. Но, когда в рамках подготовки к тех. интервью, мы просим наших студентов рассказать о своем опыте, студенты отвечают: «Я не знаю, что говорить и что именно рассказать». ✅Как оценивает самопрезентацию работодатель: — «Начинка» — что вы говорите о себе; — «Обертка» — как вы говорите о себе. Это структура рассказа, то, как вы формулируете мысли, легко ли вас слушать. Второй критерий не очевидный, но он важен для работодателя. ❌Вот, что может повлиять негативно: — несвязная речь, — отсутствие структуры в рассказе, — неспособность сформулировать мысль кратко, — скачки с темы на тему, — отсутствие или потеря логики, — возвращение к тому, о чем уже говорили, — неожиданные паузы (потеря мысли, забытое слово), — долгий, монотонный рассказ, — слова-паразиты ❓Почему это влияет? Технического руководителя это может навести на мысль: если у кандидата такая речь, способен ли он в принципе логически мыслить, будет ли порядок в документации, коде, последовательной работе с задачами. Все это тесно переплетается с вашими хард-скиллами и влияет на вашу оценку как профессионала. ✍️Как подготовить самопрезентацию? 1️⃣Составьте письменный рассказ о себе. Вы сможете наглядно увидеть проблемы в устной речи. В тексте проще составить структуру, логику и определить последовательность, убрать лишнее. Скорее всего, вы будете возвращаться к своему черновику не единожды и с каждым разом будете улучшать свой рассказ. 📌 Вот шпаргалка, если не знаете, что рассказать и как структурировать: — Вводная часть. Представьтесь, расскажите, как пришли в разработку/почему именно эта специальность интересна, про свой опыт в разработке, про последнее или текущее место работы; — Про проекты. На каких проектах работали (не только на последнем месте работы), с какой предметной областью (финтех, ритейл и т.д.), какие продукты разрабатывали, для кого (кто заказчик, конечный пользователь), команда проектов, стек проектов. Если опыт большой, выберите самые релевантные проекты для компании, где вы проходите интервью; — Про задачи и личные достижения. Расскажите о своих задачах и достижениях, приведите примеры. Начните с крупных, значимых, интересных задач и переходите к более мелким. Делайте упор на то, где требования в вакансии пересекаются с вашим опытом, подчеркивайте, что вы умеете именно то, что требуется в вакансии и вашей будущей команде; — Свой личный стек и компетенции. Технологии и инструменты, которыми владеете лично вы, в чем вы сильны, что вам можно доверить, чем вы можете быть полезны для проекта и команды. Начните с тех.навыков, закончите софт-скиллами, личными характеристиками; — Заключение. Почему вы сейчас в поиске работы и что ищите: какие проекты, компанию, команду, как вы видите свое профессиональное развитие. 2️⃣Перечитайте вслух то, что у вас получилось. Оцените, насколько это «ваша речь», насколько вам комфортно говорить. Засеките время вашей устной презентации. Если у вас короткий HR-скрининг, ваша презентация не должна быть дольше 2-3 минут. Если полноценное интервью, не больше 5-6 минут. Можно составить 2 текста на разную длительность. 3️⃣ Внесите корректировки в текст и порепетируйте устно наедине. В начале можно выучить самопрезентацию, чтобы чувствовать себя увереннее на встрече. Достаточно быстро вы освоитесь, отточите текст и устная речь станет более связной и логичной. Распечатайте текст и держите под рукой как шпаргалку на удаленных интервью. Эта методика поможет не теряться и при ответах на точечные вопросы интервьюера. Когда в вашей голове уже есть отрепетированные паттерны рассказа, вам гораздо легче сориентироваться и ответить на незапланированные вопросы.

💥Осталось всего три дня! Напоминаем, что у нас действует скидка на мини-курсы до 3 мая! Успейте купить мини-курс и прокачать навыки! ⚡️Выбирайте мини-курсы со скидкой здесь или задавайте вопросы нам в Telegram!

Нет смысла в названиях полей дублировать название модели: в прикладном коде название поля и так всегда следует за названием модели. Высушите названия полей. Код из нашего примера может выглядеть так: from django.db import models class Owner(models.Model): full_name = models.CharField('ФИО владельца', max_length=200) phonenumber = models.CharField('Номер владельца', max_length=20) flats = models.ManyToManyField( 'Flat', verbose_name='Квартиры в собственности', related_name='owners') def __str__(self): return self.full_name