index0h

нормальной архитектурой, качеством кода, нормальным современным процессом с CI/CD и т.д.

От говнопроекта не застрахован никто, вне зависимости, php, java, c#, js, brainfuck...
Чаще всего архитектура, качество кода и вот это вот все развито там, где это критично для бизнеса и бизнес понимает, либо пишем нормально, либо жопа. Но таких, к сожалению, мало. Можете на собесе спросить, какой даунтайм допускается и как часто они происходят. Если адунтайм в минуту надо согласовывать за неделю и более - скорее всего об качестве пекутся. Если даунтайм в пол часа не особо проблема - всем нас*ать))

С одной стороны в требованиях были знания стильно-модно-молодежных Redis, Symfony понимания Git-Flow, Agile и т.д. и там же указаны - знание WP 1С-Битрикс. Как это можно понимать?

Это некомпетентность составившего вакансию, не более.

Как то, что придется занимать разно плановыми задачами?

Задайте вопрос рекрутеру))

Если выделить суть вопроса - как отличить компанию в которой можно будет вырасти в PHP разработчика, а не веб мастера.

Задайте несколько вопросов:
0. Вы продуктовая компания?
1. Что с их точки зрения легаси, какой его процент в проекте и как часто возвращается технический долг?
2. Какой процесс разработки от начала и до конца?
3. Какие стандарты и требования используются?
4. Какое покрытие тестами?

На собеседованиях обычно спрашивают уровень владения языком в баллах.

Вероятно это спрашивают неопытные итервьюеры. Ответ на этот вопрос с вашей стороны полностью субъективен, а со стороны интервьюера бесполезен.

Что нужно подтянуть, чтобы претендовтаь на 10 баллов из 10?

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

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

Задание на 3 дня - это постная хрень, которая говорит об низком уровне интервьюера.

Спрашивайте то, что вас интересует. Если ничего не интересует - ничего не спрашивайте.

Код ревью обычно ведется по каким то критериям качества (это нечто большее, чем код стайл). У вашего нового тл-а эти критерии жестче, чем у предыдущего. Обычно это хорошо. Это значит, что ему не нас*ать.

Потребуйте у нового тл-а список критериев оценки. Внимательно ознакомьтесь, если что-то не ясно, или спорно - задавайте вопрос: wtf?
Бывают спорные критерия стиля оформления, их принимают для унификации.
А бывают требования не очевидные, но вполне решающие какую-то свою задачу.

UPD

Вот вам пример критерия, об который сломана куча копий:
Валидация на тип и граничные значения должна быть в каждом публичном/защищенном методе.
Это очень геморный критерий, множество методов состоят из проверки аргументов более, чем на 50%. Но этот же критерий убирает целый класс ошибок + очень помогает в поиске ошибок.

Доходит до того, что он переделывает какие-то названия переменных или классов

Именование классов для вас вкусовщина?))

Или же он недоволен, когда я начинаю править что-то в коде для своей задачи

Вы нарушаете при этом принципы типа SOLID/YAGNI/... ?

Как вы считаете, что здесь играет роль?

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

Просто такой попался лид?

Самая большая похвала, которую я в свое время получил за свой код: "твой код не совсем говно", это при том, что ТЛ - с большой буквы, и мой код от его кода очень тяжело отличить, даже проработав более года на проекте.
Если ваш язык php - можете ознакомиться с требованиями: https://github.com/index0h/php-conventions

Или же у нас с ним пропасть в навыках, поэтому его коробит от любых моих действий?

Дык учитесь у него!

Сталкивались ли вы с подобной ситуацией? Как бы поступили?

Сталкивался и очень много спорил, по поводу каждого требования, у нас даже стоп слово было "иди на ***" - оно применялось, когда у сторон не хватает аргументации, что бы прийти к конкретному соглашению.

На данный момент, я хочу понять, стоит ли мне просить перевода на другой проект и сколько дать себе времени на то, чтобы привыкнуть к новому лиду?

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

Я понимаю, что я могла бы многое взять у этого человека, но всё сводится к тому (в моем восприятии), что он защищает свой идеальный код от меня.

Еще бы: представьте, вы кардиохирург, делаете операцию и тут подходит мед сестра и начинает тыкать больного скальпелем в ногу, что бы протез было удобно монтировать, хотя нога вполне здорова.