Что я увидел в своих собеседованиях (часть 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

Снова о необходимости архитектурных схем

Продолжим пост об архитектурных схемах с более практической стороны.

– Как-то так повелось, что мы используем C4 model. Не нагромождённая и достаточно лаконичная. Если вдруг кому-то кажется, что C4 – это какая-то новомодная модель, спешу разочаровать. Придумана она была почти 20 лет назад.

– C4 model не предусматривает никакой описательной части, поэтому ко всем архитектурным схемам у нас имеется тезисное описание всех компонентов, изображённых на схеме.

– C4 несложная, но глаз может замылиться, а всё ли сделано правильно? На этот случай на официальном сайте есть чеклист (там же pdf), по которому можно быстро проверить вашу схему на соответствие правилам и адекватность.

– Хотя я очень люблю делать схемы в визуальных редакторах, но понимаю, что реюзабельность такого творчества страдает. Поэтому правильнее готовить такие схемы в виде кода. Хорошим решением будет Structurizr, опенсорсная self-hosted штуковина. Помимо самих схем, там же можно документировать своё решение.

– По моему опыту очень полезной может оказаться Deployment-диаграмма. Её можно немного извратить, отойти от канонов и получить примерно такое изображение:

Особенно удобно, когда существует целый зоопарк самых разнообразных сервисов. Все они в разных закрытых сетевых контурах, с разными командами поддержки. Кто-то должен предоставить вам кубер, кто-то базы, кто-то s3. Что-то будет в Harvester, что-то в Proxmox. Такая диаграмма поможет разобраться во всём этом и как-то структурировать. А новый девопс на вашем проекте скажет за такое большое человеческое спасибо.

DevFM

Зачем фиксировать зоны ответственности разработки

Мы обсудили, как фиксировать зоны ответственности. А теперь обсудим несколько причин, почему это полезно:
– если проект долгоиграющий, то в целом хорошо бы понимать, кто за что отвечает, кто в чём разбирается. На длинной дистанции найдется достаточно количество заинтересантов, которые будут приходить с разными вопросами
– позволяет отслеживать bus factor. Табличка даёт очень наглядное представление, где у нас проблема с зонами ответственности, за какой функционал отвечает всего один человек, и нет у него никакой подмены
– более вдумчиво планировать отпуска. Сразу понятно, кого нельзя отправлять в отпуск одновременно
– и ещё один пункт, который совсем недавно поймали. У нас была проблема, что баги тестироващиками классифицировались по направлениям бек/фронт, но далее они падали на тимлидов, которые должны были вникать и распределять по ответственным и, самое печальное, – тратить свое драгоценное время. Потом мы показали тестировщикам табличку с зонами ответственности, они теперь дотошно диагностируют проблему и закидывают баг сразу на исполнителя. Получилось очень хорошо, ошибок минимальное количество

Как фиксировать зоны ответственности разработки

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

Структура подобной таблички:
– сервис – самая верхнеуровневая сущность для удобной навигации по табличке. Если у вас монолитная архитектура, то можно эту колонку опустить или взять любую другую верхнеуровневую единицу разделения. Тут главное, чтобы вам удобно было ориентироваться
– модуль – более конкретное уточнение функционала
– ответственный разработчик – кто именно отвечает за этот модуль, с ним советуются, если что-то хотят туда внедрить, его тегают в МРах, к нему идут, если что-то сильно сломалось
– разработчики – те, кто принимал участие в разработке модуля и представляют, что там происходит
– аналитик – если в вашей команде есть системные аналитики, то имеет смысл указать этих ребят в этой же табличке

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

Для чего нужны архитектурные схемы

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

Для чего конкретно нам нужна архитектурная схема? Конечно, кроме того, что это просто красиво.

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

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

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

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

Как документировать архитектуру?

Как документировать архитектуру

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

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

В качестве структурного шаблона для документирования предлагается использовать arc42. Для визуализации — C4 model. Кстати, C4 оказалась вполне удобной, и мы активно применяем её у себя.

Из приятного — для arc42 и C4 автор приводит ссылки на хорошие примеры реализации.

В конце автор рассказывает, как можно всё описанное организовать, применяя подход — documentation as code, а так же приводит полезные тулзы для этого.

Багскрам

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

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

Кто участвует: тестировщики, команда разработки и руководитель проекта. Если система сложная, то ещё аналитики. Встреча получается дорогой, поэтому проводить её нужно, понимая цель, чётко и быстро.

Подготовка: выбрать скоуп багов, которые хотите разобрать.

Сама встреча:

1. Ведущий встречи открывает каждый из багов.

2. Тестировщик, который завёл баг, тезисно описывает проблему.

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

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

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

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

Анализ источника багов как начало улучшения процессов работы в команде

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

Всё шло как обычно, тестировщики тестировали, баги заводились, баги фиксились.

Но тут мы решили посмотреть на природу багов. Из-за чего они возникают? Где что-то ломается?

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

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

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

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

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