Собеседования в крупные компании. Часть 3 - лайвкодинг и проектирование фичи
Наверное, самая интересная часть из всего процесса найма. Если предыдущие этапы заезжены до невозможного, то эта часть была у меня впервые (что-то подобное встречалось ранее при собеседовании в другую компанию, но там было проектирование на минималках).
Дается ТЗ на фичу, где указаны вводные данные и что необходимо сделать. Не могу сказать, что именно было на этом этапе, но подсвечу - это не то проектирование фичи, которое есть в Google, Uber, или каком-нибудь Amazon. Не нужно проектировать бэкенд, говорить про разделение логики на миркосервисы - мы просто пишем Flutter-код. Времени дают около полутора часов, из которых час с небольшим будет на реализацию задачи, а остальное время идет на обсуждение решения.
На этом этапе нужно максимально понять ТЗ - это очень важно, так как если вы что-то упустите, то дальше придется много переделывать, а это время, которое можно потратить на написание другой логики. Не бойтесь задавать даже глупые на первый взгляд вопросы - вам нужно приступить к написание кода с понятными требованиями.
Реализация фичи будет без менеджеров состояний и других решений - чистый Flutter. Может быть получится использовать какие-то плагины, но тут нужно уточнять, и лучше заранее, чтобы не тратить время на настройку окружения. Ванильный Flutter показывает, насколько вы знакомы со стандартным SDK (а в таких задачах точно требуются Future, всякие лоадеры, написание состояний, моделей, репозиториев), без генераторов и всего прочего. Советом тут может быть только рекомендация тренировки на голом Dart + Flutter, без плагинов, и желательно без автокомплита (чтобы не теряться и всегда помнить, какие методы и где вызывать). В браузерной IDE, которую мы использовали для задачи, были подсказки, и это экономило время, но в другой компании среда разработки может быть без них.
Когда я писал какие-то простые решения с применением setState, то всегда говорил, что это решение из коробки, и при использовании менеджера состояний был бы другой подход. Иногда были моменты, когда я спрашивал, что вот тут давайте просто держать в голове, что есть красивая кнопка, но делать ее не будем, и мне шли на встречу - какие-то компоненты не были реализованы в угоду экономии времени.
Если видите, что меняются какие-то требования, или вам нужно изменить ход решения - тоже говорите об этом. Собеседующий не залезет к вам в голову и не прочитает ваши мысли. Код, скорее всего, вы до конца не допишите, так как дано очень мало времени на решение задачи. Нужно выжать максимум и показать, что возможно сделать за час с небольшим.
После решения задачи, начинается ее обсуждение. Тут все индивидуально, но мы больше говорили, как бы я, при наличии времени и возможности добавления плагинов, сделал бы фичу и что использовал бы. Обговорили куда тут можно засунуть BLoC, что будет в состоянии, какое решение взял бы для DI - смотрели больше на мой опыт и глубину знания работы плагинов и реализации архитектуры.
Далее, как обычно, ждем ответа команды. HR вернется через пару дней, и либо у вас будет секция с продактом, либо дадут развернутый фидбэк и скажут, что вам не по пути (собеседоваться можно раз в какое-то время, сможете сделать это снова, но позже). На самом деле, если вы прошли эту секцию, то уже являетесь отличным специалистом, а полученный ответ при отказе даст возможности скорректировать направление обучения и подскажет, на что нужно обратить внимание в ваших знаниях на данный момент и на чем стоит сосредоточиться в будущем.
ℹ️ Все посты по теме