Простите, я тут повангую и поностальгирую немного. Когда-то, лет в 22-25, я "почти все знал про IT". Конечно, не в полной мере, но имел представление обо всем, какой-то хотя бы небольшой опыт во многом. Да, отчасти это можно списать на юношескую самоуверенность и Даннинга-Крюгера (где-то я возможно не видел границы своей некомпетентности), но только отчасти.
Я считаю себя генералистом. То есть, такой "универсальный солдат", могу кун-фу, могу самбо, могу стрелять из гаубицы и из лука, управлять гироскутером, камазом и звездолетом, и все это делаю одинаково плохо (но, тем не менее, гравицапу установить и координаты в тентуре расчитать смогу). Думаю, что я достаточно важный и ценный сотрудник там, где я работаю, и очень неплохо зарабатываю, в пересчете на час работы. Однако, если бы я пошел на собеседование на более скромную позицию какого-нибудь программиста или админа - наверняка завалил бы продвинутые тесты по множеству тем, кроме нескольких. Любой узкий специалист который 10 лет делает одно дело, знает это дело лучше и глубже.
Сфера IT в мои 20+ самом деле была гораздо меньше, чем сейчас. Через пару десятков лет после первого сеанса братьев Люмьер было несложно стать киноведом, который видел все фильмы.
К примеру, MySQL и PostgreSQL вышли в середине 90-ых. Тогда было несложно знать эти новые крошечные и простые проекты. Отработал JOIN слева, JOIN справа - и вот у тебя уже черный пояс по SQL, а значит и по базам данных в целом (потому что больше пока что ничего просто и нет). До появления Redis (key-value) было еще 10+ лет, до CockroachDB и Prometheus - 20 лет - можно было ничего о них не знать, и быть полноценным гуру в СУБД с полными знаниями о теме! Сейчас я не уверен, что смогу назвать даже все типы СУБД которые есть (реляционные, key-value, документные, графовые, time-series, ....), не говоря уже о названиях проектов. Что мы сейчас (в суровой реальности) можем ожидать от программиста в сфере баз данных? Мы ему объясняем проект, он нам распишет схему, как ее по табличкам разбить, какие индексы создать и что подкрутить с настройками СУБД под нашу специфику. Но это очень плохой уровень . А что я хочу от эксперта? Чтобы он сказал, к примеру: тут вам лучше вообще не реляционную использовать, а NOSQL, вот либо СУБД А, либо B, либо C (она только в прошлом году появилась, но очень итересная!). Но у A плохая лицензия, подходят только B и С. По скорости, для ваших задач лучше подойдет B, она на таком типе нагрузок по бенчмаркам быстрее работает, но у вас Debian на серверах? А у нее на Debian есть утечки памяти - возможно это блокирующая проблема. Еще, вы хотите из Java с ней работать? Для Java у нее нет клиента, только для C и Python, так что, придется доработать или дождаться.
