Под прошлым постом попросили рассказать, какие вопросы задавать кандидату, чтобы понять, что он норм
Начнём с неприятного:
ни один вопрос сам по себе этого не покажет
Почти к любому вопросу можно подготовиться
99% вопросов с собесов уже лежат в интернете
Ответы на них - тоже
Плюс сейчас кандидат может отвечать с помощью ИИ
И вы, возможно, даже этого не поймёте
Так как тогда проверять?
Практикой
Одно из лучших собеседований у меня было в Райффайзенбанке.
Да, я просидел там почти два часа
Но мне не задавали теорию в стиле:
«Что такое REST?»
«Чем PUT отличается от PATCH?»
«Какие бывают требования?»
Собес был почти полностью на практике
И это, как по мне, идеальная модель
Хотите проверить бизнес-процессы?
Дайте кейс и попросите нарисовать BPMN
Хотите проверить REST?
Пусть кандидат напишет пример запроса в блокноте
Хотите проверить интеграции?
Пусть нарисует сиквенс диаграмму
Хотите проверить system design?
Пусть набросает архитектуру сервиса
Хотите проверить требования?
Дайте мутный запрос от бизнеса и посмотрите, какие вопросы он начнёт задавать
Потому что теория показывает, что человек что-то слышал
А практика показывает, как он думает
На кейсе сразу видно:
- как кандидат уточняет вводные
- видит ли ограничения
- замечает ли риски
- умеет ли декомпозировать задачу
- понимает ли границы системы
- может ли объяснить своё решение
- не разваливается ли в неопределённости
И главное - вы видите примерно то, как человек будет работать у вас в команде
Не как он выучил ответ
А как он решает задачу
Да, к таким собеседованиям тоже можно подготовиться
Но это сложнее
Особенно если вы периодически меняете кейсы, а не гоняете один и тот же пример, который через неделю окажется в каком-нибудь чате
Только важный момент
Кейсы должны быть про вашу реальную работу
Если у вас в компании нет брокеров сообщений, не надо мучить кандидата Кафкой
Ну узнаете вы, что он работал или не работал с Kafka
И что дальше?
У вас её нет
Лучше проверять то, с чем человек реально столкнётся:
- ваши типовые интеграции
- ваши процессы
- ваши ограничения
- ваши форматы требований
- ваши сценарии взаимодействия с командами
И ещё один плюс практических собеседований:
их сложнее пройти с ИИ
Неудобно одновременно слушать кейс, рисовать схему и тыкать в подсказки
Да и ИИ пока плохо справляется с живыми задачами, где нужно уточнять вводные, держать контекст и объяснять ход мысли
Поэтому для меня лучший формат собеседования системного аналитика - это не список теоретических вопросов
А набор практических кейсов, максимально похожих на реальную работу
Вам нужен не человек, который красиво рассказывает, что такое API
Вам нужен человек, который сможет прийти в хаос, задать нормальные вопросы, нарисовать понятную схему и довести задачу до разработки без цирка