Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Объясните, зачем вам задача на SQL live coding, и на стримы ?!
Лично я с позиции своего опыта - убил бы за запросы со сложной иерархией. Во-первых, если вы их каждый день не пишете - то фига с два вы помните все особенности синтаксиса. Особенно - приятные различия между Oracle и Postgres. Во-вторых, вы офигеете это отлаживать, в особенности когда план запроса не захочет строиться перебором, а потребует чего то типа Genetic Query Plan Optimization. То есть - у вас будет выходить РАЗНЫЙ план запроса на разных базах и в разное время. Будет еще смешнее если вы туда воткнете параметризацию - потому что в сочетании с ORM - оно вам закеширует query plan построенный без знания реальных значений параметров - а потом будет его исполнять, даже если с конкретным значением в подстановках - он будет сильно неоптимальный... И с этим вы будете отдельно бороться!
А стримы - ИМХО вообще дико перегретая тема. Да - много на чем можно людей подловить, ибо разных методов там дофига и больше (а еще запомнить где какой параметр в темплейтах - м-м, песня). На практике, когда мне кто-то приносит MR в котором очень умно скомбинированы все возможности стримов - я спрашиваю, есть ли шанс что мы вот в этом получим реальный выигрыш за счет ленивых операций и (возможно) параллелизма? И если нет (а зачастую там коллекция из пары десятков, если не единиц элементов) - начинаю цитировать новгородскую берестяную грамоту: "Брате, (нецензурное слово из трех букв на "е") лежа!". Если у вас в стриме сложная обработка - пишите кастомный фильтр, или вообще выразьте свои намерения в императивном, а не декларативном формате через for с итерацией по коллекции...
А вот за секцию с код-ревью - однозначный плюс в карму. Ибо 70% времени мы читаем код - а проверяем на собесах совершенно другое!
За секцию с итератором - не знаю. Если вы регулярно такое пишете по необходимости у себя в проекте - тогда наверное плюс. Если же вы это придумали как головоломку которую надо решить в условиях стресса (или знать решение заранее) - тогда минус. Потому что вы опять проверяете не то, что надо - а то, что легче проверить. Вменяемый человек не держит в памяти особенности реализации JDK, и в первую очередь должен задать вопрос - обязательно ли вашу задачу надо решать через вот такие извращения с итераторами, и неявным сохранением (копированием) коллекций под капотом ? Ибо интуитивно это похоже на то, что человека подводят к столу, и просят съесть апельсин, но по ходу дела выясняется, что руками трогать его нельзя, наклоняться к столу тоже нельзя - а ожидается что кандидат достаточно находчив и гибок чтобы это сделать отвернувшись от стола, и обязательно через жопу...
Чтобы не выглядеть огульным критиканом - скажу свою задачу на собеседование для лайв-кодинга. Есть устройство с дисплеем на 20 знако-мест. Интерфейс простейший: device.display(String). Время от времени нам приходят сообщения от системы явно больше чем 20 символов длины. Нужно придумать и реализовать показ их пользователю. Принимается любое разумное решение, которое кандидат сможет реализовать, время пошло. И дальше там тоже есть о чем поговорить...
Есть набор требований "сверху". Их здесь оценивать не будем. Среди них- умение разбираться в некоторых вопросах. Значит можно или скопипастить задачу с какого-то известного сайта или дать свою. Я не вносил новые секции, я переработал уже существовавшие. Если было требование sql, значит пишем sql. Кажется, я сразу задал контекст рассматриваемого вопроса: я не владелец бизнеса и не CTO, я делаю по набору требований. Но знать запросы надо, полтора года эксплуатации прода подтверждают.
Запросы в целом пишем, так что не понятен негатив. И при разработке, и при поддержке. Если человек перенервничал например на ревью или на теоретической секции, а утверждает, что проектировал базы, почему бы не дать шанс и не пообщаться на такие темы? Чаще всего достаточно простых вариаций задач. Это я описал, какие задачи когда и как часто используются.
Не будет там разных баз, так что однозначность и детерминированность есть.
Задача на стримы не про показ новых технологий и чистого кода. Со стримами почти все работали, понижает сложность и стресс. Хорошо или плохо в продуктиве - не тема этой статьи. Цель использования задач со стримами вроде доходчиво мотивирована в тексте.
Вопросы параллелизма стримов на интервью вообще касаются только каждый сотый раз. Не вижу смысла сильно акцентрироваться. Пример кода это не must have. Хорошо, что вы заметили этот нюанс.
Итератор как пример. Я вариаций 6 давал в разное время. Есть и более простые. Надо знать или понимать примитивы. Интервью это не допрос и не дуэль, а диалог. На правильный вопрос будет правильный ответ. И эти вопросы не менее важны, чем решение. Если убрать цель "самоутвердиться" или цель унизить, то задача становится по силам большинству кандидатов.
У вас есть на готове настолько же короткая задача, которая проверяет и знание jdk, и мыслительный процесс? Описанная не выглядит настолько же краткой, не уверен, что сотрудник банка быстро поймет предметную область. В любом случае, тут больше про вкус фламастеров, а не качество фильтра.
Если вам требования спускают сверху, а вы их только исполняете в ходе интервью - к вам претензий нет, скорее они к тем, кто вам их спустил...
Про запросы - я с базами данных работаю года этак с 96'го. Помню и Query-by-example в Paradox, и синтаксис 4GL в Progress v9, и разумеется Oracle/Postgres в их развитии. Но видит бог, я вам сходу на бумажке не напишу сложный запрос с window functions, having, и прочими интересными вещами. И если вы на моих глазах начнете такое писать, то попробую вас отговорить от самоубийства. Ибо сложные запросы - это обычно признак того, что в проекте по недосмотру архитектора смешаны OLTP и аналитика! И вы пытаетесь достать аналитические значения из OLTP базы. Понятно, что если прижало - то еще не так раскорячишься - но я буду корячиться в обнимку с документацией, итеративно отлаживая запрос - и поминутно гляля в explain analyze чтобы понять - не положу ли я продашкн устраивая fullscan или hash-join на таблицах реальных размеров...
По задачам на стримы, как и по задачам на странные итераторы - претензия в том, что опять непонятно, что именно вы проверяете. Я помню как стримы и итераторы появились в толстой книге Страуструпа - и дальше разошлись по разным языкам программирования. Это совершенно не значит, что я на месте вам вспомню детали их реализации. Максимум чего бы я в этом смысле смотрел - это понимает ли человек как работают стримы - и может ли он переписать код со стримами на код без них ? Потому что есть деятели, которые запоминают методы стримов как магические слова...
В мире финансов - моя любимая задача - это дать на ревью код, где проценты и остатки хранятся в double. В зависимости от того, насколько быстро и насколько матерно кандидат начнет ругаться - можно сделать вывод о его практическом опыте в отрасли. :-) Дальше - если мы говорим о серьезном уровне, я бы продолжил говорить в сторону того, как этот код изменять и поддерживать если к нам будут приходить умные маркетологи и периодически менять правила игры - кому, что и за что начисляем...
Вообще - главный вопрос который надо решить на собеседовании - это умеет ли человек ясно и однозначно мыслить о свойствах сложных систем ? Ибо есть люди у которых принципиально каша в голове - и какой бы вы не дали им язык программирования и фреймворк - результат будет неудовлетворительный. Второй вопрос - это опыт кандидата с языком и нашей предметной областью - что влияет на время адаптации и самостоятельность. Поэтому я против задач с leetcode, и за то чтобы давать задачи приближенные к предметной области (но упрощенные для того чтобы влезть в стандартные 30 минут на решение). И однозначно против "китайского экзамена по каллиграфии", когда мы обсуждаем все более специальные вопросы (типа устройства JDK или конкретных правил happens-before) в надежде что кандидат в какой-то момент дойдет до предела своих знаний...
Ибо сложные запросы - это обычно признак того, что в проекте по недосмотру архитектора смешаны OLTP и аналитика
С чего бы? Для расследования ошибок в проде не надо писать запросы? Будут ли они такие же, как на hql? Не стоит же задача "написать запрос для hibernate"?
Максимум чего бы я в этом смысле смотрел - это понимает ли человек как работают стримы - и может ли он переписать код со стримами на код без них ? Потому что есть деятели, которые запоминают методы стримов как магические слова...
Я проверял, а знает ли человек эту магию вообще. Про устройство даже не начинаю говорить. Незачем, цель другая.
Вообще - главный вопрос который надо решить на собеседовании - это умеет ли человек ясно и однозначно мыслить о свойствах сложных систем ?
Еще требование знать N библиотек, M паттернов. От платформы, от корпорации.
Приоритет могут ставить выше.
Какая, блин, глупость! Я имею в виду - ставить вперед "N библиотек и M паттернов"! Следуя вашей логике - мне году в 2004 надо было в сибирской глубинке искать специалистов по 4GL... Как-то я сомневаюсь, что они там вообще были в это время. Тем более - безработные. Если у человек мозг работает в правильную сторону, то он прекрасно переходил от решения задач на Delphi к 4GL, а еще к "C", и далее к Java.
С тем же успехом можно слесаря так нанимать: "Скажите, а вы красным (!) молотком умеете по полуоси стучать? Нет я понимаю, что у вас опыт работы - но вот у нас молотки только красные - и мы предпочитаем кандидатов которые именно с этим инструментом работали...".
Эти требования спускаются выше. Глупость или не глупость я буду решать будучи CTO, но сейчас у меня другая должность.
Я не указываю вам как надо было искать, я не знаю нюансов вашего проекта. А вы не знаете всех требований моего проекта и холдинга.
Если директор сказал искать стучальщиков красными молотками- мне надо выполнять или надо приводить абстрактные аргументы и вставать в позу "я самый умный"?
У конкретного бизнеса есть конкретные потребности и запросы, лучше удовлетворять их без оглядки что у кого-то абстрактного было в 2004. Я решаю задачи конкретного проекта, а не занимаюсь философией. Есть конкретный стек, конкретные библиотеки, конкретный продукт, и это никак не сыязано с Сибирью, хрущевской оттепелью, холодной войной или Жанной д'Арк. Таких параметров в этой задаче просто нет. И я не рассказываю, как в 1982 году искать программистов на Ruby.
Вопросов к вам, как я написал выше - у меня нет. К тому, кто вам выдает такие требования - есть... Но вот опять же из жизненного опыта - есть две стратегии: можно в рамках организационного люфта (я надеюсь что ваш начальник - не микроменеджер) исправлять глупости начальства, а можно лихо и задорно их усугублять. Вот ваша статья - это мануал на тему: как глуповатые требования руководства превратить в абсурдные вопросы на интервью.
Но правда и в том, что я работаю не с вами, и не в вашем холдинге. Поэтому, продолжайте в том же духе - если вы не правы, жизнь вам это рано или поздно объяснит...
Да причём тут глуповатые или нет? Все действие и развитие в чётко очерченных рамках. Можно копать, можно не копать. А можно там, где ограничения чуть менее явно заданы, что-то налаживать и улучшать.
Да, большинство задач проксирование и крудостроение по заданным правилам. И часто используются стримы (без референса на тотхорошо или плохо). Но есть 10% нестандартных задач и, по ходу выкатки продуктов на прод, будет всё больше и больше задач ребусов поддержки. И вот там критически важно быстро и надёжно выявлять и править ошибки. Там и всякие SLA, и репутация, и прочее. В таких задачах почти никогда не прокатит отговорка "это всё сделает ORM". Как показывает опыт, почти все при выявлении ошибок в данных используют 100500 однострочных скриптов, копируя туда-сюда UUID'ы. Это, мягко говоря, неэффективно-- использовать непонятные селекты, магически комбинируя, вместо написания 1 запроса.
И реализация по интерфейсы - вовсе не олимпиадная задача. Похожее периодически встречается при разработке пользовательских историй, и на более сложных интерфейсах. Тем более, задача на live coding, как я писал пару раз, направлена не сколько на знание синтаксиса, а на другое.
Кажется, я двумя статьями так и не смог до всех донести мысль о том, что главное в интервью - слышать и говорить. Лично мне разговоры почти всегда дают понять заранее, какие результаты кодинга будут.
На мой взгляд, задача с нечеткой постановкой на более высокий уровень. Именно потому что не только НФТ отсутствуют, но и ФТ не все прописаны:
есть ли органы управления?
можно ли прокручивать?
может ли устройство само включать бегущую строку?
одинаков ли буфер для кириллицы и латиницы?
какие ограничения по кодировке?
почему изначально на входе нет фильтра при сохранении в системе длинных строк?
Ну и в целом, лично у меня такая задача вызовет чувство абсурдности:
пишем на джаве, то есть контейнер в контейнере в контейнере
сверху всякая оркестрация и гейтвеи
и вывод на дисплей с 20 символами.
Это как вообще?
Я бы, встретив такую задачу, вспомнил бы бесмыссленность некоторых оптимизаций на литкоде.
Ну и, самое, пожалуй, главное. Это задача больше инженерная. Те разработчики, миддлы с галер и финтехов, чаще возраста 25-30,не инженеры, часто не имеют (не показывают) инженерный склад ума. Кандидаты возраста 40+ может более целевая аудитория для таких проверок. Но их мало приходило. И абстракции с перечислениями были поеятны, затруднений не вызывало.
Да, задача прикольная и интересная, но не для моих задач, которые описываю. Она имеет другую постановку, требует выявления совсем других требований, нежели продуктовая разработка. В продукте стримы, мапперы, ретраи, работа со структурными списками. Так зачем давать задачу про дисплей? Не уместнее задачи на сортировки, маппинг, изоляцию и транзакционность?
Ну блин - эта задача про дисплей абсолютно реальная. Производственное оборудование - оно вот такое бывает... Со странностями. :-) И да, я приветствую заданные вопросы. И если вы предложите архитектурное решение - типа пробросить device capabilities внутрь сессии, и там сделать умный i18n который будет из базы выбирать сообщение не только по языку, но и по capabilities устройства - в моей голове вы получите жирный плюс. Но я предложу пока оставить это для следующего мажорного релиза и придумать как заткнуть проблему "прямщас". И я приму любое решение, если вы сможете сделать чтобы оно работало: хотите - бегущую строку, хотите - пейджинг, хотите - слова сокращайте, хотите что-то еще придумайте. Мне важно понять, что вы вообще умеете программировать - я видел лично людей, которые блин не могли реализовать бегущую строку в цикле... А работы (если вы хоть как-то программировали) - там на 10 минут!
Опять же - я не защищаю конкретную задачу. В зависимости от отрасли - я бы давал то, с чем мы работаем, и что позволяет строить разговор дальше. Про транзакционность - моя любимая задача была - это единый вход в transactional-annotated, и там некая бизнес-операция и логгирование успеха или неудачи операции с выкидыванием экспшена. Ну и понятно, что если транзакция помечается как rollback-only, то и в лог-таблицу ничего не пишется. И дальше смотрим как человек предлагает с этим разбираться...
некоторые не признаются, пытаясь на ходу то ли вспомнить, то ли придумать синтаксис
То есть ведут себя как классическая LLM)
Я использовал этот вопрос
Рядовой SNAFU идет в DBA / Хабр https://share.google/qPPbyN4drwqVrqxkJ
Автор проделал, без сомнения, большую работу, систематизируя свой подход. Однако, при ближайшем рассмотрении, он создал не систему отбора лучших инженеров, а элитный клуб для любителей олимпиадных задач и викторин на знание, который в современных реалиях абсолютно неэффективен.
Лайв-кодинг в блокноте - главный провал методики Это самая абсурдная и оторванная от жизни часть. Требовать писать код в онлайн-редакторе без привычной IDE - это как просить хирурга провести операцию перочинным ножом, а потом удивляться, что он не помнит точное латинское название каждого инструмента.
Проверка памяти, а не интеллекта. Современная разработка - это не про запоминание всех методов Collectors или сигнатур функций. Это про умение решать бизнес-задачи с помощью инструментов. IDE - наш главный инструмент. Отказывая в нём, интервьюер проверяет не способность мыслить, а банальную зубрежку.
Искусственный стресс. Никто не пишет код в таких условиях. Это искусственно созданная стрессовая ситуация, которая отсеивает не плохих разработчиков, а тех, кто хуже справляется с бессмысленным давлением.
Игнорирование реальности. Автор сам пишет про Spring Boot, Hibernate, Kotlin. Все эти технологии подразумевают активное использование IDE для навигации, автодополнения и рефакторинга. Заставлять писать на них код вслепую - это полный нонсенс и демонстрация непонимания рабочего процесса.
Гонка вооружений с нейросетями, которую невозможно выиграть Автор создает настолько сложные и "хитрые" задачи, что сам же толкает кандидатов на жульничество.
Стимуляция обмана. Чем сложнее и академичнее задача, тем выше соблазн быстро "спросить" у ChatGPT. В итоге соревнование идет не в знаниях, а в скорости и незаметности использования нейросетей.
Неверный результат. Вместо того чтобы нанять человека, который умеет рассуждать, компания нанимает лучшего "оператора" нейросети. Автор жалуется на некомпетентность, но его же система и способствует ее сокрытию.
"Хитрые" SQL-задачи и Code Review как поиск "пасхалок" Подход к базам данных и ревью кода страдает той же болезнью - фокусом на эзотерических знаниях, а не на практической ценности.
SQL-акробатика. Автор сам признает, что большинство использует ORM, но упорно продолжает гонять кандидатов по "оконным функциям" и "хитрым группировкам". Да, это полезно знать, но для 95% задач бэкенд-разработчика это не является ключевым навыком. Гораздо важнее уметь спроектировать нормальную модель данных, а не написать монструозный запрос, который потом никто не сможет поддерживать.
Ревью ради ревью. Задача ревью - улучшить код и помочь коллеге, а не сыграть в "найди 10 отличий" с кодом, который нарочно написан как можно хуже. Этот "фрагмент реальной enterprise-системы" выглядит как свалка всех возможных анти-паттернов. Хороший инженер может не найти все 34 "ошибки", потому что в реальной жизни он бы написал этот код совершенно иначе с самого начала.
Итог: Кого на самом деле ищет автор?
Эта система отбирает людей, которые:
Обладают феноменальной памятью.
Отлично справляются с бессмысленным стрессом.
Имеют опыт решения олимпиадных задач.
Либо очень хорошо умеют жульничать.
Но являются ли они лучшими командными игроками, архитекторами и инженерами, способными создавать и поддерживать сложные системы? Очень сомнительно.
В погоне за "идеальным" кандидатом, который знает наизусть все тонкости SQL и JDK, автор рискует упустить десятки отличных, прагматичных инженеров, которые просто хотят делать свою работу с помощью современных инструментов, а не сдавать экзамены из прошлого века.
Я не упустил, я набрал. Писал ранее. Вывод-догадка не верен.
Вы упустили, скорее всего, хороших инженеров, а набрали, в итоге, хороших операторов нейросетей.
У меня был опыт работы с одной компанией, которая так же делает бессмысленные технические интервью.
Проблема была в том, что они так же на серьезных щах "умничают" на собеседованиях, рассказывают какие они крутые профи, но продукт, который они делают, работает отвратительно.
Возникает вопрос, а как такие профессионалы делают на столько отвратительный продукт? А очень просто: они отсеяли всех хороших инженеров. Потому как операторы нейросетей даже не смотрят на код, который им сгенерировала нейронка. Они его тупо не понимают. И не читают. Им банально лень читать, скопировал, вставил, о, работает. То что работает плохо он не понимает. Что бы прочитать код и разобраться в нем нужно, как минимум, время. Но на собеседованиях этого времени не дают. И тут приходит кандидат, который за секунды разбирает код. И находит все 34 ошибки. Гений, не иначе. (Сарказм).
Сколько я видел различных продуктов, столько я видел максимально тупых глюков этих продуктов умноженных на 10.
У меня вообще закралась мысль, что подобные интервью созданы специально, что бы бездари, которые пришли после 2 недельных курсов во время ковида не теряли места, а инженеры не могли найти нормальную работу.
Тот же Яндекс взять, у них тех собеседование проходит в режиме "быстрее - бегом", время на подумать? Нет, вы что, подумать ответ на вопрос нужно было ещё за час до самого вопроса. И сами интервьюеры там - школьники что ли.... Которые, например, на позицию сениора спрашивают "а что такое дата класс в котлин". Это идиотизм.
Вы упустили, скорее всего, хороших инженеров, а набрали, в итоге, хороших операторов нейросетей.
Вы оцениваете людей, не видя их, без общения?
Я работаю с этими людьми почти год. Готовлю статью о команде.
У меня вообще закралась мысль, что подобные интервью созданы специально, что бы бездари, которые пришли после 2 недельных курсов во время ковида не теряли места
Я не спорю, что вкатуны - проблема. Как попытались вкатиться - так и выкатывались, некоторые убегали с интервью до задач. Одна из моих задач было проверить понимание. Другая - выявить широту и глубину кругозора, об этом предыдущая статья.
а инженеры не могли найти нормальную работу.
Слишком наивное утверждение. Бизнес не будет тратить деньги, чтоб утвердить самомнение ноунеймов. Другое дело, что в отдельных продуктах задачи - это штамповки, и менее инженеры, более удобные и спокойные нужны.
И, да, во многих компаниях не умеют проводить интервью.
Да, разговоры с яндексом стабильно приводят к "рукалицо".
Они богатые, свои причуды. И люди же тянутся.
Как Вы считаете, прошли бы Вы подобное интерьвю, только с другими переменными предпочтений у похожего на Вас собеседующего?
Представили себе? )
Как руководитель я бы вот прямо сейчас начал делить команду на 2 части: с Вами и без
А тут нечего считать, и сослагательное наклонение не нужно.
Проходил.
И задачи с таких интервью меня вдохновили. Тиньков, РТК, кажется Леруа или Ашан (французское что-то) и пару неизвестных контор. А остальные 500 своих собеседований я не запомнил.
Не люблю вангование и игру в экстрасенсов.
Как руководитель... не факт, что нашли б общий язык или сработались.
Проекты разные - цели разные. Команды отличаются - ценности отличаются.
Сколько руководителей - столько же вариантов аджайла.
У нас на проекте изначально ставились высокие планки для кандидатов, во всех направлениях, на многих должностях/ролях. Некоторые лиды искали только сеньоров или даже выше. Некоторые проводили трёхчасовые тех. интервью. Зачем и почему - вопросы точно не ко мне.
И еще раз уточняю: каждая задача - это повод поговорить. Цель - не унизить человека, а найти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гибкость технического интервью