О собеседованиях (на Habr), чаще пишут с точки зрения соискателей, я же предлагаю посмотреть на собеседование со стороны нанимателя, что на habr гораздо реже. А именно, на то, как собеседовать аналитиков.
Замечу — аналитиков в нашей отрасли очень много, их численность вполне сравнима с численностью разработчиков. Но про тонкости собеседования аналитиков (что бизнес-, что системных) сообщество молчит, предпочитая обсуждать собеседования девелоперов. На худой конец рассуждают про общие проблемы собеседований. При этом, тема о том, как собеседовать (и во многом отбирать) аналитиков, презабавная.
Скажу сразу: проведение собеседования аналитика весьма отличается от собеседования разработчика. То есть, конечно имеются общие вещи, которые не зависят от специализации потенциального сотрудника:
Но, как только мы доходим до выяснения, что за специалист перед нами, всё меняется. Вот вам пример — в среде нанимателей кочует задачка на тему: «почему канализационные люки круглые?». Правильный ответ кандидата на должность разработчика: «Круглые, потому, что, т. к. диаметр круга одинаков, то люк круглой формы никогда не провалится в колодец...». Правильный ответ аналитика: «Потому что стволы деревьев на спил круглые». Причина расхождения, в отличии задач, стоящих перед этими двумя специализациями. Разные задачи, для своего решения, требуют разные стили мышления. Аналитик анализирует реальный мир и от него идет к IT проблематике, разработчик мыслит математической логикой (в данной случае геометрией, которая есть отрасль математики).
Итак, давайте определимся, что мы хотим от аналитика, не считая специальных знаний (всяких там нотаций; да знания тонкостей работы отрасли, для которой разрабатываем софт)?
Базовые требования к идеальному аналитика, следующие:
Вот человек, который способен слепить, из кучи бессвязных восклицаний, работающие требования к реализации (и далее по списку).
В силу своих служебных обязанностей, мне довелось нанимать довольно большое количество аналитиков различного профиля, и я наработал несколько приемов, которые с успехом использовал, для проведения результативных собеседований.
Вот один из этих приемов — задачи на соблюдение базовых условий выполнения процесса, прохождение таких задач проверяет первые два пункта из требований к идеальному аналитику.
Процент успешного выполнения этой задачи, на собеседованиях — 50%
Дана схема, нарисована небрежно (это так и задумано, многие перестают на этом думать, уходя детали и перестают видеть процесс целиком). На схеме клиент (человек) ищет в некой дистрибутивной системе, а потом и покупает, билет на концерт. Схема откровенно жульническая, так работать не может, кроме, как у криминального бизнеса.
Вопрос — почему?
— подсказка: нарушен базовый принцип
— подсказка: помни про бритву Оккама
— подсказки те же
И опять неработающая схема.
Есть CRM и суперкомпьютер (строго говоря система администрирования ресурсов суперкомпьютера, но это совсем детали), нужно из CRM создавать научные проекты (в суперкомпьютере) и выделять созданным проектам ресурсы суперкомпьютера, а затем в созданном проекте раздать доступы участникам.
API CRM —
/projects
GET
Получить список всех проектов. Ключевые поля: id – id проекта в системе, name – название
/projects/
GET
Получить информацию по конкретному проекту. Ключевые поля: все поля проекта
/users
GET
Получить список всех пользователей в системе. Ключевые поля: id – id юзера в системе, name – ФИО, email – E-mail, projects – id проектов, в которых участвует, active = [true | false] – состояние доступа
/users/
POST
Обновить информацию по состоянию доступа у конкретного пользователя
API суперкомпьютера -
/users
POST
Список пользователей, которым необходимо предоставить доступ: [users: [{id: , email: , access: [true | false], is_new: [true| false], access_end: }, …]].
Ответ: {success: [true|false], error: } — запрос корректен, выполнение в очереди / ошибка в запросе + информация в поле error.
Ваши ответы? :)
Замечу — аналитиков в нашей отрасли очень много, их численность вполне сравнима с численностью разработчиков. Но про тонкости собеседования аналитиков (что бизнес-, что системных) сообщество молчит, предпочитая обсуждать собеседования девелоперов. На худой конец рассуждают про общие проблемы собеседований. При этом, тема о том, как собеседовать (и во многом отбирать) аналитиков, презабавная.
Скажу сразу: проведение собеседования аналитика весьма отличается от собеседования разработчика. То есть, конечно имеются общие вещи, которые не зависят от специализации потенциального сотрудника:
- Что за человек?
- Что ищет?
- Сколько хочет?
- Когда может выйти?
Но, как только мы доходим до выяснения, что за специалист перед нами, всё меняется. Вот вам пример — в среде нанимателей кочует задачка на тему: «почему канализационные люки круглые?». Правильный ответ кандидата на должность разработчика: «Круглые, потому, что, т. к. диаметр круга одинаков, то люк круглой формы никогда не провалится в колодец...». Правильный ответ аналитика: «Потому что стволы деревьев на спил круглые». Причина расхождения, в отличии задач, стоящих перед этими двумя специализациями. Разные задачи, для своего решения, требуют разные стили мышления. Аналитик анализирует реальный мир и от него идет к IT проблематике, разработчик мыслит математической логикой (в данной случае геометрией, которая есть отрасль математики).
Итак, давайте определимся, что мы хотим от аналитика, не считая специальных знаний (всяких там нотаций; да знания тонкостей работы отрасли, для которой разрабатываем софт)?
Базовые требования к идеальному аналитика, следующие:
- Структурированное мышление;
- Умение видеть главное и не терять за деревьями лес;
- Гибкость ума.
Вот человек, который способен слепить, из кучи бессвязных восклицаний, работающие требования к реализации (и далее по списку).
В силу своих служебных обязанностей, мне довелось нанимать довольно большое количество аналитиков различного профиля, и я наработал несколько приемов, которые с успехом использовал, для проведения результативных собеседований.
Вот один из этих приемов — задачи на соблюдение базовых условий выполнения процесса, прохождение таких задач проверяет первые два пункта из требований к идеальному аналитику.
Задача № 1
Процент успешного выполнения этой задачи, на собеседованиях — 50%
Дана схема, нарисована небрежно (это так и задумано, многие перестают на этом думать, уходя детали и перестают видеть процесс целиком). На схеме клиент (человек) ищет в некой дистрибутивной системе, а потом и покупает, билет на концерт. Схема откровенно жульническая, так работать не может, кроме, как у криминального бизнеса.
Вопрос — почему?
— подсказка: нарушен базовый принцип
— подсказка: помни про бритву Оккама
Задача № 2
— подсказки те же
И опять неработающая схема.
Есть CRM и суперкомпьютер (строго говоря система администрирования ресурсов суперкомпьютера, но это совсем детали), нужно из CRM создавать научные проекты (в суперкомпьютере) и выделять созданным проектам ресурсы суперкомпьютера, а затем в созданном проекте раздать доступы участникам.
API CRM —
/projects
GET
Получить список всех проектов. Ключевые поля: id – id проекта в системе, name – название
/projects/
GET
Получить информацию по конкретному проекту. Ключевые поля: все поля проекта
/users
GET
Получить список всех пользователей в системе. Ключевые поля: id – id юзера в системе, name – ФИО, email – E-mail, projects – id проектов, в которых участвует, active = [true | false] – состояние доступа
/users/
POST
Обновить информацию по состоянию доступа у конкретного пользователя
API суперкомпьютера -
/users
POST
Список пользователей, которым необходимо предоставить доступ: [users: [{id: , email: , access: [true | false], is_new: [true| false], access_end: }, …]].
Ответ: {success: [true|false], error: } — запрос корректен, выполнение в очереди / ошибка в запросе + информация в поле error.
Ваши ответы? :)
