Дизайн системы во время интервью - сбор требований

Прежде чем ты начнёшь читать, я должен заметить, что эта заметка была написана ещё зимой, до того, как я перешёл на нынешнюю работу. Это было спонтанное интервью, потому что рекрутер обещал много денег, а я тогда особо и не искал работу, но решил все же попробовать. Потом заметка потерялась на планшете и я сейчас наткнулся на неё и решил опубликовать. 

Мне не так часто удаётся столкнуться с хорошим интервью, но только дважды мне приходилось сталкиваться с тем, чтобы меня просили нарисовать дизайн какой-то системы. Не буду говорить в последовательности их прохождения, а скажу в последовательности успешности. Успешным было интервью в архитектуру в Ceridian и провальным было на менеджера в одну компанию, куда меня не взяли.

Когда меня в Ceridian попросили нарисовать архитектуру какого-то проекта, то там не было рамок, я мог спокойно выбирать технологии и решения и процесс интервью шёл очень гладко.

 Когда меня в одном стартапе на позицию менеджера попросили нарисовать архитектуру определенной системы, то я нарисовал им два решения, но ни одно из них не понравилось потому, что нужно было использовать Serverless подход. Как я должен был догадаться? Давайте обсудим.

В Ceridian у меня было достаточно свободное задание, поэтому можно было рассуждать, можно было рассказывать и показывать, как художник рисует картину. Наверно поэтому мне было легко. 

В стартапе мне дали более конкретное задание и поэтому я сразу почувствовал, что тут мне не быть художником и поэтому прежде чем бросаться в решение задачи я начал задавать вопросы и пытаться выяснить максимум требований, но в ответ мне давали только общие ответы типа пользователей может быть очень много и им нужно дать данные. Я пытался хоть как-то понять - сколько это «много». Это может быть миллион, может быть миллиард. Когда мы создаём систему мы должны понимать хоть какие-то рамки. Как они будут обращаться, все сразу или нет? На это я так же не получил нормального ответа. 

Мне казалось, что именно сбор требований должен был стать частью интервью на дизайн системы, когда подаёшься на архитектора или менеджера, потому что это показывает, как я работаю с проблемой. Точно так же и вопросы на решение каких-то задач, я также люблю, когда кандидаты задают вопросы - а сколько памяти у меня есть, как много данных будет, какие могут быть данные. Хорошие вопросы со стороны кандидата являются частью процесса собеседования. 

Но в стартапе мне просто сказали начать что-то рисовать и там будут уже вопросы с их стороны, а не с моей. Очень странно. 

В общем я пытался рисовать что-то и в итоге два возможных решения явно не понравились, потому что среди них не было Serverless. Я понимаю, что в задании они не хотели указывать на то, что решение должно быть именно Serverless, но на мои вопросы по требованиям к системе могли же они давать внятные ответы, чтобы мы вышли на это требование.

Хорошее интервью на дизайн не должно быть на конкретное решение, оно должно быть гибким. Дизайн системы - это не просто пятиминутное решение, это долгая работа с одними только требованиями. 

Как я уже сказал отдельные плюсы могут и должны быть за то, собирает ли кандидат нужную информацию или бросается решать задачу сразу. 

Если хочется довести кандидата до определенного решения, то можно же во время интервью как-то дополнительными условиями направлять человека. Хотя наличие определенного решения подталкивает меня на мысль, что что-то не то в процессе и компания ищет не специалиста, а исполнителя под конкретную идею.

---

Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым

---