Брать или не брать? или Как собеседовать разработчика

Погуглить возможные решения; Попросить помощи у коллег; Задать вопрос на специализированном форуме; Если проблема связана с какой-то коммерческой библиотекой, то обратиться в службу поддержки этой библиотеки; Сообщить своему менеджеру и попросить у него помощи; Если возможно, то вообще не делать эту задачу (изменить требования); Переключиться на другую задачу. Возможно, решение придёт, когда над ним не работаешь; Закопаться в код поглубже, нерешаемых задач нет. Длина такого списка возможных действий определяет способность кандидата работать над такими «нерешаемыми» задачами. Эти задачи не решаются в лоб, поэтому чем больше вариантов может придумать кандидат, тем больше вероятность, что один из них сработает. Особенно хорошо, когда в этом списке есть неочевидные решения (вроде варианта не решать эту задачу). Просто прекрасно, когда кандидат учитывает нетривиальные проблемы, связанные с этими вариантами. Например, просить помощи на форуме можно, только если проблемный код не содержит значимой интеллектуальной собственности (чтобы можно было его разместить в общем доступе). Но кроме того интересно, есть ли у кандидата в ответе варианты попросить у кого-то помощи (у менеджера, у коллег, у экспертов в интернете). Если этого нет, то у кандидата проблемы с коммуникацией.

Как всегда, лучшим способом определить, может ли кандидат быстро учиться, будет просто задать прямой вопрос кандидату: «Предположим вам нужно выучить совершенно новую область для вас (библиотеку распознавания образов, например). Как вы подойдёте к этому?» Хороший ответ

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