Если отсылка к публикации контрактов, то скажу вот что: часть контрактов может быть платформенная или от СБ, она особо не меняется и обязана поддерживаться, там гибкость может вредить.
Публикация моделей не заставляет абсолютно всех абсолютно все модели использовать. Тут пространство для проектирования и выбора.
Лично мне на моём проекте это полезно.
Такую особенность можно включать и выключать, это не краеугольный камень слоистости, а доп. опция.
Да причём тут глуповатые или нет? Все действие и развитие в чётко очерченных рамках. Можно копать, можно не копать. А можно там, где ограничения чуть менее явно заданы, что-то налаживать и улучшать.
Да, большинство задач проксирование и крудостроение по заданным правилам. И часто используются стримы (без референса на тотхорошо или плохо). Но есть 10% нестандартных задач и, по ходу выкатки продуктов на прод, будет всё больше и больше задач ребусов поддержки. И вот там критически важно быстро и надёжно выявлять и править ошибки. Там и всякие SLA, и репутация, и прочее. В таких задачах почти никогда не прокатит отговорка "это всё сделает ORM". Как показывает опыт, почти все при выявлении ошибок в данных используют 100500 однострочных скриптов, копируя туда-сюда UUID'ы. Это, мягко говоря, неэффективно-- использовать непонятные селекты, магически комбинируя, вместо написания 1 запроса.
И реализация по интерфейсы - вовсе не олимпиадная задача. Похожее периодически встречается при разработке пользовательских историй, и на более сложных интерфейсах. Тем более, задача на live coding, как я писал пару раз, направлена не сколько на знание синтаксиса, а на другое.
Кажется, я двумя статьями так и не смог до всех донести мысль о том, что главное в интервью - слышать и говорить. Лично мне разговоры почти всегда дают понять заранее, какие результаты кодинга будут.
Если директор сказал искать стучальщиков красными молотками- мне надо выполнять или надо приводить абстрактные аргументы и вставать в позу "я самый умный"?
У конкретного бизнеса есть конкретные потребности и запросы, лучше удовлетворять их без оглядки что у кого-то абстрактного было в 2004. Я решаю задачи конкретного проекта, а не занимаюсь философией. Есть конкретный стек, конкретные библиотеки, конкретный продукт, и это никак не сыязано с Сибирью, хрущевской оттепелью, холодной войной или Жанной д'Арк. Таких параметров в этой задаче просто нет. И я не рассказываю, как в 1982 году искать программистов на Ruby.
Ибо сложные запросы - это обычно признак того, что в проекте по недосмотру архитектора смешаны OLTP и аналитика
С чего бы? Для расследования ошибок в проде не надо писать запросы? Будут ли они такие же, как на hql? Не стоит же задача "написать запрос для hibernate"?
Максимум чего бы я в этом смысле смотрел - это понимает ли человек как работают стримы - и может ли он переписать код со стримами на код без них ? Потому что есть деятели, которые запоминают методы стримов как магические слова...
Я проверял, а знает ли человек эту магию вообще. Про устройство даже не начинаю говорить. Незачем, цель другая.
Вообще - главный вопрос который надо решить на собеседовании - это умеет ли человек ясно и однозначно мыслить о свойствах сложных систем ?
Еще требование знать N библиотек, M паттернов. От платформы, от корпорации.
На мой взгляд, задача с нечеткой постановкой на более высокий уровень. Именно потому что не только НФТ отсутствуют, но и ФТ не все прописаны:
есть ли органы управления?
можно ли прокручивать?
может ли устройство само включать бегущую строку?
одинаков ли буфер для кириллицы и латиницы?
какие ограничения по кодировке?
почему изначально на входе нет фильтра при сохранении в системе длинных строк?
Ну и в целом, лично у меня такая задача вызовет чувство абсурдности:
пишем на джаве, то есть контейнер в контейнере в контейнере
сверху всякая оркестрация и гейтвеи
и вывод на дисплей с 20 символами.
Это как вообще?
Я бы, встретив такую задачу, вспомнил бы бесмыссленность некоторых оптимизаций на литкоде.
Ну и, самое, пожалуй, главное. Это задача больше инженерная. Те разработчики, миддлы с галер и финтехов, чаще возраста 25-30,не инженеры, часто не имеют (не показывают) инженерный склад ума. Кандидаты возраста 40+ может более целевая аудитория для таких проверок. Но их мало приходило. И абстракции с перечислениями были поеятны, затруднений не вызывало.
Да, задача прикольная и интересная, но не для моих задач, которые описываю. Она имеет другую постановку, требует выявления совсем других требований, нежели продуктовая разработка. В продукте стримы, мапперы, ретраи, работа со структурными списками. Так зачем давать задачу про дисплей? Не уместнее задачи на сортировки, маппинг, изоляцию и транзакционность?
Есть набор требований "сверху". Их здесь оценивать не будем. Среди них- умение разбираться в некоторых вопросах. Значит можно или скопипастить задачу с какого-то известного сайта или дать свою. Я не вносил новые секции, я переработал уже существовавшие. Если было требование sql, значит пишем sql. Кажется, я сразу задал контекст рассматриваемого вопроса: я не владелец бизнеса и не CTO, я делаю по набору требований. Но знать запросы надо, полтора года эксплуатации прода подтверждают.
Запросы в целом пишем, так что не понятен негатив. И при разработке, и при поддержке. Если человек перенервничал например на ревью или на теоретической секции, а утверждает, что проектировал базы, почему бы не дать шанс и не пообщаться на такие темы? Чаще всего достаточно простых вариаций задач. Это я описал, какие задачи когда и как часто используются.
Не будет там разных баз, так что однозначность и детерминированность есть.
Задача на стримы не про показ новых технологий и чистого кода. Со стримами почти все работали, понижает сложность и стресс. Хорошо или плохо в продуктиве - не тема этой статьи. Цель использования задач со стримами вроде доходчиво мотивирована в тексте.
Вопросы параллелизма стримов на интервью вообще касаются только каждый сотый раз. Не вижу смысла сильно акцентрироваться. Пример кода это не must have. Хорошо, что вы заметили этот нюанс.
Итератор как пример. Я вариаций 6 давал в разное время. Есть и более простые. Надо знать или понимать примитивы. Интервью это не допрос и не дуэль, а диалог. На правильный вопрос будет правильный ответ. И эти вопросы не менее важны, чем решение. Если убрать цель "самоутвердиться" или цель унизить, то задача становится по силам большинству кандидатов.
У вас есть на готове настолько же короткая задача, которая проверяет и знание jdk, и мыслительный процесс? Описанная не выглядит настолько же краткой, не уверен, что сотрудник банка быстро поймет предметную область. В любом случае, тут больше про вкус фламастеров, а не качество фильтра.
Просили больше технических деталей в статье? И они у меня есть. Представляю продолжение рассказа об архитектуре интервью: https://habr.com/ru/articles/996296/
Да, интересно. Во многом не согласен, но вы прям-таки (провоцируете) воодушевляете написать статью. Я бы другие аспекты подсветил, не игнонирую необходимость прилагать усилия по созданию климата, разумеется.
Нет, надеюсь, до SOAPа не дойдёт, хотелось бы баланса.
Соблюдать договоренности QA заставят, частично они - тот барьер между разработкой и хаосом. Если нормальный коллектив и нормальные процессы.
А вообще "заставить соблюдать договоренности" - тема больная. Можно решать по-разному.
Да, можно пойти издалека и налить воды. Да, можно игнорировать NDA и описать предметную область. Это было бы втрое больше.
Да, можно было бы написать ADR и C4, но это была бы другая статья.
Да, можно было написать верхнеуровневые требования и спроектировать платформу. Но это тоже была бы другая статья.
У меня не было таких целей.
Предложенные решения можно применять к разным предметным областям в энтерпрайзе.
Я не описываю архитектуру всей системы, уровень абстракции гораздо ниже. Я не описываю продукт, и не хотел.
Зачем я буду писать, что выбирал джаву и мавен (не знаю, какую вы статью про мавен читали, не уверен, что эту), если я не выбирал это?
Если отсылка к публикации контрактов, то скажу вот что: часть контрактов может быть платформенная или от СБ, она особо не меняется и обязана поддерживаться, там гибкость может вредить.
Публикация моделей не заставляет абсолютно всех абсолютно все модели использовать. Тут пространство для проектирования и выбора.
Лично мне на моём проекте это полезно.
Такую особенность можно включать и выключать, это не краеугольный камень слоистости, а доп. опция.
SOAP, всё ж, строже намного.
Не напоминайте. Я же это видел.
Ну и SOAP придумали в другое время, когда еще яндекс не обучал всех подряд, а систем было на порядки меньше.
wsdl
Шаг влево или вправо - расстрел и тотальное падение. С большим количеством сервисов это пытка.
Думаю, это такая ирония.
Написал вторую часть статьи про интервью, как раз с технической конкретикой и большими листингами кода: https://habr.com/ru/articles/996296/
Написал вторую часть статьи про интервью, как раз с технической конкретикой и большими листингами кода: https://habr.com/ru/articles/996296/
Да причём тут глуповатые или нет? Все действие и развитие в чётко очерченных рамках. Можно копать, можно не копать. А можно там, где ограничения чуть менее явно заданы, что-то налаживать и улучшать.
Да, большинство задач проксирование и крудостроение по заданным правилам. И часто используются стримы (без референса на тотхорошо или плохо). Но есть 10% нестандартных задач и, по ходу выкатки продуктов на прод, будет всё больше и больше задач
ребусовподдержки. И вот там критически важно быстро и надёжно выявлять и править ошибки. Там и всякие SLA, и репутация, и прочее. В таких задачах почти никогда не прокатит отговорка "это всё сделает ORM". Как показывает опыт, почти все при выявлении ошибок в данных используют 100500 однострочных скриптов, копируя туда-сюда UUID'ы. Это, мягко говоря, неэффективно-- использовать непонятные селекты, магически комбинируя, вместо написания 1 запроса.И реализация по интерфейсы - вовсе не олимпиадная задача. Похожее периодически встречается при разработке пользовательских историй, и на более сложных интерфейсах. Тем более, задача на live coding, как я писал пару раз, направлена не сколько на знание синтаксиса, а на другое.
Кажется, я двумя статьями так и не смог до всех донести мысль о том, что главное в интервью - слышать и говорить. Лично мне разговоры почти всегда дают понять заранее, какие результаты кодинга будут.
Если директор сказал искать стучальщиков красными молотками- мне надо выполнять или надо приводить абстрактные аргументы и вставать в позу "я самый умный"?
У конкретного бизнеса есть конкретные потребности и запросы, лучше удовлетворять их без оглядки что у кого-то абстрактного было в 2004. Я решаю задачи конкретного проекта, а не занимаюсь философией. Есть конкретный стек, конкретные библиотеки, конкретный продукт, и это никак не сыязано с Сибирью, хрущевской оттепелью, холодной войной или Жанной д'Арк. Таких параметров в этой задаче просто нет. И я не рассказываю, как в 1982 году искать программистов на Ruby.
Эти требования спускаются выше. Глупость или не глупость я буду решать будучи CTO, но сейчас у меня другая должность.
Я не указываю вам как надо было искать, я не знаю нюансов вашего проекта. А вы не знаете всех требований моего проекта и холдинга.
Я не упустил, я набрал. Писал ранее. Вывод-догадка не верен.
Для стека джава не подходит. Буду собеседовать дельфиста - вспомню.
С чего бы? Для расследования ошибок в проде не надо писать запросы? Будут ли они такие же, как на hql? Не стоит же задача "написать запрос для hibernate"?
Я проверял, а знает ли человек эту магию вообще. Про устройство даже не начинаю говорить. Незачем, цель другая.
Еще требование знать N библиотек, M паттернов. От платформы, от корпорации.
Приоритет могут ставить выше.
На мой взгляд, задача с нечеткой постановкой на более высокий уровень. Именно потому что не только НФТ отсутствуют, но и ФТ не все прописаны:
есть ли органы управления?
можно ли прокручивать?
может ли устройство само включать бегущую строку?
одинаков ли буфер для кириллицы и латиницы?
какие ограничения по кодировке?
почему изначально на входе нет фильтра при сохранении в системе длинных строк?
Ну и в целом, лично у меня такая задача вызовет чувство абсурдности:
пишем на джаве, то есть контейнер в контейнере в контейнере
сверху всякая оркестрация и гейтвеи
и вывод на дисплей с 20 символами.
Это как вообще?
Я бы, встретив такую задачу, вспомнил бы бесмыссленность некоторых оптимизаций на литкоде.
Ну и, самое, пожалуй, главное. Это задача больше инженерная. Те разработчики, миддлы с галер и финтехов, чаще возраста 25-30,не инженеры, часто не имеют (не показывают) инженерный склад ума. Кандидаты возраста 40+ может более целевая аудитория для таких проверок. Но их мало приходило. И абстракции с перечислениями были поеятны, затруднений не вызывало.
Да, задача прикольная и интересная, но не для моих задач, которые описываю. Она имеет другую постановку, требует выявления совсем других требований, нежели продуктовая разработка. В продукте стримы, мапперы, ретраи, работа со структурными списками. Так зачем давать задачу про дисплей? Не уместнее задачи на сортировки, маппинг, изоляцию и транзакционность?
Есть набор требований "сверху". Их здесь оценивать не будем. Среди них- умение разбираться в некоторых вопросах. Значит можно или скопипастить задачу с какого-то известного сайта или дать свою. Я не вносил новые секции, я переработал уже существовавшие. Если было требование sql, значит пишем sql. Кажется, я сразу задал контекст рассматриваемого вопроса: я не владелец бизнеса и не CTO, я делаю по набору требований. Но знать запросы надо, полтора года эксплуатации прода подтверждают.
Запросы в целом пишем, так что не понятен негатив. И при разработке, и при поддержке. Если человек перенервничал например на ревью или на теоретической секции, а утверждает, что проектировал базы, почему бы не дать шанс и не пообщаться на такие темы? Чаще всего достаточно простых вариаций задач. Это я описал, какие задачи когда и как часто используются.
Не будет там разных баз, так что однозначность и детерминированность есть.
Задача на стримы не про показ новых технологий и чистого кода. Со стримами почти все работали, понижает сложность и стресс. Хорошо или плохо в продуктиве - не тема этой статьи. Цель использования задач со стримами вроде доходчиво мотивирована в тексте.
Вопросы параллелизма стримов на интервью вообще касаются только каждый сотый раз. Не вижу смысла сильно акцентрироваться. Пример кода это не must have. Хорошо, что вы заметили этот нюанс.
Итератор как пример. Я вариаций 6 давал в разное время. Есть и более простые. Надо знать или понимать примитивы. Интервью это не допрос и не дуэль, а диалог. На правильный вопрос будет правильный ответ. И эти вопросы не менее важны, чем решение. Если убрать цель "самоутвердиться" или цель унизить, то задача становится по силам большинству кандидатов.
У вас есть на готове настолько же короткая задача, которая проверяет и знание jdk, и мыслительный процесс? Описанная не выглядит настолько же краткой, не уверен, что сотрудник банка быстро поймет предметную область. В любом случае, тут больше про вкус фламастеров, а не качество фильтра.
Просили больше технических деталей в статье?
И они у меня есть.
Представляю продолжение рассказа об архитектуре интервью: https://habr.com/ru/articles/996296/
Да, это стимул лучше премий
Да, интересно. Во многом не согласен, но вы прям-таки (провоцируете) воодушевляете написать статью. Я бы другие аспекты подсветил, не игнонирую необходимость прилагать усилия по созданию климата, разумеется.