Разберете, че аз съм разработчик, а не компилатор

Наскоро проведох телефонно интервю, на което ми бяха зададени различни въпроси за Java. Това е стандартно интервю и повечето от въпросите също бяха доста стандартни:

• Какво е полиморфизмът?
• Каква е разликата между List и Set? Кога трябва да използвате първото и кога второто?
• Къде можете да срещнете взаимно блокиране (deadlock)?
• Каква е разликата между стриктното и слабото типизиране?

В общи линии въпросите бяха съвсем естествени. Лично на мен не ми хареса въпросът за полиморфизма, защото той е толкова тясно свързан с повечето обектно-ориентирани езици и наследяването, че повечето хора, които го използват (например при пренаписване или претоварване на даден метод), дори не се замислят, че: „О! Това е полиморфизъм в действие!„. Вместо това бих задал въпроса „Какво е наследяването и къде се използва?“, защото повечето обектно-ориентирани езици имат ключова дума или шаблон за него. Но това вече е мое лично предпочитание и аз напълно разбирам логиката на интервюиращата компания.

Въпросът за стриктното и слабото типизиране бе малко необичаен, защото моят интервюиращ всъщност имаше предвид контрола на типовете, а не стриктното типизиране, така че беше малко изненадан, когато казах, че C има слабо статично типизиране, Java има стриктно статично типизиране, а Python има стриктно динамично типизиране (мисля, че JavaScript използва слабо динамично типизиране, но не го споменах).

Тези въпроси обаче бяха последвани от „нано-въпроси“:

• В кой пакет се намира List?
• В кой пакет се намира File?
• Коя ключова дума се използва за извършване на унаследяването?

(Имаше и „стандартни въпроси за интервюта като „къде се виждате след пет години“ и т.н.)

Ръс Олсен казва, че „нановъпросите“ водят до две последствия:

Освен че не ви казват почти нищо за кандидата, тези дребни въпроси имат два реални недостатъка: първо, те отнемат времето, което бихте могли да отделите за по-добро опознаване на човека и да разберете дали е достатъчно умен, дали има нужния опит и дали ще се впише в екипа ви. Второ, подобни въпроси отблъскват точно този тип умни и гъвкави хора, които искате да наемете.

Аз правилно отговорих на тези нано-въпроси, но мога да ви кажа, че те имат трети недостатък: нано-въпросите могат да доведат до фалшиво отрицателни отговори за тези, които иначе са идеални за вашата организация.

Добрият инженер мисли абстрактно, на езика на проектирането и изграждането на системи, на езика на алгоритмите, компонентите и техническия дизайн. Не е задължително той да знае всички детайли на синтаксиса на даден език, особено ако е свикнал с качествен IDE, който му помага в това (аз използвам Eclipse: набирам List и след това натискам control-space, за да зареди java.util.List). По-важно е да разбера кой пакет трябва да използвам, отколкото да запомня името му.

По същия начин е по-важно да мога да разбера къде трябва да използвам наследяване и къде полиморфизъм, отколкото да формулирам техните дефиниции.

По принцип всеки въпрос, на който може да се отговори за пет секунди с помощта на Google/ChatGPT, е лош въпрос. Любимият ми въпрос от телефонно интервю: „Кой е любимият ви програмен език? Какви са слабостите му?“

Въпреки това много интервюта и много изпити по същество ви проверяват доколко добре можете да замените един компилатор. Дори сертификационните изпити за Java са склонни да наблягат на въпроси за синтаксиса и компилацията вместо на въпроси за това колко добре можете да програмирате и проектирате системи.

Аз съм един добър инженер, а не добър компилатор. Не мога да погледна част от кода и веднага да кажа какъв е проблемът му и дали ще доведе до ClassNotFoundException, компилаторът прави това вместо мен. Ако не веднага, то поне когато се опитам да компилирам кода. Означава ли това зависимост от IDE? Вероятно, но това не е непременно нещо лошо, защото IDE е един от инструментите, които използваме в ежедневната си работа.