За последние полгода я посетил более 10 собеседований на позиции от синьор бэкенд разработчика до техлида и тимлида команды.

В ЭТОМ ПОСТЕ я описал:
- какие технические вопросы чаще всего задают;
- какие практические задачи дают;
- ссылки для подготовки к таким собеседованиям.

Telegram

.NET backend study

Что чаще всего спрашивают про распределённые системы на собеседованиях + подборка материалов За последние полгода я посетил более 10 собеседований на позиции от синьор бэкенд разработчика до техлида и тимлида команды. Во время технической части очень популярны…

В ЭТОМ посте я рассказал о самом важном вопрос на собеседовании. У него множество вариаций, но основа одна - “расскажите о себе”.

5 принципов, которые помогут тебе лучше ответить:

1. акцентируй внимание на релевантных навыках

Подсвети из опыта всё, что покажет тебя подходящим именно на эту позицию.

2. делай упор на проактивности, лидерстве и вовлечённости

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

3. адаптируй рассказ в зависимости от компании и позиции

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

4. заверши рассказ своими целями

Покажи себя специалистом, ориентированным на рост и профессиональное развитие.

5. подготовь структуру заранее

Так ты будешь уверен, что подсветишь все основные поинты из своего опыта. Используй подготовленный рассказ в качестве чек-листа.

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

Переходи и читай полную версию статьи.

Как отвечать на самый важный вопрос собеседования

От ответа на этот вопрос зависит пройдёшь ли ты собеседование. И нет, это не вопрос про устройство сборщика мусора, отличия микросервисов от монолита и минусов скрама.

Что это за вопрос, какие ошибки допускают люди при ответе на него, как правильно отвечать - в статье ниже.

https://telegra.ph/Kak-otvechat-na-samyj-vazhnyj-vopros-sobesedovaniya-08-16

#карьера_и_деньги

Telegraph

Как отвечать на самый важный вопрос собеседования

Ты услышишь этот вопрос абсолютно на каждом собеседовании. У него могут быть разные формулировки и степень детализации - но его неизменно зададут. Ответ на этот вопрос будет иметь очень большое значение, на некоторых позициях даже решающее. И нет, это не…

Вот ТУТ я описывал концепт собеседования работодателя кандидатом.

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

Прикладываю список вопросов отдельным pdf-файлом.

Сохраняй себе на случай собеседований. Делись своими вопросами в комментариях.

#карьера_и_деньги

Собеседуем работодателя

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

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

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

https://telegra.ph/Sobeseduem-rabotodatelya-08-06

#карьера_и_деньги

Telegraph

Собеседуем работодателя

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

Dev notes на практике

Что такое dev-notes и зачем это нужно, я писал вот ЗДЕСЬ

Вкратце, dev-notes - это предварительное описание решения от разработчика. Иногда ещё называется design review процессом. Т.е. перед тем как реализовывать фичу - разработчик проектирует решение, которое ревьюят его коллеги. Обычно dev-notes пишутся для небольших и средних фич.

Dev-notes не имеет чётко выраженной структуры. Я бы предлагал адаптировать под ваш проект. Скелет структуры:
- API для фронтенда - какие методы будут затронуты, как изменятся контракты, являются ли изменения обратно несовместимыми
- API для внешних потребителей (если есть отдельное) - какие методы будут затронуты, как изменятся контракты, являются ли изменения обратно несовместимыми
- фронтенд - что можно вынести в компоненты для последующего переиспользования, какие элементы будут затронуты
- бэкенд - какие компоненты внутренней архитектуры бэкенда и какие конкретно классы будут затронуты. Если планируется добавлять работу с брокером сообщений - нужно указать используемые контракты.
- структура БД - какие таблицы нужно будет затронуть и что в них изменить.

Если вы используете микросервисную архитектуру и во время фичи нужно затрагивать несколько сервисов или вы описываете очень крупную фичу- лучше использовать ADR. Об этой концепции я рассказывал ЗДЕСЬ и ЗДЕСЬ

#процессы

Способы решения replication lag

Ранее я писал о репликации:
Основы
Виды
Отказоустойчивость

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

1) отображение своих данных
Проблема - пользователь опубликовал твит, перезагрузил страницу и не увидел своего твита. Т.к. он записывал данные в мастер-реплику, а читал с одной из слейв-реплик, на которую ещё не дошли данные с мастер-реплики.

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

2) монотонное чтение
Проблема - пользователь обновил ленту, увидел твит1. Ещё раз обновил ленту - твит1 пропал. Такое может случиться, если запросы были адресованы на разные реплики. И на одну реплику данные уже могли поступить, а на другую ещё нет.

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

3) получение данных в правильном порядке
Проблема - твит2 является ответом на твит1. Пользователь открывает ленту - видит твит2, но не видит твит1. Это происходит из-за шардирования - твиты могли быть записаны в разные шарды и реплики этих шардов ещё не получили всех последних данных.

Решение - связанные данные записывать в один шард. Таким образом, данные будут реплицированы уже в согласованном состоянии. Если клиент видит твит2 - то он точно видит твит1.

#архитектура_и_распределённые_системы

Graceful degradation

Изящная деградация или плавное сокращение функциональности.

Это подход в проектировании, при котором система продолжает выполнять свою основную функцию, даже если отдельные её компоненты вышли из строя.

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

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

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

ACID и BASE транзакции

ACID-транзакции - согласованность в ущерб доступности. Если на любом этапе транзакции возникает ошибка - вся транзакция откатывается.

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

ACID
- атомарность - все результаты транзакции либо полностью приняты, либо полностью отвергнуты
- согласованность - если транзакция принята, то гарантируется, что данные в согласованном состоянии - внешние ключи, уникальность значений, not-null и прочие ограничения
- изоляция - сколько бы не было транзакций будет создаваться впечатление, что они выполняются последовательно. Транзакции не будут мешать друг другу
- надёжность - если транзакция сохранила данные, то они останутся в БД, даже в случае сбоя системы (например, в результате отключения электричества).

BASE
- basically available (базовая доступность) - БД должна быть доступна одновременно для всех пользователей в любое время. Если одна из реплик недоступна - система всё равно работает, т.к. данные получаются с другой реплики. Также система может писать данные, т.к. если из строя вышла мастер-реплика, одна из слейв-реплик возьмёт её обязанности на себя
- soft state (мягкое состояние) - любые данные могут находиться в промежуточном состоянии и поменять своё значение по итогу без выполнения новых операций. Т.е. значение будет может быть окончательно определено только когда закончились и подтвердились все write-операции
- eventual consistency (согласованность в конечном счёте) - продолжение предыдущего пункта. Все данные достигнут своего конечного состояния, когда закончатся и зафиксируются все операции записи. Только после этого все пользователи системы увидят одни и те же данные.

Отличия
- масштабирование
ACID БД хуже масштабируются горизонтально т.к. ориентированны на согласованность. И для одной записи в момент времени может быть выполнена только одна транзакция, а это усложняет масштабирование.
BASE БД хорошо масштабируются горизонтально т.к. им не нужно поддерживать строгую согласованность.

- гибкость
ACID БД менее гибки засчёт обязанности поддерживать строгую согласованность.

- производительность
ACID БД менее производительны, т.к. обрабатывают все запросы в строгом порядке и обязаны поддерживать постоянную согласованность данных.
Т.к. BASE БД не имеют таких ограничений - они работают быстрее.

Что, когда использовать
ACID БД идеально подходит для корпоративных приложений, в которых требуется согласованность, надёжность и не так важна скорость работы. Также это лучший выбор для банковских приложений, где целостность и надёжность намного важнее скорости.

BASE БД лучше подходят для аналитической обработки слабо структурированных данных в больших объёмах. Например, сервис по сбору аналитики - намного важнее, чтобы он быстро принимал все новые данные и не так важно, что отчёт будет в конечном состоянии только через какое-то время.

Разница между CQS и CQRS

CQS (command query separation) - концепция, определяющая 2 типа операций, обрабатываемых в системе:
1) команды - выполняют какое-либо действие, модифицируют данные;
2) запросы - возвращают данные из системы.
Цель - упростить понимание системы, уменьшить вероятность возникновения побочных эффектов.

CQRS (command query responsibility segregation) - это архитектурный паттерн, который применяет концепцию CQS.
Он разделяет систему на 2 части: одна для выполнения изменений в системе, а вторая для чтения данных системы.
Цель - повышение производительности и масштабируемости. Упрощение компонентов за счёт разделения ответственности
CQRS более сложен в реализации, т.к. может требовать различных баз данных для чтения/записи, решения проблемы несогласованности данных.

В этом посте описывал паттерн CQRS - https://t.me/DotnetBackendStudy/65

Здесь представлена архитектурная схема паттерна CQRS- https://t.me/DotnetBackendStudy/66