За долгие годы коммерческого опыта я прошел огромное количество технических собеседований, посвященных Java и друзьям. Менялись интервьюеры и язык повествования, глубина вопросов и количество собеседований, но что‑то оставалось неизменным —
«разогревочный» вопрос «расскажи, как работает HashMap?»
Давайте разберемся, почему это не только бесполезный, но и вредный вопрос, который противопоказано задавать в большинстве собеседований на позицию Java-разработчика.
Перед тем как углубимся в проблематику, определимся:
Зачем вообще нужны технические собеседования?
Предположим, что номинальной целью любого технического собеседования является оценка технических знаний, навыков и способностей кандидата успешно выполнять задачи, связанных с предстоящей работой или проектами в компании (практически, это не всегда так, и огромное количество собеседований преследуют какие-то другие, непонятные цели, но с этим разберемся в другой раз).
Исходя из общей цели можем также разумно предположить, что целью каждого отдельного вопроса является проверка определенных, конкретных аспектов кандидата, которые имеют решающее значение для успешного выполнения задач на позиции.
Получается, каждый ответ должен приближать нас к пониманию, справится ли кандидат с поставленной задачей, или нет.
Это может быть вопрос о насущном фреймворке или библиотеке, предыдущем техническом опыте кандидата, дипломной работе в университете и темам, в которых он разбирается и которые ему интересны, но главное – вопрос должен быть полезным, т.е. в зависимости от ответа, интервьюер сможет сделать соответствующие выводы о компетенции и опыте.
Что же насчет работы HashMap?
Разберем на конкретных примерах ответов:
Кандидат А: "Я знаю, как работает HashMap, ..."
Самый частый и предполагаемый ответ. Иногда кандидат знает, как HashMap работает внутри, просто потому что ответил на этот вопрос на 20ти предыдущих собеседованиях. Иногда, сам разобрался и выяснил. Но дело в другом: получая правильный ответ на этот вопрос, давайте спросим себя, приблизились ли мы к цели собеседования на самом деле?
Скорее всего, да. Да, при условии, что мы нанимаем человека на работу над библиотекой продвинутых структур данных, где коллеги пишут свои собственные реализации Java коллекций на постоянной основе.
В оставшемся большинстве случаев, что нам это дает? Знание того, что кандидат проходил собеседования до нас? Возможно, что кандидат заучил список топ-100 вопросов на Java собеседований накануне (к сожалению, такие списки очень популярны)? В теории, что он понимает устройство языка глубже, чем просто использование? Зачем? А если это то, что нам нужно, – является ли такой шаблонный вопрос хорошим для подобной проверки?
Дополнительно спросим себя: если вопрос гуглится, понимается и запоминается за считанное мгновение, является ли незнание ответа на него чем-то, на что мы должны полагаться при решении приема на работу?
Можно также возразить, что на этот вопрос некоторые интервьюеры смотрят со стороны "начать диалог, снизить напряжение". Но может ли вопрос, предполагающий точный, однозначный ответ, быть корректным для этой цели? Первое впечатление слишком сильно влияет на последующее восприятие, и в интересах интервьюера дать кандидату раскрыться с первой же минуты диалога.
Кандидат B: "Я не знаю, как работает HashMap, но знаю, что он обеспечивает, и как пользоваться"
Хуже ли такой ответ варианта Кандидата А? Кажется, что нет. На первый взгляд также может показаться, что кандидат честно признается, что не обладает всеми знаниями, а честность – это хорошо! Но когда речь заходит о техническом собеседовании, ситуация не так очевидна.
Ответ вроде "не знаю, но ..." может обеспечить подсознательную негативную оценку со стороны интервьюера. Психологические исследования подсознательных суждений показывают, что даже когда мы стараемся быть объективными, мы склонны ассоциировать знание с компетентностью. Когда кандидат говорит, что не знает, это может подсознательно вызвать сомнения в его способности эффективно выполнять задачи, хотя на практике – скорее всего, это неправда!
Чтобы избежать подобных ложных установок, можно постараться спланировать вопрос в ключе "существует ли единый, однозначный ответ?", и, если ответ существует, – дважды подумать перед тем, как задать его.
К счастью для разработчиков, мы можем уверенно подойти к проблеме отсутствия точных знаний, посредством задания неточных вопросы: "Какие коллекции знаешь, как использовал?", "Как справлялись с проблемами распределенных транзакций?", "Какую бы БД ты бы выбрал в этом случае? А почему, какие альтернативы?"
Бенефиты такого способа опроса заключаются не только в уменьшении возможных ложных суждений, но и в увеличении вашей собеседнической тракции, глубокому пониманию опыта кандидата, проверке критического мышления и умения находить полезные компромиссы.
Никакая технология в программировании не существует в вакууме – подобно конкретному слову/переводу в словаре, технология в первую очередь – это средство достижения цели.
Представьте, что на выпускном экзамене в лингвистическом университете у выпускников бы спрашивали – "как переводится слово causal? (причинно-следственный, всегда путаю с casual)", и на основании еще 50ти знакомо-незнакомых слов принимали решение о выдаче диплома? Звучит абсурдно, но этот пример совсем не далек от "стандартных" вопросов на техническом собеседований.
Кандидат C: "Я не знаю, как работает HashMap, но могу предположить, что..."
Хуже ли такой ответ варианта кандидата А? Если предположение совпадает с реальностью, нисколько! Зависит от настроения интервьюера, но возможно даже получится так, что кандидат получит несколько бонусных очков за рассуждение! А кандидат А, знающий прямой ответ, оттарабанив его на автомате, их получит? Сомневаюсь.
Ситуация становится еще хуже, если предположение не совпадает с действительностью, но звучит разумно. Разумность, при этом, определяется интервьюером, который может не располагать необходимыми знаниями в требуемой глубокой области, ведь задав точный вопрос – ты ожидаешь получить точный ответ.
Возможно, наш кандидат на завтрак объясняет устройство дерева Фенвика бакалавриату ИТМО и на обед консультирует младшего брата Роберта Мартина по написанию чистого кода, но на вопросы "как работает HashMap" и "Расшифруй SOLID" отвечает – "не знаю, но могу предположить..", и получает штраф-балл за свое собственное "не знаю, но.." и штраф-балл за то, что не знает интервьюер, который не ожидал такого поворота событий. А что еще хуже, интервьюер о таких увлечениях кандидата в потоке шаблонного собеседования может даже не узнать!
Если исходить из предположения, что интервьюер всегда знает широкий ответ на собственный вопрос (что тоже разумно, ведь сам интервьюер как-то работает) и может дать возможность порассуждать, – почему не дать порассуждать кандидатам А и В?
Чем ближе семантика ответов нескольких кандидатов в сравнении, тем проще делать выбор между ними.
Сделать выбор между кандидатом, ответившим правильно на точный вопрос и кандидатом, ответивший с энтузиазмом, ноткой критического мышления и здравым смыслом – тяжело.
Чем шире область вопроса – тем глубже можно зайти. Не загоняйте себя в ловушку собственными формулировками.
Кандидат D: "Я не знаю, что такое HashMap"
Возможно, единственный ответ на конкретный вопрос, который приблизил нас к пониманию. Возможно, не только приблизил, но и убил, и мы спрашиваем себя – как такой кандидат вообще к нам прошел? В данном конкретном случае кажется, что это совсем не тот вариант ответа, который мы ожидаем, но это показательный пример по другой причине:
Наши ожидания – наши проблемы.
Уверенность в определенном варианте ответа всегда плохо сказывается на трезвой оценке происходящего. Чем сильнее ожидание – тем сильнее падение в случае опровержения, и тем слабее ощущение в случае подтверждения.
Рассмотрим чуть менее шаблонный (и не менее вредный) вопрос: – "Что означает буква D в аббревиатуре SOLID?". Вопрос классический, и как интервьюер, могу предположить, что 9 кандидатов ответит на него верно, а 1 – запутается в термине DI и начнет рассказывать про механизм Dependency Injection. Говорит ли нам это, что код этого бедолаги читается хуже, чем остальных? Узнали ли мы что-то о его стиле разработки, о вещах, которые он ценит при написании кода, при ревью? А что насчет тех ребят, которые ответили верно? [Аргументы из секции Кандидата A].
Мы буквально узнали только то, что кандидат понимает термин Dependency Injection, но не может расшифровать букву D. В наших же глазах он опустился на последнюю строчку по вопросу "чистого кода", который предполагается под этим самым SOLID вопросом, и упал еще ниже на основании наших собственных ожиданий, что безусловно, ложно.
Дело, конечно, не в HashMap. "Как работает HashMap" лишь частный случай куда большей проблемы – бездумной преемственности вредных вопросов, кочующих от интервьюеров к кандидатам – будущим интервьюерам, из года в год как неявный бэклог.
С каждым "вопросом с общего листа" шанс найти настоящий бриллиант пропорционально уменьшается, а шанс найти очередную звезду собеседований – увеличивается. Просматривая потенциальные варианты вопросов, спросите себя, можно ли к ним "явно" подготовиться? Имеют ли вопросы точные и однозначные ответы? Представьте себе худшую теоретическую картину кандидата, который потенциально может пройти собеседование, и пересмотрите свой подход, если картина вам не нравится.
К сожалению, большинство компаний, в которых мне посчастливилось проходить собеседования, упускало еще одну очень важную деталь – заинтересованность самого интервьюера в качественном найме на позицию. Если человек не понимает, кого они ищут, если человек не знает, зачем им еще один коллега, никакие советы по содержанию здесь не помогут. Посмотреть на ситуацию под этим углом мы попробуем уже в следующей статье.
Комментарии (41)
Nurked
29.08.2023 08:48+10Вообще ни разу не нашёл в жизни работу по собеседованию. Один раз за 20 лет был на таком собеседовании и понял, что искать работу так я не буду никогда вообще.
Всегда вступал в компании, в которых собеседование проходило так:
"Ты программист?"
"Да, могу на C# и golang"
"Отлично. Вот проект, у тебя месяц испыталовка. Если покажешь что можешь писать, ты нанят."
Всё.
Это освобожлало жизнь от ненужных интервью. Все прекрасно понимают, что мне не надо устраивать цирк с клоунами, чтобы попытаться показать, что знание О нотации будет иметь хотя бы отдалённое отношение к моей работе. Более того, при таком подходе ты отсекаешь бесконечные траты на HR, и приступать к работе можешь на следующий день.
20 лет программирую. 20 лет так и было. Хотя нет, на первой работе было собеседование. 15 минут, просто поспрашивали вопросы и наняли. Но там всё понятно было. Малёк из универа.
Сейчас я сам нанимаю себе людей, и прекрасно понимаю, что следить надо не за синтетическими KPI, а за наличием результата. Никакая метрика не покажет вам, хорошо ли написана программа. Только результат работы этой программы.
Конечно, при таком подходе надо понимать, что свеженанятых не надо ставить на "самый важный и сверхсекретный проект". Дать им песочницу, пусть напишут утилиту и всё такое. Подкинуть пару задач посложнее, посмотреть как справятся. Кто-то отлично справляется. Это хорошо. Кто-то честно приходит и просит о помощи - это хоршо. Кто-то замыкается и не говорит ни о чём. Это - плохо. А кто-то врёт и вешает лапшу на уши. С такими после месяца - байбай.
Всё. Есть результат - да хоть на голове стой и пиши, махая палочкой, я тебе буду платить. Нет результата - хоть буть ты трижды сертифицирован самим Билом Гейтсом и Стивом Джобсом, пусть у тебя Столлман во френдах в Линкедине, пусть тебя на работу возит Страуструп, ты мне не нужен.
А то приходят, обвешанные сертификатиками как современные генералы медальками. Все эти литкоды и хакерранки можно получить немного погуглив. А вот собрать нормальное приложение, а потом показать что ты можешь его менять и обновлять, да ещё и пишешь его так, как нам надо - этого никто никогда не отменит.
Главное в кандидате - это способность учиться.
bugy
29.08.2023 08:48+3Более того, при таком подходе ты отсекаешь бесконечные траты на HR, и приступать к работе можешь на следующий день.
С такими после месяца - байбай
Был такой мемасик. Одна минута планирования экономит 10 минут исполнения. Но верно и обратное, 10 минут исполнения экономит минуту планирования!
Зачем тратить дни HR'ов, если можно тратить месяцы разработчиков.
Никакая метрика не покажет вам, хорошо ли написана программа. Только результат работы этой программы.
Категорично не согласен. Результат работы программы вообще не показывает, хорошо ли она написана. Хорошо ли программа/фича написана, покажет количество времени, которое придётся потратить на её поддержку (баги, рефакторинг и т.п.).
Разумеется я смотрю только с колокольни долгоживущего продукта. А не проекта, который написал, зарелизил и забыл. Максимум небольшая платная поддержка. В таком случае да, единственное что имеет значение, работает программа или нет. Но я бы не употреблял термин "хорошо написана". Если пациенту сделали операцию, и на следующий день его сбила машина, это не значит, что операция была сделана хорошо. Это значит, что её качество не имело значение.
Nurked
29.08.2023 08:48Нет, я не говорю, что надо принимать бинари, и говорить, что всё работает - это хорошо. Это вообще тема для другой статьи - центр контроля качества ПО. Его вообще нет у 99 процентов компаний. проверять код на PR, это хорошо, это надо делать. Но это делают недостаточно часто.
ssmaslov
29.08.2023 08:48+1Я как раз именно так и набираю к себе в команду, технических вопросов вообще не задаю, ну или минимум, смотрю как человек рассказывает о своем опыте, максимально полно рассказываю ему чем мы занимаемся вообще и чем будет заниматься конкретно он, собственно если в целом человек нормальный спрашиваю ну как, справишься? Если да то испыталка 3 мес, за человеком закрепляется наставник и поехали. За 12 лет и наверное полторы сотни кандидатов два не прогедших испыталку. Считаю, отличный показатель
c_kotik
29.08.2023 08:48Не мог не пустить скупую мужскую слезу, прочитав ваш комментарий. Ибо как раз в процессе поиска работы и уже не помню в какой раз на собеседованиях диалоги выглядят так:
О, у вас 10лет опыта, но давайте поговорим о типах данных в js...
SadOcean
29.08.2023 08:48+2Иронично, но Я считаю вопрос про словари достаточно полезным.
Ведь для многих вопросов важно не только то, что задают, но и как отвечают.
Как кандидат владеет темой, как говорит и рассуждает.Это хороший вопрос, потому что люди разных уровне ответят на него по разному - от кейсов использования до глубокого понимания алгоритмов, а с некоторыми кандидатами можно еще и посмеяться про тупые вопросы на собеседованиях.
Отдельно нужно отметить, что Я не ожидаю, что кандидат точно знает ответ на вопрос, более того, Я не всегда знаю идеальные ответы на вопросы, которые задаю.
moonster
29.08.2023 08:48Лучше проверять не наличие конкретных знаний, а способность их применять.
Можно, например, предложить кандидату на обзор кусок забагованного кода, для починки которого без понимания устройства HashMap не обойтись.
Этот подход хорош еще и возможностью интегрировать несколько проверок.
ptr128
29.08.2023 08:48-2Мне недавно пришлось синьору(!) объяснять, что такое дополнительный код числа, так как он не понимал, как конвертировать внутреннее бинарное представление decimal между Java и C#. Хотя в обеих языках профи.
Так что порой лучше все же спросить, понимает ли соискатель, как реализован HashMap (или как в памяти могут храниться числа).
Leetc0deMonkey
29.08.2023 08:48-1Мне недавно пришлось синьору(!) объяснять, что такое дополнительный код числа, так как он не понимал, как конвертировать внутреннее бинарное представление decimal между Java и C#. Хотя в обеих языках профи.
Он и не должен был понимать, если не Сишник. Ну, ОК, была поставлена задача, он во всём разобрался, задачу решил. В чём проблема, не понимаю?
ptr128
29.08.2023 08:48А при чем тут C, если поддержка decimal и в C#, и в Java сделана их же средствами, а вовсе не на C?
Проблема, например, в прямых затратах на внутренний проект, так как выставить их заказчику не представляется возможным.
Leetc0deMonkey
29.08.2023 08:48Сишники непосредственно работают с бинарными представлениями всего и вся, поэтому странно было бы если бы Сишник не знал устройства double. Но Java и C# целенаправленно избавляют от этой необходимости. Претензии знать про дополнительный код непонятны. Другое дело, это не какие-то сакральные знания, это легко гуглится в рамках решения поставленной задачи. Неспособность самостоятельно разобраться - вот красный флажок. А не отсутствие каких-то знаний.
ptr128
29.08.2023 08:48При чем тут double? Double - это уже представление для CPU. А я про decimal, который и в Java, и в C# реализован классами на этих же языках. Соискатель при устройстве на работу заявлял, что может выполнять работу на уровне синьора на Java и C#, а так же обладает профессиональными знаниями gRPC. Но как только между микросервисами на Java и C# потребовалось передать данные в decimal - вообще не смог решить задачу. Я понимаю, что можно забыть о том, что такое дополнительный код. Понимаю, что можно было бы не знать, что в Java и C# разные способы представления decimal. Но раз человек не смог разобраться с этим самостоятельно, то тут уж явно недостаток базовых знаний.
Да, первый раз - случайность. Второй - совпадение. Но третий - уже закономерность. Поэтому если подобное повторится в третий раз, этот сотрудник окажется перед выбором перевода на должность мидла со снижением компенсации или увольнения по собственному желанию.
Leetc0deMonkey
29.08.2023 08:48Что-то я теперь окончательно запутался. То у вас "внутреннее бинарное представление", то "реализован классами" и передаётся между микросервисами. Да и само понятие "дополнительный код" числа не имеет никакого отношения ни к Java ни к C#. Сдаётся мне, может и упомянутый сеньйор не особо-то в чём-то виновен. А точно так же как я не понял что от него вообще хотят.
ptr128
29.08.2023 08:48Внутренне бинарное представление decimal в Java реализовано через класс BigDecimal в котором все значащие цифры числа представлены в виде unscaledValue E -scale, где unscaledValue - строка байтов в дополнительном коде. Тоже самое в C#, но unscaledValue, упрощенно - в виде 64-битного и 32-битного целых чисел в прямом коде, а знак отдельным битом.
В стандарте protobuf нет decimal. Поэтому через gRPC он передается в виде структуры. Так как есть еще и Confluent, то выбрана была структура уже поддерживаемая Connect/Sink из коробки, полностью совпадающая с внутренним представлением в Java. А сотруднику была поставлена задача написать класс на C#, конвертирующий эту структуру в класс Decimal (внутреннее бинарное представление C#) и обратно. Так, уже на пальцах, понятно?
panzerfaust
29.08.2023 08:48Если это ваша единственная претензия к этому сеньору, то это смешно. Точно также найдется немало людей (возможно, азиатов), которые вздрючат лично вас на темах, в которых вы считаете себя профи.
ptr128
29.08.2023 08:48-1Не понял, при чем тут вдруг оказались расы. У Вас какие-то личные проблемы?
Во-вторых, при чем тут вздрючат? Вы вообще поняли о чем я писал?
Сотрудник не смог самостоятельно решить задачу на языках, в которых он профи, так как даже не подозревал о существовании дополнительного кода.
panzerfaust
29.08.2023 08:48А вы точно уверены, что вы способны решить 100% задач в вашей области без советов со стороны? Вы родились профессионалом?
ptr128
29.08.2023 08:48-1Сначала ответьте на заданные мной вопросы
panzerfaust
29.08.2023 08:48при чем тут вдруг оказались расы
Вы вообще поняли о чем я писал?
Да. Вы пеняете человеку, что он чего-то не знает.
Сотрудник не смог самостоятельно решить задачу на языках, в которых он
профи, так как даже не подозревал о существовании дополнительного кодаПотому что не родился всезнающим, очевидно. Бывает. Вот я и спрашиваю, каково это - родиться всезнающим и не нуждаться в советах и обучении?
ptr128
29.08.2023 08:48Ссылка не открывается. Так что подозрение Вас в расизме сохраняется.
И не вижу ответа на вопрос о "вздрючат"
subzey
29.08.2023 08:48Вы подходите к интервью излишне механистично.
Может быть, важно не только то, что человек ответит, а ещё и как? «Звёзд интервью» отличить от «лоулевел задротов» можно, развив беседу.
Проводить собеседование — это не просто зачитывать вопросы и ставить галочки, а потом считать их количество. Галочки — это скрининг, а не собес.
mantegna Автор
29.08.2023 08:48За семь лет коммерческого опыта я прошел около ~350 технических собеседований – от Netflix и Amazon, до Тинькофф и Яндекс, от маленьких СНГ аутсорсов, до road-to-unicorn YC стартапов. К сожалению, текущие реалии сценариев технических собеседований _как раз механистичны_ – об этом и статья. Продукты разные, обязанности разные, технологии разные, кандидаты разные, а вопросы – одни.
"Как" ответит кандидат безусловно важно, но слыша одни и те же шаблонные вопросы из раза в раз от разных интервьюеров, я, честное слово, очень сомневаюсь, что даже самый глубокий интервьюер сумеет корректно оценить ситуацию. Сама статья всем сердцем кричит – уходите в вопросы пошире; развивайте беседу; держите в голове картину кандидата, а не лист и галочки.
Если это не ваша ситуация, я искренне, в хорошем смысле, завидую вашим кандидатам.
subzey
29.08.2023 08:48+2Что ж, выходит, спорить нам в общем-то не о чем. Эт хорошо)
Увы, я гораздо больше раз был в шкуре интервьюера, чем интервьюйи. С моей колокольни вопросы одинаковые, а кандидаты прям совсем разные.
Кто-то не дослушает вопрос и бежит отвечать (ладно бы ещё вопрос угадал!). Кто-то пытается засрать эфир терминами. Кто-то спокоен как удав (сразу видно, сеньор). Кто-то начинает воспаляться по поводу того, что вопросы слишком простые для его величества Сеньора (сразу видно, мидл). Кто-то перенервничал, и ему нужны сейчас не подсказки, а кружка чая и 20 минут посидеть. Кто-то ответит на вопрос и ещё и приправит байкой как в 1998 из-за лёгкого подбора коллизий хэшмапа превратилась в односвязный список, и всё прилегло, и как они это искали…
В общем, каждый собес — это что-то личное и уникальное
panzerfaust
Я еще на заре своей карьеры интервьюера усвоил, что вопросы "Что такое Х и как он устроен" - это трата времени. Это как юнит-тест без ассертов. То есть работа какая-то выполняется, а выводов нормальных не получается.
sshikov
Ну… видите ли в чем дело. Хеш функции — это некая база. На них например основаны некоторые реализации JOIN в SQL, и много чего еще. Ну то есть, принципы их работы понимать очень желательно, они нужны далеко за пределами HashMap-а. И когда я спрашиваю, как работает HashMap, я ожидаю от человека понимания не того, как устроен конкретный класс (там достаточно много нюансов, которые проще посмотреть в коде, чем зачем-то запоминать), а именно этих принципов. Что такое хеш функция, и что означает равенство двух хеш функций от двух объектов, а что оно не означает?
Я не хочу сказать, что это вопрос идеальный, но с учетом вот такого вот подхода он намного, намного лучше ряда вопросов, которые показывают только способности человека что-нибудь запомнить.
Моя практика в целом показывает, что человек, которые на такие вопросы ничего внятного не может ответить — он как правило и в других областях плавает. То есть это неплохой такой способ понять, как человек думает, и думает ли вообще.
panzerfaust
А моя практика показывает, что 90% канидатов способны как по учебнику объяснить мне устройство хэш-таблиц. Это не заботал уже только ленивый. А потом где-то только 10% кандидатов способны ответить на вопрос "существуют ли в принципе такие индексы в БД, поиск по которым имеет сложность меньше чем O(logN) (т.е. быстрее чем b-tree)?". Люди не видят связи между инструментом и кейсом его применения. Поэтому я и отказался от вопросов в лоб. Да, знание хэш-таблиц и прочей классики проверить нужно, но не в лоб.
sshikov
Ну мне не всегда так везет. Были выпускники курсов (даже не помню уже, каких), которые не смогли. Ну то есть они может и объясняют, но на простой вопрос "а почему это работает быстро (медленно, жрет меньше памяти и т.п.)" — уже ответить не могут.
А кто предлагал в лоб? Я как раз про это и толкую, что сама тема очень даже важная, причем с разных сторон. Ответ в точности по учебнику тоже кое-о чем может сказать. Что человек заучить и пересказать близко к тексту может (что в общем уже неплохо, бывают люди и это не могут), а пересказать суть кратко своими словами — уже нет. Ну и чем это не повод для выводов? Не окончательных, но вполне себе интересных.
vassabi
хмм.... это когда в поле лежит смещение записи в БД ?
(т.е. если БД\таблица - это один файл, то это позиция байт в файле - чтобы поиск был равен 0, можно было сразу считывать данные)
aleksandy
Скорее всего имелись ввиду индексы на битовых масках.
panzerfaust
Имелись в виду буквально индексы на хэш-таблице. Мой поинт в том, что мне очень подозрительно, когда у человека от зубов отскакивает "устройство хэшмапы", а потом он не может даже предположить, что точно такой же механизм может быть использован вне джавы.
Это типичный паттерн поведения отличника-зубрилы. На прямой вопрос ответит, на более хитром обязательно споткнется.
oracle_schwerpunkte
> Поэтому я и отказался от вопросов в лоб.
Люто поддерживаю.
> Люди не видят связи между инструментом и кейсом его применения.
В защиту кандидатов:
Потому что куча подводных камней, и теория далеко отстоит от практики. Сложность при доступе к данным никого не интересует, важна скорость и ресурсы. И если на практике сложный алгоритм окажется быстрее, выберут его. Поэтому в реальной жизни и table full scan часто быстрее вообще любого индекса, и 90% таблиц в классической БД будут иметь "более медленный" b-tree индекс.
mantegna Автор
При такой формулировке в текущих реалиях, скорее всего, вы получите ответ про конкретный класс, и даже очень удивитесь (ложно-позитивно), как много кандидаты знают про его устройство.
Если хочется понять как человек думает на примере хеш-*, наводящие вопросы типа "Существует ли быстрый способ понять, что две строки не равны, явно не сравнивая их содержание? Является ли этот способ безопасным в 100% случаев? А чтобы понять, что строки равны?", куда более свободные и открытые к обсуждению, и даже если какой-нибудь джуниор на самом деле не будет знать, что такое хеш-код, но проявит смекалку и придумает свой собственный способ (скорее всего, похожий на хеш!), вы получите куда больше полезной информации о кандидате, чем могли изначально.
sshikov
Вообще все что вы рассказываете в последнем абзаце — это и есть в моем понимании ответ на вопрос "как работает хешмап". То есть меня интересуют именно принципы и "почему так сделано", а не его конкретное содержание в виде кода, как его написали уважаемые:
тем более что код-то на гитхабе лежит. И я толкую как раз про то, что надо просто так к вопросу и подходить. А не требовать рассказ из учебника, считая близкий к тексту пересказ хорошим ответом. Такой вопрос и такой ответ правда не имеют смысла. Но дьявол как всегда в нюансах.
N4N
Вы вообще не поняли смысл статьи. Вам про конкретные проблемы говорят, а вы все про свои хеши
Garuda860702
Не проще ли дать задачу и там уж точно будет видно как человек думает?
mantegna Автор
Задачи занимают много времени, а по области получения полезной информации – ограничены тематикой. Могут быть полезны – безусловно, но проблематика очень сильно разнится от компании к компании, и речь в статье о вредных вопросах на технических собеседованиях, не про подходы найма технических специалистов в целом.
sshikov
Дать задачу написать хешмап? :) Ну в общем да, так можно конечно, просто это другой подход. Он не лучше и не хуже в целом, он просто другой.
Leetc0deMonkey
Чтобы джойнить таблицы не надо понимать хеш-функции. Более того, там под капотом всё может быть устроено гораздо сложнее чем вам кажется. И до этого уровня СУБД вас не допустит. Так, всё ограничится рекомендациями как что правильно джойнить.
Моя практика показывает ровно обратное. "Парни дела" очень скупы на слова и объяснения теорий. А звонкие теоретики бесполезны в мало-мальски сложной разработке.
sshikov
Ага, ага.
Leetc0deMonkey
И? Обычные хинты. Без понимания что именно они делают, а с одними только поверхностными представлениями можно только хуже сделать.
sshikov
Да. Обычные хинты. Которые явно указывают, что вот тут надо использовать хеш джойн (ну или там индекс, бла-бла-бла). Это же именно тот уровень, про который вы говорите, что СУБД меня не допустит, разве нет?
Я вам больше скажу, в спарке вообще API есть, то есть это может быть обязательное указание, а не хинт.
А уж все кто читает планы запросов — просто обязаны понимать, какой именно способ джойна выбран, и какой лучше.
Я вполне соглашусь, что очень многие до такого уровня не добираются, но это скорее говорит об их квалификации (или специализации), а не о том, что никому не нужно понимать, чем хеш джойн отличается inner loop, условно. У нас вот данных за 20Пб перевалило, у много кому такое нужно.