Novikov on Soapbox

Как смотреть в код

Это продолжение предыдущего поста.

Сам факт того, что у соискателя должности есть непустой аккаунт на гитхабе — уже говорит что перед вами не хер собачий, а человек ну как минимум заинтересованный в разработке ПО. Проявите уважение, блядь!

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

Для начала: необходимо чтобы вы сами были знакомы с платформой/языком, на котором исполнен проект. Нужно это чтобы отличить авто-генерированный и glue-код от того, который автор написал сам. А то будете как дурак копаться в node_modules и восторгаться талантом, а человек просто не знает что node_modules добавляют в .gitignore. Fail. Так что в целевой платформе надо шарить хотя бы в общих чертах.

Дальше всё довольно просто: гуляем по директориям, оцениваем насколько всё логично и уместно организовано.

Логично: это когда человек может разложить код по полочкам так, чтобы не запутаться самому и не запутать других. Это отличный навык. Говорит о наличии системного мышления и способности "посмотреть сверху". Если всё хаотично рассовано по директорям — это флажочек о небрежности и непоследовательности. Необходимо уточнить у автора лично что за фигня.

Уместно: когда человек может организовать проект в соответствии с принятыми практиками для платформы, на которой работает. Это говорит о способности читать и усваивать стандарты разработки, а не воевать с ними. Если человек всё же воюет со стандартами разработки, то он будет обязан защитить своё решение и по фактам обосновать почему так лучше. В личном разговоре. Убедит — молодец. Не убедит — плохо.

Пытаемся въехать в проблематику и общий дизайн решения. Если удалось понять дизайн — ищем в нём огрехи и фиксируем вопрос для личного разговора. Если дизайн понять не удалось — кандидату же хуже. Будем заставлять рисовать дизайн на доске и объяснять почему так. Для проформы можно выбрать несколько совершенно рандомных файлов, притащить их кандидату и пытать на тему зачем они нужны и почему без них нельзя. Только смотрите не обосритесь, а то притащите код, сгенеренный фреймворком — стыдно потом будет. Хотя толковый кандидат и за генерированный код сможет пояснить.

Дальше надо составить общее понимание о том, как человек пишет. Откройте 10 рандомных файлов из разных точек проекта. Посмотрите насколько код в целом вменяем, написаны ли комменты, соблюдены ли naming conventions. Смотрите, используются ли фишки платформы и правильно ли они используются. Например в C# можно смотреть using-и, lock-и, системные атрибуты, правильную перегрузку equality members, корректное использование EF, ASP .NET MVC и иже с ними. Если понимания не сложилось — откройте ещё 10 файлов. И так далее, пока не сложится. Все возникающие вопросы записывайте в блокнотик и откладывайте до личного разговора.

Так же стоит обратить внимание на unit-тесты и сборочные скрипты. Если они есть — это win. Если проект собирается и выкладывается через github actions — это flawless victory. Если при этом ещё и прогоняются тесты — это fatality. Человек шарит за CI/CD, тестирование и — самое крутое — умеет это настраивать и использовать. А если у него есть понимание зачем это надо (уточняется в лично разговоре) — делайте оффер.

Важно понять следующее: не надо вчитываться и анализировать какие-то отдельные строчки. Всё равно досконально не разберётесь. Надо прочитать по диагонали и подбить тем для разговора с кандидатом на час-другой. Если глаз намётан, то на это уходит не более 10 минут. О чём говорить после просмотра репозитория — в следующем посте.

Не переключайтесь.

www.tgoop.com/reinforced_sc/47

1.7K viewsAug 2, 2021 at 16:00

Как смотреть в код

Это продолжение предыдущего поста.

Сам факт того, что у соискателя должности есть непустой аккаунт на гитхабе — уже говорит что перед вами не хер собачий, а человек ну как минимум заинтересованный в разработке ПО. Проявите уважение, блядь!

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

Для начала: необходимо чтобы вы сами были знакомы с платформой/языком, на котором исполнен проект. Нужно это чтобы отличить авто-генерированный и glue-код от того, который автор написал сам. А то будете как дурак копаться в node_modules и восторгаться талантом, а человек просто не знает что node_modules добавляют в .gitignore. Fail. Так что в целевой платформе надо шарить хотя бы в общих чертах.

Дальше всё довольно просто: гуляем по директориям, оцениваем насколько всё логично и уместно организовано.

Логично: это когда человек может разложить код по полочкам так, чтобы не запутаться самому и не запутать других. Это отличный навык. Говорит о наличии системного мышления и способности "посмотреть сверху". Если всё хаотично рассовано по директорям — это флажочек о небрежности и непоследовательности. Необходимо уточнить у автора лично что за фигня.

Уместно: когда человек может организовать проект в соответствии с принятыми практиками для платформы, на которой работает. Это говорит о способности читать и усваивать стандарты разработки, а не воевать с ними. Если человек всё же воюет со стандартами разработки, то он будет обязан защитить своё решение и по фактам обосновать почему так лучше. В личном разговоре. Убедит — молодец. Не убедит — плохо.

Пытаемся въехать в проблематику и общий дизайн решения. Если удалось понять дизайн — ищем в нём огрехи и фиксируем вопрос для личного разговора. Если дизайн понять не удалось — кандидату же хуже. Будем заставлять рисовать дизайн на доске и объяснять почему так. Для проформы можно выбрать несколько совершенно рандомных файлов, притащить их кандидату и пытать на тему зачем они нужны и почему без них нельзя. Только смотрите не обосритесь, а то притащите код, сгенеренный фреймворком — стыдно потом будет. Хотя толковый кандидат и за генерированный код сможет пояснить.

Дальше надо составить общее понимание о том, как человек пишет. Откройте 10 рандомных файлов из разных точек проекта. Посмотрите насколько код в целом вменяем, написаны ли комменты, соблюдены ли naming conventions. Смотрите, используются ли фишки платформы и правильно ли они используются. Например в C# можно смотреть using-и, lock-и, системные атрибуты, правильную перегрузку equality members, корректное использование EF, ASP .NET MVC и иже с ними. Если понимания не сложилось — откройте ещё 10 файлов. И так далее, пока не сложится. Все возникающие вопросы записывайте в блокнотик и откладывайте до личного разговора.

Так же стоит обратить внимание на unit-тесты и сборочные скрипты. Если они есть — это win. Если проект собирается и выкладывается через github actions — это flawless victory. Если при этом ещё и прогоняются тесты — это fatality. Человек шарит за CI/CD, тестирование и — самое крутое — умеет это настраивать и использовать. А если у него есть понимание зачем это надо (уточняется в лично разговоре) — делайте оффер.

Важно понять следующее: не надо вчитываться и анализировать какие-то отдельные строчки. Всё равно досконально не разберётесь. Надо прочитать по диагонали и подбить тем для разговора с кандидатом на час-другой. Если глаз намётан, то на это уходит не более 10 минут. О чём говорить после просмотра репозитория — в следующем посте.

Не переключайтесь.

BY Novikov on Soapbox