Давайте посмотрим на стандартный вопрос по Java, который вы можете задать во время собеседования с инженером.
Что дает данный Java-код?
public static void main(String[] args){
Integer num1 = 100;
Integer num2 = 100;
if(num1 == num2){
System.out.println("num1 == num2");
} else {
System.out.println("num1 != num2");
}
}
}
Отвечать
Он напечатает «num1 == num2». Каждый раз, когда две разные ссылки на объекты сравниваются с использованием «==», значение всегда равно «false». Но здесь из-за целочисленного кеширования числа num1 и num2 автоматически запаковываются. Таким образом, num1 == num2 возвращает «истину». Целочисленное кеширование происходит только для значений от -128 до 127.
Правильно? Неправильный!
Настоящий ответ на этот вопрос следующий: Мне все равно!
Это очень плохой код, который я бы никогда не впустил в свою кодовую базу и сразу отказался бы от проверки кода. Более того, я даже не хочу тратить время на выяснение результата. Просто не сравнивайте объекты с помощью ==, используйте вместо этого equals - это правило облегчает нашу жизнь.
И в том-то и дело: все сложные языковые вопросы касаются странных, неочевидных языковых функций, которые сложно понять, использовать и поддерживать, если вы не потратите на это много времени.
Я не хочу расшифровывать код, я хочу сразу понять, что происходит, с первого взгляда. Не потому, что я ленив (хотя я этого не отрицаю), а потому, что как инженер у меня есть гораздо более важные задачи: приносить пользу для бизнеса. Лучший код - супер-глупый, очевидный и простой (мы все знаем о KISS). Избегание сложных языковых конструкций позволяет вам тратить свое время на бизнес-задачи, а не на синтаксис, позволяет без проблем привлекать разработчиков с разным техническим опытом и в результате не быть привязанным к определенному технологическому стеку.
Так почему компании до сих пор задают эти вопросы?
Удивительно, но существует так много компаний, которые все еще используют эти вопросы во время собеседований. Я настоятельно рекомендую рассмотреть ваше заявление о приеме на работу, если вы столкнетесь с таким вопросом. Есть 4 причины, по которым они это делают. И все они нехорошие.
Мы уверены, что это необходимо
Один из лучших вариантов, с которым вы можете столкнуться, - это то, что они искренне верят, что разработчику важно знать такие вещи, чтобы вносить свой вклад в команду. По моему опыту, способность понимать и писать сложный код не коррелирует со способностью писать чистый и поддерживаемый код. Вообще. Но хоть шанс попасть в команду солидных профессионалов.
Нам просто нужно кое-что спросить
Ситуация чуть хуже, если они делают это только потому, что их процесс найма недостаточно зрел, и эти вопросы задаются не специально, а чтобы как-то восполнить пробел. Риск здесь состоит в том, чтобы попасть в команду, нанятую таким же образом, что потенциально довольно случайно.
У нас есть такой код и нам нужно с ним разобраться
Довольно часто следствием подхода «Знать это необходимо» является то, что со временем ваша кодовая база будет содержать все больше и больше конструкций «супер-умный-только-хакер-может-понять», и вы действительно должны уметь с этим справляться. Ну что, готовы присоединиться к такому проекту?
У нас есть такой код, и он нам нравится!
Худший сценарий. Если они не только считают, что разработчику важно знать такие вещи, но им действительно нравится писать такой код, и они хотят, чтобы вы поступали так же. Забудьте о любой эффективности доставки (потратьте время на разгадку загадок), быстром масштабировании команды (с таким проектом могут справиться только определенные технические гики) и будьте готовы надолго запереться внутри одного технологического стека. Удачи!
Тогда какие хорошие вопросы?
Что ж, это огромная тема! Но в целом, чем ближе процесс собеседования к вашим реальным задачам и проблемам - тем лучше. По крайней мере, вы не удивитесь в первый день, и работодатель и сотрудник будут знать, чего ожидать друг от друга.
