Я не заметил такого. Тестирование это понятно - есть хороший тест, есть не очень, есть покрытие. Мысль, что вопрос для интервью может быть плохим и не адекватным - явление намного более редкое.
Да, согласен. Я, если честно, не помню уже что там ценится в России. Цель была показать что различия есть в принципе.
Разве это не базовые знания? На этих вопросах можно проверить понимание зачем нужен hashcode, основы оптимизации. Даже если человек все заучил - подловить его можно. А если так заучил, что не подловишь - значит он это понял)
Я начну с конца. Если у вас цель "подловить" на интервью, то вы не там работаете. Вам бы в полицию!) Если же он "заучил", то зачем его ловить? Разве есть какой-то другой способ узнать как работает Hashmap, кроме как "заучить"? Но в целом просто знание Hashmap, как и любого другого алгоритма, имеет только академический интерес (а этот вопрос ничего другого и не дает узнать). Мы не узнаем, знает кандидат что-то еще. Мы не узнаем умеет ли он применять Hashmap. И тем более не узнаем может ли кандидат распознать ситуации, не вполне очевидные, когда следует применить Hashmap или другую структуру или как-то все это скомбинировать или как-то по-другому использовать знания о том как работает Hashmap. (например, в задаче про поиск строки в подстроке) Цель интервью ведь не вопрос задать и получить на него правильный или не правильный ответ. Цель интервью и вопросов - узнать кандидата, узнать его способности, узнать что он умеет и знает. Сосредотачиваться нужно не на вопросе, а на то что вы хотите узнать о человеке, и потом уже подбирать под это вопрос. Касательно Hashmap, спросите лучше как решить ту или иную проблему, где нужен Hashmap и сразу многое узнаете, не только про то знает ли кандидат устройство какой-либо конкретной реализации.
Хотя бы в том, что в индустрии теперь сложно встретить человека не знающего наиболее популярные алгоритмы и структуры данных. Теперь не нужно их учить на onboarding :)
Не тоже самое. Там другая система и работает она по-другому. Но я не об этом говорю. Суть в том, что зарплата 2x это не самое главное в FAANG. У них интересная система мотивации, конечно, но я оставил это за рамками статьи, т.к. писал о найме. Кроме того, эта система мотивации очень сильно завязана на особенности самих США, без знания который вы просто не поймете как это работает.
Я не сравниваю FAANG с российскими аналогами. Я даже так и пишу в статье "не копируйте". Смысл статьи в том, и это вынесено во введение, чтобы показать проблемы найма в России. Типа, вот там люди видят эти проблемы и вот так вот решают, а тут, не редко, даже проблему разглядеть не могут. Яркий пример: где-то читал, как один "эксперт в собеседованиях" провел более сотни интервью и не предложил ни одного человека к найму. Мысли о том что что-то не так с процессом у него даже не зародилось, вся вина была возложена на низкий уровень кандидатов.
Еще раз, копировать FAANG никто не предлагает - предлагают критически посмотреть на процесс найма в России. Отказываться от этого только на основании "тут не FAANG" мне кажется глупым.
Я в другой ветке ответил в целом и тут мне можно не отвечать. В ядре линукса, например, нет GC, а перфоманс есть. И еще тонна мест где GC нет, а перфоманс есть. И что с этим делать? Вот нанимая перфоманс инженера в HotSpot ( да хоть и в node.js) вы его будете спрашивать об устройстве и особенностях перфоманса ОС или какой-то специфичный алгоритм GC?
пригодится минимальное понимание GC и знание размеров примитивов и объектов
Приобрести которые, по вашему же утверждению, дело одного вечера. Так стоит ли на такую мелочь тратить драгоценное время на интервью? Спор уже выходит за тему статьи и не имеет собственной цели, как мне кажется. Предлагаю пожать руки и согласиться не соглашаться ?
Ну вот видите, сами же и говорите что в случае чего, это "один вечер" почитать. Так стоит ли с упорством, достойным лучшего применения, задавать этот вопрос на интервью? В целом я не хотел вдаваться в спор насколько ценен этот вопрос. Суть в том что этот вопрос задавал каждый второй, потому он и попал в топ. При том что задавали его независимо от позиции и компании. Хуже того, не в обиду, но ваш пример это показывает, что многие даже не задумываются зачем они задают этот вопрос, что хотят выяснить и дает ли этот вопрос возможность выяснить то что они хотят. И это проблема. Возможно, есть какая-то, узкая и очень специфичная позиция, где этот вопрос действительно имел бы существенную ценность. Возможно, что у вас она именно такая. Однако, для 90% остальной индустрии это не так.
"Чтобы знать в общих чертах как работает гц " - сколько времени займет прочитать книжку и пересказать? Неделя? "достаточно один раз потюнить или порешать серьезную проблему на проде" - сколько времени вы тратите на изучение ключей и проверку по сравнению с книжкой про GC? Я уж молчу что подкрутка ключей это вообще другая специальность, особенно в проде. "серьезную проблему на проде" - какой процент проблем в проде были именно из-за GC и которые были решены изменением кода с применением знаний алгоритмов GC определенной конкретной VM (реч про java?) ? "человек любопытный" - как вы считаете, есть ли другой, способ узнать о любопытстве человека? И почему вы считаете что вопрос про GC говорит о любопытстве человека? "короткого скрининга лучше подходят стандартные вопросы с ожидаемыми ответами" - а резюме не достаточно? Откройте и спросите что-то вроде: "вот у вас написано <название проекта>, меня заинтриговала эта строчка, не могли бы рассказать по-подробнее". Время займет столько-же сколько рассказ про GC, но информации вы получите на порядок больше.
Во-первых это близоруко, так лидерами не становятся. Нельзя ждать пока кто-то пнет. Во-вторых, так вот почему у них так испортился поиск и карты на андройде никак не могут подружиться с permissions. И потом, HR у Яндекса настолько хорошо скрывает их корпоративные стандарты, что я узнал об их существовании от вас. ?
Я не очень понимаю. Что вы хотите сказать? Сначала говорите что "Это не взгляд оттуда" , потом "Откуда такое утверждение?". У вас есть другой вариант процесса? Опишите его.
"Задачи на кодинг/алгоритмы/системный дизайн и прочее, выделяется час-два времени, за которые кандидат в стрессе должен что то сделать." - задача интервьюера минимизировать стресс. Проводит интервью это особый скилл, и не каждый инженер автоматически способен это делать. Это одна из основных причин почему написана статья - учитесь проводить интервью.
"как человек размышляет над задачей" - это не софт-скилл. Вот донести размышления до кого угодно - это софт-скилл. Перед интервью спрашивают на наличие различных инвалидностей и соответственно пытаются подстроиться, так что заикание не проблема.
IBM - отстой, она свой век доживает, я думаю. MS - оборонные госконтракты, META - чисто политическая история.
Впрочем, это все оффтопик.
Я не заметил такого. Тестирование это понятно - есть хороший тест, есть не очень, есть покрытие. Мысль, что вопрос для интервью может быть плохим и не адекватным - явление намного более редкое.
Да, согласен. Я, если честно, не помню уже что там ценится в России. Цель была показать что различия есть в принципе.
Я начну с конца. Если у вас цель "подловить" на интервью, то вы не там работаете. Вам бы в полицию!) Если же он "заучил", то зачем его ловить? Разве есть какой-то другой способ узнать как работает Hashmap, кроме как "заучить"?
Но в целом просто знание Hashmap, как и любого другого алгоритма, имеет только академический интерес (а этот вопрос ничего другого и не дает узнать). Мы не узнаем, знает кандидат что-то еще. Мы не узнаем умеет ли он применять Hashmap. И тем более не узнаем может ли кандидат распознать ситуации, не вполне очевидные, когда следует применить Hashmap или другую структуру или как-то все это скомбинировать или как-то по-другому использовать знания о том как работает Hashmap. (например, в задаче про поиск строки в подстроке)
Цель интервью ведь не вопрос задать и получить на него правильный или не правильный ответ. Цель интервью и вопросов - узнать кандидата, узнать его способности, узнать что он умеет и знает. Сосредотачиваться нужно не на вопросе, а на то что вы хотите узнать о человеке, и потом уже подбирать под это вопрос.
Касательно Hashmap, спросите лучше как решить ту или иную проблему, где нужен Hashmap и сразу многое узнаете, не только про то знает ли кандидат устройство какой-либо конкретной реализации.
Зато у нас сразу видно что люди делом занимаются, а не проталкивают свой хлам, ха-ха).
Хотя бы в том, что в индустрии теперь сложно встретить человека не знающего наиболее популярные алгоритмы и структуры данных. Теперь не нужно их учить на onboarding :)
Не тоже самое. Там другая система и работает она по-другому. Но я не об этом говорю. Суть в том, что зарплата 2x это не самое главное в FAANG. У них интересная система мотивации, конечно, но я оставил это за рамками статьи, т.к. писал о найме. Кроме того, эта система мотивации очень сильно завязана на особенности самих США, без знания который вы просто не поймете как это работает.
Я не сравниваю FAANG с российскими аналогами. Я даже так и пишу в статье "не копируйте". Смысл статьи в том, и это вынесено во введение, чтобы показать проблемы найма в России. Типа, вот там люди видят эти проблемы и вот так вот решают, а тут, не редко, даже проблему разглядеть не могут.
Яркий пример: где-то читал, как один "эксперт в собеседованиях" провел более сотни интервью и не предложил ни одного человека к найму. Мысли о том что что-то не так с процессом у него даже не зародилось, вся вина была возложена на низкий уровень кандидатов.
Еще раз, копировать FAANG никто не предлагает - предлагают критически посмотреть на процесс найма в России. Отказываться от этого только на основании "тут не FAANG" мне кажется глупым.
Я в другой ветке ответил в целом и тут мне можно не отвечать.
В ядре линукса, например, нет GC, а перфоманс есть. И еще тонна мест где GC нет, а перфоманс есть. И что с этим делать? Вот нанимая перфоманс инженера в HotSpot ( да хоть и в node.js) вы его будете спрашивать об устройстве и особенностях перфоманса ОС или какой-то специфичный алгоритм GC?
это так
Приобрести которые, по вашему же утверждению, дело одного вечера. Так стоит ли на такую мелочь тратить драгоценное время на интервью?
Спор уже выходит за тему статьи и не имеет собственной цели, как мне кажется. Предлагаю пожать руки и согласиться не соглашаться ?
Ну вот видите, сами же и говорите что в случае чего, это "один вечер" почитать. Так стоит ли с упорством, достойным лучшего применения, задавать этот вопрос на интервью?
В целом я не хотел вдаваться в спор насколько ценен этот вопрос. Суть в том что этот вопрос задавал каждый второй, потому он и попал в топ. При том что задавали его независимо от позиции и компании. Хуже того, не в обиду, но ваш пример это показывает, что многие даже не задумываются зачем они задают этот вопрос, что хотят выяснить и дает ли этот вопрос возможность выяснить то что они хотят. И это проблема. Возможно, есть какая-то, узкая и очень специфичная позиция, где этот вопрос действительно имел бы существенную ценность. Возможно, что у вас она именно такая. Однако, для 90% остальной индустрии это не так.
"Чтобы знать в общих чертах как работает гц " - сколько времени займет прочитать книжку и пересказать? Неделя?
"достаточно один раз потюнить или порешать серьезную проблему на проде" - сколько времени вы тратите на изучение ключей и проверку по сравнению с книжкой про GC? Я уж молчу что подкрутка ключей это вообще другая специальность, особенно в проде.
"серьезную проблему на проде" - какой процент проблем в проде были именно из-за GC и которые были решены изменением кода с применением знаний алгоритмов GC определенной конкретной VM (реч про java?) ?
"человек любопытный" - как вы считаете, есть ли другой, способ узнать о любопытстве человека? И почему вы считаете что вопрос про GC говорит о любопытстве человека?
"короткого скрининга лучше подходят стандартные вопросы с ожидаемыми ответами" - а резюме не достаточно? Откройте и спросите что-то вроде: "вот у вас написано <название проекта>, меня заинтриговала эта строчка, не могли бы рассказать по-подробнее". Время займет столько-же сколько рассказ про GC, но информации вы получите на порядок больше.
Определенно, вопрос про GC, ничего не скажет вам о том как человек работает в сфере перфоманса. Ни положительный, ни отрицательный.
Про "не готов учить" имелось ввиду что человек должен сам обучиться. Никто не будет ходить следом и разжевывать.
Во-первых это близоруко, так лидерами не становятся. Нельзя ждать пока кто-то пнет.
Во-вторых, так вот почему у них так испортился поиск и карты на андройде никак не могут подружиться с permissions.
И потом, HR у Яндекса настолько хорошо скрывает их корпоративные стандарты, что я узнал об их существовании от вас. ?
Я не очень понимаю. Что вы хотите сказать?
Сначала говорите что "Это не взгляд оттуда" , потом "Откуда такое утверждение?". У вас есть другой вариант процесса? Опишите его.
А почему они у всех на слуху, как думаете?
"Задачи на кодинг/алгоритмы/системный дизайн и прочее, выделяется час-два времени, за которые кандидат в стрессе должен что то сделать." - задача интервьюера минимизировать стресс. Проводит интервью это особый скилл, и не каждый инженер автоматически способен это делать. Это одна из основных причин почему написана статья - учитесь проводить интервью.
"как человек размышляет над задачей" - это не софт-скилл. Вот донести размышления до кого угодно - это софт-скилл. Перед интервью спрашивают на наличие различных инвалидностей и соответственно пытаются подстроиться, так что заикание не проблема.
Образование (высшее) это больше про знание и там проверяют только насколько усвоил те знания и немного навыки, какие дают. Опыт там получить сложно.