С автором статьи в корне не согласен. Всё, что автор называет мифами, возможно для каких-то людей и являются мифами, но точно не для всех. Я работал полностью удалённо около 8 лет - с 15 по 23 год, до этого с 12 по 15 я работал на гибриде и также работаю с 23 до текущего момента. Удаленка дала мне возможность поездить по миру, посетить много интересных и удивительных мест. Но это приносило удовольствие не только мне - те места, куда я приезжал, были рады мне не меньше, но совсем в другом смысле - те скромные ресурсы, которые я привозил, позволяли им развиваться и делали жизнь людей лучше. Я даже в своё время написал текст о своём опыте и размышлениях на эту тему https://medium.com/@ivankhodyrev/do-not-return-to-the-office-44319aedb373 . И всё бы так и продолжалось, если бы не одно но, которое я в тот момент еще не очень учитывал: дети пошли в школу. И в этот момент выяснилось, что это самый большой и практически непреодолимый якорь, который привязывает вас к одному место, чаще всего большому городу. Почему? Потому что вы хотите отправить ребенка в хорошую школу, а это обычно есть только в больших городах, причем в школу очередь, экзамен,.... После школы у ребенка кружки, футболом по зуму не позанимаешься, опять же хорошие кружки есть в основном в больших городах и запись с лета на весь год. И т.д. Если бы современный мир был устроен по-другому и готов к тому, что люди мобильны и могут путешествовать круглогодично с детьми, не имея проблем с доступом к базовым сервисам, которые требуются для семейной жизни, я не задумываясь продолжал бы путешествовать. Сказать по правде, я верю, что в будущем это не будет проблемой и мир придет к значительно большей территориальной и сервисной диверсификации, возможно не на моём веку, но я абсолютно убежден, что это правильный вектор развития и что рано или поздно это станет реальностью.
Давать сложные задачи нужно. Обязательно ждать правильного ответа не стоит. Стоит послушать как человек размышляет и пытается решать проблему, которая перед ним стоит. Если все проблемы человека на собеседовании свести к разговору о нем самом, то вы вряд ли о нем что-нибудь узнаете.
ORM не сам по себе ценен, а в экосистеме. Если у вас есть способ автоматически генерировать энтити, валидировать, что ваши энтити совпадают с базой и делать типобезопасные запросы поверх энтитей, которые может проверить компилятор, то это безусловно значительно лучше, чем писать голый sql. Если же у вас ничего этого нет и всё делается руками, то вопрос о том имеет ли смысл использовать голый sql может иметь место.
JOOQ бесспорно хороший, но если у вас уже есть модель entitей, то почему бы не использовать например Querydsl, он и в связке со Spring data прекрасен и сам по себе великолепен. А хранить сгенереные классы в репозитории - это весьма опасный путь.
Это работает немного по-другому, непосредственный руководитель человека должен обязательно присутствовать на собеседованиях, чтобы понимать, что в голове у потенциального сотрудника, а сотрудник соответственно понимать, какие ожидания у руководителя.
Видите, как я написал в комментарии мой пост был про "хорошего" сотрудника, таким сотрудником я в силу своего опыта считаю только тех, для кого деньги не являются основным мотиватором. А что является? Интерес к отрасли, к технологиям, любопытство, стремление к познанию и саморазвитию (возможно неосознанное). И безусловно недовольство и даже обида, когда руководитель оказывается "не тот". Не потому, что платит мало денег. А потому, что "ведет компанию не туда", "выбирает не те технологии", "не хочет прислушиваться к профессионалам"... Именно для людей в такой ситуации я писал комментарий, а не тех, кто ставит материальную выгоду во главу угла. Деньги конечно важны, но "хороший" сотрудник в моём понимании - это человек, для которого в принципе может существовать вакансия, ради которой он готов пожертвовать материальной выгодой, пусть это и не та компания, в которой он работает сейчас. То, о чём пишете вы - я хорошим сотрудником не считаю и с такими людьми обычно долго не разговариваю. Вы скажете - это удобная позиция для руководителя и невыгодная для сотрудника. На поверхности это выглядит так, но если вы рассмотрите типичную карьеру сотрудника, для которого материальная выгода является вторичной перед нематериальной, то в конечном счёте через некоторое время выяснится, что он и зарабатывает больше и позиция у него выше и кругозор шире. Я не хочу вас переубеждать, это просто мой опыт.
Начал читать статью со скепсисом, но в итоге дочитал с интересом. Из своего 19 летнего опыта могу сказать, что практически со всем согласен. Отдельно хочу заметить про четвертый пункт: часто бывает такое, что и сотрудник хороший и руководитель неплохой, но вместе работать не могут. Никак. При другом руководителе всё было классно, при этом плохо. А у руководителя при этом с большинством сотрудников всё идеально. Я бывал с обеих сторон этой ситуации и могу дать совет сотруднику - надо отпустить и уйти. Не потому что ты плохой, неэффективный, халявщик, или непризнанный герой-правдоруб, а потому что в этой ситуации нет хороших решений, и копаться в причинах скорее всего бесполезно - вы не подходите друг другу. Но есть решение, которое чуть лучше, чем другое. Уход сотрудника по собственному желанию без скандала во-первых открывает перед ним новые горизонты рынка труда и обычно увеличение зарплаты, во-вторых это новые вызовы, новые технологии, возможно уход в смежную деятельность, короче всё, что принято называть развитием. И в-третьих о человеке останется хорошая память в команде: был не согласен с руководством, развернулся и сам ушёл, сохранил принципы, не изменил себе и т.д. Поверьте, репутация такого человека очень поможет вам в будущем, ваши бывшие коллеги через nное кол-во лет могут всё это вспомнить и сделать интересный оффер, хорошая репутация всегда хорошо запоминается. Ну а вторая опция - стоять до конца, саботировать, мочить в курилке и т.д. Обычно эта опция приятнее в моменте, но последствия будут значительно менее приятными причем не только для вас, но и для команды в целом.
Если мало ли вы попадете в такую ситуацию, смело выбирайте первый вариант. Если же вы руководитель, дайте человеку немного времени, пару раз намекните, что в мире много интересного помимо вашего болота, ну а потом, что делать, увольняйте.
Самое удивительное в истории с микросервисами - это как люди много лет делали вид, что все в порядке, и вдруг к середине 20х годов прозрели, что они не гугл, а бизнесу больше неинтересно слышать в качестве причины для увеличения бюджета/сроков "особенности архитектуры". Я хорошо помню свой шок от того, как в 16 году руководство настойчиво предложило мне "поделить всё на 10" - вместо одного приложения, репозитория, ci/cd и базы сделать 10. "-Зачем?" "-Так надо!" "-Нас пятеро, нас не 50!" "-Суть не в этом, мы изолируем бизнес области" "-У нас же все разбито по модулям, все изолировано!" "-Это не то!". Мне стоило больших усилий тогда отговорить их, хотя информационный фон этому мягко говоря не способствовал. 10 years later... и эти усилия к счастью больше не нужны. Начинаешь снова верить в здравый смысл.
Сделайте типизированный объект params/options и передавайте его.
Это можно, но тогда у каждого метода будет свой "in" объект и свой "out" объект. Для внешнего апи действительно, лучше так и делать, но для внутреннего, это выглядит тяжеловато особенно с учетом того, что компилятор подскажет тому, кто изменил метод, где еще нужно поменять и, например, если перед комитом обязательно делать билд, то без исправления всех мест человек просто не сможет отправить изменение, т.е. проблема обратной совместимости автоматизируется, а не энфорсится битьём по голове. Это работает почти из коробки для монорепы, если же речь о наборе репозиториев, то помучавшись чуть дольше можно настроить процесс так, чтобы перед коммитом собирались все репозитории с новыми изменениями. Еще как вариант - сделать полиморфный метод, со старой сигнатурой, который вызовет новый метод с дефолтными параметрами.
Аспекты вполне работают для библиотечного кода, например аннотация Transactional из спринга оборачивает метод соответствующим аспектом. А если вы когда-либо использовали библиотеку javamelody для observability, то там целый набор аспектов, которые регистрируют разные события и считают метрики абсолютно независимо от вашего кода и не требуя от вас практически ничего, кроме добавления зависимости и включения в код одной аннотации. Что касается джунов, то как ни странно, джун джуну рознь, есть толковые ребята, которые все схватывают на лету.
Про обертки над библиотеками двумя руками за. Много раз это спасало. Из последнего, меняли реализацию http библиотеки с okhttp на java http клиент, чтобы произвести замену нам пришлось переписать только один класс - собственно реализацию нашей обертки и всё, это очень экономит время.
Про параметры api согласен не до конца. Если речь про внутренний программный API и речь идет о строго типизированном языке, то лучше иметь конкретные параметры, которые нужны в данный момент. После их изменения компилятор подскажет вам, где нужно поменять код, а если делать универсальный нетипизированный параметр, то да, расширить его будет просто, но поправить все места, где это требуется будет сложнее.
Если же речь про внешний апи, то лучше всего и входные и выходные значения оборачивать в объект и добавлять в него поля по необходимости, либо, что, конечно, более правильно но дольше, делать api/v2/ с новым интерфейсом.
Что касается колбэков, то у разных языков есть разные механизмы, которые позволяют не тащить специфику middleware в параметрах по стеку вызовов. Для Java, например, можно использовать аспекты, на которых построено много интересного, от общих вещей вроде observability и транзакционности, до реализации бизнес специфичных требований. Этим не стоит увлекаться, иначе есть шанс получить сложно отлаживаемые ситуации, но часто это гораздо лучше, чем протаскивать лишнее в сигнатурах.
Пропустили пожалуй самый важный Jep - 491. Если кто не в курсе, проблема, которую он решает - это последняя преграда для того, чтобы можно было полноценно использовать Loom не боясь неприятностей (читай - дедлоков) от synchronized. Если вдруг вы не в курсе, что такое Loom, очень рекомендую прекрасную статью https://www.infoq.com/articles/java-virtual-threads. Спойлер: мучиться с async больше будет не нужно.
Не было никаких проблем с тем, чтобы двигаться с Classic UI вперед. Добавлять AI и новые функции можно было легко и в нём. Полностью всё менять в угоду сомнительной моде было совершенно необязательно.
То, что Jetbrains делает с UI/UX своих продуктов в последние 3 года - это очень плохо. Я не знаю, что точно у них изменилось внутри компании, но невооружееным глазом видно, что важные решения теперь принимаются без оглядки на пользовательский опыт. Похоже их стратегией стало: "Догнать и перегнать Vscode", а что там на местах происходит - это проблема мест.
Всегда удивлялся, что люди после java переходят на go. Единственный реальный плюс, который был актуален до недавнего времени, это горутины (сейчас после релиза loom это больше не актуально). Другие аргументы вроде "spring сложный, аннотации неочевидны" мягко скажем не про java и если у вас нет необходимости их использовать - это необязательно. Но больше всего меня поразило, когда в go наконец завезли генерики и я даже рассматривал его как потенциальный язык для следующего проекта, внезапно значительная часть комьюнити начала их хейтить, мол оно нам не надо. Это чем-то напомнило мне, как мои родители долго не переходили на смартфоны: "нам нужен кнопочный".
Много раз писал об этом на хабре, но раз уж есть целая статья о том, какие тестовые задания плохие, напишу еще раз. Тестовые задания работают. Я даю их уже много лет и нахожу с помощью них прекрасных специалистов, при этом не выгорая на разгребании сотен холодных откликов. Я не использую код в рамках тестовых в продакшене. Любому, кто сделал тестовое я оставляю обратную связь. С любым кто сделал тестовое хорошо, я разговариваю. Разговор я всегда начинаю с тестового задания, которое в дальнейшем выступает лейтмотивом разговора и предметом life-кодинга. За все эти годы ни разу поиск не занимал больше полутора месяцев. Я отдаю себе отчет, что тестовое может срезать специалистов высокого уровня, но с введением этой практики значительно выросло как минимальное, так и среднее время нахождения нанятых спеалистов в компаниях, т.е. люди, выполнившие тестовые, оказывались в среднем лояльнее. Это крайне важно, поскольку частые увольнения, особенно в небольших командах, сильно бьют по их устойчивости. Также на практике было проверено, что люди хорошо выполнившие тестовое и прошедшие собеседование, гораздо проактивнее в целом и быстрее разбираются в чём-то новом, т.е. дорасти до нужного уровня, если он ниже, чем хотелось бы, для них проще, а с учетом того, что они реже увольняются, время на это есть.
Компаниям, которые внедряют эту практику, могу посоветовать потратить время и сделать тестовое задание небанальным и интересным. От себя добавлю, что когда сам устраивался, то получал от интересных тестовых большое удовольствие, а неинтересные просто не делал, в этом смысле выбор всегда есть.
Если у вас всё замечательно с индексами субд, то какие тогда могут быть проблемы с хэш таблицей? Если же у вас есть проблемы с хэш таблицей, то я не уверен, что вы до конца понимаете индексы субд.
С автором статьи в корне не согласен. Всё, что автор называет мифами, возможно для каких-то людей и являются мифами, но точно не для всех. Я работал полностью удалённо около 8 лет - с 15 по 23 год, до этого с 12 по 15 я работал на гибриде и также работаю с 23 до текущего момента. Удаленка дала мне возможность поездить по миру, посетить много интересных и удивительных мест. Но это приносило удовольствие не только мне - те места, куда я приезжал, были рады мне не меньше, но совсем в другом смысле - те скромные ресурсы, которые я привозил, позволяли им развиваться и делали жизнь людей лучше. Я даже в своё время написал текст о своём опыте и размышлениях на эту тему https://medium.com/@ivankhodyrev/do-not-return-to-the-office-44319aedb373 . И всё бы так и продолжалось, если бы не одно но, которое я в тот момент еще не очень учитывал: дети пошли в школу. И в этот момент выяснилось, что это самый большой и практически непреодолимый якорь, который привязывает вас к одному место, чаще всего большому городу. Почему? Потому что вы хотите отправить ребенка в хорошую школу, а это обычно есть только в больших городах, причем в школу очередь, экзамен,.... После школы у ребенка кружки, футболом по зуму не позанимаешься, опять же хорошие кружки есть в основном в больших городах и запись с лета на весь год. И т.д. Если бы современный мир был устроен по-другому и готов к тому, что люди мобильны и могут путешествовать круглогодично с детьми, не имея проблем с доступом к базовым сервисам, которые требуются для семейной жизни, я не задумываясь продолжал бы путешествовать. Сказать по правде, я верю, что в будущем это не будет проблемой и мир придет к значительно большей территориальной и сервисной диверсификации, возможно не на моём веку, но я абсолютно убежден, что это правильный вектор развития и что рано или поздно это станет реальностью.
Давать сложные задачи нужно. Обязательно ждать правильного ответа не стоит. Стоит послушать как человек размышляет и пытается решать проблему, которая перед ним стоит. Если все проблемы человека на собеседовании свести к разговору о нем самом, то вы вряд ли о нем что-нибудь узнаете.
ORM не сам по себе ценен, а в экосистеме. Если у вас есть способ автоматически генерировать энтити, валидировать, что ваши энтити совпадают с базой и делать типобезопасные запросы поверх энтитей, которые может проверить компилятор, то это безусловно значительно лучше, чем писать голый sql. Если же у вас ничего этого нет и всё делается руками, то вопрос о том имеет ли смысл использовать голый sql может иметь место.
JOOQ бесспорно хороший, но если у вас уже есть модель entitей, то почему бы не использовать например Querydsl, он и в связке со Spring data прекрасен и сам по себе великолепен. А хранить сгенереные классы в репозитории - это весьма опасный путь.
Это работает немного по-другому, непосредственный руководитель человека должен обязательно присутствовать на собеседованиях, чтобы понимать, что в голове у потенциального сотрудника, а сотрудник соответственно понимать, какие ожидания у руководителя.
Видите, как я написал в комментарии мой пост был про "хорошего" сотрудника, таким сотрудником я в силу своего опыта считаю только тех, для кого деньги не являются основным мотиватором. А что является? Интерес к отрасли, к технологиям, любопытство, стремление к познанию и саморазвитию (возможно неосознанное). И безусловно недовольство и даже обида, когда руководитель оказывается "не тот". Не потому, что платит мало денег. А потому, что "ведет компанию не туда", "выбирает не те технологии", "не хочет прислушиваться к профессионалам"... Именно для людей в такой ситуации я писал комментарий, а не тех, кто ставит материальную выгоду во главу угла. Деньги конечно важны, но "хороший" сотрудник в моём понимании - это человек, для которого в принципе может существовать вакансия, ради которой он готов пожертвовать материальной выгодой, пусть это и не та компания, в которой он работает сейчас. То, о чём пишете вы - я хорошим сотрудником не считаю и с такими людьми обычно долго не разговариваю. Вы скажете - это удобная позиция для руководителя и невыгодная для сотрудника. На поверхности это выглядит так, но если вы рассмотрите типичную карьеру сотрудника, для которого материальная выгода является вторичной перед нематериальной, то в конечном счёте через некоторое время выяснится, что он и зарабатывает больше и позиция у него выше и кругозор шире. Я не хочу вас переубеждать, это просто мой опыт.
Начал читать статью со скепсисом, но в итоге дочитал с интересом. Из своего 19 летнего опыта могу сказать, что практически со всем согласен. Отдельно хочу заметить про четвертый пункт: часто бывает такое, что и сотрудник хороший и руководитель неплохой, но вместе работать не могут. Никак. При другом руководителе всё было классно, при этом плохо. А у руководителя при этом с большинством сотрудников всё идеально. Я бывал с обеих сторон этой ситуации и могу дать совет сотруднику - надо отпустить и уйти. Не потому что ты плохой, неэффективный, халявщик, или непризнанный герой-правдоруб, а потому что в этой ситуации нет хороших решений, и копаться в причинах скорее всего бесполезно - вы не подходите друг другу. Но есть решение, которое чуть лучше, чем другое. Уход сотрудника по собственному желанию без скандала во-первых открывает перед ним новые горизонты рынка труда и обычно увеличение зарплаты, во-вторых это новые вызовы, новые технологии, возможно уход в смежную деятельность, короче всё, что принято называть развитием. И в-третьих о человеке останется хорошая память в команде: был не согласен с руководством, развернулся и сам ушёл, сохранил принципы, не изменил себе и т.д. Поверьте, репутация такого человека очень поможет вам в будущем, ваши бывшие коллеги через nное кол-во лет могут всё это вспомнить и сделать интересный оффер, хорошая репутация всегда хорошо запоминается. Ну а вторая опция - стоять до конца, саботировать, мочить в курилке и т.д. Обычно эта опция приятнее в моменте, но последствия будут значительно менее приятными причем не только для вас, но и для команды в целом.
Если мало ли вы попадете в такую ситуацию, смело выбирайте первый вариант. Если же вы руководитель, дайте человеку немного времени, пару раз намекните, что в мире много интересного помимо вашего болота, ну а потом, что делать, увольняйте.
Самое удивительное в истории с микросервисами - это как люди много лет делали вид, что все в порядке, и вдруг к середине 20х годов прозрели, что они не гугл, а бизнесу больше неинтересно слышать в качестве причины для увеличения бюджета/сроков "особенности архитектуры". Я хорошо помню свой шок от того, как в 16 году руководство настойчиво предложило мне "поделить всё на 10" - вместо одного приложения, репозитория, ci/cd и базы сделать 10. "-Зачем?" "-Так надо!" "-Нас пятеро, нас не 50!" "-Суть не в этом, мы изолируем бизнес области" "-У нас же все разбито по модулям, все изолировано!" "-Это не то!". Мне стоило больших усилий тогда отговорить их, хотя информационный фон этому мягко говоря не способствовал. 10 years later... и эти усилия к счастью больше не нужны. Начинаешь снова верить в здравый смысл.
Это можно, но тогда у каждого метода будет свой "in" объект и свой "out" объект. Для внешнего апи действительно, лучше так и делать, но для внутреннего, это выглядит тяжеловато особенно с учетом того, что компилятор подскажет тому, кто изменил метод, где еще нужно поменять и, например, если перед комитом обязательно делать билд, то без исправления всех мест человек просто не сможет отправить изменение, т.е. проблема обратной совместимости автоматизируется, а не энфорсится битьём по голове. Это работает почти из коробки для монорепы, если же речь о наборе репозиториев, то помучавшись чуть дольше можно настроить процесс так, чтобы перед коммитом собирались все репозитории с новыми изменениями. Еще как вариант - сделать полиморфный метод, со старой сигнатурой, который вызовет новый метод с дефолтными параметрами.
Аспекты вполне работают для библиотечного кода, например аннотация Transactional из спринга оборачивает метод соответствующим аспектом. А если вы когда-либо использовали библиотеку javamelody для observability, то там целый набор аспектов, которые регистрируют разные события и считают метрики абсолютно независимо от вашего кода и не требуя от вас практически ничего, кроме добавления зависимости и включения в код одной аннотации. Что касается джунов, то как ни странно, джун джуну рознь, есть толковые ребята, которые все схватывают на лету.
Про обертки над библиотеками двумя руками за. Много раз это спасало. Из последнего, меняли реализацию http библиотеки с okhttp на java http клиент, чтобы произвести замену нам пришлось переписать только один класс - собственно реализацию нашей обертки и всё, это очень экономит время.
Про параметры api согласен не до конца. Если речь про внутренний программный API и речь идет о строго типизированном языке, то лучше иметь конкретные параметры, которые нужны в данный момент. После их изменения компилятор подскажет вам, где нужно поменять код, а если делать универсальный нетипизированный параметр, то да, расширить его будет просто, но поправить все места, где это требуется будет сложнее.
Если же речь про внешний апи, то лучше всего и входные и выходные значения оборачивать в объект и добавлять в него поля по необходимости, либо, что, конечно, более правильно но дольше, делать api/v2/ с новым интерфейсом.
Что касается колбэков, то у разных языков есть разные механизмы, которые позволяют не тащить специфику middleware в параметрах по стеку вызовов. Для Java, например, можно использовать аспекты, на которых построено много интересного, от общих вещей вроде observability и транзакционности, до реализации бизнес специфичных требований. Этим не стоит увлекаться, иначе есть шанс получить сложно отлаживаемые ситуации, но часто это гораздо лучше, чем протаскивать лишнее в сигнатурах.
Пропустили пожалуй самый важный Jep - 491. Если кто не в курсе, проблема, которую он решает - это последняя преграда для того, чтобы можно было полноценно использовать Loom не боясь неприятностей (читай - дедлоков) от synchronized. Если вдруг вы не в курсе, что такое Loom, очень рекомендую прекрасную статью https://www.infoq.com/articles/java-virtual-threads. Спойлер: мучиться с async больше будет не нужно.
Удалено
В старом интерфейсе они хотя бы были. В новом всё скрыто за несколькими слоями различных меню по принципу hotkey or die.
Не было никаких проблем с тем, чтобы двигаться с Classic UI вперед. Добавлять AI и новые функции можно было легко и в нём. Полностью всё менять в угоду сомнительной моде было совершенно необязательно.
Нет, этого недостаточно. Я говорю не только за себя. Это ясно видно из статистики скачиваний и комментариев к плагину classic ui.
То, что Jetbrains делает с UI/UX своих продуктов в последние 3 года - это очень плохо. Я не знаю, что точно у них изменилось внутри компании, но невооружееным глазом видно, что важные решения теперь принимаются без оглядки на пользовательский опыт. Похоже их стратегией стало: "Догнать и перегнать Vscode", а что там на местах происходит - это проблема мест.
Если коротко отвечать автору, то нет, ООП не так плох, как написано в статье, а Java до сих пор один из лучших языков программирования.
Всегда удивлялся, что люди после java переходят на go. Единственный реальный плюс, который был актуален до недавнего времени, это горутины (сейчас после релиза loom это больше не актуально). Другие аргументы вроде "spring сложный, аннотации неочевидны" мягко скажем не про java и если у вас нет необходимости их использовать - это необязательно. Но больше всего меня поразило, когда в go наконец завезли генерики и я даже рассматривал его как потенциальный язык для следующего проекта, внезапно значительная часть комьюнити начала их хейтить, мол оно нам не надо. Это чем-то напомнило мне, как мои родители долго не переходили на смартфоны: "нам нужен кнопочный".
Много раз писал об этом на хабре, но раз уж есть целая статья о том, какие тестовые задания плохие, напишу еще раз. Тестовые задания работают. Я даю их уже много лет и нахожу с помощью них прекрасных специалистов, при этом не выгорая на разгребании сотен холодных откликов. Я не использую код в рамках тестовых в продакшене. Любому, кто сделал тестовое я оставляю обратную связь. С любым кто сделал тестовое хорошо, я разговариваю. Разговор я всегда начинаю с тестового задания, которое в дальнейшем выступает лейтмотивом разговора и предметом life-кодинга. За все эти годы ни разу поиск не занимал больше полутора месяцев. Я отдаю себе отчет, что тестовое может срезать специалистов высокого уровня, но с введением этой практики значительно выросло как минимальное, так и среднее время нахождения нанятых спеалистов в компаниях, т.е. люди, выполнившие тестовые, оказывались в среднем лояльнее. Это крайне важно, поскольку частые увольнения, особенно в небольших командах, сильно бьют по их устойчивости. Также на практике было проверено, что люди хорошо выполнившие тестовое и прошедшие собеседование, гораздо проактивнее в целом и быстрее разбираются в чём-то новом, т.е. дорасти до нужного уровня, если он ниже, чем хотелось бы, для них проще, а с учетом того, что они реже увольняются, время на это есть.
Компаниям, которые внедряют эту практику, могу посоветовать потратить время и сделать тестовое задание небанальным и интересным. От себя добавлю, что когда сам устраивался, то получал от интересных тестовых большое удовольствие, а неинтересные просто не делал, в этом смысле выбор всегда есть.
Если у вас всё замечательно с индексами субд, то какие тогда могут быть проблемы с хэш таблицей? Если же у вас есть проблемы с хэш таблицей, то я не уверен, что вы до конца понимаете индексы субд.