Комментарии 14
Хороший подход. Пока активно собесил, всегда строил практическую часть разговора вокруг код-ревью. Кусок кода был гораздо грязнее и, что называется, "с особым цинизмом". Я там насчитывал до 26 проблем. Сеньоры без проблем находили почти все, джуны и самозванцы могли и пяти не осилить. Выборка около 100 кандидатов. Алгосы и теория всегда оставляют сомнение, а ревью почти никогда.
Интересный вариант. Но на практике, когда приходишь на проект, никогда не разрешают переделывать код. Всегда требуют писать в том же стиле, что уже есть на проекте.
Да, это действительно неплохой подход, лично мне такое нравится. Однако, тут может быть несколько вопросов.
Во первых разные подходы в понимании "что такое хорошо и что такое плохо". Например людям может быть "наплевать" на солид, но они любят KISS и т.д. Это я привел просто какой-то крайний случай различий. И тут получается, что да, мы берём специалиста "под себя", но мы не можем гарантировать, что выбор будет лучшим.
Код слишком длинный. Лично я просто "запутался" пока читал ) Да, 20 минут исправят ситуацию само собой, но не слишком ли это будет долго? Собеседование в любом случае стрессовая ситуация, а ещё и сидеть так долго и "под присмотром". Это конечно чисто мое имхо, но я бы сократил код и просто дал бы меньше времени.
Но, в любом случае, это действительно лучше чем решать тупые стандартные задачки.
На нескольких собесах сталкивался с таким. Вроде и в Яндексе просили чужой код прокомментировать. Потом в реальной работе обидно бывает, когда "работает же, не трогай, нам сейчас не до этого, пили новую фичу, потом как нибудь отрефакторим".
Да, такой подход получше чем олимпиадные задачки, особенно если вы не гугл.
Нахожу 5 ошибок, дальше отправляю лесом(передаю коллегам). Ибо в реальности отправлю автора такого кода на... performance improvement plan, т.к. в работать с такими очень сложно.
Сам проходил через это со стороны ревьюера, поэтому более профессиональным считаю по максимуму отдать такую работу линтерам, стайлчекерам и т.п. анализаторам кода. (читать статью "Вы не умеете делать code-review")
Отличный подход! Спасибо за статью! Надеюсь рано или поздно компании откажутся от лавкодинга в пользу рефакторинга.
Когда приходишь на новую работу в первую очередь на тебя вываливают кучу легаси кода и с ним приходится разбираться. А не деревья вертеть как на собесе.
Два раза встречался с таким подходом на собеседовании - и оба раза мне понравилось. Опыта просмотра кода много, т.к. преподаю и применяю подход: студенты проводят ревью моего кода, а я их. Поэтому более-менее просто могу увидеть что-то что мне не понравится в коде. Но, опять же, у меня один подход к написанию, у кого-то другого - другой. И не всегда он совпадает. Понятно, что есть что-то "фундаментально" как именование, но есть и что-то более размытое. Например, DI (Dependency Injection).
Но бывают ситуации, про которые выше уже писали, что на собеседовании ты делаешь ревью кода - а на работе "потом, сейчас некогда...". И это очень печалит.
Очень простой и скучный код в примере. Все проблемы расскажет любой толковый студент.
Но если у вас задачи уровня «сложить формы в базу», для которых студентов достаточно, то норм.
Этот код содержит как простые ошибки, которые заметит любой толковый студент, так и менее заметные и концептуальные. Например, HttpClient socket exhaustion или отсутствие TimeProvider. К тому же про каждую из таких ошибок - можно рассказать более развернуто с примерами из опыта. Я насчитал как минимум 50 недочетов. Уверен, их можно найти больше.
Получается занимательная беседа двух разработчиков которые общаются наравне - гораздо приятнее, когда оценивают не тебя, а ты оцениваешь код в комфортной беседе с интервьюером. Еще классно, когда кандидат находит новую ошибку или предлагает идею, которую я раньше не замечал.
Программирую 30 лет, был синьором дважды и лет 7 тимлидом, подымал продукты в одиночку, проводил много интервью, с задачей не справился. Смотрел на код пол часа, не понял что от меня хотят. Где там какой солид в трёх строках, о каком масштабировании речь, куда там транзакции, что значит не оптимальное использование базы, как предполагалось обрабатывать исключения, нахрена какие-то лишние строки, с чего уже нельзя бизнес логику в контроллере, когда она вся в три строки и так далее. Пошел уволюсь.
Проходил задачи подобного рода и всегда заваливался. Потому что за 20 минут нужно не только понять код, но и понять правила этой игры.
Если я вижу реальный код, я знаю что он как минимум работает, знаю что если в не что-то плохо, то это не просто так, а потому что были причины так сделать. Или я знаю что это джуниор и он не знает некоторых вещей и в этом причина. На искусственном код ревью это так не работает. Нужно догадаться, что намеренный косяк, а что условность, введённая потому, что это не реальный проект. Например, эта схема с накапливанием пользователей в списке, это на полном серьёзе или это условное упрощение?
И ещё говорят "с сохранением интерфейсов" но никогда не говорят что именно нельзя менять.
Когда устал от алгоритмов: Ревью кода на собеседовании