German Jet

Эти подходы не только для крупных проектов, они вообще для любых проектов.

1. БД обновляется через миграции. То есть, вы пишете SQL-скрипты, которые нужно выполнить в БД (создание новых таблиц, новых колонок, добавление записей в справочные таблицы, удаление ненужных более колонок и т.д.), а система миграции (вот не в курсе есть ли такая у WP, но совершенно точно есть у более продвинутых Laravel/Doctrine) контролирует что скрипты миграций были выполнены (и выполнены в правильном порядке). Можно скрипты прокатывать и руками, но в таком случае всегда есть вероятность ошибки.
   
2. Разделение исходного кода и собранного кода. У вас есть исходный код и работает разработчик с исходным кодом проекта. Тут путаница возникает в том числе потому, что у PHP исходный код и исполняемый код - суть одно и тоже. Но концептуально разделять это стоит. После того как исходный код написан, выполняется сборка (в частности на этом этапе отрабатывают SCSS/gulp/webpack и т.п. инструменты) и получается код для загрузки на сервер. Поэтому задача "поменять цвет кнопки" решается изменением одной строчки в исходном коде, затем пересборкой и перезаливкой собранного кода на сервер
   
3. Пересборку и перезаливку можно делать вручную. Но лучше если этим будет заниматься CI-сервер. Бесплатно CI предоставляет, например, гитлаб. Насчет гитхаба/битбакета не в курсе, не интересовался. Суть в том, что при изменении исходного кода в репозитории, автоматически (или вручную) запускается некоторый процесс (pipeline), выполняющий сборку-тестирование-деплой новой версии. Разумеется, чтобы это все работало сначала придется потрудиться, разобраться, написать нужные скрипты и конфиги. Но для большого проекта это незаменимый инструмент.
   

Главная идея принципа инверсии зависимостей "детали зависят от абстракций, но не абстракции от деталей".
В приведенном вами примере класс Main зависит от всего: от интерфейса INumberOperation и от обоих классов NumberOperation1, NumberOperation2. То есть тут принцип инверсии зависимостей вообще не работает. Никак.

Проявляется же он в следующем примере. Пусть у меня есть некая абстрактная логика "прочитай число, выполни над ним операцию, запиши результат". Эта абстрактная логика (потому она и абстрактная) ничего не должна знать ни откуда она читает число, ни какую операцию над ним выполняет, ни куда и как записывает результат. Таким образом, у нас есть модуль, состоящий из

interface NumberInput {
  int read();
}
interface NumberProcessor {
  int process(int a);
}
interface NumberOutput {
  void write(int a);
}
class Processor {
  private final NumberInput input;  
  private final NumberProcessor processor;
  private final NumberOutput output;

  public Processor(NumberInput input, NumberProcessor processor, NumberOutput output) {
    this.input = input;
    this.processor = processor;
    this.output = output;
  }

  void process() {
    output.write(processor.process(input.read()));
  }
}

Все. Модуль получился очень абстрактным и ни от кого никак не зависящим.
Затем мы можем сделать реализации этих интерфейсов - они будут зависеть от нашего модуля логики (так как ссылаются на интерфейсы). И это полностью соответствует принципу инверсии зависимостей - детали зависят от абстракций.

И наконец функция main, которая будет собирать все это в единое целое. Она самое конкретное что есть в нашей программе, так как она имеет дело с конкретными классами, экземпляры которых она создает. Поэтому она зависит от всех модулей - от модуля абстрактной логики и от модулей с реализациями интерфейсов. И тут принцип инверсии зависимостей тоже соблюдается - деталь (в какой именно конфигурации запускается программа) зависит от абстракции (абстрактная логики и конкретные реализации интерфейсов из которых выбирается именно та, которая будет использована)

Этот принцип очень хорошо объяснен в книге Р.Мартина "Чистая архитектура", по крайней мере у меня все встало на свои места именно после прочтения этой книги.

Сетевое оборудование с которым можно столкнуться не углубляясь в дебри:

1. Хаб. Самое древнее и сейчас уже обычно неактуальное. В него включаются несколько сетевых проводов и все что он делает - пересылает все пакеты из каждого порта всем остальным. А дальше сетевые карты уже сами разбираются - надо им этот пакет или нет. Работает только в пределах локальной сети.
   
2. Свитч. Тот же хаб, но поумнее. Умеет понимать аппаратные адреса (MAC-адреса) и посылать пакеты конкретному адресату. Опять же работает только в пределах локальной сети.
   
3. Роутер. Соединяет 2 (или более) локальных сети, работает уже не на уровне MAC-адресов, а на уровне сетевых (IP) адресов. Определяет в какую локальную сеть отправить пакет в соответствии с таблицей маршрутизации. Обычно также может выполнять функции свитча, то есть поддерживать локальную сеть. И большинство роутеров "для дома" именно так и используются - локальная сеть на LAN-портах и маршрутизация пакетов в интернет через WAN-порт. Также роутеры часто содержат уйму дополнительных возможностей - DHCP, VPN-подключения, файрволл, NAT, проброс портов и т.д. Но концептуально это отдельный функционал. Маршрутизатор занимается только передачей пакетов из одной локальной сети в другую.
   
4. Точка доступа. Чисто технически это "беспроводной свитч". То есть весь функционал точки доступа - это принимать пакеты по проводу и транслировать их по радиоканалу для беспроводных устройств и наоборот - принимать пакеты по радиоканалу и транслировать их по проводу. Это точка доступа в узком смысле. Но домашние роутеры часто объединяют с точкой доступа, что и вызывает путаницу - я выхожу в интернет с телефона через точку доступа. Да, разумеется, потому что там 2-в-1 устройстве: точка доступа обеспечивает радиоканал, а маршрутизатор обеспечивает передачу данных в глобальную сеть.
   

Вот уже 9 Месяцев пишу на NestJS за деньги, и пока что могу сказать — ничего лучше на данный момент для NodeJS я не нашёл.

Благодаря экспрессу под капотом мы можем юзать кучу его крутых библиотек типа Swagger UI и так далее. Для всего тут автоматом генерируются тесты (темплейты). Можно адекватно пользоваться декораторами из тайпскрипта. А валидация в несте с его DTO это просто сказка.

С нестом наконец-то можно писать настоящий бекенд на ноде.

Конечно, Nest не идеальный. У меня много вопросов накопилось к этому фреймворку за время его использования, например про инъекцию зависимостей в гарды, интесепторы и т.д. из-за которой не получится нормально сделать JWT аутентификацию с помощью Nest модулей для этого (можно схитрить при помощи NestFactory.createApplicationContext(), а юзать этот обоссанный Passport.js я не хочу; выбрасывание исключений вместо нормального способа отправки ошибки пользователю, слабая документация. Однако я готов помучиться со всем этим, лишь бы не переходить на Express или любой другой фреймворк для ноды.

Я даже купил книгу Роберта Мартина про архитектуру — вот насколько меня всё это вдохновило!

Сервис — в нём пишем всю нашу логику. Сервис ничего не должен знать о запросе. У него нет доступа ни к Request, ни к Response.

Контроллер — принимает запрос и передаёт в наш сервис.

С бд можно работать в сервисе, но всё чаще вижу, что люди используют паттерн «Репозиторий», когда всю логику работы с бд суют в него.

С конца отвечу)
В первую очередь ознакомьтесь с конфигурацией УТ (Управление Торговлей). Она наиболее востребована и во многом пересекается с другими конфигурациями.

Что именно подразумевается под "знание" - вопрос неоднозначный, зависит от вакансии.
Например, для консультанта я спрашиваю план счетов бухучета (базово, без субсчетов и сложных операций), порядок проведения документов (какими документами отображается отражение приобретения товаров), соответственно это общая методология учета, заложенная в программу. Если с программой работали, ответить на вопросы не составляет труда, так как это фактически ежедневные операции. Бухгалтера и, тем более, какие-нибудь кладовщики, к сожалению, не всегда понимают эту логику.
Для программиста важно понимание структуры конфигурации, метаданных, организации хранения данных в объектах (здесь, на самом деле, не так важна конкретная конфигурация, они все похожи) - например, чем отличаются справочники, регистры сведений и регистры накопления. Кстати, поверьте, даже опытный разработчик может сходу на такой вопрос не ответить)

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

Автор, как советует куратор, разберись в себе. Тогда и без нас будешь знать, куда идти.

А ближе к теме...
Записывай слова для гугления:
АСУ ТП, SCADA, ПЛК, автоматизация производства, учёт электроэнергии, телеметрия, промышленная автоматизация.

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

Используй базу, которая у тебя есть, с умом.
Моё мнение, "уеб-программисты" в большинстве случаев - это путь для тех, кто никакой базы не имеет. Не ведитесь на рекламу курсов и предметные статьи/ролики блогеров и ютуберов.

И учти главное: у работодателей голод на хороших технарей в автоматизации производств последние лет 30. А джунов веб-мастеров переизбыток уже 15 лет минимум.

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

Но если желаете более предметно, то вот Вам мои ощущения по поводу Вашей структуры, к которой вы пришли...

Первое, что бросается в глаза - настройки. Да, Вы следуете идеологии Django, которая неявно шепчет всем нам как их компоновать: но это небезопасно. Почему в настройках у вас модули, два из которых отражает какое-то окружение (разработка, боевое и что-то общее между тем и тем)? Исходя из Вашей структуры сразу витает в воздухе вопрос: "А почему настройки боевого окружения вдруг должны быть в репозитории? А как быть с секретным ключом? А безопасно ли это?". Следующий логичный вопрос удобства: почему я, как разработчик, вдруг должен заставлять своих DevOps'ов компоновать и поддерживать за меня настройки в виде файлов (модулей)? Это ведь исполняемый файл и там бесчисленное количество возможностей; более того, это не безопасно. Сейчас бОльшая часть проектов поднимается средствами docker-compose, куберов и прочих прелестей: дико неудобно собирать и поддерживать настройки в виде файлов для каждого запускаемого контейнера (у нас ведь есть переменные окружения). Надеюсь, здесь понятен основной посыл: безопасность и удобство использования.

(здесь я не сразу понял, что это именно проект, а не приложение; подробности в комментариях)
Едем дальше - core. Почему именно такое название? Понятное дело, ядро, Django в своих исходниках делает и всё такое... Но зайдя в такой проект, сразу ли будет понятно за что отвечает это приложение? Нет. В общем-то даже в документации к Django в quick start название приложения опирается на её главную бизнес-потребность.

Переходим к следующему: папка apps с приложениями. Для начала вроде всё удобно и логично: есть ядро проекта, а есть дополнения к нему а значит их нужно как-то отделить от этого ядра. А что делать если ядро будет всегда одно в проекте? А что делать если дополнительных приложений будет всего одно? А зачем тогда ему целая папка (приложению) если само приложение - и есть папка (или модуль в нашем случае)? Так оставлять или менять уровень вложенности? На самом деле что core, что appN - являются такими же Django приложениями (одинаковыми), а значит и уровень абстракции у них - один; один уровень абстракции говорит нам о том, что и appN нужно класть где-то рядом с core (здесь должно быть другое название как и писал). Часто я вижу в проектах, что core так и остаётся одой единственной core папкой без дальнейшей расширяемости. Вывод - преждевременная оптимизация - вещь нелогичная по сути своей.

Папка template. Здесь я всегда доверяюсь Django и кладу шаблоны в папку приложения (делая ещё две папки - templates, а в ней - папку с названием приложения). Здесь, думаю, подойдёт правило класть то, что используется, ближе к тому месту, где это используется (но с поправкой на рекоммендации оф. документации Django).

Папка static. В среде отладки её быть в принципе быть не должно; обычно вся статика всегда в первую очередь связана с приложением, куда мы её и стараемся класть (как с папкой templates), что является и советом из Django документации.

Папка models. Вынося её куда-то в отличное от папки приложения место, мы сразу же забиваем на автономность самого приложения; приложение сразу же становится зависимым от внешнего кода (чего нужно избегать). Обычно каждое приложение имеет свои модели и не зависит от моделей другого приложения.

venv. Актуально только на компьютере каждого разработчика; по-моему это неудачное решение класть платформо-зависимые файлы под контроль версий.

https://hh.ru/search/vacancy?area=1&fromSearchLine...

Delphi - востребованный язык, первая же вакансия показывает зарплату более 125 тыс. руб.

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

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

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

Или ты умеешь работать и ты работаешь за деньги.
Или ты не умеешь, и предлагаешь себя бесплатно, но такие никому не нужны.
Ты уж определись.

Из стоящих работ к сожалению могу предоставить код своей незавершённой социальной сети.

Не всегда важен размер работы. Важна завершенность. Можно и маленькие вещи сделать. А если у вас за все ваше время был всего-лишь один недоделанный проект, который нельзя показать, еще и непонятно что делали вы, а что друг...

Зачем docker+redis для неработающего проекта?
Что docker+redis это какие-то совместимые технологии? Нет.

Что этим вы хотели сказать? Что вы хорошо знакомы с докером? не уверен.
Особенно, учитывая что вместо того, чтобы просто хранить докерфайлы и инструкцию по запуску, у вас прямо в гит-репо лежат бинарники питона и джанго
Вдобавок вообще нет ну никакого описания ни что это ни зачем это ни как это использовать. Такой код показывать нет смысла.
Зайтите на гитхабе в десяток совершенно рандомных репозиториев и постарайтесь за 3-5 минут понять что это за проект и зачем он. Если не выходит - то работодатель тем более не будет лазить по исходникам и пытатся искать конкретные коммиты. В идеале проект нужно показывать в рабочем состоянии, чтобы можно было зайти, покликать мышкой, а потом уже заинтересоваться как реализована конкретная штука в исходниках, но не наоборот

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

Какой процент помощи вам оказала убунта? вы непосредственно в ней писали, или просто запускали докер?

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

А самое важное для работодателя - это понимать уровень экспертизы и адекватности человека.

к примеру, у одного объявления в среднем 3 тега, на 1 миллион объявлений будет 3 миллиона записей в "объявления-теги", как там будет по скорости при выборке? Сильно я выиграю, если нарушу правило и буду писать теги, перечисляя их в строку через запятую?

1. Представим, что промежуточная таблица объявление-тег - это два гуида.
Тогда одна строчка будет занимать около 32 байт. 3*32*1000000 = 96 мегабайт (метрических)
2. Естественно, выборка будет медленной, если не добавить индекс. Индекс по id объявления ещё примерно столько же займёт. Выборка уже будет быстрее. Для фильтров ещё надо будет добавить индекс в обратную сторону - от id тега.
3. Ещё и фильтроваться по тегам можно будет, что, мне кажется, является одним из важнейших качеств тегов.
4. Если 96 мегабайт тебя пугает - используй int64 или int32 - тогда будет меньше в 2 или в 4 раза соответственно

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

Как уже сказали в комментах - очень сильно обосрёшься.
Выборка, конечно, будет очень быстрая, но
1. Представим что тег - это 6 букв на русском языке, а храним мы строки в Utf8 кодировке.
Тогда на каждое объявление будет тратиться 6*2*3+3+4=45 байт. Соответственно на миллион объявлений уйдёт 45 метрических мегабайт.
2. Но тут не будет индексов, по тому и фильтроваться будет очень дорого

PS: все прикидки по памяти взяты с потолка. В реальной БД числа будут другие, но примерно похожие.
PPS: если не совсем понятно, что я предлагаю, то вот:

._________.             .______________.           .____________.
| post    |             | post_tag     |           | tag        |
|=========|             |==============|           |============|
| id: int |<------------| post_id: int |           | id: int    |
| ...     |             | tag_id: int  |---------->| name: text |
|_________|             |______________|           |____________|

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

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

Как в наших реалях найти работу сис админа.

Все просто - ищешь вакансии, трудоустраиваешься.
Если не выходит - значит мало знаний или твой стек не подошел на эту позицию (но ты же заранее почитал требования в вакансии?)
В разных компаниях админы делают разные вещи.
В какой-то маленькой компании это просто заказать в интернет-магазине новое железо, подождать пока бухгалтерия проплатит, получить железки, собрать (если купил не собранный), поставить софт, добавить в сеть и периодически менять клавы, мышки, подключать патчкордами девайсы.
В другой к этому может добавиться еще и настройка единственного роутера в организации.
Но с такими вещами можно справиться и своими силами - продвинутые пользователи есть и среди бухгалтеров и среди менеджеров и других сотрудников. У них есть дети, друзья, племянники из айтишников, а множество магазинов предоставляют услугу сборки и установки OEM винды сразу, только в розетку включить и все.
Поэтому зачастую начинающий сисадмин на кусочек ставки вообще не нужен - маленькие компании экономят на всем, и на сотрудниках в том числе.

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

Есть огромное желание развиваться в данном направление.Опыт работы системным администратором нет.

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

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

Это очень общие слова. Вот мы понятия не имеем, насколько у тебя хорошее понимание и задач и насколько у тебя вообще есть навыки работы с софтом.

Есть опыт своего игрового сервера на esxi я не про vps а полноценный сервер.

Этой фразой ты противоречишь сам себе. Чем VPS не полноценный сервер - непонятно - сейчас на VPS навреное живет почти все.
Опять же игровые сервера бывают разные.
Например у меня был опыт нескольких игровых серверов. И опыт работы с ними можно сравнить с весьма неслабым опытом и разработки и поддержки в коммерческой организации.
А можно было просто поставить майнкрафт на домашнем компе без виртуалки - и тоже "опыт игрового сервера", при этом практически ноль технического.
То есть твоя формулировка ну ничего не несет (ну разве что ты создавал виртуалку на esxi, но ведь это может быть и create-next-done по инструкции в инете)

Так же знаю что нужно знать сетевые стеки tcp/ip, osi в этом не сильно силён но есть понимание настройки домашний сети.

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

Так же есть опыт в сборке железа. И работы с nas synology думаю на определенной фирме не стоит заострять внимание так как примерно все они работают одинаково. Но в чем же спросить проблема?

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

Все актуальные вакансии требуются с опытом от 2-3 лет.

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

Ситуация в мире сильно развилась за последние 20 лет. Если 20 лет назад просто поставить винду для обычного пользователя был сложный квест, то сейчас практически любая ОС ставится легко (next-next-done).
Не нужно компилировать софт под Линукс, не нужно ставить все драйвера руками под Windows 95 с постоянными синими экранами. Очень, очень много вещей сейчас user-friendly по сравнению с прошлым.
Поэтому недосисадмин-эникейщик - крайне редкий вид.

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

Минимальная ставка - это не преимущество. Вот давай серьезно. Нужно дома переклеить обои. И есть в интернете незнакомый человек, который говроит - я сделаю очень дешево, за копейки, но опыта у меня вообще нет. Наймешь? Или все-таки наскребешь и наймешь опытного? Или вообще сделаешь сам, потому что пускать к себе домой неизвестного человека, мало ли что он там наделает без опыта. Наклеит криво (испортит материалы), будет срать в твоем туалете, ходить по полу в грязной обуви, вообще в принципе чужие запахи. И нахрена это?
Незнакомого малоопытного человека нужно пустить в святая святых, где админ это по идее тот, у которого есть доступ ко всему, и к документам и к клиентам и вообще.

Конечно составлять sql запросы я не умею но понимание что такое БД тоже есть. Перечислять все свои знания либо понимание каких либо вещей не вижу смысла так как хочу услышать совета а не оставить здесь своё резюме))

Ну совет только один - повышай квалификацию, ищи дальше. Нет волшебной палочки.
Те же самые sql запросы - это настолько простая вещь, что простейшие sql запросы учат набирать в любом вузе. Как человек, считающий себя начинающим сисадмином не умеет? Нонсенс.
Понимание что такое БД - ну для этого достаточно прочитать 1 абзац в википедии. От сисадмина требуется хотя бы навыки резервного копирования, восстановления, простого траблшутинга.

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

Суть в практических знаниях.
2-3 года коммерческого опыта, это в первую очередь показатель, что ты наконец чему-то научился полезному для работы на позиции сисадмина.
В современном ИТ мире существует уже не просто абстрактный "компьютерщик", а множество профессий, которые уже и не особо друг с другом сочетаются.
Поэтому оценить что именно учить, без опыта работы - сложно.
Зато поработав в крупной организации со развитой инфраструктурой, даже не занимаясь техническими задачами, можно примерно понять что сделано, какими инструментами и главное зачем.

Вдобавок мотивация и психология. Заставлять себя регулярно (пусть не каждый день, но тратить много часов в неделю) заниматься различными техническими задачами, и делать это не ударную неделю, а годами.
Тут даже неважно какой возраст - подросток, юноша или взрослик - это чисто личная характеристика, когда ты сам себя мотивируешь и занимаешься работой, а не ищешь волшебные курсы, где тебе рассказывают как взять себя в руки и начать что-то делать.

Именно поэтому и требуют опыт, как самый простой способ подтвердить знания еще до собеседования.

Что можете посоветовать в данной ситуации

Не сможешь найти работу - изучай самостоятельно.
Без опыта тоже возьмут, если у тебя действительно есть знания и ты сможешь их подтвердить на собеседовании и испытательном сроке.
Это сделать сложно, но все в твоих руках.

а забыл упомянуть что есть так же оыпт работы с Linux и ssh на базавом уровне.

Что значат эти слова?
Для меня они обозначают, что ты очень плохо знаешь Linux и ssh, потому что... ну вот банально, давай спрошу про ssh. Как используется ssh ключ хостов? Поднимал обратный проброс портов через ssh?
Или подожди, я конечно догадываюсь, что ты перепутал слова и хотел сказать Linux и shell.
Но вот именно такие оговорки и подразумевают, что знания у тебя скорее всего недостаточны даже для работы стажером.

P.s думал выбрать направление devops но там все намного сложней нужен хороший опыт сис админа пока изучаю docker но уже научился git)

В DevOps вообще пока не лезь.
DevOps это уже путь ИЗ сисадмина или ИЗ разработчика или ИЗ тестировщика. Но первой профессией DevOps - это звучит бредово. DevOps в проекте нужен тогда, когда проект уже сложный. Настолько сложный, что нужен отдельный человек со специфическим набором навыков. DevOps джуниор это зачастую мид или даже сеньор в другой области.

Научился в git - опять таки слова, слова... Как ты им пользуешься? Есть что-то на гитхабе или в локальной репе? Или ты просто почитал что-то, попробовал что-то но даже не нашел как применить git в своих собственных повседневных задачах?

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