Большое спасибо за ревью (единственное в вопросе) и фидбек. С кретином вы погорячились, не зная полной картины (сроков выполнения, качество кода на момент подачи отклика, глубину знаний стека, etc). Банально могли нанять более опытного спеца, что уже имеет опыт коммерческой разработки в команде
Плюс подходы к разработке бывают разные. Есть сторонники ООП-подхода, есть сторонники ФП. Мне кажется нельзя объективно сказать, что подход X лучше подхода Y, т.к нужно учитывать большое количество переменных, вес которых каждый разработчик ставит исходя из своего опыта решения бизнес-задач.
Я думаю что сторонники ООП имеют бóльший шанс пройти собеседование с техлидом-сторонником ООП, и имеют бóльший шанс провалить собеседование с техлидом-сторонником ФП. Это нормально и логично. Некорректно будет обвинять ФП-техлида за то, что он отказал человеку, хорошо знающего ООП (и скептически относящегося к ФП). Вместо ООП и ФП можно подставить любой подход к разработке
Sun_Day, опять же, джуновских вакансий удаленно на ноду, по моим оценкам, около нуля. Не удаленно штуки две. На имеющиеся бывает по 300 заявок, как указали ниже. Поэтому приходится работать с тем, что имеется
Sun_Day, будучи джуном, откликаешься на любые вакансии, что есть. Конкретно джуновских вакансий на бекенд-ноде около нуля, как мне показалось) Плюс, в начале опыт важнее денег.
Тестовое было интересным и много чего узнал, в том числе благодаря фидбеку от техлида. Шанс получить работу при конкуренции в сто человек, я думаю, был, хоть и не очень высок) Поэтому не жалею, что выполнил ТЗ и откликнулся
tltary, я бы с радостью опубликовал ответ, если бы у меня было согласие, чтобы не тратить ничьё время, но ревью сразу получится biased, поэтому ответ изначально не опубликован
tltary, так и есть, основная цель (как и у всех других вопросов по тегу code review) - получить ревью от людей с разнообразным бекграундом и опытом разработки. Нет цели получить ответа на вопрос, почему меня не взяли. Единственная цель - получить ревью, чтобы не делать похожих ошибок в дальнейшем
approximate solution Большое спасибо за отклик. Я не расстраиваюсь) Единственная цель данного вопроса - получить фидбек о том, какие ошибки есть в коде, что можно исправить, и что не читабельно. Цели получить ответ на вопрос, почему меня не приняли, нет, т.к я подавал заявку на миддл\миддл+ позицию будучи джуном
Олег Смирнов, там всё адекватно, техлид грамотный и фидбек был предоставлен. Часть замечаний реализована. Но основная проблема, на которую мне указали и предложили потенциальное решение, всё еще есть в коде. Я на 99% согласен с потенциальным решением, но оно слегка идёт в разрез с тем пониманием, которое я получил по мере получения опыта. В силу того, что опыта у меня мало, хотелось бы послушать мнение от людей с разнообразным бекграундом\подходами, чтобы принять оптимальное решение, потому что с одной стороны фидбек от человека с реальным опытом коммерческой разработки, а с другой - где-то начитанные выкладки, которые вроде бы логичны, но не факт, что применяются в реальной разработке
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Плюс подходы к разработке бывают разные. Есть сторонники ООП-подхода, есть сторонники ФП. Мне кажется нельзя объективно сказать, что подход X лучше подхода Y, т.к нужно учитывать большое количество переменных, вес которых каждый разработчик ставит исходя из своего опыта решения бизнес-задач.
Я думаю что сторонники ООП имеют бóльший шанс пройти собеседование с техлидом-сторонником ООП, и имеют бóльший шанс провалить собеседование с техлидом-сторонником ФП. Это нормально и логично. Некорректно будет обвинять ФП-техлида за то, что он отказал человеку, хорошо знающего ООП (и скептически относящегося к ФП). Вместо ООП и ФП можно подставить любой подход к разработке
Буду рад услышать противоположную точку зрения