Менеджер, который устраивается в IT компанию, понимает, что ему предстоит работать с командой технарей, которые разговаривают «на своем языке». Понимание технической стороны рабочих процессов поможет менеджеру вести проекты правильно, уменьшить вероятность ошибок и решить большое количество сложностей в работе с клиентами.
Собрали в статью секреты и рекомендации спикеров курса TechMind — опытных менеджеров и технарей. Читайте, забирайте в копилку и легко проходите самые сложные собеседования.
12 главных пунктов, по которым задают вопросы на техническом собеседовании
Большинство технических собеседований проходят примерно одинаково. Рекрутер может задавать разные вопросы, но все они касаются определенных тем и направлений. Мы выделяем 12 главных пунктов, по которым наверняка будут вопросы:
- Жизненный цикл продукта
- Методологии
- Бизнес-аналитика
- Техническая документация
- Инструментарий проекта
- Архитектура
- Клиент-сервер
- REST
- Фреймворки, библиотеки, код
- Git
- Натив/кросс-платформы
- Тестирование
Давайте подробнее пройдем по каждому и разберем, какие вопросы могут задавать в этих темах.
Жизненный цикл продукта
Это не столько техническая тема, сколько проверка общих знаний менеджера, который стремится в IT-сферу. Вы должны уверенно подготовиться к этим вопросам, так как уже по ним рекрутер поймет, насколько вы разбираетесь в теме разработки и сможете ли работать в команде с технарями. Итак, вопросы и ответы к ним:
Какие этапы есть в жизненном цикле ПО
Формирование требований к ПО на стадии анализа, проектирование, реализация, тестирование, внедрение, эксплуатация и сопровождение, снятие с эксплуатации. Сначала идет стадия, которая отвечает на вопрос: «Что мы будем делать?». Вторая стадия отвечает на вопрос «Как мы это будем делать?». Дальше стадия реализации задуманного проекта, после — тестирование и внедрение. Завершающая стадия — сдача проекта и дальнейшая техническая поддержка.
Чем отличается формирование требований от проектирования
Формирование требований — это процесс, при котором менеджер выясняет у заказчика, какие именно бизнес-процессы он хочет автоматизировать и что он хочет получить. На этом этапе работают аналитики и проектный менеджер. Проектирование — процесс, при котором собирается команда разработчиков и определяет, как будут реализованы требования.
Что такое поддержка
Техническая поддержка не означает, что вы будете отвечать на звонки клиентов вашего заказчика. Речь идет о решении проблемных задач в случае нарушения работы продукта. Если что-то «ломается», перестает работать, команда разработчиков должна оперативно отреагировать и сделать так, чтобы все было хорошо.
Как происходит снятие с эксплуатации
Если продукт теряет свою актуальность, или его заменяют на более новое и техничное решение, происходит снятие с эксплуатации. Разрабатывается план, согласовывается, после чего начинается постепенное снятие с эксплуатации.
Пример: на предприятии есть десктопная версия продукта, но компания решила перейти на новое приложение, которое работает с мобильных устройств.
Разрабатывается стратегия перехода, подготавливается продукт, и постепенно переносятся все данные, обучаются сотрудники, внедряются новые инструменты.
Какие сотрудники нужны на каждом этапе жизненного цикла
При формировании требований участвуют бизнес-аналитики, на стадии проектирования ключевые люди — архитекторы и лиды разработчиков. На реализации проекта нужны программисты, дизайнеры. Тестированием занимаются QA инженеры. Для внедрения нужны практически все участники проекта, а «звезда» — проектный менеджер. Если команда выделяет инженера сопровождения, то он отвечает за техподдержку. Если его нет, то участвуют QA, разработчики и проектный менеджер.
Методологии
Выбор методологии не относится к техническому собеседованию, но есть вопросы, которые косвенно влияют на команду разработчиков. Например, какую форму оплаты труда выбрать. Вы можете столкнуться с такими вопросами:
В чем разница между Fix Price и Time&Materials
Fix Price подразумевает, что мы ведем проект за определенный бюджет. Компания оговаривает с заказчиком, что она делает и за какие деньги. Time&Materials применяется в том случае, если у клиента есть неопределенности и он не знает, каким будет финальный продукт. Он готов выкупать команду и платить за сделанную работу. Time&Materials часто применяется в гибкой методологии Scrum.
Какая модель лучше
Fix Price отлично работает для проектов, которые имеют строгий фиксированный бюджет и они четко знают, что хотят получить. В таком случае любые дополнения, изменения или предложения просто не реализуются. Time&Materials подходит для стартапов и проектов, где сложно понять точное количество задач и как будет выглядеть финальный продукт.
Бизнес-анализ
Проектный менеджер нередко выполняет функции бизнес-аналитика. Даже если этого не происходит, на собеседованиях рекрутеры хотят понять, насколько вы разбираетесь в направлении BA, и сможете ли выполнять его задачи. Вас ожидают следующие вопросы:
В чем разница между бизнес-аналитиком и системным аналитиком
Бизнес-аналитик — это человек, который разбирается в бизнес-процессах компании, которые необходимо автоматизировать. Детально разбирается в их особенностях и ищет подходы, которые помогут улучшить процессы. Изучает требования, цели и задачи заказчика.
Системный аналитик переводит информацию из формата «что нужно сделать» в формат «Как это сделать». Он составляет схемы, диаграммы, работает с технической командой и погружается в архитектуру.
Что такое User Story и Use Cases
User Story — это «история» клиента компании, который проходит путь с ней от начала до конца. Например, от входа в интернет-магазин до регистрации, оформления заявки и покупки товара.
Use Cases — это подробное рассмотрение User Story на определенном этапе. Например, клиент оставил заявку на сайте. Это один из этапов User Story. Но сам кейс — это заполнение конкретных полей при заказе.
Разница между функциональными и нефункциональными требованиями
Функциональные требования предполагают описание того, что нужно сделать. Изучаются требования заказчика. Нефункциональные требования касаются нетехнической части. Например, время отклика, на каких устройствах должно работать приложение. У нас есть отдельный курс по нефункциональным требованиям, можете изучить его программу на сайте.
Техническая документация
Менеджеру приходится постоянно работать с технической документацией. Очевидно, что на собеседовании будут вопросы в этой теме.
Что такое техническое задание
Без ТЗ — результат ХЗ. Это самый главный документ, задание на разработку, в котором описывается, что нужно сделать, как это сделать. Туда же пишутся функциональные и нефункциональные требования. Техническое задание — это документ, который описывает, что должно получиться в итоге. Эти требования фиксируются и являются основой для работы всей команды. ТЗ дает защиту как разработчикам, так и клиенту. Потому что каждый соблюдает требования ТЗ.
Use Cases, Test Cases
Use Cases описывает сценарий взаимодействия участников. Он может быть представлен в виде диаграмм или в текстовом виде. Они нужны разработчикам, тестировщикам и всей проектной команде, чтобы понимать полную спецификацию требований. Test Cases нужны для того, чтобы тестировщик прошел по всему продукту и ничего не упустил. Они должны быть написаны так, чтобы любой тестировщик из другого проекта мог разобраться в них.
Где хранить и менеджерить требования
Все зависит от взаимоотношений с заказчиком. Для этой задачи подходит Confluence, причем удобнее хранить у себя, а не на сервере заказчика. Потому что менеджер может писать ту информацию, которую не хотел бы показывать заказчику. Также можно использовать Jira или Notion.
Инструменты проекта
На собеседованиях рекрутеры хотят узнать, с какими инструментами вы можете работать. Поэтому нужно быть готовым к вопросам. В этих вопросах лучше подготовиться заранее, хотя бы поверхностно изучить те инструменты, которые использует менеджер. Вы можете столкнуться с такими вопросами:
Какой Task Tracker лучше выбрать
Каждый таск трекер имеет много классных фич, поэтому нужно смотреть возможности инструментов и подбирать под конкретные проекты. Часто пользуются Jira. Это не значит, что она лучшая, но этот инструмент в 33% вакансий на должность проектного менеджера.
Для чего нужен Project Planning
В первую очередь, чтобы построить диаграмму Ганта. Это базовый инструмент для проектного менеджера, где можно отслеживать этапы ведения проекта, строить его от начала до конца. Инструменты Project Planing нужны для того, чтобы отслеживать результативность выполнения задач, смотреть, сколько остается времени и бюджета.
Архитектура
Это отдельная большая тема, в которой менеджер должен хорошо разбираться, если хочет качественно вести IT-проекты. По архитектуре у нас есть отдельный большой курс Delivery Mind, на котором мы подробно разбираем, что это такое, как устроена и зачем менеджеру вообще знать архитектуру. Посмотрите программу на сайте и регистрируйтесь на курс, чтобы изучить архитектуру. Скажите менеджеру, что вы пришли со статьи по прохождению технического собеседования, и получите персональную скидку. Ну а тут мы разберем вопросы, с которыми вы можете столкнуться уже на собеседовании.
Архитектура для проектного менеджера
PM должен понимать, где мы храним данные, с помощью каких данных мы вынимаем эти данные, будет ли архитектура клиент-серверной или другой. Архитектура — это схематическое пояснение, откуда и куда перетекают данные, как они обрабатываются, на каких этапах предоставляются пользователям.
На собеседованиях могут спрашивать детальнее про архитектуру, но это тема отдельной статьи. В нашем блоге вы можете почитать, как выглядит архитектура и как менеджеру понимать ее.
Чем отличаются бэкенд и фронтенд
К примеру, у нас есть мобильное приложение. То, что у вас на устройстве, это фронтенд. То, с чем пользователь взаимодействует и видит. Бэкенд — это процессы, которые не видны пользователю. Обработка данных, хранение, передача, обращение к серверам. Этот же принцип работает с любым продуктом. То, что видит пользователь — фронтенд. Все, что происходит «за дверьми» — это бэкенд.
Что значит тонкий клиент и толстый клиент
Нет, речь не об объемах талии. На этом вопросе «валятся» все, кто не имеет технического образования и скиллов. Поэтому мы рекомендуем прокачивать технические навыки на курсе Techmind. Вы получите практику и знания, которые помогут проходить собеседования и не попадаться на такие уловки рекрутеров. Теперь к вопросу.
«Толщина» клиента зависит от того, сколько логики находится на клиенте. Если у приложения минимальная логика на самом клиенте, а основная — на сервере, то образуется тонкий клиент. Если при загрузке приложения обрабатывается сразу большое количество данных на самом клиенте, то «толщина» увеличивается.
Разница между ними в вариантах обработки данных. Толстые клиенты преимущественно работают с информацией на основе собственных программных возможностей, в то время, как тонкие клиенты применяют ПО центрального сервера для обработки. Все браузеры и веб приложения, онлайн игры — это тонкие клиенты. А вот Microsoft Outlook или Office 365 — толстые.
Что такое база данных
Это место, где хранятся и обрабатываются все данные. Представлены в виде таблиц, в которых разделяются данные на столбцы и строчки. Например, имя пользователя, его номер телефона, почта. Все таблицы связаны между собой, поэтому при запросе одних данных, можно получить и другую информацию.
DNS — что это такое
На собеседованиях часто приводят подобную ситуацию: пользователь вводит какие-то данные в поисковую строку браузера и нажимает кнопку «Найти». Как происходит весь процесс? На этот вопрос можно отвечать детально, но рекрутер ждет пояснения, что такое DNS.
Если есть физические сервера, на которых расположена информация, к ним нужно как-то получить доступ. У каждого сервера есть имя, которое выглядит в виде IP-адреса. Чтобы не запоминать большое количество цифр, была разработана DNS система. DNS имеет читабельный вид и иерархическую структуру, благодаря чему пользователь дает запрос и получает доступ к информации. На курсе Techmind мы подробно рассказываем, как работает DNS и базы данных.
Зачем нужна репликация
Репликация нужна, чтобы делать копии баз данных. Сама база данных хранится на сервере, Но что с ней произойдет, если с сервером что-то случится? Сгорит, повредится, будет взломан? База данных потеряется. Годы работы могут исчезнуть. Избежать этого помогает репликация. Делаются копии баз данных и размещаются на разных серверах и локальных носителях. Регулярно БД обновляется, и с настраиваемой периодичностью реплики пополняются обновленной информацией.
В чем разница между микросервисом и монолитом
Монолит — это централизованная обработка запросов, а микросервисы — индивидуальная обработка запросов. Монолитное приложение выглядит, как единый общий модуль, в котором происходит вся работа. Архитектура микросервиса имеет несколько небольших развертываемых служб.
Что лучше — нельзя однозначно сказать, потому что каждый имеет свои особенности. Монолитная архитектура считается более традиционной, независимой от других сервисов, имеет единую базу кода. Чтобы внести изменения, необходимо обновлять весь стек. На начальных этапах проекта это выгодное решение, итак как развертывание происходит легче. Микросервис легче масштабировать, тестирование и обновление происходят быстрее и дешевле, приложение становится более гибким.
Клиент-сервер
Углубляясь в технические знания, проектный менеджер должен понимать, что такое-клиент-сервер. Вот наиболее частые вопросы, которые задают по этой теме:
Что такое клиент-сервер
Это элементы архитектуры, которые подразумевают, что есть клиентская часть, которая взаимодействует с пользователем, а есть серверная часть — логика приложения. Клиентская часть отвечает за то, как показать пользователю данные, каким цветом вывести окошки, где будет кнопка. Серверная часть отвечает за сбор и хранение данных, обработку запросов и логику взаимодействия пользователя с продуктом.
Зачем нужен REST
Это набор определенных правил, которые показывают, как нужно общаться между клиентом и сервером. Это некий «транспорт», по которым передаются данные. Клиент запрашивает у сервера какие-то данные. Этот запрос идет на сервер и он отдает их. REST — это свод правил, который помогает серверу и клиенту понимать друг друга.
Куда выносить какую логику
Тут нет универсального ответа. Одни считают, что лучше всю логику выстраивать на бэкенде, а на клиент не давать нагрузку. Другие утверждают ровным счетом наоборот. Ответ, который понравится: все зависит от того, что мы делаем и в какой среде находимся. Можно вносить все на клиент, но все, что связано с безопасностью, выстраивать на бэкенд. Сложные вычисления которые связаны с оплатой, тоже лучше оставлять в бэкенд.
REST
В двух словах мы уже сказали, что REST — это определенный стиль взаимодействия между клиентом и сервером. Он помогает наладить коммуникацию между запросом и получением данных. В теме REST могут возникнуть следующие вопросы:
Что такое json, xml, html
Это форматы файлов, которыми обменивается клиент и сервер. Они не перечисляют все данные через запятую, их нужно структурировать. Это и есть варианты структуры. Json используется для обмена данными в мобильных устройствах, xml, html работают в вебе.
Методы update, delete, get, post
Мобильные девайсы взаимодействуют с бэкендом какими-то запросами. Условно говоря, это ссылка и какие-то дополнительные поля. Мы идем на ссылку и даем одну из команд: update, delete, get, post.
- get — мы что-то забираем, например «Дай список контактов»
- post — говорим, что нужно что-то добавить, например, нового друга в социальной сети
- delete — этой командой мы говорим, что нужно удалить данные, например, файл с телефона
- update — обновление файла: переименование, внесение новых данных.
Эти четыре команды нужно знать детально. Рекомендуем почитать о них отдельно. На курсе Techmind мы разбираем их более подробно и обучаем, как работать с этими командами.
Фреймворки и библиотека
По этой теме нетехнических специалистов спрашивают довольно часто. Поэтому лучше заранее подготовиться и углубиться в знания фреймворков, разобраться с библиотеками. Вот главные вопросы, который могут задать:
В чем разница между фреймворком и библиотекой
Фреймворк — это некая структура с кодом, которая позволяет удобно что-то разрабатывать. Библиотека — это тоже структура с кодом, но она берется извне. Ее берут, как готовое решение для разработки. Кажется, что это более удобный и легкий способ разработки. Но библиотека — это стороннее решение, которое сложно дорабатывать.
Например, нужен календарь. Можно взять готовое решение из библиотеки и внедрить в приложение. Но если заказчик попросит добавить цвета в календарь, поменять шрифт, изменить начало недели не с воскресенья, а с понедельника, править ее будет сложно. Библиотека подходит для типовых и быстрых решений.
Git
Git — это система управления версиями. У нас есть разработчики, которые постоянно что-то дорабатывают, внедряют новые фичи. Чтобы не запутаться и получить строгую структуру, вводится система управления версиями. По ней нетехническому специалисту могут задавать следующие вопросы:
Как работает Git
Чтобы не потерять готовые результаты, создается главная ветка — Мастер. Это уже рабочие утвержденные решения, которые подходят для релиза. Дальше приходит идея внедрить новую фичу. В мастере фиксируется «отправная точка», делается фича, тестируется и проверяется. В Git она идет отдельной веткой. В ней ведется разработка, связанная только с этой новой фичей. Когда она сделана, протестирована и принято решение внедрять ее, она мёрджится в Мастер.
Зачем нужен Git
Чтобы не запутаться. Самая сложная ветка — разработчиков. Там происходят основные процессы, появляется много багов в ходе работы и отслеживать их становится сложно. Но Git помогает выстроить ветки так, чтобы было наглядно понятно, что уже работает, а что нуждается в доработке.
Что такое merge, push, pull
Merge — это процесс слияния кода из одной ветки в другую. Мёрджить — переносить код. Когда вам понятно, что фича работает, она добавляется в основную версию Git.
Push — процесс, когда отдельный кусок кода нужно добавить в какую-то ветку. Pull — обратный процесс, когда нужно что-то убрать из ветки с кодом.
Кросс-платформа
В современной разработке все реже используются только десктопные или только мобильные версии продукта. Но отдельно разрабатывать под каждую систему продукт достаточно дорого. Поэтому часто используется кросс-платформа. Нетехнический специалист должен понимать, что это за процессы и как они устроены.
Что такое натив
Если разработка ведется на родном языке для определенной платформы, это называется натив. Например, если делается продукт под операционную систему iOs, то используется Swift.
Что такое кросс-платформа
Это процесс, при котором приложение разрабатывается с кодовой базой, которая работает на разных операционных системах. То есть приложение будет работать как на «яблоках», так и на андроидах. Несмотря на то, что это кажется более выгодным, кросс-платформенные решения имеют довольно много недостатков и не всегда работают качественно. Под каждый проект определяется стек технологий, и при разработке архитектуры решается, использовать натив или кросс-платформу.
Что дешевле
Для быстрого запуска стартапа с какой-нибудь функциональностью дешевле сделать кросс-платформенное решение. Если нужна хорошая функциональность, выгоднее делать ее на нативе. Потому что на кросс-платформе придется «натягивать» многие решения, в итоге это займет больше времени и сил. С точки зрения общей оценки, дешевле кросс-платформа. Но не всегда она подходит для проектов.
Тестирование
Какие типы тестирования бывают
Функциональное тестирование — мы берем и тестируем конкретную функциональность. Смоук тестирование применяется, когда обнаруживается маленький баг, не влияющий на функциональность. Регрессионное тестирование — это полный процесс проверки на баги всего кода, как правило, применяется перед релизом продукта.
Нагрузочное тестирование применяется для сложных продуктов с нефункциональными требованиями, связанными с нагрузкой. Например, приложение должно работать при одновременной нагрузке в 20 000 пользователей.
Интеграционное тестирование применяется тогда, когда сервер уже написан, а клиент еще меняется. Автотесты работают так: кодируются определенные действия или запросы, и проверяются ответы. Часто применяется при интеграционном тестировании.
Что такое приоритеты
Каждому багу присваивают статус, который определяет важность тестирования и исправления. Как правило, используются статусы «Критичный», «Высокий», «Средний», «Низкий», «Блокер». При критичном статусе продукт не может работать, пока его не исправят, но при этом функциональность можно проверять. Блокер — это статус, при котором невозможно дальнейшее проведение тестов, пока он не будет устранен.
Заключение
Это не все вопросы, которые могут задавать менеджеру на технических собеседованиях. Чтобы устроиться в IT компанию, необходимо понимать рабочие процессы, терминологию и язык технарей. Чтобы выучить все это одной даже очень полезной статьи недостаточно. Поэтому мы создали курс TechMind для нетехнических специалистов, которые работают в IT. За пару месяцев вы научитесь управлять командой разработчиков, правильно ставить задачи, вести проекты, подбирать оптимальные решения и избегать ошибок. Посмотрите программу курса и поймете, что он сделан для полного освоения технических процессов.
Записывайтесь на курс TechMind, прокачивайте навыки и с легкостью проходите технические собеседования. А если скажете менеджеру, что вы читали статью про 37 вопросов на собеседовании — получите дополнительную персональную скидку 😉