Comments 47
Я еще на заре своей карьеры интервьюера усвоил, что вопросы "Что такое Х и как он устроен" - это трата времени. Это как юнит-тест без ассертов. То есть работа какая-то выполняется, а выводов нормальных не получается.
Ну… видите ли в чем дело. Хеш функции — это некая база. На них например основаны некоторые реализации JOIN в SQL, и много чего еще. Ну то есть, принципы их работы понимать очень желательно, они нужны далеко за пределами HashMap-а. И когда я спрашиваю, как работает HashMap, я ожидаю от человека понимания не того, как устроен конкретный класс (там достаточно много нюансов, которые проще посмотреть в коде, чем зачем-то запоминать), а именно этих принципов. Что такое хеш функция, и что означает равенство двух хеш функций от двух объектов, а что оно не означает?
Я не хочу сказать, что это вопрос идеальный, но с учетом вот такого вот подхода он намного, намного лучше ряда вопросов, которые показывают только способности человека что-нибудь запомнить.
выводов нормальных не получается
Моя практика в целом показывает, что человек, которые на такие вопросы ничего внятного не может ответить — он как правило и в других областях плавает. То есть это неплохой такой способ понять, как человек думает, и думает ли вообще.
Моя практика в целом показывает
А моя практика показывает, что 90% канидатов способны как по учебнику объяснить мне устройство хэш-таблиц. Это не заботал уже только ленивый. А потом где-то только 10% кандидатов способны ответить на вопрос "существуют ли в принципе такие индексы в БД, поиск по которым имеет сложность меньше чем O(logN) (т.е. быстрее чем b-tree)?". Люди не видят связи между инструментом и кейсом его применения. Поэтому я и отказался от вопросов в лоб. Да, знание хэш-таблиц и прочей классики проверить нужно, но не в лоб.
объяснить мне устройство хэш-таблиц
Ну мне не всегда так везет. Были выпускники курсов (даже не помню уже, каких), которые не смогли. Ну то есть они может и объясняют, но на простой вопрос "а почему это работает быстро (медленно, жрет меньше памяти и т.п.)" — уже ответить не могут.
знание хэш-таблиц и прочей классики проверить нужно, но не в лоб.
А кто предлагал в лоб? Я как раз про это и толкую, что сама тема очень даже важная, причем с разных сторон. Ответ в точности по учебнику тоже кое-о чем может сказать. Что человек заучить и пересказать близко к тексту может (что в общем уже неплохо, бывают люди и это не могут), а пересказать суть кратко своими словами — уже нет. Ну и чем это не повод для выводов? Не окончательных, но вполне себе интересных.
"существуют ли в принципе такие индексы в БД, поиск по которым имеет сложность меньше чем O(logN) (т.е. быстрее чем b-tree)?
хмм.... это когда в поле лежит смещение записи в БД ?
(т.е. если БД\таблица - это один файл, то это позиция байт в файле - чтобы поиск был равен 0, можно было сразу считывать данные)
Скорее всего имелись ввиду индексы на битовых масках.
Имелись в виду буквально индексы на хэш-таблице. Мой поинт в том, что мне очень подозрительно, когда у человека от зубов отскакивает "устройство хэшмапы", а потом он не может даже предположить, что точно такой же механизм может быть использован вне джавы.
Это типичный паттерн поведения отличника-зубрилы. На прямой вопрос ответит, на более хитром обязательно споткнется.
> Поэтому я и отказался от вопросов в лоб.
Люто поддерживаю.
> Люди не видят связи между инструментом и кейсом его применения.
В защиту кандидатов:
Потому что куча подводных камней, и теория далеко отстоит от практики. Сложность при доступе к данным никого не интересует, важна скорость и ресурсы. И если на практике сложный алгоритм окажется быстрее, выберут его. Поэтому в реальной жизни и table full scan часто быстрее вообще любого индекса, и 90% таблиц в классической БД будут иметь "более медленный" b-tree индекс.
И когда я спрашиваю, как работает HashMap, я ожидаю от человека понимания не того, как устроен конкретный класс (там достаточно много нюансов, которые проще посмотреть в коде, чем зачем-то запоминать), а именно этих принципов.
При такой формулировке в текущих реалиях, скорее всего, вы получите ответ про конкретный класс, и даже очень удивитесь (ложно-позитивно), как много кандидаты знают про его устройство.
Если хочется понять как человек думает на примере хеш-*, наводящие вопросы типа "Существует ли быстрый способ понять, что две строки не равны, явно не сравнивая их содержание? Является ли этот способ безопасным в 100% случаев? А чтобы понять, что строки равны?", куда более свободные и открытые к обсуждению, и даже если какой-нибудь джуниор на самом деле не будет знать, что такое хеш-код, но проявит смекалку и придумает свой собственный способ (скорее всего, похожий на хеш!), вы получите куда больше полезной информации о кандидате, чем могли изначально.
Вообще все что вы рассказываете в последнем абзаце — это и есть в моем понимании ответ на вопрос "как работает хешмап". То есть меня интересуют именно принципы и "почему так сделано", а не его конкретное содержание в виде кода, как его написали уважаемые:
тем более что код-то на гитхабе лежит. И я толкую как раз про то, что надо просто так к вопросу и подходить. А не требовать рассказ из учебника, считая близкий к тексту пересказ хорошим ответом. Такой вопрос и такой ответ правда не имеют смысла. Но дьявол как всегда в нюансах.
Вы вообще не поняли смысл статьи. Вам про конкретные проблемы говорят, а вы все про свои хеши
Не проще ли дать задачу и там уж точно будет видно как человек думает?
Задачи занимают много времени, а по области получения полезной информации – ограничены тематикой. Могут быть полезны – безусловно, но проблематика очень сильно разнится от компании к компании, и речь в статье о вредных вопросах на технических собеседованиях, не про подходы найма технических специалистов в целом.
Дать задачу написать хешмап? :) Ну в общем да, так можно конечно, просто это другой подход. Он не лучше и не хуже в целом, он просто другой.
И до этого уровня СУБД вас не допустит.
Ага, ага.
select /*+ MAPJOIN(time_dim) */
SELECT /* LEADING ( v12 v34 )
USE_HASH( v34 )
NO_SWAP_JOIN_INPUTS( v34 ) */Да. Обычные хинты. Которые явно указывают, что вот тут надо использовать хеш джойн (ну или там индекс, бла-бла-бла). Это же именно тот уровень, про который вы говорите, что СУБД меня не допустит, разве нет?
Я вам больше скажу, в спарке вообще API есть, то есть это может быть обязательное указание, а не хинт.
А уж все кто читает планы запросов — просто обязаны понимать, какой именно способ джойна выбран, и какой лучше.
Я вполне соглашусь, что очень многие до такого уровня не добираются, но это скорее говорит об их квалификации (или специализации), а не о том, что никому не нужно понимать, чем хеш джойн отличается inner loop, условно. У нас вот данных за 20Пб перевалило, у много кому такое нужно.
Вообще ни разу не нашёл в жизни работу по собеседованию. Один раз за 20 лет был на таком собеседовании и понял, что искать работу так я не буду никогда вообще.
Всегда вступал в компании, в которых собеседование проходило так:
"Ты программист?"
"Да, могу на C# и golang"
"Отлично. Вот проект, у тебя месяц испыталовка. Если покажешь что можешь писать, ты нанят."
Всё.
Это освобожлало жизнь от ненужных интервью. Все прекрасно понимают, что мне не надо устраивать цирк с клоунами, чтобы попытаться показать, что знание О нотации будет иметь хотя бы отдалённое отношение к моей работе. Более того, при таком подходе ты отсекаешь бесконечные траты на HR, и приступать к работе можешь на следующий день.
20 лет программирую. 20 лет так и было. Хотя нет, на первой работе было собеседование. 15 минут, просто поспрашивали вопросы и наняли. Но там всё понятно было. Малёк из универа.
Сейчас я сам нанимаю себе людей, и прекрасно понимаю, что следить надо не за синтетическими KPI, а за наличием результата. Никакая метрика не покажет вам, хорошо ли написана программа. Только результат работы этой программы.
Конечно, при таком подходе надо понимать, что свеженанятых не надо ставить на "самый важный и сверхсекретный проект". Дать им песочницу, пусть напишут утилиту и всё такое. Подкинуть пару задач посложнее, посмотреть как справятся. Кто-то отлично справляется. Это хорошо. Кто-то честно приходит и просит о помощи - это хоршо. Кто-то замыкается и не говорит ни о чём. Это - плохо. А кто-то врёт и вешает лапшу на уши. С такими после месяца - байбай.
Всё. Есть результат - да хоть на голове стой и пиши, махая палочкой, я тебе буду платить. Нет результата - хоть буть ты трижды сертифицирован самим Билом Гейтсом и Стивом Джобсом, пусть у тебя Столлман во френдах в Линкедине, пусть тебя на работу возит Страуструп, ты мне не нужен.
А то приходят, обвешанные сертификатиками как современные генералы медальками. Все эти литкоды и хакерранки можно получить немного погуглив. А вот собрать нормальное приложение, а потом показать что ты можешь его менять и обновлять, да ещё и пишешь его так, как нам надо - этого никто никогда не отменит.
Главное в кандидате - это способность учиться.
Более того, при таком подходе ты отсекаешь бесконечные траты на HR, и приступать к работе можешь на следующий день.
С такими после месяца - байбай
Был такой мемасик. Одна минута планирования экономит 10 минут исполнения. Но верно и обратное, 10 минут исполнения экономит минуту планирования!
Зачем тратить дни HR'ов, если можно тратить месяцы разработчиков.
Никакая метрика не покажет вам, хорошо ли написана программа. Только результат работы этой программы.
Категорично не согласен. Результат работы программы вообще не показывает, хорошо ли она написана. Хорошо ли программа/фича написана, покажет количество времени, которое придётся потратить на её поддержку (баги, рефакторинг и т.п.).
Разумеется я смотрю только с колокольни долгоживущего продукта. А не проекта, который написал, зарелизил и забыл. Максимум небольшая платная поддержка. В таком случае да, единственное что имеет значение, работает программа или нет. Но я бы не употреблял термин "хорошо написана". Если пациенту сделали операцию, и на следующий день его сбила машина, это не значит, что операция была сделана хорошо. Это значит, что её качество не имело значение.
Я как раз именно так и набираю к себе в команду, технических вопросов вообще не задаю, ну или минимум, смотрю как человек рассказывает о своем опыте, максимально полно рассказываю ему чем мы занимаемся вообще и чем будет заниматься конкретно он, собственно если в целом человек нормальный спрашиваю ну как, справишься? Если да то испыталка 3 мес, за человеком закрепляется наставник и поехали. За 12 лет и наверное полторы сотни кандидатов два не прогедших испыталку. Считаю, отличный показатель
Не мог не пустить скупую мужскую слезу, прочитав ваш комментарий. Ибо как раз в процессе поиска работы и уже не помню в какой раз на собеседованиях диалоги выглядят так:
О, у вас 10лет опыта, но давайте поговорим о типах данных в js...
Иронично, но Я считаю вопрос про словари достаточно полезным.
Ведь для многих вопросов важно не только то, что задают, но и как отвечают.
Как кандидат владеет темой, как говорит и рассуждает.
Это хороший вопрос, потому что люди разных уровне ответят на него по разному - от кейсов использования до глубокого понимания алгоритмов, а с некоторыми кандидатами можно еще и посмеяться про тупые вопросы на собеседованиях.
Отдельно нужно отметить, что Я не ожидаю, что кандидат точно знает ответ на вопрос, более того, Я не всегда знаю идеальные ответы на вопросы, которые задаю.
Лучше проверять не наличие конкретных знаний, а способность их применять.
Можно, например, предложить кандидату на обзор кусок забагованного кода, для починки которого без понимания устройства HashMap не обойтись.
Этот подход хорош еще и возможностью интегрировать несколько проверок.
Мне недавно пришлось синьору(!) объяснять, что такое дополнительный код числа, так как он не понимал, как конвертировать внутреннее бинарное представление decimal между Java и C#. Хотя в обеих языках профи.
Так что порой лучше все же спросить, понимает ли соискатель, как реализован HashMap (или как в памяти могут храниться числа).
А при чем тут C, если поддержка decimal и в C#, и в Java сделана их же средствами, а вовсе не на C?
Проблема, например, в прямых затратах на внутренний проект, так как выставить их заказчику не представляется возможным.
При чем тут double? Double - это уже представление для CPU. А я про decimal, который и в Java, и в C# реализован классами на этих же языках. Соискатель при устройстве на работу заявлял, что может выполнять работу на уровне синьора на Java и C#, а так же обладает профессиональными знаниями gRPC. Но как только между микросервисами на Java и C# потребовалось передать данные в decimal - вообще не смог решить задачу. Я понимаю, что можно забыть о том, что такое дополнительный код. Понимаю, что можно было бы не знать, что в Java и C# разные способы представления decimal. Но раз человек не смог разобраться с этим самостоятельно, то тут уж явно недостаток базовых знаний.
Да, первый раз - случайность. Второй - совпадение. Но третий - уже закономерность. Поэтому если подобное повторится в третий раз, этот сотрудник окажется перед выбором перевода на должность мидла со снижением компенсации или увольнения по собственному желанию.
Внутренне бинарное представление decimal в Java реализовано через класс BigDecimal в котором все значащие цифры числа представлены в виде unscaledValue E -scale, где unscaledValue - строка байтов в дополнительном коде. Тоже самое в C#, но unscaledValue, упрощенно - в виде 64-битного и 32-битного целых чисел в прямом коде, а знак отдельным битом.
В стандарте protobuf нет decimal. Поэтому через gRPC он передается в виде структуры. Так как есть еще и Confluent, то выбрана была структура уже поддерживаемая Connect/Sink из коробки, полностью совпадающая с внутренним представлением в Java. А сотруднику была поставлена задача написать класс на C#, конвертирующий эту структуру в класс Decimal (внутреннее бинарное представление C#) и обратно. Так, уже на пальцах, понятно?
Если это ваша единственная претензия к этому сеньору, то это смешно. Точно также найдется немало людей (возможно, азиатов), которые вздрючат лично вас на темах, в которых вы считаете себя профи.
Не понял, при чем тут вдруг оказались расы. У Вас какие-то личные проблемы?
Во-вторых, при чем тут вздрючат? Вы вообще поняли о чем я писал?
Сотрудник не смог самостоятельно решить задачу на языках, в которых он профи, так как даже не подозревал о существовании дополнительного кода.
А вы точно уверены, что вы способны решить 100% задач в вашей области без советов со стороны? Вы родились профессионалом?
Сначала ответьте на заданные мной вопросы
при чем тут вдруг оказались расы
Вы вообще поняли о чем я писал?
Да. Вы пеняете человеку, что он чего-то не знает.
Сотрудник не смог самостоятельно решить задачу на языках, в которых он
профи, так как даже не подозревал о существовании дополнительного кода
Потому что не родился всезнающим, очевидно. Бывает. Вот я и спрашиваю, каково это - родиться всезнающим и не нуждаться в советах и обучении?
Ссылка не открывается. Так что подозрение Вас в расизме сохраняется.
И не вижу ответа на вопрос о "вздрючат"
Вы подходите к интервью излишне механистично.
Может быть, важно не только то, что человек ответит, а ещё и как? «Звёзд интервью» отличить от «лоулевел задротов» можно, развив беседу.
Проводить собеседование — это не просто зачитывать вопросы и ставить галочки, а потом считать их количество. Галочки — это скрининг, а не собес.
За семь лет коммерческого опыта я прошел около ~350 технических собеседований – от Netflix и Amazon, до Тинькофф и Яндекс, от маленьких СНГ аутсорсов, до road-to-unicorn YC стартапов. К сожалению, текущие реалии сценариев технических собеседований _как раз механистичны_ – об этом и статья. Продукты разные, обязанности разные, технологии разные, кандидаты разные, а вопросы – одни.
"Как" ответит кандидат безусловно важно, но слыша одни и те же шаблонные вопросы из раза в раз от разных интервьюеров, я, честное слово, очень сомневаюсь, что даже самый глубокий интервьюер сумеет корректно оценить ситуацию. Сама статья всем сердцем кричит – уходите в вопросы пошире; развивайте беседу; держите в голове картину кандидата, а не лист и галочки.
Если это не ваша ситуация, я искренне, в хорошем смысле, завидую вашим кандидатам.
Что ж, выходит, спорить нам в общем-то не о чем. Эт хорошо)
Увы, я гораздо больше раз был в шкуре интервьюера, чем интервьюйи. С моей колокольни вопросы одинаковые, а кандидаты прям совсем разные.
Кто-то не дослушает вопрос и бежит отвечать (ладно бы ещё вопрос угадал!). Кто-то пытается засрать эфир терминами. Кто-то спокоен как удав (сразу видно, сеньор). Кто-то начинает воспаляться по поводу того, что вопросы слишком простые для его величества Сеньора (сразу видно, мидл). Кто-то перенервничал, и ему нужны сейчас не подсказки, а кружка чая и 20 минут посидеть. Кто-то ответит на вопрос и ещё и приправит байкой как в 1998 из-за лёгкого подбора коллизий хэшмапа превратилась в односвязный список, и всё прилегло, и как они это искали…
В общем, каждый собес — это что-то личное и уникальное
Это хороший вопрос, который задают джунам и мидлам. Алгоритмы и структуры данных - базисная лекция в западных вузах. Смысл не в том, чтобы посмотреть, знает ли человек внутрянку стд библиотек. Смысл в том, что бы начать интересный диалог, т.к. это колоссально глубокая тема. Там и математика, и логика, и информатика, начиная от самого простого и заканчивая проблемой "реализации" теоретических алгоритмов. А если человек удивил, то можно пойти во всякие кучи, деревья и их влияние на прикладные задачи.
Сорри, но я не понял, о чем эта длинная статья. "Это не только бесполезный, но и вредный вопрос, который противопоказано задавать...". Для кого бесполезный и вредный, кому противопоказано, кто это противопоказал? Если интервьюер задает этот вопрос, значит для него он полезен. Кто не знает, какой профит извлечь из ответа на этот вопрос, значит, не задает его. Или скрытый посыл статьи, что большинство интервьюеров не компетентны? Тогда это лучше в какой-нибудь телеграм-чат с пятничным флеймом.
P.S. Для статистики могу сказать про себя. Я никогда не задаю впрямую вопрос об устройстве HashMap, НО обычно один из моих вопросов неявно подразумевает знание этого механизма. И я точно знаю, зачем я это делаю и какие рассуждения я хотел бы услышать от интервьюируемого, особенно на синьорскую позицию.
Сорри, но я не понял о чем этот длинный коментарий. "Сорри, но я не понял, о чем эта длинная статья..." Для кого бесполезая и вредная, кому противопоказано, кто это противопоказал? Если читатели комментирюут эту статью, значит для них она полезна. Кто не знает, какой профит извлечь из этой статьи, значит, не комментирует. Или скрытый посыл комментария, что большинство авторов не компетентны? Тогда это лучше в какой-нибудь телеграм-чат с пятничным флеймом.
P.S. Для статистики могу сказать про себя - вот это единственный смысл комента, что я нашел )) Поделиться какой я классный на фоне остальных
Меня на прошлой неделе интервьюер спросил про хэш-мапу и про то, в какой ситуации элемент может "потеряться". Эдакая угадайка) Я указал ему, что он "наверное" имел в виду HashSet и изменение полей, входящих в hash. Я сам много лет проводил собеседования, и проходил собеседования не один десяток раз, и знал этот пример хорошо. Лучше интервьюера) Сам никогда не спрашивал, как то неинтересно что ли.
Реквием по «Расскажи, как работает HashMap?»