Термины и понты: как оценивать опыт специалиста?

Один мой коллега, перейдя на работу в другую компанию, как-то с сожалением констатировал, что чувствует себя в новой команде "полным нубом". Далее между нами произошёл такой диалог:

Я: Что заставляет тебя оценивать себя так скромно?

Коллега: Меня окружают очень опытные люди.

Я: Почему ты так решил?

Коллега: По их разговорам и используемым терминам. Многие из терминов я просто не знаю...

Этому разговору можно было бы не придавать значения, если бы не обсуждения на программерских форумах, посвящённые тому, как оценивать квалификацию программиста, и не мой интерес к этому вопросу.

Предыдущие публикации и обсуждения смотрите здесь:

Первая публикация

Вторая публикация

Обсуждение

Зададимся вопросом: А как инженеры оценивают квалификацию других инженеров?

При помощи тестовых заданий и грамотных вопросов на собеседовании? Не только.   Реплика моего коллеги показывает, что немаловажную роль играют терминология и характерные речевые обороты.

Чтобы подтвердить эту мысль, приведу другой пример. Недавно один мой коллега "обиделся" на меня: "Почему ты всё время говоришь "анриэловский движок"? Этим ты как бы принижаешь его роль. У тебя получается, что будто бы это движок одной игры - Unreal Tournament. Правильнее говорить Unreal Engine!"

Неправильная профессиональная терминология режет слух и часто заставляет усомниться в квалификации специалиста.

С другой стороны, квалифицированных программистов не так много, и оценивать опыт исключительно по терминологии (а иногда - и по понтам), на мой взгляд, неразумно. Это открывает широкие возможности для слабо образованных специалистов - достаточно лишь поднабраться правильных терминов.

Другой мой коллега является мастером по прохождению собеседований. Сразу скажу, что, помимо этого, он ещё и является хорошим специалистом. Как-то в разговоре он поделился секретом своего успеха: на многие типовые вопросы, которые задают на собеседованиях, у него заготовлены типовые ответы. Важное замечание: эти ответы составлены терминологически правильно - так, что создают у собеседующего правильное впечатление.

Например, на вопрос "Что такое программная архитектура?" мой коллега имеет заготовленный ответ - "Это набор функциональных компонентов и взаимосвязей между ними".

Честно признаюсь, звучит красиво. ;)

Выше я писал, что оценивать опыт специалиста исключительно по правильным словам, которые он говорит, неразумно. Попробую предложить для оценки квалификации другие критерии, на мой взгляд, более инструментальные.

Критерий 1: количество завершённых коммерческих проектов.

Сразу скажу, не интересуют демо-версии, программы, написанные для души, курсовые и дипломные работы.

В жёстком варианте следует учитывать только те программы, которые были не только сделаны, но и поступили в продажу (для продуктовых разработчиков) или установлены и используются клиентом (для разработчиков, пишущих софт на заказ).

В мягком варианте можно учитывать программы, которые были сделаны до конца, но не были выпущены не по вине разработчика (например, в связи с банкротством издателя).

Критерий 2: вес/объём каждого из выпущенных проектов.

Важно понимать, о проектах какой сложности идёт речь.

Сложность можно оценивать по трудозатратам. Но не по фактическим (т.к. при плохой организации разработка даже самой простейшей программы может занять месяцы и годы), а по нормативным (важно оценить, за какое время и какими силами такой проект может быть сделан).

Критерий 3: вклад специалиста в каждый проект.

Если целиком проект оценить в 100%, то какая часть из этого реализована собеседуемым специалистом?

Если пользоваться приведёнными критериями, то опыт можно посчитать по формуле:

Опыт = Сумма_по_всем_проектам (Вес_проекта * Вклад_специалиста)