Ревью ТЗ, по которому отказ. Какие грубые ошибки совершил?

Question

[subsetofmultiset]

Добрый день. Откликнулся на вакансию, выполнив тестовое задание. (получил отказ)

Старался отделить домен от инфраструктуры\фреймворка, чтобы уменьшить сцепление и в случае расширения было легко поддерживать. Взамен пришлось писать кастомные решения, потеряв в легкочитаемости \ понимании кода, в силу того, что решения не стандартны

Стоит ли убрать разделение между доменом и инфраструктурой? Можете пожалуйста подсказать, какие грубые ошибки совершил и что можно исправить, чтобы улучшить качество кода?

Репозиторий (клик)
Тестовое задание (клик)

Comments

[Олег Смирнов]

А они не давали никакой фидбек? Если не давали, то это очень неадекватно, как мне кажется - давать такое объемное тестовое задание и не давать фидбек.

[Дмитрий]

Лучше напрямую спросить. Я спрашивал, и иногда отвечают. У меня был конкретный случай, что им понравилось мое тестовое задание, но они нашли специалиста, который согласен работать за меньшие деньги. Может у него чуть хуже код, а может нет, этого я не знаю, но факт, что он справился с заданием и просит меньше денег. Для многих конторок это решающий фактор

[subsetofmultiset]

Олег Смирнов, там всё адекватно, техлид грамотный и фидбек был предоставлен. Часть замечаний реализована. Но основная проблема, на которую мне указали и предложили потенциальное решение, всё еще есть в коде. Я на 99% согласен с потенциальным решением, но оно слегка идёт в разрез с тем пониманием, которое я получил по мере получения опыта. В силу того, что опыта у меня мало, хотелось бы послушать мнение от людей с разнообразным бекграундом\подходами, чтобы принять оптимальное решение, потому что с одной стороны фидбек от человека с реальным опытом коммерческой разработки, а с другой - где-то начитанные выкладки, которые вроде бы логичны, но не факт, что применяются в реальной разработке

[tltary]

subsetofmultiset, может лучше тогда опубликовать ответ?
что бы было понятно на что вы хотите получить фидбэк

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

[subsetofmultiset]

tltary, так и есть, основная цель (как и у всех других вопросов по тегу code review) - получить ревью от людей с разнообразным бекграундом и опытом разработки. Нет цели получить ответа на вопрос, почему меня не взяли. Единственная цель - получить ревью, чтобы не делать похожих ошибок в дальнейшем

[subsetofmultiset]

tltary, я бы с радостью опубликовал ответ, если бы у меня было согласие, чтобы не тратить ничьё время, но ревью сразу получится biased, поэтому ответ изначально не опубликован

[Sun_Day]

Щас бы тестовые задания такого объема выполнять. И 100к не зп мидла.
Короче, твоя ошибка в том, что ты вообще на такие вакансии откликаешься.
Ну а по тестовому: банально нашли чувака с большим опытом в бэкэнде как таковом, скорее всего.

[subsetofmultiset]

Sun_Day, будучи джуном, откликаешься на любые вакансии, что есть. Конкретно джуновских вакансий на бекенд-ноде около нуля, как мне показалось) Плюс, в начале опыт важнее денег.

Тестовое было интересным и много чего узнал, в том числе благодаря фидбеку от техлида. Шанс получить работу при конкуренции в сто человек, я думаю, был, хоть и не очень высок) Поэтому не жалею, что выполнил ТЗ и откликнулся

[Sun_Day]

subsetofmultiset, да не было никакого шанса получить работу, если там вакансия на мидла. Больше слушай тех, кто эту чушь несет.
Ищи вакансии, где конкретно хотят джуна и старайся там что-то делать, нравиться. Здесь ты только время будешь тратить, на тестовых не прокачаешься вообще никак.
Лучше тогда начни свой серьезный проект, больше пользы будет.
Сейчас не 2012 год, там сотни откликов послекурсовых гениев и тех, кто реально релевантен вакансии тоже хватает.

[subsetofmultiset]

Sun_Day, опять же, джуновских вакансий удаленно на ноду, по моим оценкам, около нуля. Не удаленно штуки две. На имеющиеся бывает по 300 заявок, как указали ниже. Поэтому приходится работать с тем, что имеется

[black1277]

Думаю, вы отсеялись в тот момент, когда согласились выполнять такое ТЗ бесплатно. Мидлы давно уже не берутся выполнять ТЗ, а тем более объемные. У них довольно широкий выбор и тратить время на ТЗ - для них потеря денег просто.

Answer 1

[approximate solution]

Может быть она уже нашли специалиста и проводить ваше code review уже было накладно.


Например стучится на эту вакансию 100+ человек, каждый высылает по тестовому заданию.

Факторы: скорость выполнения, адекватность собеседника, личные предпочтения. Какой-то фактор сыграл не в вашу пользу, и скорее всего вы отсеялись на уровне - "так, тех. задание выполнил, но Вася Пупкин из саратова сделал на 2 часа быстрее, + понравился HR или тех. лиду".

Итог: не расстраивайтесь, выполнять code review каждому потенциальному кандидату - это деньги, и время. Не все компании готовы выливать излишек.

PS: у нас на позицию джуна в прошлом месяце пришло 320 резюме + тех.задание, на 150м резюме мы остановились, условно мы нашли всех кандидатов, остальные 170 остались в недоумении скорее всего. Таков бизнес :)

Comments

[subsetofmultiset]

approximate solution Большое спасибо за отклик. Я не расстраиваюсь) Единственная цель данного вопроса - получить фидбек о том, какие ошибки есть в коде, что можно исправить, и что не читабельно. Цели получить ответ на вопрос, почему меня не приняли, нет, т.к я подавал заявку на миддл\миддл+ позицию будучи джуном

Answer 2

[xfg]

subsetofmultiset Бегло посмотрел код. Видно сразу что имеется определенное представление о слоистой/чистой/луковой архитектуре, возможно даже читал что-то из книг Эванса/Вернона по DDD и PoEAA от Мартина Фаулера, ну или как минимум какие-то статьи базирующиеся на информации из этих книг.

Довольно толково сделано. Единственное это то, что доменные сущности без поведения получились, состояние - есть, поведения - нет. Например следовало пету добавить метод любить человека, туда поместить бизнес-правила и если они все соблюдаются то создавать и возвращать из этого метода объект LovesHumanRelation и тому подобное. А так получилась что называется анемичная модель.

Но это всё можно быстро рассказать такому кандидату, дать почитать соответствующие главы из книг и будет реально толковый специалист. С такими знаниями не то что джуны, даже те кто сеньорами себя мнят ничерта подобного не знают. Одни ифоделы приходят (if-else-if-else).

Я так понял, для техлида то что ты написал получилось слишком сложно. Он походу хотел чтобы ты написал всё используя подход transaction script и готово, как это делают кнопкодавы.

Для меня, человек который вас не нанял - кретин. Показать бы ему что к нам приходит на собеседования за 100к.

Comments

[subsetofmultiset]

Большое спасибо за ревью (единственное в вопросе) и фидбек. С кретином вы погорячились, не зная полной картины (сроков выполнения, качество кода на момент подачи отклика, глубину знаний стека, etc). Банально могли нанять более опытного спеца, что уже имеет опыт коммерческой разработки в команде

Плюс подходы к разработке бывают разные. Есть сторонники ООП-подхода, есть сторонники ФП. Мне кажется нельзя объективно сказать, что подход X лучше подхода Y, т.к нужно учитывать большое количество переменных, вес которых каждый разработчик ставит исходя из своего опыта решения бизнес-задач.

Я думаю что сторонники ООП имеют бóльший шанс пройти собеседование с техлидом-сторонником ООП, и имеют бóльший шанс провалить собеседование с техлидом-сторонником ФП. Это нормально и логично. Некорректно будет обвинять ФП-техлида за то, что он отказал человеку, хорошо знающего ООП (и скептически относящегося к ФП). Вместо ООП и ФП можно подставить любой подход к разработке

Буду рад услышать противоположную точку зрения