Где описана методика определения уровня скиллов — от джуна до сениора?

Для этого есть какие-то устоявшиеся методики или программисты сами себе лычки придумывают?

Скорее второе.
Система грейдов может сильно отличаться в разных компаниях. В Сбере, например, любят сразу давать «старшего» разработчика, даже людям совсем без опыта.
В некоторых командах абсолютно невозможно стать «сеньером», но как-то, за выслугу лет, видимо, «сеньера» там получают. Да и рост з.п. как-то нужно оправдывать перед hr.

Где описана методика определения уровня скиллов — от джуна до сениора?

Нигде, это абстракции, зависящие от компании. Джун в одной может быть тем самым, что и синьор в другой.

Как понять что ты уже не джун, а миддл?

Открыть своё резюме и посмотреть названия занимаемых должностей.

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

Никто, вы можете себя назвать хоть гениралисимусом.

Для этого есть какие-то устоявшиеся методики или программисты сами себе лычки придумывают?

Это не методика. Как определить свой уровень программирования?

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

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

В сфере разработки ПО кругом одни абстракции: инструменты, процессы, рабочие окружения, методики. Поэтому стек технологий и получил приставку «софт».

Для специализаций, которые ближе к железу, требования, область важных знаний и определение уровней квалификаций меняются не так быстро. Но вот в чем ближе к софту, тем сильнее одно место работы может отличаться от другого.

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

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

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

Подытожу: если получилось получить оффер на архитектора, значит архитектор; если при этом получил из другой фирмы оффер на джуна значит джун.

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

Обычно, методика она не описывается, поскольку все зависит от конкретного исполнителя. Но может быть записана, если того требует бюрократия, во внутреннем документе какой-то корпорации, например, в корпорации зла такой документ есть, правда все существенные детали все равно не записаны, а находятся в головах тех, кто проводит тестирование/собеседование.