Собеседую программистов на Java. Единый набор вопросов для любого уровня

    В своей карьере мне приходилось быть и разработчиком, и менеджером, и даже один раз «CTO» в небольшом стартапе. И, разумеется, приходилось проводить большое количество собеседований кадидатов. Поэтому для себя я выработал такие правила проведения технических собеседований:

    • всем кандидатам задавать одинаковые вопросы,
    • вопросы должны быть такие, чтобы на них ответил и junior, и senior, но по разному,
    • после трёх вопросов должен быть понятен уровень кандидата.

    И вот такие три вопроса для Java-разработчиков у меня получились.

    Расскажите про HashMap


    Да-да, тот самый стандартный вопрос, с которого начинается 50% собеседований. Почему я его задаю? Потому что на него можно ответить очень и очень по разному.

    • Идеальный ответ начинается с постановки задачи. Зачем нам нужна такая структура? Какую именно задачу она решает? Как выглядит тривиальное решение данной задачи «в лоб» и чем оно плохо?
    • «Бонусные очки» за исторический экскурс, знание автора решения, хотя бы примерный год его появления (не в Java, разумеется)
    • Ответ хотя бы junior'а обязан включать способы использования структуры. Какие методы она поддерживает.
    • От middle-разработчика требуется понимание внутреннего устройства, а также описание контрактов функций hashCode() и equals(), функциональных требований к ним
    • «Бонусные очки» за описание нефункциональных требований к hashCode() и equals()
    • «Бонусные очки» за рассмотрение вопроса использования HashMap в многопоточной среде.
    • «Бонусные очки» за рассмотрение альтернатив HashMap — их перечисление, сравнение по сложности реализации, использования, скорости работы в общем, идеальном и самом плохом случаях.
    • «Бонусные очки» за альтернативы HashMap в виде отдельных компонентов системы (например, баз данных и «внешних» кэшей).
    • «Бонусные очки» за описание того, как HashMap используется в базах данных, и почему обычно используют индексы на основе двоичных деревьев, а не HASH-индексы.

    Как видите, очень большое количество «бонусных опций», о которых можно поговорить с senior'ом. А о скольких пунктах вы сами можете поговорить хотя бы минут 10?

    Если будет скучно, замените HashMap на TreeMap.

    Напишите SQL...


    Ага, и снова «стандартный» вопрос, который 10 лет назад был на каждом собеседовании. Сейчас уже реже, видимо из-за моды на nosql. Но умение работать с данными всегда нужно, и программисты, понимающие декартово произведение, всегда полезнее (и дороже) тех, кто ограничивается общим пересказом учебника.

    А вопрос звучит так:
    Пусть в базе данных существуют две таблицы: students и groups. У каждого студента указан идентификатор группы group_id, к которой он относится. Напишите SQL-запрос без использования вложенных, выводящий список групп (или количество групп) без единого студента

    Правильный ответ будет, разумеется, содержать не просто JOIN, но LEFT JOIN со сравнением значения на NULL. Самое интересное будет поговорить с кандидатом о том, какие ошибки можно допустить при написании запроса, и почему именно запрос не будет работать, если их допустить. Почему нельзя сравнивать с NULL через равенство? Почему не будет работать простой JOIN?

    Бонус за индексы, которые ускорят работу этого запроса и за рассмотрение вариантов SQL в разных диалектах (разных СУБД).

    Найдите ошибки в коде


    Кандидату озвучивается задача так:
    Предположим, что вам на code review приходит Pull Request (Merge Request) от другого разработчика. В этом request'е большое количество разных файлов, но один из них выглядит следующим образом (приведён код класса целиком):

    package ru.mycompany.utils;
    
    /** Wrap around Lock to simplify interface */
    class LockWrapper {
        private Lock lock;
        public wait() {
            this.lock.wait()
        }
    }
    

    Будут ли у вас замечания к этому коду, и если будут, то какие? Пропустите ли вы запрос с таким файлом далее (в master-ветку), или же потребуете переделать, и почему?

    Разумеется, и здесь есть как минимум три уровня.

    • Любой junior должен указать на синтаксические ошибки, которые есть в этом коде. Разработчик должен указать, почему код не скомпилируется. И проблема не только в синтаксисе, разумеется.
    • Разработчик должен знать, почему даже если код скомпилируется, он не заработает. И как необходимо этот код поправить, чтобы он заработал. Разработчик должен уметь использовать и конструкцию synchronize, и классы из пакета java.util.concurrent, и знать, почему одно второму не третье.
    • Идеальный разработчик же должен начать с вопроса, а зачем этот код нужен, какую задачу он решает, и может ли он её решить, даже если исправить все существующие проблемы в этом коде.

    В процессе ответа вместе с кандидатом приводим код к «идеальному» виду. Итоговый вид, разумеется, зависит от квалификации кандидата. Лучший из моих кандидатов нашёл здесь 13 ошибок. Не считая «самой главной ошибки».

    Бонусом можно поговорить о том, какие средства автоматического контроля кода следует использовать, чтобы найти хотя бы часть присутствующих ошибок.

    Вместо заключения


    Один совет, который хочется дать всем тем, кому придётся собеседовать будущих коллег. Не пытайтесь дать ответ — подходит человек или нет. Формулируйте своё мнение либо в виде грейда (если у вас в компании они приняты), либо в виде денежной суммы, которую вы готовы заплатить кандидату, чтобы он работал в вашей компании. Это, во-первых, упрощает принятие решение вам, ведь оно не будет чёрным или белым, во-вторых — тому, кто будет принимать финальное решение или сравнивать итоги нескольких собеседований.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 55

    • UFO just landed and posted this here
        +6

        С точки зрения Макконнелла, очевидно

          +1
          Речь не про то, чтобы дать или не дать ответ кандидату, а про то, как для себя лично формулировать цель собеседования. Если формулировать жестко: «я должен принять решение», то это и себе стресс, и в случае, если кандидат «на границе», от субъективности больше зависит. Оценка же в «цифрах» всегда мягче, и упрощает процесс.

          Для кандидата все остаётся по прежнему. В крупных компаниях на собеседованиях могут (редко) разобрать ошибки, но почти никогда не говорят итогового «принят» или «не принят».

          Про SQL обсудить тоже много чего можно, но я ищу разработчика backend’а, а не DBA. Хотя о том, зачем вообще нужен SQL и современные СУБД и как они упрощают жизнь (и сравнение с NoSQL) я бы поговорил. Акцентируя внимание в том числе на ACID и оптимизаторах запросов. Главное помнить про время :-)

          «Идеальный» надо взять в кавычки, правильное тут слово скорее «работающий».
          • UFO just landed and posted this here
          +1
          Да, я тоже, на прошлом месте работы так делал. У меня было несколько стандартных вопросов, которые давали и грубую оценку и повод поговорить.
          Я, вообще, собеседуя, предпочитал говорить о том, что человек сам заявил как «знаю».
            –3
            Собеседую Java программистом одним вопросом — прошу рассказать о режимах сборщика мусора.
              +12
              Я всегда знал что с джавистами что-то не так
                +7

                Режим сборщика мусора на случай если таски по джаве закончатся?)

                  +29

                  За двенадцать лет коммерческой разработки это знание пригодилось примерно никогда.

                  • UFO just landed and posted this here
                      0

                      Может вы имели в виду, как работает сборщик, про всякие эдены и поколения? Точное устройство слишком точное, чтобы ради общего собеседования лезть в сорцы Hotspot, и не очень нужное, если используется коммерческая VM, в которой вообще что угодно может быть, отличное от поколений.

                        +2
                        А оно и не может пригодится.
                        Ну раз оно скорее всего не пригодится, то зачем тратить на это время?) Тем более, если не использовать, то рано или поздно забудется.
                        Вот заняться людям нечем, кроме как учить то, что им не пригодится. Не разумней ли учить то, что реально может быть полезным в работе? Такого итак нескончаемый поток.

                        Ну столкнется человек раз в году с задачей, по которой нужно глубоко разбираться в теоретической части чего-то. Потратит часов 50 рабочего времени и разберется. Компания разорится на целых 50 часов его обучения. В тоже же время за год он столкнется с 50 задачами, которые он знает как делать и ему, в отличие от других в команде, для их выполнения не придется тратить часов 200 на дополнительное изучение технологий. Компания в итоге окажется в плюсе.

                        Как будто разработчики сразу должны знать, как любую задачу решить.
                        Нет, конечно. Все много чего не знают, много чего не помнят и гуглят каждый день.
                        Если поставить двух сеньоров из разных компаний прособеседовать друг друга, с очень большим процентом вероятности каждый из них посчитает другого джуном, что обычно и происходит. У каждого свои знаний, свой опыт/задачи. Каждый считает, что каждый разработчик должен знать именно «это».

                        За двенадцать лет коммерческой разработки это знание пригодилось примерно никогда.
                        Вполне хороший ответ, если он не на все вопросы такой)
                        Имхо, если собеседующий считает такой ответ минусом, то компания доверила собеседовать не тому человеку и несет из-за этого небольшие дополнительные убытки.
                        Конечно, есть области, где нужно глубоко знать какую-либо технологию. Там подобные вопросы уместны. Но, часто подобное любят спрашивать даже там, где это никогда не использовалось и не будет.
                          0
                          Вполне хороший ответ, если он не на все вопросы такой)

                          Сильно зависит от вопросов. Вдруг они все "такие"?

                          –4

                          Ну да, а потом мне продают продукт (с поддержкой), который раз в пять минут на минутку фризится, когда ему памяти вместо 16 Гб дали 128. На 16 он ругался на нехватку, а в 128 вдруг фризится.
                          Как вы думаете — почему? Как ответить на этот вопрос, если не знать про типы и настройки gc?

                          0

                          Вы никогда не знаете, что может пригодиться.


                          Я не далее чем вчера решал в реальном коде предельно собеседовательную задачу: проверял, сбалансировано ли скобочное выражение. Впервые за сколько себя помню.

                            +3

                            Да, но это не повод спрашивать "олимпиадные" задачи на общем собеседовании.

                          +2

                          Шипилёв, перелогинься! :p

                            0

                            5 баллов

                            0

                            Последний пункт интригует. Как выглядел этот кандидат, который нашел только 13 ошибок?

                              0

                              Гик. Умный, но далекий от бизнеса.

                              +1

                              Подскажите пожалуйста, а что такое "обычный JOIN"?

                                +1

                                INNER JOIN


                                «Обычным» называю потому, что во многих диалектах его можно заменить перечислением таблиц во FROM

                                  +2

                                  Нет-ли ошибки в этом утверждении?

                                  0
                                  По контексту имеется ввиду inner join
                                  0
                                  Неплохой набор вопросов, а точнее способ из задавать. Главное только этими вопросами не ограничиваться, потому что сама по себе тема неисчерпаемая.

                                  И еще, не заметил чтобы аврор акцентировал на этом внимание — этот способ не формализуем. То есть, мы не можем заранее сформулировать список вопросов предлагаемого автором типа, а потом попросить их задать кого угодно, и проверить ответы. Не получится, так как нет заранее известных точных ответов. Ну и как минимум, чтобы так интервьюировать синьоров, нужно самому быть синьором.
                                    +2
                                    А мне способ задавания вопросов не понравился.

                                    Это если они так и делают как в статье: «Расскажите про хэшмэп!» и дальше молчат и ждут ответа на все свои пункты и бонусы.

                                    Надеюсь я просто неправильно понял как автор предлагает вести такое собеседование.
                                      0
                                      Разумеется, если человек для начала ограничивается кратким ответом, то к полному ответу его нужно подводить наводящими вопросами. «А зачем нам HashMap?», «А как понять, хорошая hashCode() или плохая?», «будет ли работать HashMap в многопоточной среде?» и т.п.
                                        +3
                                        нужно подводить наводящими вопросами

                                        "Кто и в каком году её придумал?"

                                          0
                                          Это, очевидно, бонус, и знать не обязательно. Но бонус был бы приятный. Как, например, обсудить за кружкой пива, сколько бит в байте, и почему.
                                          +2
                                          Интересно, как часто джависты прямо вот ручками пишут формулу для хэшкодов, чтобы помнить, плохой алгоритм или хороший? В 95% случаев используется либо Ломбок, либо Objects.hash(...).
                                            +2
                                            Вы, наверное, хотели сказать «99,9% случаев»?
                                              0
                                              Мне интересен не код хорошей функции, а требования к ней. Не то, как должна быть написана функция, с какими константами и операциями, а почему, исходя из каких требований, она должна быть так написана?

                                              Какие функциональные (контракт) и нефункциональные требования есть к функции hashCode()?
                                            0
                                            Я подозреваю, что неправильно поняли. Суть метода, как я его понимаю, состоит в том, что вопрос — это только тема для беседы. И то, насколько глубоко собеседуемый может его раскрыть — как раз очень хорошо показывает его уровень. Ну то есть да, наводящие вопросы, как автор ниже уточняет, потому что что за беседа, когда оба молчат?

                                            Этот способ, например, не пропускает людей, которых можно условно назвать «зубрилами». То есть способных выучить те или иные учебники, но не способных при этом полученные знания либо применить, либо глубоко осознать. Потому что в учебнике про хешмапы обычно не пишут, что такое хорошая хеш функция, этим немного в других книгах занимаются. И если человек такой уровень ответа смог раскрыть — значит он не просто учебник зубрил.

                                            Это не идеальный метод, у него свои ограничения есть. Но это именно ограничения, не недостатки.
                                          +1
                                          Правильный ответ будет, разумеется, содержать не просто JOIN, но LEFT JOIN со сравнением значения на NULL.

                                          А в данном случае нельзя использовать EXCEPT?
                                          (select id from groups) except (select group_id from students)?
                                            0

                                            В качестве первого подхода можно, но потом попрошу переделать на JOIN.

                                              +1
                                              попрошу переделать на JOIN

                                              Вы имеете в виду с целью выяснить умение пользоваться JOIN, или в данном случае у него есть преимущества над EXCEPT?
                                                0
                                                Именно с целью выяснить умение работать с JOIN и NULL
                                                +2
                                                Был у меня как-то такой вопрос на собеседовании. И интервьюер как раз хотел услышать именно такой ответ, как вы и дали.
                                                Пришлось ему объяснять, что
                                                select count(g.id) 
                                                  from group g 
                                                  left join students s on s.group_id = g.id
                                                 where s.id is null
                                                

                                                как правило (но не всегда!), проигрывает в производительности
                                                select count(g.id) 
                                                  from group g 
                                                 where not exists (select null
                                                                     from students s 
                                                                    where s.group_id = g.id)
                                                


                                                Добавлю к этому очень немаловажный факт, что в разных СУБД и версиях этих СУБД (!), с разным количеством данных в таблицах и разными индексами на таблицах, могут быть разные планы и производительность этих двух запросов.

                                                Вообще, тема anti-semi join довольно холиварная. Но я бы такой запрос, который вы привели как правильный, вежливо попросил бы переделать (откуда и для чего ограничение на подзапросы, если, конечно, речь не о какой-нибудь старенькой Firebird) — он предпочтительнее, чаще производительнее, так как нет тяжелого «left join» и, в конце-то концов, зачем вам тащить «студентов» наверх, если вы их используете только как условие для отбора данных?
                                              +9
                                              От себя замечу, что если описана ситуация когда разработчику приходит на PR синтаксически неверный код, я бы очень задумался о процессах в этой компании, о ее зрелости и вообще стоит ли дальше общаться.
                                                0

                                                Как по-вашему, ребята какого уровня должны решать вопросы со зрелостью процессов в компании и почему бы именно вам этим не заняться? Был-ли у вас подобный опыт в прошлом? Какие цели вы поставите и какие действия будут вами предприняты, чтобы улучшить ситуацию?

                                                  0
                                                  Только этим я и занимаюсь, я специализируюсь на процессах, в частности на процессах обеспечения качества.

                                                    0
                                                    че тут решать, PR отправляется на сборку и выпадает в красный билд. тоже мне проблема
                                                    +5
                                                    Да и требовать глазами найти синтаксические ошибки это из разряда попросить написать рабочий код на доске.
                                                      –1
                                                      Синтаксические ошибки это уровень junior'а. Вполне допустимо, если сразу переходим к другим проблемам. Однако, пару раз у меня было собеседование, когда человек ничего кроме синтаксических ошибок и не нашёл.
                                                      –1
                                                      Нигде же не говорится, что эта ситуация реальная. Это модель некоторого рабочего процесса с целью выяснить знания человека. Данная модель нужна для решения задачи проведения собеседования.

                                                      Ну а как устроены CI-процессы можно рассказать отдельно.
                                                        0
                                                        Это мне напоминает, когда C на собеседовании дают выражение, поведение которого не определено даже стандартом. При этом удивляются, когда кандидат увидев это, говорит, вы что это в боевом коде используете? А если нет, зачем спрашиваете? А вам для проверки кругозора, аааа, понятно…

                                                        Я не спорю, но по вашим примерам судят о бардаке в компании в общем, и в вашей группе в частности.

                                                        Можно, но если у вас все норм, то тогда будет еще больший диссонанс. Зачем меня это спрашивали.
                                                      +4
                                                      Один совет, который хочется дать всем тем, кому придётся собеседовать будущих коллег.

                                                      Оценивайте не знание фамилии изобретателя хэшмепы, а общую адекватность, практические знания и насколько хорошо человек соображает — например нащупать тему, с которой он не работал и попросить поразмышлять на тему "как бы вы сделали вот такое и почему именно так?"

                                                        +3
                                                        Как сказал великий: «Говорить о программировании — все равно что танцевать об архитектуре». Терпеть ненавижу собеседования вида «а поговорить?». Выявляет только у кого язык гибче и длиннее. Пишите код.
                                                          –1
                                                          как раз код писать это для code monkey.
                                                          Надо проверять сообразительность — например кинуть задачку на сложный случай в распредсистеме с требованием обеспечить консистенси, или какую другую на думание.
                                                          И софт скиллс — будет ли этот человек дружить, делиться, создавать позитив, или все у него будут уроды на почве того, что он больше деталей помнит из treemap. Cнобов, манипуляторов, циников — с любыми достижениями — за дверь. Потому что если из за одного человека уйдет два или больше, то он в жизни их не заменит, каким бы гуру он не был.

                                                          А на случай непроизводительности — есть тестовый период, за этот срок можно все выяснить спокойно и не путем попытки натянуть сову на глобус и найти идеального кандидиата через 3 или 33 вопроса.
                                                          +1
                                                          как HashMap используется в базах данных

                                                          И как же?

                                                            0
                                                            Для выполнения hash join?
                                                            0
                                                            Мысль посетила, что одним из первых вопросов должен быть: «В чем вы сильны, на вопросы по каким темам вы сейчас готовы ответить на вопросы?» И уже исходя из этого строить дальнейший диалог.
                                                              +4
                                                              Эх, собеседования. Хочу напомнить одну простейшую вещь. Работает везде, делюсь. Куда вы вкладываете ресурсы, время и деньги, то вы и получите.

                                                              Итак, куда же вкладывает ресурсы автор текста?

                                                              1. Исторический экскурс в хэшмап. Вы этим деньги планируете зарабатывать, историей кто-когда предложил? Или это собеседование на предмет соответствия хобби интервьюера?
                                                              2. Стиль советского экзамена «наизусть». Я вот не смогу сразу сказать, почему индексы не на хешах, будет нужно — посмотрю. Пары дней хватит, чтобы раскурить любые мануалы по любым деревьям. Вы этим деньги планируете зарабатывать, написанием индексов? Нет? Тогда зачем? Куда полезнее будет предложить творческую задачку, базирующуюся на хешмапе, и посмотреть, как человек соберет ее с точки зрения производительности, thread safety и пр.
                                                              3. Опять же, SQL задачка — вы прям вот пишете сразу на Oracle и MSSQL, с постгресом и MariaDB на стороне? Что за монстра вы создали? Вы этим планируете зарабатывать деньги?

                                                              В общем, автор имплицитно подкладывает нам собеседование не на любого разработчика, а на разработчика, приятного конкретному автору с его персональным багажом.

                                                              Вообще судля по профилю автора текста — он занимается какими-то алгоритмами. Да, там все это может быть полезно, но это нишевые навыки. Листовки на полстраницы будет достаточно любому джуну, чтобы знать про хешмап, дальше он будет смело использовать стандартную библиотеку и в 99% случаев этим вы и будете зарабатывать деньги. Прекрасная книга Гоетца решит проблемы с конкарренси, а кратенький Виньяндс — с LEFT JOIN.

                                                              Что автор тестирует: насколько человек про себя умеет подчеркнуть ошибки лучше IntelliJ. Вы этим зарабатываете деньги?

                                                              Что автор не тестирует:
                                                              — умение сочинить сложную модульную систему, которая будет готова к unknown unknowns от бизнеса с дедлайном неделю (воображаю человека, который работает по 17 часов в сутки, получает истерики от бизнеса за неготовость и самоутешается знанием о том, кто когда изобрел хешмап)
                                                              — умение писать быстро работающий код. А не такой, который быстро только на юниттесте, а в проде с нагрузкой в миллион раз больше сваливается по таймауту, и тому через полчаса, оставив базу в inconsistent state, чтобы, значит, было чем заняться в консоли бд ручками.
                                                              — умение разработчика быстро подтянуть нужную инфу, если он ее не знает.

                                                              Нужно помнить, что собеседование — оно вообще-то в обе стороны. Мне лично было бы интересно узнать, рассказывает ли интервьюер ответы после того, как закончил спрашивать. Судя по тому, что он намекнул на 13 ошибок тут, но скрыл детали, на базе текста напрашивается вывод, что не склонен он прошаривать коллег. Каждый сам за себя, времена такие, приходите к нам, в нашу сплоченную организацию, толстая кожа как у мамонта — бонусные очки.

                                                              Любой выпускник вуза, который не знает всех этих тонкостей сразу, сможет спокойно разобраться с ними за пару дней, но данного собеседования не пройдет. Оно не соответствует тем вещам, которые нужны в большинстве мест, и проходит по советской системе «помнишь-молодец». Помнить что-то надежно можно, если занимался этим и только этим. Это такой больше академический подход. Есть способы быстро научить людей любым нужным навыкам, так как по сути все программирование — это довольно просто, по сравнению с какой-нибудь космологией или медициной, и выхваляться тут нечем, если конечно вы не пишете на ассемблере работающий код прямо на доске или на худой конец не торгуете с миллисекундными раундтрипами. Все остальные вещи осваиваются за сравнительно краткий промежуток времени. Лично мне ближе принцип — не важно, что ты не знаешь сейчас, важно, сможешь ли ты научиться с нормальной скоростью.
                                                                0

                                                                Согласен с вами. У меня план собеседования такой. Задаю вопрос, отвечая на который можно много чего рассказать, а дальше задаю вопросы по тем темам, которые собеседник сам обозначил. Чем выше уровень специалиста, тем быстрее и дальше продвинется диалог. Когда время подходит к концу, я прикидываю объем того, что человек успел мне рассказать. Чем дальше прошел, тем лучше.

                                                                +1

                                                                Я после большого числа проведенных собеседований убедился, что лучше всего специалист проявляет себя тогда, когда слышит вопрос, к которому он не готовился. Поэтому свои 3 вопроса я нигде публикую.

                                                                Only users with full accounts can post comments. Log in, please.