За семь лет коммерческого опыта я прошел около ~350 технических собеседований – от Netflix и Amazon, до Тинькофф и Яндекс, от маленьких СНГ аутсорсов, до road-to-unicorn YC стартапов. К сожалению, текущие реалии сценариев технических собеседований _как раз механистичны_ – об этом и статья. Продукты разные, обязанности разные, технологии разные, кандидаты разные, а вопросы – одни.
"Как" ответит кандидат безусловно важно, но слыша одни и те же шаблонные вопросы из раза в раз от разных интервьюеров, я, честное слово, очень сомневаюсь, что даже самый глубокий интервьюер сумеет корректно оценить ситуацию. Сама статья всем сердцем кричит – уходите в вопросы пошире; развивайте беседу; держите в голове картину кандидата, а не лист и галочки.
Если это не ваша ситуация, я искренне, в хорошем смысле, завидую вашим кандидатам.
Задачи занимают много времени, а по области получения полезной информации – ограничены тематикой. Могут быть полезны – безусловно, но проблематика очень сильно разнится от компании к компании, и речь в статье о вредных вопросах на технических собеседованиях, не про подходы найма технических специалистов в целом.
И когда я спрашиваю, как работает HashMap, я ожидаю от человека понимания не того, как устроен конкретный класс (там достаточно много нюансов, которые проще посмотреть в коде, чем зачем-то запоминать), а именно этих принципов.
При такой формулировке в текущих реалиях, скорее всего, вы получите ответ про конкретный класс, и даже очень удивитесь (ложно-позитивно), как много кандидаты знают про его устройство.
Если хочется понять как человек думает на примере хеш-*, наводящие вопросы типа "Существует ли быстрый способ понять, что две строки не равны, явно не сравнивая их содержание? Является ли этот способ безопасным в 100% случаев? А чтобы понять, что строки равны?", куда более свободные и открытые к обсуждению, и даже если какой-нибудь джуниор на самом деле не будет знать, что такое хеш-код, но проявит смекалку и придумает свой собственный способ (скорее всего, похожий на хеш!), вы получите куда больше полезной информации о кандидате, чем могли изначально.
В данном случае – однозначно соглашусь, и к сожалению, это первая ссылка в Google по запросу "java classloader". Уже отослал ребятам на почту письмо с недочетами, но пока безответно
Можем попробовать! Платформа для рисования вообще три шрифта поддерживает – обыкновенный, "нарисованный" (наш основной), и код. В статье все три используются для разных целей, но соглашусь, что нарисованный с первого раза не всем может зайти, что-нибудь придумаем :)
Не секрет, конечно :) Excalidraw.com – простая в использовании, диаграммы получаются достаточно приятные на восприятие, бесплатная версия не лимитирована по количеству элементов, поэтому можно сразу несколько систем в одном файлике совмещать
За семь лет коммерческого опыта я прошел около ~350 технических собеседований – от Netflix и Amazon, до Тинькофф и Яндекс, от маленьких СНГ аутсорсов, до road-to-unicorn YC стартапов. К сожалению, текущие реалии сценариев технических собеседований _как раз механистичны_ – об этом и статья. Продукты разные, обязанности разные, технологии разные, кандидаты разные, а вопросы – одни.
"Как" ответит кандидат безусловно важно, но слыша одни и те же шаблонные вопросы из раза в раз от разных интервьюеров, я, честное слово, очень сомневаюсь, что даже самый глубокий интервьюер сумеет корректно оценить ситуацию. Сама статья всем сердцем кричит – уходите в вопросы пошире; развивайте беседу; держите в голове картину кандидата, а не лист и галочки.
Если это не ваша ситуация, я искренне, в хорошем смысле, завидую вашим кандидатам.
Задачи занимают много времени, а по области получения полезной информации – ограничены тематикой. Могут быть полезны – безусловно, но проблематика очень сильно разнится от компании к компании, и речь в статье о вредных вопросах на технических собеседованиях, не про подходы найма технических специалистов в целом.
При такой формулировке в текущих реалиях, скорее всего, вы получите ответ про конкретный класс, и даже очень удивитесь (ложно-позитивно), как много кандидаты знают про его устройство.
Если хочется понять как человек думает на примере хеш-*, наводящие вопросы типа "Существует ли быстрый способ понять, что две строки не равны, явно не сравнивая их содержание? Является ли этот способ безопасным в 100% случаев? А чтобы понять, что строки равны?", куда более свободные и открытые к обсуждению, и даже если какой-нибудь джуниор на самом деле не будет знать, что такое хеш-код, но проявит смекалку и придумает свой собственный способ (скорее всего, похожий на хеш!), вы получите куда больше полезной информации о кандидате, чем могли изначально.
Вы правы, спасибо за поправку! Исправлю
В данном случае – однозначно соглашусь, и к сожалению, это первая ссылка в Google по запросу "java classloader". Уже отослал ребятам на почту письмо с недочетами, но пока безответно
Можем попробовать! Платформа для рисования вообще три шрифта поддерживает – обыкновенный, "нарисованный" (наш основной), и код. В статье все три используются для разных целей, но соглашусь, что нарисованный с первого раза не всем может зайти, что-нибудь придумаем :)
Не секрет, конечно :) Excalidraw.com – простая в использовании, диаграммы получаются достаточно приятные на восприятие, бесплатная версия не лимитирована по количеству элементов, поэтому можно сразу несколько систем в одном файлике совмещать