Как-то раз ходил на собеседование в одну компанию на должность архитектора. По результатам - завёл обсуждение на RSDN. Будет интересно, к чему это обсуждение приведёт. Текст моего поста:
Предыстория: Некая компания ищет архитектора на проект, который предполагает рефакторинг. Не исключено, что руководитель отдела разработки этой компании ошибается, и проекту в большей степени требуется грамотный технический лидер, нежели архитектор, или же и архитектор, и тех. лидер в одном лице.
Суть проблемы: Система, которую придётся рефакторить, состоит из двух составляющих:
(1) картографические данные, хранящиеся в БД на сервере;
(2) визуализация этих картографических данных, хранящаяся на другом сервере.
Дело в том, что с частью (1) работает огромное число пользователей. А наша система относится к части (2), с которой работает лишь небольшое подмножество пользователей части (1).
Основная проблема заключается в том, что пользователи части (2) вынуждены синхронизировать вручную визуальную информацию с актуальной картографической. Ситуация осложняется тем, что подобная синхронизация (== создание растрового изображения) занимает длительное время — несколько часов.
Хотелось бы, чтобы в новой версии системы эта проблема была бы устранена. Чтобы для любой картографической информации всегда бы имелась актуальная графическая.
Подходы к решению:
1) Система (2) автоматически следит за данными в системе (1) и, если они обновились, перегенерирует растровое изображения изменённых участков. Недостаток: система (2) должна хранить данные из системы (1) для того, чтобы узнать, что они обновились.
2) Встроиться каким-либо образом между пользователями системы (1) и конечной базой данных для системы (1), чтобы отлавливать запросы на изменение данных. Если данные изменяются, то посылать уведомление системе (2) для того, чтобы она перегенерировала растровые изображения для изменённых данных.
3) Поработать над сокращением времени генерации растрового изображения.
Ситуация осложняется тем, что система (1) является приватной. К ней нет доступа. В принципе, можно было бы растеризовать данные в фоновом режиме, но непонятно, как узнать, что информация в системе (1) обновлена. Нет никаких сервисов, позволяющих узнать это. Доступ к СУБД системы (1) возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.
Как проводят собеседования кандидата:
1) Просят рассказать о предыдущем опыте проектирования систем.
2) Просят спроектировать текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов.
3) Рисуют на листочке то, как устроена их система, просят кандидата назвать недостатки дизайна и предложить варианты решений.
По п.п. 1 и 2 формально время не ограничивают. Но если за 5 минут кандидат не нарисует на бумаге дизайн системы, быстро теряют интерес и перебивают.
Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
Как следствие, не понимают:
(1) важность перевода задачи из формы, как она сформулирована заказчиком (например, "спроектируйте текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов") в форму, пригодную для выработки технического решения;
(2) важность написания юз-кейсов для выполнения п. (1).
Резюме: ИМХО, подобный вариант проведения собеседования с архитектором не является эффективным.
Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором:
(1) на разработку нового проекта с нуля;
(2) на масштабный рефакторинг готового проекта.
Просьба высказывать свои варианты и свои точки зрения.
P.S.: Чуть позже расскажу, как бы я проводил собеседование с кандидатом в архитекторы. Но сначала будет интересно узнать мнения коллег.
Предыстория: Некая компания ищет архитектора на проект, который предполагает рефакторинг. Не исключено, что руководитель отдела разработки этой компании ошибается, и проекту в большей степени требуется грамотный технический лидер, нежели архитектор, или же и архитектор, и тех. лидер в одном лице.
Суть проблемы: Система, которую придётся рефакторить, состоит из двух составляющих:
(1) картографические данные, хранящиеся в БД на сервере;
(2) визуализация этих картографических данных, хранящаяся на другом сервере.
Дело в том, что с частью (1) работает огромное число пользователей. А наша система относится к части (2), с которой работает лишь небольшое подмножество пользователей части (1).
Основная проблема заключается в том, что пользователи части (2) вынуждены синхронизировать вручную визуальную информацию с актуальной картографической. Ситуация осложняется тем, что подобная синхронизация (== создание растрового изображения) занимает длительное время — несколько часов.
Хотелось бы, чтобы в новой версии системы эта проблема была бы устранена. Чтобы для любой картографической информации всегда бы имелась актуальная графическая.
Подходы к решению:
1) Система (2) автоматически следит за данными в системе (1) и, если они обновились, перегенерирует растровое изображения изменённых участков. Недостаток: система (2) должна хранить данные из системы (1) для того, чтобы узнать, что они обновились.
2) Встроиться каким-либо образом между пользователями системы (1) и конечной базой данных для системы (1), чтобы отлавливать запросы на изменение данных. Если данные изменяются, то посылать уведомление системе (2) для того, чтобы она перегенерировала растровые изображения для изменённых данных.
3) Поработать над сокращением времени генерации растрового изображения.
Ситуация осложняется тем, что система (1) является приватной. К ней нет доступа. В принципе, можно было бы растеризовать данные в фоновом режиме, но непонятно, как узнать, что информация в системе (1) обновлена. Нет никаких сервисов, позволяющих узнать это. Доступ к СУБД системы (1) возможен только через Apache Tomcat. Напрямую доступ к БД закрыт, т.к. она приватна и принадлежит другой компании. Доступ только на общих основаниях.
Как проводят собеседования кандидата:
1) Просят рассказать о предыдущем опыте проектирования систем.
2) Просят спроектировать текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов.
3) Рисуют на листочке то, как устроена их система, просят кандидата назвать недостатки дизайна и предложить варианты решений.
По п.п. 1 и 2 формально время не ограничивают. Но если за 5 минут кандидат не нарисует на бумаге дизайн системы, быстро теряют интерес и перебивают.
Мой вывод: Не понимают, что прежде чем решать задачу, её для начало надо грамотно поставить (слова "грамотно" и "поставить" здесь ключевые).
Как следствие, не понимают:
(1) важность перевода задачи из формы, как она сформулирована заказчиком (например, "спроектируйте текстовый редактор с хайлайтингом, проверкой правописания и расстановкой переносов") в форму, пригодную для выработки технического решения;
(2) важность написания юз-кейсов для выполнения п. (1).
Резюме: ИМХО, подобный вариант проведения собеседования с архитектором не является эффективным.
Интересует: Мне в этой ситуации интересен общий подход к проведению собеседования с архитектором:
(1) на разработку нового проекта с нуля;
(2) на масштабный рефакторинг готового проекта.
Просьба высказывать свои варианты и свои точки зрения.
P.S.: Чуть позже расскажу, как бы я проводил собеседование с кандидатом в архитекторы. Но сначала будет интересно узнать мнения коллег.
Неадекваты встречаются везде. Скажи спасибо, что не попросили перечислить все известные паттерны проектирования:)
ОтветитьУдалитьЕсли это не огромная корпорация с формальным и отлаженным процессом найма, то сама по себе вакансия "Архитектора" весьма странная. Скорее хотели написать "Спасатель проекта", но при этом оставить руководство проектом в своих руках =)
По теме собеседования архитектора, вряд ли обладаю достаточным опытом, но я бы предлагал практические задачи.
Как то: 1. Общий подход к решению частной задачи. Разработать архитектуру конкретной прикладной программы с некоторым распределением вероятностей в каком направлении могут быть изменения. (абсолютно абстрактная система абсолютно бесполезна :) )
2. Дал бы такое же задание паре программистов из компании, и результат их труда показал кандидату. На какие проблемы/ошибки в проектировании он укажет.
3. Показал бы архитектуру проекта, который собственно разрабатывается компанией, может в несколько упрощенном варианте. Но сказал бы, что это синтетический тест (или предыдущая версия проекта), чтобы соискатель не стеснялся ругать :)
1. Не похоже, чтобы в компании был отлаженный формальный процесс. Скорее всего, действительно был нужен человек, который как-то вытянет проект. По разговору я понял, что многие кандидаты просто от проекта отказывались.
ОтветитьУдалитьЯ даже не уверен в том, что этот проект разработан в этой компании, а не поступил к ним в таком виде на аутсорсинг. Помню, в ДатаАрте мне приходилось сопровождать монстрообразную и ужасно глючную web-систему. Ни о какой архитектуре там не было речи. Нужен был обыкновенный багфиксинг.
2. Любое задание, связанное с проектированием системы, требует выполнения процедуры по постановке задачи. Иными словами, нужно преобразовать ситуацию, представленную в описании заказчика, к упорядоченному набору технических и управленческих задач.
Такая операция не делается мгновенно. А со стороны работодателя присутствовал "архитектор", который хотел, чтобы кандидат начал рисовать архитектуру системы сразу после того, как проблема была сформулирована.
А у меня сразу множество слоёв и компонентов в голове возникло, которые необходимы для решения этой задачи. На любой вопрос на собеседовании, тем более серьёзный, можно ответить "слишком абстрактно", "it depends", "нужно долго думать","я же не знаю, что вы имеете ввиду под словом 'редактор' "...
ОтветитьУдалитьИмхо достаточно высказать, что вы думаете про такую постановку задачи, что вы всё-таки под ней понимаете и рассказать о своём видении в первом приближении, начав с высокоуровневых вещей и углубляясь в детали.