**КАЙФОВОЕ СОБЕСЕДОВАНИЕ на Системного Аналитика — Transcript & Summary | SozAI** Source: https://sozai.app/transcript/system-analyst-job-interview-experience/ Разбор реального собеседования на системного аналитика: как отвечать на вопросы о карьере, архитектуре, оценке задач и работе с ошибками. Практические советы от Вадима Новосёлова. ## Key Takeaways - На собеседовании важно быстро показать цельный профессиональный образ, а не просто перечислять опыт - Архитектурные решения принимаются под конкретную задачу, а не по моде - Оценка аналитических задач должна быть декомпозирована и учитывать риски и зависимости - Сильный ответ о собственной ошибке содержит анализ причин, масштаба, исправления и выводов для команды - Качественные вопросы интервьюеру показывают вовлечённость и понимание предметной области ## What the video covers - Видео разбирает реальное собеседование кандидата на системного аналитика в компанию по защите ПО и разработке ИИ - Автор ставит видео на паузу и комментирует, как сильнее отвечать на каждый вопрос - Первый вопрос про путь в IT: важно сразу собрать у интервьюера цельный образ специалиста с понятной ролью и стеком артефактов - Разбор выбора между монолитом и микросервисами: микросервисы оправданы только когда части системы действительно можно разделить - Вопрос про баланс скорости и качества: решение зависит от критичности задачи, рисков и цены ошибки; MVP допустим для некритичных задач - Работа с непонятными требованиями: составить список стоп-факторов и искать источники их устранения - Оценка эпика аналитики строится снизу вверх: декомпозиция, отдельная оценка работ, рисков и зависимостей - Ответ про совершённую ошибку должен содержать что произошло, к чему привело, как исправили и какие правила ввели - Вопросы кандидата интервьюеру должны показывать интерес к продукту, процессам и росту - Автор рекламирует помощь менторов для подготовки к собеседованиям ## Chapters 1. 00:00 Введение и знакомство с кандидатом 2. 01:43 Монолит против микросервисов 3. 03:23 Скорость или качество: как выбирать 4. 06:06 Работа с непонятными требованиями 5. 08:00 Оценка задач системного аналитика 6. 14:14 Ошибки и работа с инцидентами 7. 17:00 Вопросы кандидата и онбординг 8. 20:40 Роль менторов и итоги Answers ## Questions about this video Почему автор считает, что первый ответ кандидата был слабым? Кандидат честно и подробно рассказывал опыт, но не собрал его в единый образ специалиста. По словам автора, на первом вопросе интервьюер должен сразу понять роль, контекст и стек артефактов кандидата. Как правильно выбирать между скоростью и качеством в работе аналитика? Сначала нужно оценить критичность задачи, риски и последствия ошибки. Если цена ошибки высокая, приоритет у качества; для некритичных или проверочных задач допустим подход MVP без ущерба стабильности. Как оценить эпик в роли системного аналитика? Оценка строится снизу вверх: эпик раскладывается на части, отдельно оцениваются работы, риски, зависимости и неизвестность. Только после этого получается вменяемая итоговая оценка. ## Full Transcript — Download SRT & Markdown 00:00 Speaker A Привет. Сегодня я покажу тебе реальное собеседование в одну очень хорошую компанию по защите ПО и разработке собственного искусственного интеллекта. 00:06 Speaker A Это собеседование на системного аналитика. Всё будет как обычно. Кандидат будет отвечать на вопросы, я буду ставить видео на паузу и разбирать то, как правильно на эти вопросы лучше отвечать. А как отвечать вообще не стоит. Записывай все вопросы, на которые я буду отвечать. Это поможет тебе получить оффер можно скорее. Поэтому наливай себе чаёк или кофеёк, как в моём случае, и будем учиться на чужих ошибках. Погнали. 00:17 Speaker A Прежде всего хотел бы попросить тебя рассказать пару слов о себе. Какой был твой путь? Как пришёл во IT? Нравится, не нравится, в чём всё, что посчитаешь нужным, можно кратенько, можно некратенько рассказать. 00:25 Speaker A IT — это, наверное, увлечение в целом со школы ещё было. Можно, наверное, с этого начать. Пошёл, соответственно, учиться на специальность соответствующую, ну, не совсем туда, куда хотел, но в целом направление тоже. То есть я хотел пойти на, как она там правильно называлась, комплексное обеспечение информационной безопасности автоматизированных систем. Но туда я не прошёл по рейтингу. Ну, скажем так, там более приоритетные кандидаты заняли места. Я занимался, учился на специальности «информационные системы и технологии» в «технической физике». Там ну можно сказать, что 50 на 50 было. Это профильное направление непосредственно факультета физико-технического. А второе — это всё, что связано с информационными технологиями. Дальше, соответственно, я пошёл работать именно по направлению IT. 00:34 Speaker A И спустя какое-то время после начала работы я параллельно, скажем так, с основной обязанностью системного администратора начал выполнять некоторые функции, которые связаны с требованиями к программному обеспечению. Дальше, соответственно, на новом месте работы я уже работал аналитиком. С 2018 года аналитиком работать продолжаю. 00:50 Speaker A Хороший ответ здесь мог звучать примерно так. Я системный аналитик, работаю с 2018 года, в Full Cycle аналитике, и работал на проекте генетической лаборатории: собирал требования, писал юзкейсы, прорабатывал экранные формы, делал ER-диаграммы и писал контракты на GraphQL. Работал я всегда на стыке заказчика, фронта и бэка. Когда уже на первых секундах становится понятно, что у человека есть профильная роль и релевантный контекст, понятный стек артефактов и нормальный уровень погружённости в процессы, — а у нашего кандидата видно, что опыт есть, но подача какая-то очень слабенькая. Ну, точнее, слабее, чем могла бы быть. Он рассказывает всё очень честно и подробно, но у интервьюера в голове это не собирается в единый образ специалиста, а именно это и должно происходить на первом вопросе, чтобы всё оставшееся собеседование прошло гладенько. И, кстати, ты можешь получить помощь с подготовкой к собеседованиям от наших менторов. Ссылочка будет в описании. И теперь разберём следующий момент собеседования. 01:08 Speaker A Сейчас задам вопрос, потом прыгнем сразу обратно. Я правильно понимаю, что твой проект сейчас это микросервис? Это не монолит? 01:22 Speaker A Скажем так, история у него сложная. Здесь первоначально архитектор закладывал микросервисную архитектуру, но из-за того, что очень много сущностей связаны друг с другом и ссылаются друг на друга, это всё обратно в монолитную архитектуру было переделано. Ну, не обратно, переделано, в общем, в монолитную архитектуру. 01:43 Speaker A Монолиты и микросервисы — это два разных подхода к архитектуре системы. Монолит — это когда приложение собрано в одну большую систему, а микросервисы — это когда система разбита на отдельные сервисы, и каждый отвечает за свою часть логики. На словах микросервисы звучат всегда очень красиво. Это масштабируемость, независимые команды, гибкость, отдельные сервисы. Но на практике они хорошо работают только тогда, когда части системы действительно можно разделить без постоянной боли. Вот здесь кандидат отвечает достаточно интересно. Он говорит, что систему сначала пытались строить как микросервисную, но потом откатились в монолит. Почему? Потому что сервисы оказались слишком связаны друг с другом. 01:59 Speaker A А это, кстати, и есть их основная ключевая проблема. Если данные, сущности и процессы постоянно пересекаются, сервисы начинают бесконечно дёргать друг друга, интеграции усложняются, а любая доработка становится дороже и медленнее. 02:13 Speaker A То есть проблема не в том, что микросервисы — это плохо, а в том, что их часто пытаются внедрить туда, где система к этому просто не готова. И поэтому кандидат здесь ответил нормально. Он показывает, что понимает главное: архитектуру выбирают не потому, что это модно, а потому, что она подходит под конкретную задачу. 02:26 Speaker A Да. Начнём с такого вопроса. А что для тебя в работе важно, важнее скорость или качество работы? Как ты оцениваешь, что вот я закончил всё, моя работа здесь сделана, можно её дальше отдать, допустим, на ревью? Да, здесь, наверное, всё равно нужна какая-то экспертиза, но в том плане, что должен быть опыт для того, чтобы проводить такую оценку, ну, видимо, на конкретном проекте. Тут проще, наверное, так будет сказать. И исходя из опыта просто понимать, что данного объёма, скажем так, изложенного в постановке будет достаточно исполнителю для того, чтобы выполнить свою задачу. 02:32 Speaker A Верно. Угу. Ну, то есть в целом, да, можно либо, допустим, с тем лидом стыковаться и сказать: «Да, что будет достаточно?» Да, это хороший ответ. 02:37 Speaker A Это один из самых частых вопросов на собеседовании, потому что на самом деле здесь проверяют не то, что ты выберешь, а как ты принимаешь решение в условиях ограничений. Потому что если ответить всегда «скорость», это звучит как «готов делать всё на коленку». А если ответить всегда «качество», это звучит так, будто я бесконечно буду всё полировать и никогда не буду закрывать задачи в срок. Правильная логика здесь такая. 02:55 Speaker A Сначала нужно понять контекст задачи. Для аналитика это обычно означает четыре вещи: насколько задача критичная и каков риск ошибки. Что будет, если сделать быстро, и что будет, если задержать решение? Например, если речь идёт про критическую интеграцию и расчёт денег, безопасность или какой-нибудь важный пользовательский сценарий, там цена ошибки очень высокая. А значит, и приоритет смещается в сторону качества. 03:07 Speaker A Больше проверок, больше уточнений, больше аккуратности. А если задача менее критична, например, цель — быстро проверить гипотезу, собрать обратную связь или выкатить первый рабочий вариант, то логично идти в сторону MVP. 03:23 Speaker A Это не «сделать плохо и побыстрее». Это значит сделать минимально достаточный объём, без которого дальше невозможно двигаться, и не тратить время на второстепенные вещи. И если перевести это в сильный ответ на собеседовании, то он должен звучать примерно так: я не выбираю между скоростью и качеством абстрактно. Я сначала смотрю на критичность задачи, риски и последствия. Если цена ошибки высокая, приоритет качеству. Если задача проверочная или некритичная, иду через MVP, но без ущерба стабильности. 03:30 Speaker A Кандидат в целом идёт в правильную сторону. Он говорит про полезность и про то, что нужно смотреть на последствия. Но ответ можно было сделать сильнее, если бы он назвал сам принцип явно: сначала контекст, а потом уже решение. 03:42 Speaker A Вот тебе пришла задачка, да, или требование. Ты читаешь и тебе непонятно. По какой причине непонятно? Ну, неважно. Это может быть, понятно, недостаточность опыта, да, в продукте, погружённость или в целом по предметной области что-то. Что ты будешь делать, когда тебе придёт, допустим, от лида аналитики такая задача на проработку, а ты в ней, ну, что-то здесь, наверное, после ознакомления с той информацией, которая предоставлена, можно составить список того, что можно назвать стоп-факторами. То есть определить для себя, что именно мешает продвинуться в прогрессе или чего не хватает для выполнения этой задачи. А дальше уже работать с тем, какие источники доступны для того, чтобы все эти, ну, сто факторов устранить. То есть это может быть документация, не знаю, код, данн 03:53 Speaker A что это модно, а потому, что она подходит под конкретную задачу. Да. Начнём с такого вопроса. А что для тебя в работе важно, важнее скорость или качество работы? Как ты оцениваешь, что вот я закончил всё, как бы моя работа 04:08 Speaker A здесь сделана, можно её там дальше отдать, допустим, ну, на ревью, да, то есть ну здесь, наверное, всё равно нужна какая-то экспертиза, но в том плане, что должен быть опыт для того, чтобы проводить такую оценку, ну, видимо, на конкретном проекте. Тут проще, наверное, 04:22 Speaker A так будет сказать. И исходя из опыта, просто понимать, что данного объёма, ну, скажем так, изложенного в постановке будет достаточно исполнителю для того, чтобы выполнить свою задачу. 04:32 Speaker A [откашливается] Верно. Угу. Ну, то есть в целом, да, можно либо, допустим, с с тем лидом, да, стыковаться и сказать: "Да что, что будет достаточно?" Да, это хороший ответ. 04:42 Speaker A Это один из самых частых вопросов на собеседовании, потому что на самом деле здесь проверяют не что ты выберешь, а как ты принимаешь решение в условиях ограничений. Потому что если ответить всегда скорость, это звучит как готов делать всё на коленку. А если ответить 04:54 Speaker A всегда качественно, это звучит как будто я бесконечно буду всё полировать и никогда не буду закрывать задачи в сроке. Правильная логика здесь такая. 05:01 Speaker A Сначала нужно понять контекст задач. Для аналитика - это обычно означает четыре вещи: насколько задача критичная и каков риск ошибки. Что будет, если сделать быстро и что будет, если задержать решение? Например, если речь идёт про критическую интеграцию и расчёт денег, 05:14 Speaker A безопасности или какой-нибудь важный пользовательский сценарий, там цена ошибки очень высокая. А значит, и приоритет смещается в сторону качества. 05:21 Speaker A Больше проверок, больше уточнений, больше аккуратности. А если задача менее критична, например, цель быстро проверить гипотезу, собрать обратную связь или выкатить первый рабочий вариант, то логично идти в сторону MVP. 05:30 Speaker A Это не сделать плохо и побыстрее. Это значит сделать минимально достаточный объём, без которого дальше невозможно двигаться и чтобы не тратить время на второстепенные всякие вещи. И если перевести это в сильный ответ на собеседование, то он должен звучать примерно так. Я не выбираю между 05:43 Speaker A скоростью и качеством абстрактно. Я сначала смотрю на критичность задачи, риские и последствия. Если цена ошибки высокая, приоритет качеству. Если задача проверочная или некритичная, иду через MVP, но без ущерба стабильности. 05:54 Speaker A Кандидат в целом идёт в правильную сторону. Он говорит про полезность и про то, что нужно смотреть на последствия. 05:58 Speaker A Но ответ можно было сделать сильнее, если бы он назвал сам принцип явно. Сначала контекст, а потом уже решение. 06:04 Speaker A Вот тебе пришла задачка, да, ну или требование. Ты читаешь и тебе непонятно. По какой причине непонятно? Ну неважно. 06:12 Speaker A Это может быть там, понятно, недостаточность там опыта, да, в продукте, там погружённость или в целом там по предметной области что-то. Что, что ты будешь делать, когда тебе придёт вот, допустим, от лида аналитики тамк на проработку, а ты в нём, ну, что-то вот 06:28 Speaker A здесь, наверное, ну, после ознакомления с той информацией, которая предоставлена, можно составить список, ну, чего-то, что можно называть стопфакторами. Ну, то есть определить для себя, что именно мешает продвинуться в прогрессе или, ну, чего не хватает для выполнения этой задачи. А дальше уже 06:45 Speaker A работать с тем, какие источники доступны для того, чтобы все эти, ну, 100факторы устранить. То есть, ну, это может быть документация, не знаю, там код, ээ, данные в базе посмотреть уточнить ну получается профильного специалиста, уточнить коллег. 07:01 Speaker A А сколько бы ты себе времени дал на самостоятельное, так скажем, поиск информации? Здесь, наверное, надо исходить из общей оценки времени, которая установлена на эту задачу. Ну, то есть разбить на этапы, когда к какому следует приступить. Ну, там, понятно, с 07:19 Speaker A заложенными резервами. на основании этого, наверное, строить, ну, исходя из такого рассуждения, что если я к такому-то моменту не продвинусь самостоятельном изучении, то мне необходимо искать, ну, скажем так, повышать приоритет, как-то эскалировать эту ситуацию для того, видимо, чтобы уже 07:37 Speaker A подключать коллег, ну, других сотрудников для решения этого вопроса. Это одна из самых жизненных ситуаций в работе аналитика. Почти никогда требования не приходят в идеальном виде. 07:46 Speaker A Обычно не хватает деталей, бизнес-правил, крайних случаев, ограничений или просто контекста, без которого нельзя нормально составить задачу для разработчика. Например, в задаче может быть написано: "Нужно добавить новый статус заявки". И на первый взгляд всё понятно. Но как только начинаешь копать глубже, сразу вылезают 08:00 Speaker A вопросы: кто может менять этот статус? Из каких состояний его можно перейти? Что должно происходить после смены, что увидит пользователь, что удёт во внешние системы и что делать, если данные уже лежат в старом формате. И в этот момент хороший аналитик не просто говорит: 08:12 Speaker A "Требований немало", он переводит это в конкретный рабочий формат. Что именно? Непонятно, почему это мешает двигаться дальше и какие риски создаёт это для команды. И взрослый, сильный, серьёзный подход здесь выглядит примерно так. 08:22 Speaker A Сначала ты собираешь список неопределённостей, потом отделяешь мелкие вопросы от критичных, а дальше закрываешь в первую очередь то, без чего разработка реально могла пойти не туда. 08:30 Speaker A Например, если тебе не ясно, как выглядит подпись поля на форме. Это, конечно, неприятно, но и не смертельно. 08:36 Speaker A А вот если непонятно, какие данные уезжают во внешнюю систему и как работает валидация или какие переходы статусом допустимы, это уже реально критично. Ещё один важный момент. В жизни далеко не всегда можно быстро получить ответ. Поэтому зрелый аналитик умеет не только уточнять, но и 08:50 Speaker A фиксировать рабочие предложения, то есть прямо писать. Если до такого-то момента уточнение не получено, работаем по предположению. Этим он спасает команду от хаоса и снимает часть сюрпризов на следующих этапах, но при этом берёт ответственность на себя. Сам кандидат отвечает в правильную сторону. Он 09:03 Speaker A говорит про уточняющий контекст, документацию, коллег, код, базу. Это уже хороший знак, потому что видно, что человек не просто ждёт, пока ответ прилетит сам. Но его ответ на этот вопрос можно было сделать сильнее, если бы он прямо показал системный подход к 09:15 Speaker A неопределённости, а не просто перечислил источники, куда можно пойти за ответом. Слушай, а ты вот коснулся такого вопроса, это оценка задач аналитики, да? 09:26 Speaker A То есть ты говоришь там от оценки сколько там требуется. А как вообще оценить задачу аналитики? Ну тебе приходит эпик, да? Как бы ты его оценил? 09:35 Speaker A Сколько у тебя уйдёт времени? И вообще возможно ли это? Возможно или нет? Тут, скорее всего, зависит от точности. Ну, то есть это, ну, вот мой любимый, наверное, пример здесь. Это, ну, не знаю, будет понятно или нет. Есть такая игра XCOM. Ну, грубо 09:49 Speaker A говоря, это про сражение с инопланетянами. И там один из аспектов есть - это изучение технологий. Вот. Ну, в общем случае, наверное, чем меньше информации, тем ближе это к XCOM, что сроки исследования неизвестно, результат тоже заранее неизвестен, к чему это 10:04 Speaker A приведёт. Ну, опять же, крайние случаи, они редко бывают. и когда можно всё чётко просчитать, и когда, ну, совсем непонятно, скорее всего, здесь, ну, больше от опыта, от каких-то договорённостей с коллегами можно было бы исходить из того, сколько примерно на 10:20 Speaker A задачу может уйти, ну, и поставить для себя какие-то внутренние сроки для исполнения, ну, каждого из этапов этой задачи. 10:28 Speaker A Оценка задачи для аналитика - это не просто сказать цифру на глаз. Это попытка заранее понять, из каких частей состоит работа и где в ней есть узкие места и что может неожиданно съесть в твоё время. Потому что у аналитика время 10:39 Speaker A уходит не только на подумать и написать. В реальности туда почти всегда входит разбор требований, уточнения, созвоны, согласования, описание артефактов, правки после интервью. Иногда туда входит ещё повторный круг обсуждения, если всплыли какие-нибудь новые вводные. 10:52 Speaker A Например, если приходит задача на новую интеграцию, аналитик оценивает не просто как описать API, он должен понять, какие системы участвуют, какие данные входят между ними. Есть ли ошибки Еритраи, кто владелец контракта, что нужно фронту, что нужно БКУ и сколько вообще 11:06 Speaker A понадобится итераций, чтобы всё согласовать. Поэтому сильная оценка обычно строится снизу вверх. Сначала задача раскладывается на части и потом отдельно оцениваются сами работы и отдельно всякие риски, зависимости неизвестность. Только после этого появляется вменяемая цифра. И вот здесь очень важный момент. Хороший специалист 11:21 Speaker A редко называет одну точную цифру, особенно если задача очень сырая. Потому что такая цифра создаёт ложное ощущение контроля и гораздо честнее и профессиональнее давать диапазон. и сразу проговорить, от чего этот диапазон зависит. То есть оценка аналитика - это не всегда только про объём работы, но и 11:36 Speaker A про степень определённости задач. Чем меньше понятного контекста на старте, тем выше погрешность. Сам кандидат отвечает в целом правильно. Говорит про объём анализа, интеграции, сложность логики. То есть базовое понимание у него есть. Но ответ можно было сделать гораздо сильнее, если бы он показал 11:51 Speaker A механизм самооценки. Не просто что влияет, а как именно он это собирает и эту оценку. То есть интервьюр должен понять, что перед ним не просто человек, который просто называет сроки, а специалист, который понимает, откуда вообще этот срок берётся. 12:02 Speaker A Меня прежде всего интересует, какое твоё самое, на твой взгляд, а, большое достижение в последнем месте работы, и второе, какой был самый жёсткий косяк и как вы его решали. 12:11 Speaker A Наверное, здесь была ключевая перестройка одной из основополагающих сущностей, которые находятся в стеме, э, и проработку всех аспектах, связанных теми, скажем так, связанными сущностями. 12:22 Speaker A Это вот то, что в последнем контракте было. Из того, что можно отнести к провалам. Наверное, самое большое - это вот у меня воспоминание опять же с первого места работы. Там как ну какой состав получается был и что делали. Там были разработчики, я как 12:36 Speaker A аналитик и системные администраторы, они же специалисты по телефонии. И мы вместе с ними обкатывали новую фичу. И была доработка, что мы, ну, скажем так, мониторим, сколько есть свободных операторов в дополнительных группах, и часть вызовов них перекидываем на, ну, 12:54 Speaker A получается, основное группы для того, чтобы эффективнее всё обрабатывать, качество сервиса просто повышать. И там был такой момент, что мы, когда писали скрипт для телефонии, у нас ну вот этот новый под новую логику. У нас ээ очень много вызовов из-за того, что они 13:10 Speaker A попадали там по одному из условий в цикл вот такой, из которого выйти нельзя было и в котором никаких действий не было. Ну при этом заранее нельзя было посмотреть. 13:18 Speaker A У нас очень много было именно потерь. Ну то есть качество сервиса серьёзно упало. Там опять же нюанс был такой, что это всё тестировалось преимущественно только вот, ну, вместе с администраторами. 13:29 Speaker A Отдельных тестировщиков у нас не было, ни протоколов тестирования, ничего не было. То есть это всё вот, ну, можно сказать, на коленке было сделано. Ну и вот когда мы это обнаружили, соответственно решили что ну опять же, мы систему тестирования проработаем 13:42 Speaker A более тщательно, больше не даём согласия на такие экстренные запуски, когда от менеджмента приходят задачи на то, чтобы в кратчайщие сроки какую-то новую, ну, вот подобную логику оптимизационную запустить. 13:56 Speaker A Тогда последний вопрос. Скажи, пожалуйста, если ты получишь от нас офер, как быстро ты сможешь выйти? 14:01 Speaker A Через 2 недели после получения? Угу. То есть там есть необходимость отрабатывать, правильно понимаю? Да. 14:07 Speaker A О'кей. Хорошо. Тогда вопросов у меня больше нет. Честно скажу, мне интервью понравилось, мне понравились живые примеры, мне понравился XCOM. Я знаю, что это за игра. Здорово, что кто-то знает её тоже. Вот. Ну ладно, о'кей. 14:19 Speaker A Это одно из самых показательных вопросов на собеседовании, потому что здесь проверяется не то, как ответит человек, а то, как он после ошибки. И хороший ответ здесь почти всегда строится по одной и той же схеме. Что именно произошло? К чему это привело? и как это 14:33 Speaker A исправили и что изменили в процессе, чтобы проблема не повторилась. Кандидат здесь вспоминает кейс со своего первого места работы кол-центра и доработку логики к телефонии. Смысл в том, чтобы перераспределить звонки между группами операторов и таким образом повышать качество сервиса. Но на запуске новая 14:49 Speaker A логика ломалась, и часть вызовов по одному из условий попадала в цикл, из которого нельзя было выйти. В результате звонки терялись, а качество сервиса серьёзно просело. И вот здесь как раз-таки начинается самое важное. 14:59 Speaker A Хороший ответ про ошибки - это не просто, ну, бывает, а нормальный разбор причин. И кандидат здесь даёт одну очень важную деталь, что проблема была не в самом сервисе телефонии, но в процессе. 15:08 Speaker A И у них не было нормального тестирования, не было отдельных тестировщиков, не было внятных протоколов, проверки. По сути, всё делалось на коленке. Это уже сильное заявление с его стороны, потому что сильный аналитик всегда отличает симптом от причин. Симптом - это то, что звонки 15:20 Speaker A потерялись, а причина - это то, что команда выпустила новую логику без нормального процесса проверки. И дальше кандидат говорит главное, что после этого они пересмотрели подход к тестированию и решили больше не соглашаться на такие срочные запуски без нормальной проверки. И это именно то, 15:35 Speaker A что интервьюер хочет услышать после любого факапа. Какой процесс вы применяли после ошибки и что вы с этим делали? Какие выводы вы сделали? По сути, у кандидата есть реальный кейс, реальные последствия и реальные выводы. 15:46 Speaker A Это уже сильно лучше, чем типичный безопасный ответ по типу: "Я слишком много работаю". Это мой главный минус. 15:51 Speaker A Но усилить ответ всё равно можно было. Не хватило более чёткой структуры. В чём именно была ошибка? Какой был масштаб последствий? Кто участвовал в исправлении и какие новые правила команда вела после инцидента? Потому что сильный ответ на такой вопрос - это не 16:03 Speaker A просто признание косяка. Это демонстрация взрослого профессионального мышления. Ошибся, разобрался, исправил. Сделал так, чтобы это больше никогда не повторяло. 16:11 Speaker A Если у тебя какие-то вопросы есть сейчас, то я думаю, что самое время их задать. То есть относительно состава команды, да, с кем работать необходимо будет и либо тебе, возможно, есть какие-то вопросы по продукту, то, наверное, я думаю, что мы можем вперлом 16:22 Speaker A ответить. Если сейчас что-то не удастся задать, то можно задать чуть попозже через Аню. Мы тоже будем готовы ответить. 16:27 Speaker A Из того, что сейчас, наверное, у меня вопрос только по каким-то, может быть, неочевидным моментам, которые, ну, вот в таком изучении будущей работы не совсем ясны. Может быть, ну вот есть какие-то моменты, на которые ещё стоит обратить внимание, там к чему подготовиться, 16:42 Speaker A может быть, что-то изучить, чтобы Ты знаешь, прости, что я тебя перебил, услышал вопрос. Я боюсь, что подготовиться будет достаточно сложно. 16:51 Speaker A Это проще значительно будет делать в процессе анбординга. Вот поэтому тех знаний и навыков именно рабочих, которые ты сейчас перечислил, в целом на первых парах будет достаточно. Однако в процессе погружения однозначно придётся какие-то вещи изучать. Ну какие, естественно, мы дадим. То есть мы 17:07 Speaker A составим планбординга, в рамках которого предстоит изучить различные пилы, понять специфику их работы, в том числе взаимодействие, интеграции с нашим продуктом. Ну вот. И, соответственно, уже в дальнейшем можно будет сориентироваться, да. Спасибо. Я понял, так скажем, новичка каких-то суперрезультатов, потому что 17:24 Speaker A действительно предметная область и предметная область очень большая и сложная, и продукт большой, и сложный. 17:30 Speaker A Онбординг у нас достаточно плавный, да? То есть у тебя в любом случае на протяжении испытательного срока будет куратор, который тебе на любые вопросы ответит, будет помогать именно непосредственно по работе. Плюс, э-э, встречи там от меня или Миши, а, с 17:50 Speaker A рассказами в целом о продукте, о, об экосистеме, потому что у нас на самом деле не один продукт, как у вендера, у нас их много. То есть помимо внешних инструментов других вендеров, у нас ещё есть продукты нашего, ну, наши же 18:04 Speaker A продукты соседних команд. Мы с ними тоже интегрированы. Вот, поэтому это всё плавно, это всё не сразу. Вот. А так в целом, девсяп по данному слову, да? как это аббревиатуре можно посмотреть информацию в целом о том, чем мы занимаемся. Dev ops, то есть есть 18:22 Speaker A девоops процесс, да, есть ops. Вот мы часть сек обеспечиваем. То есть мы берём обычный для вас процесс, да, и его так мягонько приобнимаем. 18:31 Speaker A У меня больше вопросов нет. Спасибо. Финальный вопрос на собеседование. Есть ли у вас к нам какие-то вопросы? И многие почему-то до сих пор это считают формальностью. На самом деле это не вежливый хвост беседы, а на самом деле ещё одна проверка, где узнают кандидата, 18:43 Speaker A он осознанно выбирает компанию или просто надеется, что его хоть куда-то возьмут. Потому что сильный кандидат на этом моменте не спрашивает абстрактное: "Ну а что, у вас всё нормально или нет?" Он пытается понять три вещи: как здесь устроена работа, что от него будут ждать 18:55 Speaker A и с чем ему придётся столкнуться первый месяц. В целом он здесь задаёт правильные вопросы, и он спрашивает не сколько у меня там будет корпоративов или вообще будут ли они, а то, на что стоит обратить внимание заранее и к чему 19:05 Speaker A стоит готовиться, что стоит изучать. То есть пытается понять, насколько сложным будет вход в продукт и что его здесь ждёт на обординге. Но этот блок, конечно же, можно было сделать немножко сильнее, потому что лучшие вопросы кандидата обычно делятся на несколько типов: про 19:17 Speaker A ожидания, про процессы, про команду и про критерии успеха на роль. Например, достаточно хороший вопрос был бы: "А как вы вообще понимаете, человек прошёл испытательный срок или нет? Какие задачи будут у меня в первый месяц? И как принимаются продуктовые архитектурные 19:31 Speaker A решения? Или, например, что чаще всего тормозит аналитика в вашей команде? Почему эти вопросы сильные?" Потому что в них нет позиции: "Ну, возьмите меня хоть куда-нибудь". У них есть позиция, я хочу понять, как здесь происходит результат. Именно поэтому вопросы 19:43 Speaker A кандидата в конце собеседования - это не вежливая часть, а достаточно важная очень часть самопрезентации. То есть здесь кандидат уже не отвечает на вопрос, что я умею, он отвечает на вопрос, что я вообще думаю о работе. Что же, собеседование пройдено, и перед тем, 19:55 Speaker A как рассказать, получил кандидат офер или нет, ты должен узнать одну очень важную вещь. Ведь раз ты посмотрел это скучное видео полностью, ты реально хочешь устроиться на работу, войти. Но большинство айтишников теряют миллион полто руб. на этапе подготовки. Просто 20:07 Speaker A так, даже не осознавая. Давай объясню. В IT сейчас можно сразу устроиться нала зарплатой от 200.000 руб. Почему же именно нала? Ну, есть отдельное видео на этот счёт, ты можешь посмотреть. Сейчас мы просто не будем на это отвлекаться. В 20:18 Speaker A среднем по трудоустройствам выходит 200 -ре250.000. И это не выдуманные цифры. Это реальная статистика нашей школы. Вот можешь посмотреть сам. Получается, что каждые лишние полгода подготовки - это миллион полто руб., которые ты просто подарил рынку. При этом рынок не стоит 20:32 Speaker A на месте. требования растут, и тот уровень, который сейчас даётся относительно легко, через год потребует в два раза больше усилий. Единственное, что реально сокращает этот путь, это другой человек, который прошёл его сам. 20:43 Speaker A Человек, который видит твои ошибки ещё до того, как ты их заметишь сам. Этот человек ментор, не курс с видосами, не универ, а живой человек, который скажет: "Стоп, ты тут делаешь что-то не так, и ты исправишь это за день, вместо того, 20:55 Speaker A чтобы рыться в этом месте". Но как вообще понять, что перед тобой реально сильный ментор? Вот четыре главных критерия. Первое, он с тобой не нянчится, а создаёт условия, где ты самостоятельно решаешь реальные рабочие задачи. Именно это и даёт выход сразу на 21:07 Speaker A медла, где реально меньше конкурентов и больше зарплат. Второй. Спроси прямо, что будет, если я всё сделаю правильно и не найду работу. Если внятного ответа нет - это уже красный флаг. Хороший ментор или школа всегда фиксирует гарантию. Офер от 200.000 руб. Иначе 21:20 Speaker A будет возврат денег. Третье. Тебя должны поддержать не только до офера, но и на испытательном сроке, потому что там больше всего обидных увольнений. Вот посмотри мою историю про это. И четвёртый. Перед стартом тебе просто обязаны сказать, какой у тебя уровень и 21:31 Speaker A сколько времени займёт путь до офера. Без этого ты просто покупаешь кота в мешке. Кстати, у нас это можно проверить бесплатно. Созвонишься с нами, разберём твой уровень и составим rootmap от обучения до офера. Даже если не попадёшь к нам, уйдёшь с конкретным планом и 21:43 Speaker A кучей пользы. Но это только если ты перейдёшь по ссылке в описании и заполнишь опрос в течение 5 минут после просмотра этого видео. Потом эта возможность просто сгорит, поэтому сделай это сразу, как закончишь просмотр. А теперь ответим на главный 21:53 Speaker A вопрос. Получил ли наш кандидат офер? Кандидат держался орешком, показывал себя хорошим, ответственным, взрослым специалистом, который понимает, что делает. Конечно, не суперзвезда, но надёжный, осознанный рабочий мидл, с которым приятно иметь дело. И такие ребята оферы получают без лишнего пафоса, за счёт нормальных ответов и 22:09 Speaker A адекватного подхода. Рекомендую посмотреть мой следующий обзор. Там ещё больше живых кейсов, ошибок, примеров, которые помогут вам заходить на собесы так, как будто вы принимаете на работу компанию, а не компания. Желаю всем жирных оферов и до встречи. Topics: системный аналитик собеседование IT карьера микросервисы монолит оценка задач требования разбор собеседования подготовка к собеседованию Учить по этому видео - [Карточки по этому видео](https://sozai.app/ru/tools/flashcard-maker/?from=transcript&id=87607) - [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=87607) - [Кроссворд по этому видео](https://sozai.app/ru/tools/crossword-maker/?from=transcript&id=87607) - [Филворд по этому видео](https://sozai.app/ru/tools/word-search-maker/?from=transcript&id=87607) - [Шпаргалка по этому видео](https://sozai.app/ru/tools/study-guide-maker/?from=transcript&id=87607) Бесплатно, составлено ИИ по этой расшифровке. Без регистрации. --- This is the markdown twin of https://sozai.app/transcript/system-analyst-job-interview-experience/ — the same content, without the markup. Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back. Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/