Ибо сложные запросы - это обычно признак того, что в проекте по недосмотру архитектора смешаны OLTP и аналитика
С чего бы? Для расследования ошибок в проде не надо писать запросы? Будут ли они такие же, как на hql? Не стоит же задача "написать запрос для hibernate"?
Максимум чего бы я в этом смысле смотрел - это понимает ли человек как работают стримы - и может ли он переписать код со стримами на код без них ? Потому что есть деятели, которые запоминают методы стримов как магические слова...
Я проверял, а знает ли человек эту магию вообще. Про устройство даже не начинаю говорить. Незачем, цель другая.
Вообще - главный вопрос который надо решить на собеседовании - это умеет ли человек ясно и однозначно мыслить о свойствах сложных систем ?
Еще требование знать N библиотек, M паттернов. От платформы, от корпорации.
На мой взгляд, задача с нечеткой постановкой на более высокий уровень. Именно потому что не только НФТ отсутствуют, но и ФТ не все прописаны:
есть ли органы управления?
можно ли прокручивать?
может ли устройство само включать бегущую строку?
одинаков ли буфер для кириллицы и латиницы?
какие ограничения по кодировке?
почему изначально на входе нет фильтра при сохранении в системе длинных строк?
Ну и в целом, лично у меня такая задача вызовет чувство абсурдности:
пишем на джаве, то есть контейнер в контейнере в контейнере
сверху всякая оркестрация и гейтвеи
и вывод на дисплей с 20 символами.
Это как вообще?
Я бы, встретив такую задачу, вспомнил бы бесмыссленность некоторых оптимизаций на литкоде.
Ну и, самое, пожалуй, главное. Это задача больше инженерная. Те разработчики, миддлы с галер и финтехов, чаще возраста 25-30,не инженеры, часто не имеют (не показывают) инженерный склад ума. Кандидаты возраста 40+ может более целевая аудитория для таких проверок. Но их мало приходило. И абстракции с перечислениями были поеятны, затруднений не вызывало.
Да, задача прикольная и интересная, но не для моих задач, которые описываю. Она имеет другую постановку, требует выявления совсем других требований, нежели продуктовая разработка. В продукте стримы, мапперы, ретраи, работа со структурными списками. Так зачем давать задачу про дисплей? Не уместнее задачи на сортировки, маппинг, изоляцию и транзакционность?
Есть набор требований "сверху". Их здесь оценивать не будем. Среди них- умение разбираться в некоторых вопросах. Значит можно или скопипастить задачу с какого-то известного сайта или дать свою. Я не вносил новые секции, я переработал уже существовавшие. Если было требование sql, значит пишем sql. Кажется, я сразу задал контекст рассматриваемого вопроса: я не владелец бизнеса и не CTO, я делаю по набору требований. Но знать запросы надо, полтора года эксплуатации прода подтверждают.
Запросы в целом пишем, так что не понятен негатив. И при разработке, и при поддержке. Если человек перенервничал например на ревью или на теоретической секции, а утверждает, что проектировал базы, почему бы не дать шанс и не пообщаться на такие темы? Чаще всего достаточно простых вариаций задач. Это я описал, какие задачи когда и как часто используются.
Не будет там разных баз, так что однозначность и детерминированность есть.
Задача на стримы не про показ новых технологий и чистого кода. Со стримами почти все работали, понижает сложность и стресс. Хорошо или плохо в продуктиве - не тема этой статьи. Цель использования задач со стримами вроде доходчиво мотивирована в тексте.
Вопросы параллелизма стримов на интервью вообще касаются только каждый сотый раз. Не вижу смысла сильно акцентрироваться. Пример кода это не must have. Хорошо, что вы заметили этот нюанс.
Итератор как пример. Я вариаций 6 давал в разное время. Есть и более простые. Надо знать или понимать примитивы. Интервью это не допрос и не дуэль, а диалог. На правильный вопрос будет правильный ответ. И эти вопросы не менее важны, чем решение. Если убрать цель "самоутвердиться" или цель унизить, то задача становится по силам большинству кандидатов.
У вас есть на готове настолько же короткая задача, которая проверяет и знание jdk, и мыслительный процесс? Описанная не выглядит настолько же краткой, не уверен, что сотрудник банка быстро поймет предметную область. В любом случае, тут больше про вкус фламастеров, а не качество фильтра.
Просили больше технических деталей в статье? И они у меня есть. Представляю продолжение рассказа об архитектуре интервью: https://habr.com/ru/articles/996296/
Да, интересно. Во многом не согласен, но вы прям-таки (провоцируете) воодушевляете написать статью. Я бы другие аспекты подсветил, не игнонирую необходимость прилагать усилия по созданию климата, разумеется.
строки кода не считали? У индусов может KPI и прокатит, но там надо бы на полезность и используемость смотреть. (Я не за и не против питона или его репозиториев, просто указываю на аргументацию)
Spring тоже в неумелых руках программирование превращает в конфигурирование. Не всегда быстрее и не всегда прозрачнее получается. Про быстродействие даже упоминать не стоит.
Качество лучше. На питоне генерирует на мой взгляд идеально, я сам так не напишу. На джаве- от погоды и условий зависит, если миддл юзает даже годно. На котлине ересь дает. Кроме идей подсмотреть нечего. Понятно, разный возраст языков, разный объем открытой кодовой базы.
Спасибо за цифры. Я это подозревал, но количественно увидеть очень интересно. Жаль, нет котлина и С++. Тоже с коллегами не первый год спорим о целесообразности того или иного стека и возможности подбора стека под задачу. Пока, к сожалению рулит концепт "начальство умеет пользоваться молотком- собираем шкафы молотком".
Корпоративные порядки. Из моего опыта - так никогда не бывает. В крупных компаниях хорошо если за неделю СБ проверяет, бывает до месяца. У нас они быстро работают - 2 дня, редко когда 3. И анкета не очень большая. В красном банке мне в свое время давали чуть ли не 20 листов со множеством полей.
LLM умнее людей. LLM говорит: "статья хорошая, в интернете такой нет, публикуй!", а люди видят пробелы между словами - "да это ллм, порицаю" - и пропускают смысл. А сами зачастую опубликовать не могут ничего - парадокс!
С нетерпением жду стабилизации и зрелости языковых моделей. То ли ещё будет.
Бизнес зачастую хочет универсального бойца переключать между проектами. Будет ли-вопрос другой. Но требования могут выставляться.
Не знаю. У нас воронка у HR не такая жёсткая, насколько известно. Наличие В. О., прописки в Мск и по мелочам. На некоторые вакансии нижний порог по суммарному опыту.
Да, бизнес не готов учить людей. Количество задач зашкаливает. Нет, нейронки не увеличивают производительность на 100500 процентов. Да, ожидают, что возьмут сильного человека с КПД 100500 процентов. Ну вот такая погода на рынке.
С чего бы? Для расследования ошибок в проде не надо писать запросы? Будут ли они такие же, как на hql? Не стоит же задача "написать запрос для hibernate"?
Я проверял, а знает ли человек эту магию вообще. Про устройство даже не начинаю говорить. Незачем, цель другая.
Еще требование знать N библиотек, M паттернов. От платформы, от корпорации.
Приоритет могут ставить выше.
На мой взгляд, задача с нечеткой постановкой на более высокий уровень. Именно потому что не только НФТ отсутствуют, но и ФТ не все прописаны:
есть ли органы управления?
можно ли прокручивать?
может ли устройство само включать бегущую строку?
одинаков ли буфер для кириллицы и латиницы?
какие ограничения по кодировке?
почему изначально на входе нет фильтра при сохранении в системе длинных строк?
Ну и в целом, лично у меня такая задача вызовет чувство абсурдности:
пишем на джаве, то есть контейнер в контейнере в контейнере
сверху всякая оркестрация и гейтвеи
и вывод на дисплей с 20 символами.
Это как вообще?
Я бы, встретив такую задачу, вспомнил бы бесмыссленность некоторых оптимизаций на литкоде.
Ну и, самое, пожалуй, главное. Это задача больше инженерная. Те разработчики, миддлы с галер и финтехов, чаще возраста 25-30,не инженеры, часто не имеют (не показывают) инженерный склад ума. Кандидаты возраста 40+ может более целевая аудитория для таких проверок. Но их мало приходило. И абстракции с перечислениями были поеятны, затруднений не вызывало.
Да, задача прикольная и интересная, но не для моих задач, которые описываю. Она имеет другую постановку, требует выявления совсем других требований, нежели продуктовая разработка. В продукте стримы, мапперы, ретраи, работа со структурными списками. Так зачем давать задачу про дисплей? Не уместнее задачи на сортировки, маппинг, изоляцию и транзакционность?
Есть набор требований "сверху". Их здесь оценивать не будем. Среди них- умение разбираться в некоторых вопросах. Значит можно или скопипастить задачу с какого-то известного сайта или дать свою. Я не вносил новые секции, я переработал уже существовавшие. Если было требование sql, значит пишем sql. Кажется, я сразу задал контекст рассматриваемого вопроса: я не владелец бизнеса и не CTO, я делаю по набору требований. Но знать запросы надо, полтора года эксплуатации прода подтверждают.
Запросы в целом пишем, так что не понятен негатив. И при разработке, и при поддержке. Если человек перенервничал например на ревью или на теоретической секции, а утверждает, что проектировал базы, почему бы не дать шанс и не пообщаться на такие темы? Чаще всего достаточно простых вариаций задач. Это я описал, какие задачи когда и как часто используются.
Не будет там разных баз, так что однозначность и детерминированность есть.
Задача на стримы не про показ новых технологий и чистого кода. Со стримами почти все работали, понижает сложность и стресс. Хорошо или плохо в продуктиве - не тема этой статьи. Цель использования задач со стримами вроде доходчиво мотивирована в тексте.
Вопросы параллелизма стримов на интервью вообще касаются только каждый сотый раз. Не вижу смысла сильно акцентрироваться. Пример кода это не must have. Хорошо, что вы заметили этот нюанс.
Итератор как пример. Я вариаций 6 давал в разное время. Есть и более простые. Надо знать или понимать примитивы. Интервью это не допрос и не дуэль, а диалог. На правильный вопрос будет правильный ответ. И эти вопросы не менее важны, чем решение. Если убрать цель "самоутвердиться" или цель унизить, то задача становится по силам большинству кандидатов.
У вас есть на готове настолько же короткая задача, которая проверяет и знание jdk, и мыслительный процесс? Описанная не выглядит настолько же краткой, не уверен, что сотрудник банка быстро поймет предметную область. В любом случае, тут больше про вкус фламастеров, а не качество фильтра.
Просили больше технических деталей в статье?
И они у меня есть.
Представляю продолжение рассказа об архитектуре интервью: https://habr.com/ru/articles/996296/
Да, это стимул лучше премий
Да, интересно. Во многом не согласен, но вы прям-таки (провоцируете) воодушевляете написать статью. Я бы другие аспекты подсветил, не игнонирую необходимость прилагать усилия по созданию климата, разумеется.
Это логично, аналитика, статистика всегда запаздывает. Но и разработчики не всегда последней версией пользуются.
Противоположное - это конечно интересно, но сравнительного анализа не видел.
Понятно, что есть цыгане, есть Мавроди, а есть статистика. Но лучше хоть такие цифры посмотреть, чем никакие. Дают повод подумать.
строки кода не считали?
У индусов может KPI и прокатит, но там надо бы на полезность и используемость смотреть.
(Я не за и не против питона или его репозиториев, просто указываю на аргументацию)
Spring тоже в неумелых руках программирование превращает в конфигурирование. Не всегда быстрее и не всегда прозрачнее получается. Про быстродействие даже упоминать не стоит.
Качество лучше. На питоне генерирует на мой взгляд идеально, я сам так не напишу. На джаве- от погоды и условий зависит, если миддл юзает даже годно. На котлине ересь дает. Кроме идей подсмотреть нечего. Понятно, разный возраст языков, разный объем открытой кодовой базы.
Спасибо за цифры. Я это подозревал, но количественно увидеть очень интересно. Жаль, нет котлина и С++. Тоже с коллегами не первый год спорим о целесообразности того или иного стека и возможности подбора стека под задачу. Пока, к сожалению рулит концепт "начальство умеет пользоваться молотком- собираем шкафы молотком".
Корпоративные порядки. Из моего опыта - так никогда не бывает. В крупных компаниях хорошо если за неделю СБ проверяет, бывает до месяца. У нас они быстро работают - 2 дня, редко когда 3. И анкета не очень большая. В красном банке мне в свое время давали чуть ли не 20 листов со множеством полей.
Какие-то регламенты службы безопасности холдинга. Например могут отказать, если человек долгое время работал на западную компанию из Европы.
LLM умнее людей. LLM говорит: "статья хорошая, в интернете такой нет, публикуй!", а люди видят пробелы между словами - "да это ллм, порицаю" - и пропускают смысл. А сами зачастую опубликовать не могут ничего - парадокс!
С нетерпением жду стабилизации и зрелости языковых моделей. То ли ещё будет.
Да, бизнес зачастую не готов обучать. Для дообучения долгое время приходили нулёвые после курсов. Раньше не было таких трендов.
Да можно бизнес послать куда угодно, открыть свой.
Да, что-то в этом есть
Гелеры немного потопли за последние пару лет.
Бизнес зачастую хочет универсального бойца переключать между проектами. Будет ли-вопрос другой. Но требования могут выставляться.
Не знаю. У нас воронка у HR не такая жёсткая, насколько известно. Наличие В. О., прописки в Мск и по мелочам. На некоторые вакансии нижний порог по суммарному опыту.
Да, бизнес не готов учить людей. Количество задач зашкаливает. Нет, нейронки не увеличивают производительность на 100500 процентов. Да, ожидают, что возьмут сильного человека с КПД 100500 процентов. Ну вот такая погода на рынке.
Да, всё так. Об этом статья. И хирурга от повара можно отличить в разговоре, даже если у обоих владение ножом в резюме.
Рекомендации кажутся разумными, но чтоб применяли видел только в конце 00.
На котлине строчку-то написать без IDE реально? Не идёт речь, чтоб за полчаса написать приложение.