Традиционно техническое собеседование состоит из двух частей: сначала тебя просят рассказать о своем опыте работы, а потом задают теоретические вопросы.
Встречаются собеседования, которые проходят вообще без теоретических вопросов – спрашивают только про твой опыт – что ты делал на проектах. Это самые простые собеседования.
Другая крайность – «соковыжималка» – часовое или 1,5-часовое собеседование с огромным количеством теоретических вопросов по всем темам. Очень похоже на тестирование. Выжимают все соки. Вопросы из нескольких таких «соковыжималок» тоже попали в мой список.
Что делать, когда вы не знаете ответ на вопрос
Техническое собеседование выглядит как экзамен, но на самом деле, это не экзамен. Если вам задают вопрос, на который вы не знаете ответа, не тушуйтесь, смело говорите – не знаю, не сталкивался с этой темой. Да вы и не обязаны знать всё, о чем вас спрашивают. Задача собеседующего понять, где вы сильны, а где слабы. Это нормально, что вы чего-то не знаете. Ваша спокойная реакция на сложный вопрос – это уже хороший ответ!
Абсолютный лидер среди всех технических вопросов: «Что такое REST и чем REST отличается от SOAP?»
Найдите статьи,обучающие видео, книги на эту тему и будьте готовы к этому вопросу!! Этот вопрос задают почти на каждом собеседовании. А тема интеграций – это тема номер один на собеседованиях.
«Расскажите про рабочий процесс на последнем вашем проекте»
Один из самых частых вопросов - когда тебя просят рассказать, как на твоей работе был построен рабочий процесс. Вот тут может возникнуть желание приукрасить, особенно если ваш эджайл совсем не эджайл. Этого делать не надо – нужно рассказывать именно так, как все было на самом деле, со всеми недостатками рабочего процесса (а у кого их нет?). Нужна реальная, а не приукрашенная картина.
«Расскажите, что содержится в вашей типовой постановке задач для разработчика»
Тоже один из самых частых вопросов. Лучше всего заранее вспомнить какие-то примеры из своей практики.
Вопросы на реальных технических собеседованиях на должность системного аналитика
(частые вопросы выделены жирным шрифтом)
I Общие вопросы
1. Почему вы меняете работу?
2. Расскажите о себе и своем опыте.
3. Расскажите, что вы делали как аналитик.
4. Какую работу вы ищете?
5. Что вы хотите получить от новой работы?
6. Что вам нравится делать как аналитику и что не нравится?
7. Какими достижениями в своей работе вы гордитесь?
8. Как вы относитесь к переработкам?
9. Опишите своего идеального руководителя.
10. Опишите идеальную для вас команду.
11. Что самое сложное было для вас в работе?
12. Расскажите о своей самой сложной/важной работе за последние полгода.
13. Кем вы себя видите через 2 года? Через 5 лет?
15. Были ли у вас конфликты с коллегами и как вы их решали?
16. Как решались технические разногласия в команде?
17. Какую последнюю книгу вы прочли?
18. Чем вы любите заниматься?
19. Приходилось ли вам работать со сложным заказчиком и как вы улаживали разногласия?
20. У вас есть портфолио аналитика? Пришлите что-нибудь из вашего портфолио.
II Требования
21. Какие группы требований вы знаете?
22. Что входит в нефункциональные требования?
23. Каким критериям должны соответствовать требования?
24. Вам аналитик принес список требований. Как вы их оцените?
25. Приходилось ли вам писать Use cases? Как пишутся Use cases?
26. Приходилось ли вам писать User story?
27. Вы продаете кофейные аппараты. Я заказчик. Какие вопросы вы зададите потенциальному заказчику, который хочет купить кофейный аппарат в офис? (заказчик при этом на все вопросы отвечает «не знаю»)
28. С какими группами заинтересованных лиц вы общались?
III Нотации UML и BPMN
29. Какими нотациями вы владеете?
30. Какими UML диаграммами вы пользуетесь?
31. Нарисуйте диаграмму последовательности для процесса, когда пользователь через веб-форму отправляет запросы в rest-сервис для получения данных.
32. Что такое диаграмма последовательности? (Что описывает диаграмма последовательности?)
33. Составьте схему BPMN для процесса, описывающего работу банкомата (устно)
34. Какие бывают Gateway в BPMN?
35. Какие элементы BPMN вы знаете?