Недавно у меня было телефонное собеседование, на котором мне задавали разнообразные вопросы по Java. Это стандартное собеседование и большинство вопросов тоже было вполне стандартным:
-
Что такое полиморфизм?
-
В чём разница между List и Set? Когда стоит использовать первое, а когда второе?
-
Где можно столкнуться со взаимной блокировкой (deadlock)?
-
В чём разница между строгой и слабой типизацией?
В основном вопросы были вполне закономерными. Лично мне не нравится вопрос про полиморфизм, ведь он настолько тесно связан с большинством объектно-ориентированных языков и наследованием, что большинство людей используя его (например, при переопределении или перегрузке метода) даже не думают «О! Это же полиморфизм в действии!». Вместо этого я бы задал вопрос «Что такое наследование и где оно используется», потому что в большинстве объектно-ориентированных языков для него есть ключевое слово или паттерн. Но это уже мои личные предпочтения и я вполне понимаю логику проводившей собеседование компании.
Вопрос про строгую и слабую типизацию был немного необычным, потому что мой собеседник на самом деле имел в виду контроль типов, а не строгость типизации, поэтому немного удивился, когда я сказал, что в C слабая статическая типизация, в Java — строгая статическая, а в Python — строгая динамическая (я считаю, что в JavaScript используется слабая динамическая, но говорить об этом не стал).
Однако вслед за этими вопросами последовали «нановопросы»:
-
В каком пакете находится List?
-
В каком пакете находится File?
-
При помощи какого ключевого слова выполняется наследование?
(Ещё там были «стандартные вопросы для собеседований типа «где вы видите себя через пять лет» и так далее.)
Расс Олсен говорит, что у «нановопросов» есть два последствия:
Кроме того, что они практически ничего не говорят о кандидате, эти крошечные вопросы имеют два реальных недостатка: во-первых, они занимают время, которое вы могли потратить на то, чтобы лучше узнать человека и понять, достаточно ли он умён, есть ли у него необходимый опыт и впишется ли он в вашу команду. Во-вторых, подобные вопросы отпугивают именно тех умных, разносторонних людей, которых вы и хотите нанять.
Я правильно ответил на эти нановопросы, но могу сказать, что у них есть ещё и третий недостаток: нановопросы могут привести к ложноотрицательным отказам тем, кто во всём остальном идеально подходит вашей компании.
Хороший инженер мыслит абстрактно, на языке проектирования и создания систем, на языке алгоритмов, компонентов и технического проектирования. Он необязательно знает все подробности синтаксиса конкретного языка, особенно если привык к качественной IDE, которая помогает ему в этом (я пользуюсь Eclipse: ввожу List, а затем нажимаю control-space, чтобы загрузить java.util.List). Важнее понять, какой пакет мне нужно использовать, чем помнить его название.
Аналогично, важнее то, чтобы я мог сказать, где нужно использовать наследование, а где полиморфизм, чем формулирование их определений.
По сути, любой вопрос, на который можно в течение пяти секунд ответить при помощи Google/ChatGPT — плохой вопрос. Мой любимый вопрос телефонных собеседований: «Какой язык вы любите больше всего? Какие у него есть слабые стороны?»
Однако на многих собеседованиях и многих экзаменах вас, по сути, проверяют, насколько хорошо вы сможете заменить компилятор. Даже экзамены на получение сертификата по Java склонны делать упор на вопросы о синтаксисе и компиляции вместо вопросов о том, насколько хорошо вы умеете программировать и проектировать системы.
Я хороший инженер, а не хороший компилятор. Я не могу посмотреть на фрагмент кода и сразу же сказать, в чём его проблема и не выдаст ли он ClassNotFoundException, за меня это делает компилятор. Если не сразу же, то, по крайней мере, тогда, когда я попробую скомпилировать код. Означает ли это зависимость от IDE? Возможно, но это необязательно плохо, ведь IDE — один из инструментов, которые мы используем в повседневной работе.
Автор:
PatientZero
