Нельзя использовать goto

Часто говорят, что goto плох. А собственно, почему?

В ассемблерном коде на машинном уровне все управляющие конструкции (if, while, for и другие) преобразуются в набор команд с безусловным переходом jmp (UPD: меня поправили, с безусловным или условным переходом, но по указанному адресу, то есть куда угодно).. А такой переход — самый настоящий goto. То есть ты весь такой изящный во фраке пишешь циклы, а наглый компилятор/интерпретатор выкидывает всю красоту и делает goto.

Так почему же сам goto является признаком плохого кода, если он на самом деле везде?

Ответ кроется в умении сохранять контекст. Человек может в голове держать 5-9 сущностей, больше не получается. Поэтому придумали функции, и придумали держать их небольшими — для снижения когнитивной сложности. Конструкция if переведёт тебя в одну из веток ниже, циклы for и while выполнят тело цикла или выбросят за его пределы. Команда goto сложность привносит — прыжок может быть куда угодно. А повышение сложности всегда приводит к росту числа ошибок.

Нормальный ли у меня код?

Разработчики часто задаются таким вопросом. Давайте подумаем, как оценить "нормальность" кода. На мой взгляд, важны следующие аспекты:

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

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

Быстрый по скорости и компактный по данным. Другими словами, код должен быть нормальной вычислительной и пространственной сложности. Тут помогают и интуитивные представления (что-то тормозит), и теория вычислительной сложности (О-нотация). Если вы сортируете записи за O(n^3) и требуете O(n^5) оперативной памяти, то вы делаете что-то не так.

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

Если, конечно, не горят сроки

Как я провожу синки с тимлидами

Когда у вас больше пяти тимлидов в подчинении, а задачи множатся в геометрической прогрессии, стихийные синки превращаются в рулетку: то что-то забудете, то сорвёте дедлайн, то внезапный вопрос срочно «нужно обсудить». За год+ управления командами я перепробовал кучу подходов — и в итоге отточил формат, который убирает хаос, экономит нервы и не даёт терять важное. Рассказываю, как это работает.

Формат:
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.

Структура:
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.

2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.

3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.

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

Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть онятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение

DevFM

Анализируем размер проекта

Среди метрик качества проекта теоретики выделяют число LOC == lines of code, измеряемое обычно в тысячах.

Для измерения размера проекта в строках кода есть интересный проект cloc, запускаемый в том числе в docker (зачем docker?).

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

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

DevFM

Внедрили себе gitlint

В один из проектов внедрили себе gitlint и уже несколько месяцев полноценно им пользуемся. По отзывам разработчиков: кому-то понравилось, что теперь коммиты нужно писать более дисциплинированно, кто-то и так их качественно писал, поэтому и не заметил разницы. Кто-то, конечно, воняет до сих пор, но на них не отвлекаемся :)

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

За вдохновением по правилам написания коммитов загляните сюда.

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

Вдогонку посмотрите еще на comimitizen.

Не на каждом проекте нужны такие штуки, но может именно на вашем пригодится.

DevFM

Внедрили себе gitlint

В один из проектов внедрили себе gitlint и уже несколько месяцев полноценно им пользуемся. По отзывам разработчиков: кому-то понравилось, что теперь коммиты нужно писать более дисциплинированно, кто-то и так их качественно писал, поэтому и не заметил разницы. Кто-то, конечно, воняет до сих пор, но на них не отвлекаемся :)

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

За вдохновением по правилам написания коммитов загляните сюда.

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

Вдогонку посмотрите еще на comimitizen.

Не на каждом проекте нужны такие штуки, но может именно на вашем пригодится.

DevFM

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

Это пост для исключительно для маководов.

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

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

Первое, что у меня настроено в Raycast — это хоткеи абсолютно на все программы, которыми я постоянно пользуюсь: Option + M — почта, Option + T — телеграм, option + B — браузер, и т.д.

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

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

Приглашаю вас послушать наш подкаст Роли в ИТ-проекте.

Поиск команд в консоли с помощью ctrl+r

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

Нажмите в linux-консоли ctrl+r и введите любую часть искомой команды. Будет предложен вариант команды из истории. Если он не подходит, нажмите ещё раз ctrl+r для поиска дальше в истории. Добавьте букв для уточнения поиска. Если пропустили нужную команду, итерируйтесь в обратную сторону с помощью ctrl+shift+r (но этот хоткей работает не везде, иногда надо настроить).

Обратите внимание, что курсор будет стоять на начале найденной подстроки. Прервать поиск можно с помощью ctrl-c. Когда нашли нужную команду, нажмите enter для выполнения, esc или стрелочку в сторону для модификации.

Больше хаков в терминале в нашем бесплатном курсе cli-for-dev на степике или в видео forkbomb в docker.

За что я люблю python или почему его можно выбрать в качестве основного инструмента разработчика
1. Быстрая разработка. Самая сильная сторона Python — обширная стандартная библиотека и огромное число сторонних модулей на любой случай из жизни. Их применение экономит кучу времени.

2. Простая поддержка кода. Синтаксический сахар приводит к немногословным программам. Меньше кода — меньше мест для ошибок.

3. Возможность точечного ускорения кода. Изначально невысокую скорость работы можно починить разными хаками. Обычно в программе тормозит "бутылочное горлышко" . Это не вся программа, а только небольшая её часть. Зачастую профилирование позволяет найти и устранить это "бутылочное горлышко" путём переписывания кода на правильный. Если переписывание не помогло, можно использовать pypy или написать модуль на С/С++.

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

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

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

3. Текущие неудобства с пакетным менеджером. Выбор pip, poetry, uv — хотелось бы всем на чём-то одном остановиться.

За что вы любите питон? А что вас в нём бесит?

Приглашаю вас посмотреть мой часовой стрим по созданию небольшого проекта для начинающих разработчиков. Идея проста — прочитать в csv-файле ФИО и login и проверить существование этого login на gitlab. Но тут vim, проект на gitlab, консольный git, исключения, google docstring, правильная структура проекта и тесты — всё слилось в едином экстазе.

Docker в каждый дом
Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:

1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.

2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.

3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.

4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.

5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.

6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.

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

8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.

В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.

Зачем нужны юнит-тесты

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

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

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

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

Кстати, ИИ нынче отлично умеет писать тесты. И полезно не забывать про антипаттерны тестирования ПО.

Решение задачи с собеседования — проектируем динамическую фильтрацию

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

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

💡В postgres можно спроектировать схему для хранения фильтров в связке со списком товаров, к которым эти фильтры можно применять.
🚫 Здесь не стали приводить конкретики, но отметим, что при таком подходе будут проблемы с динамическим обновлением счетчиков. А ещё такое решение несёт сложную ментальную нагрузку на разработчика.

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

Пример реализации такого решения с использованием полнотекстового поиска в postgres приведен в статье Faceted search using PostgreSQL full text search.

В DevFM пишу о полезном для разработчика.

Задача на собеседовании — проектируем динамическую фильтрацию

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

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

После уточнения задачи получаем следующие вводные:
— имеется клиент-серверное приложение интернет-магазина с возможностью поиска товаров;

— количество записей в результате поиска может доходить до 1кк;

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

— у разных категорий товаров разный набор фильтров;

— после применения конкретного фильтра появляется новая выборка и для нее также должны отображаться только актуальные фильтры. Рассмотрим на примере. Для телефонов должны быть фильтры "производитель" и "операционная система". После применения фильтра "производитель: Apple" в фильтрах ОС уже не может быть значения Android;

— для каждого значения фильтра необходимо отображать количество подходящих товаров. После выбора одного фильтра все счётчики должны пересчитываться. Было "производитель": "Apple: 10", "Xiaomi: 20", "Встроенная память": "128 Гб: 10", “256 Гб: 20". Выбрали "128 Гб", после применения станет, например, "производитель": "Apple: 7", "Xiaomi: 19". То есть 3 модели Apple и 1 модель Xiaomi не попали под выбранный фильтр.

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

Как на настоящем собеседовании, уточняющие вопросы можно задать в комментариях. Наше решение задачи в 20:00 среды.

В DevFM пишу о полезном для разработчика.

Правильная структура ответа на собеседовании

Продолжаем тему собеседований. Классический анекдот: Студент сдаёт экзамен по зоологии, а подготовился только к вопросу про блох. Тянет билет — там про собак. Начинает отвечать, что собака — млекопитающее, у неё есть голова, 4 лапы, хвост, всё это обильно покрыто шерстью, а в шерсти — блохи! И подробнейшим образом про блох. Преподаватель прерывает и просит рассказать про кошек. Студент снова: голова, усики, лапы, хвост и много шерсти, в которой — блохи, и опять про блох. Преподаватель снова прерывает и просит рассказать про рыб. Студент: тааак, рыбы., рыбы... плавают в воде, дышат жабрами, покрыты чешуёй. В чешуе блохи не водятся. Это спасает рыб от проблем с блохами. И снова про блох...

Рекомендуем версию этого анекдота с интересной историей из жизни про экзамен в РХТУ им. Менделеева. К чему это мы?

При ответе на собеседовании или на экзамене важно показать обширность и глубину ваших знаний. Выгодно максимально подробно отвечать, даже если ответ не совсем по теме. Забыли, что значит D в SOLID? Постарайтесь построить ответ так, чтобы максимально подробно рассказать про знакомые буквы. В процессе вспомнили другие темы, например, аббревиатуры, связанные с исходным вопросом? Пускайте в ход DRY, YAGNI, KISS, NIH-синдром, bus-factor и кучу другого материала, по возможности вплетая его в повествование. Высока вероятность, что собеседник забудет, что вы не до конца ответили на поставленный вопрос. Чем уместнее вы притянули смежные темы, тем менее заметна попытка скрыть незнание. Конечно, если тема совсем не к месту, то будет обратный эффект с обнаружением вашего незнания.

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

Но не злоупотребляйте таким приёмом. В работе важно уметь честно признать, что чего-то не знаешь. Нельзя знать всего, надо учиться у коллег, в том числе на правильном code review.

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

В DevFM пишу о полезном для разработчика.

Зачем нужен code review

Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. Конечно, в дополнение к статическому анализу с помощью настроенного pre-commit и тестам;
— выявить проблемы в архитектуре;
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных.

В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками;
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода;
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде;
— дают приток новых идей для улучшений в процессах, подходах и автоматизации;
— увеличивают децентрализацию знаний и bus factor.

В статье даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.

Pre-commit — must have утилита любого проекта

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

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

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

В DevFM пишу о полезном для разработчика.

Что я увидел в своих собеседованиях (часть 2)

Рекомендовал вам записать своё собеседование и делился своими наблюдениями. Вторая часть моих выводов:

❌ Оказалось, что есть типовые вопросы, которые часто задают на собеседованиях, но к которым я специально не готовился. ООП, SOLID, микросервис vs монолит и подобное — без подготовки ответ выходит путанным.
✅ Подботал типовые вопросы.

❌ В какой-то момент я забывался, что нахожусь на интервью и общался с интервьюером, как с коллегой: рассказывал о каких-то негативных моментах в прошлых проектах, говорил от имени команды в контексте "Мы”.
✅ На интервью должна быть дружеская атмосфера, но не нужно забываться. Интервьюера нужно убедить, что я именно тот специалист, который им нужен. На работу устраиваюсь Я, значит в моих рассказах должно быть побольше Я и поменьше Мы. В эту же сторону, поменьше рассказывать о каких-то проблемных местах, побольше рассказывать о удачно решённых задачах.

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

❌ Когда интервьюер спрашивал "есть ли у меня вопросы по вакансии и компании", то возникала заминка. Я спрашивал не очень связно и не всё, что действительно хотел узнать о потенциальном работодателе.
✅ Для этого я также составил чеклист со списком интересующих меня вопросов.

В DevFM пишу о полезном для разработчика.

Пока ты спишь — враг качается

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

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

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

На хабре каждый день читай топ-3 статьи за сегодня, еженедельно читай лучшие 20 статей за неделю. При этом смотри не только саму статью. Часто более полезным является чтение комментариев, где сторонние люди любыми способами постараются доказать, что автор не прав. Чужие мнения могут развить твоё критическое мышление — умение видеть проблему в предлагаемом способе решения задачи.

В году чуть больше 50 недель. При еженедельном чтении десятка статей за год ты прочитаешь около 500 статей. Эти 500 статей и комментариев с обсуждением пополнят копилку решений и обсуждений. Ещё обсуждая с коллегами очередную задачу, можно приобрести опыт решения 500 других задач. И подойти к следующей задаче во всеоружии.

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

В DevFM пишу о полезном для разработчика: инструментах вроде Raycast, об архитектурных схемах, записываю видео по FastAPI + Docker для начинающих. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике.

Что я увидел в своих собеседованиях, часть 1

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

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

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

❌ Я спешил ответить на вопрос интервьюера и начинал отвечать до завершения вопроса. Со стороны выглядело так, будто я просто перебиваю собеседника. Более того, иногда вопрос мог оказаться совсем не таким, как я думал.
✅ Пункт "дослушивать вопрос и не перебивать собеседника" отправился в копилку заметок.

❌ Порой меня спрашивали о технологиях, с которыми я не работал и про которые мало знал. В этот момент я терялся.
✅ При более предметном анализе оказалось, что на любую малознакомую технологию у меня в багаже есть аналогичная, решающая поставленную задачу. Я сделал для себя заметку: если не работал с технологией, не теряйся, подумай, как решить задачу знакомым способом. Более глобальная мысль: стараться минусы обращать в плюсы. И не забывать постоянно изучать разные технологии.

В DevFM пишу о полезном для разработчика: инструментах вроде Raycast, об архитектурных схемах, записываю видео по FastAPI + Docker для начинающих. А ещё у нас есть бесплатный курс cli-for-dev по Linux на степике.

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

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

В случае онлайн-собеседований у вас есть уникальная возможность посмотреть на себя со стороны. Запишите всё: аудио, видео со своей камеры и монитор с собеседником. На Linux для записи экрана удобен Kazam.

По видеозаписи вы сможете выявить свои косяки, которые совершенно не заметны без взгляда "со стороны". Кроме того, вы можете словить реакцию собеседующего на ваши ответы. В процессе интервью сделать это сложно — мозг занят другими вопросами.

После прохождения интервью просмотрите запись и выявите систематические ошибки. Легко сказать — выявить ошибки. На деле совсем не просто найти проблемы в своём же интервью.

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

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

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

По результатам просмотра двух первых интервью мои злые друзья нашли 36 проблемных мест. В результате их проработки я сформулировал десяток конкретных пунктов как надо делать и как делать не надо.

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

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

DevFM