Я разработчик, а не компилятор

в 7:27, , рубрики: вопросы на собеседовании, собеседование в IT, собеседования, телефонное интервью
I'm A Developer Not A Compiler

Недавно у меня было телефонное собеседование, на котором мне задавали разнообразные вопросы по 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

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js