Советы не⁠технарям: как отличить грамотного разработчика по 5 признакам

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

Казалось бы, даже мне, с дипломом технического вуза и солидным опытом разработки, ошибиться крайне сложно, но и такое случается. Если же речь о людях, далёких от IT, тем более это становится задачкой со звёздочкой.

Почему? Потому что многие «IT⁠-⁠гуру» умеют производить впечатление: сыплют терминами, уверенно рассказывают о каких⁠-⁠то космических технологиях — и вот владелец бизнеса уже очарован. А потом, к сожалению, часто выясняется, что за громкими словами ничего не стоит.

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

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

В этой статье я поделюсь этими наблюдениями. Рассмотрим конкретные признаки грамотного разработчика (по ним же легко вычислить и балабола), приведу пару реальных историй из практики и в конце вы найдете чек⁠-⁠лист для не⁠-⁠технарей. Постараюсь писать живо и по делу, без занудства — надеюсь, "коллеги по цеху" тоже оценят.

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

Объясняет сложные вещи простым языком. Хороший разработчик способен донести техническую суть понятными словами. Если вы спрашиваете, как будет работать система, он не станет грузить вас тонной непонятного жаргона. Вместо этого объяснит «на пальцах», используя аналогии или просто человеческий язык. Это признак глубокого понимания: человек сам настолько разобрался в вопросе, что может кратко и ясно изложить его даже далёкому от технологий собеседнику.

А вот пустослов обычно прячется за умными терминами. Он может говорить красиво, но после его объяснений вы чувствуете себя ещё более запутавшимся.

Например, вы спросили, справится ли сайт с наплывом пользователей, ожидая услышать что⁠-⁠то вроде «добавим серверы и оптимизируем код». Вместо этого кандидат выдает: *«Мы задействуем кластеризацию инстансов с балансировкой и горизонтальное масштабирование инфраструктуры»*. Звучит внушительно, вот только ясности вам это не прибавило. Если разработчик реально грамотный, он найдёт способ объяснить даже сложную архитектуру простыми словами, не заставляя вас гуглить каждое второе слово.

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

Например: «В последнем проекте я разработал модуль оплаты для интернет-магазина и сократил время обработки транзакций с 5 до 1 секунды». Или: «Отвечал за внедрение системы мониторинга — после её запуска количество инцидентов снизилось на 30%». Такие детали внушают доверие: видно, что человек не просто числился в команде, а реально добивался результатов.

Пустослов же обычно ограничивается общими фразами. В его рассказе много громких слов («участвовал в создании высоконагруженной инновационной платформы»), но если копнуть глубже — непонятно, что конкретно он сделал и какую пользу это принесло.

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

Честно признаёт, если чего⁠-⁠то не знает. Никто не знает всего на свете, особенно в IT, где технологий море. Грамотный разработчик это понимает.

Если задать ему вопрос вне зоны его опыта, он прямо скажет: «не сталкивался, но готов разобраться». Такой ответ куда лучше, чем беспочвенное уверение во всезнании. Настоящий профи не боится признать пробел в знаниях, потому что уверен в своём умении быстро учиться и восполнять недостаток информации.

А вот кандидат, который на любой вопрос отвечает без паузы и заявляет, что знает абсолютно всё на свете — повод насторожиться. Скорее всего, вы имеете дело с тем самым болтуном, который лучше соврёт, чем покажет свою неосведомлённость.

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

Дает реалистичные оценки и не обещает невозможного. Опытный разработчик обычно осторожен в обещаниях. Услышав описание вашего проекта, он не станет сразу кричать: «Легко, сделаем за неделю!». Скорее, уточнит детали и даст взвешенную оценку сроков и сложности.

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

Пустослов же, напротив, склонен обещать чудеса. Он мгновенно соглашается со всеми сроками и требованиями и уверяет, что проблем не возникнет. Фраза «вообще без проблем, всё сделаю в лучшем виде очень быстро» — типичный сигнал чрезмерного бахвальства.

Как правило, такие люди не укладываются в обещанное: сроки сдвигаются, качество страдает, внезапно находятся «непредвиденные сложности». В результате вы теряете время, деньги и терпение.

Поэтому лучше доверять тому, кто с самого начала настроен реалистично, пусть это и звучит не так привлекательно. Как говорится, "семь раз отмерь — один отрежь": спокойная оценка вначале сэкономит много нервов потом.

Думает о вашей задаче, а не о том, чтобы блеснуть знаниями. Для толкового разработчика технологии — всего лишь инструменты для решения вашей бизнес-задачи. Он не станет усложнять там, где можно сделать проще.

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

Пустословый же «специалист» часто помешан на «понтах». Ему важно произвести впечатление эрудицией, даже если это не помогает делу.

Такой человек может с порога заявить, что вам "обязательно" нужна блокчейн-платформа или сверхсложный AI⁠-⁠алгоритм для совершенно простого приложения. Складывается ощущение, что он решает свои инженерные амбиции, а не вашу бизнес-проблему. Бывает и иначе: кандидат знает один инструмент и пытается применять его ко всем задачам подряд, не утруждая себя поиском лучшего решения.

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

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

Один из наших клиентов (назовём его Алексей) столкнулся с такой ситуацией на собственном опыте. Алексей — предприниматель, не технарь, у него небольшой бизнес, и он решил разработать мобильное приложение для своих клиентов.

По знакомству нашёлся «опытный разработчик», который уверенно обещал сделать всё быстро и недорого. Кандидат сыпал умными терминами, заверял, что у него "всё под контролем", и Алексей ему поверил.

Первые пару месяцев шла активная переписка и созвоны. Программист уверенно рапортовал о прогрессе, хотя реального продукта Алексей так ни разу и не увидел.

Каждый раз, когда заказчик спрашивал, можно ли посмотреть хоть какой⁠-⁠то прототип, исполнитель выдавал технические объяснения: мол, «ещё нужно допилить архитектуру, настроить серверную часть, интегрировать сложный алгоритм». Звучало солидно, и Алексей особо не настаивал — он же не разбирается, решил доверять эксперту.

Спустя три месяца стало ясно, что что⁠-⁠то не так: приложение так и не заработало как нужно, половина обещанных функций отсутствовала или сломана. Алексей обратился ко мне, чтобы моя команда провела аудит кода и помогли понять, в чём дело.

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

Нам пришлось экстренно подключать свою команду. Мы частично переписали приложение с нуля, исправили критические ошибки и довели проект до рабочего состояния. Время и бюджет, потраченные на того «специалиста», конечно, не вернуть. Зато этот случай наглядно показал разницу: изначально Алексей сделал выбор, поддавшись красивым речам и нереалистичным обещаниям — и потерял несколько месяцев впустую.

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

В противовес первой истории есть и положительный пример. Один знакомый предприниматель (пусть будет Дмитрий) планировал запустить онлайн-сервис и выбирал, кого нанять для разработки. У него было два кандидата.

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

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

Что вышло? «Волшебник», обещавший чудеса, так и не получил шанса их не выполнить — вместо него за работу взялся вдумчивый разработчик. Он сразу разбил проект на этапы и помог Дмитрию сфокусироваться на главном.

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

Сам Дмитрий позже признавался, что поначалу сомневался в таком «медленном» подходе — уж очень хотелось всё и сразу. Зато в итоге он был благодарен разработчику за профессионализм: тот фактически спас его от собственных нереалистичных ожиданий. История отлично демонстрирует: порой лучший специалист — это как раз тот, кто обещает меньше, но делает больше.

Подытожим. Ниже — несколько практических рекомендаций для не⁠-⁠технического руководителя, которые помогут распознать профессионального разработчика (и вычислить пустого болтуна) ещё на этапе общения:

• Попросите объяснить техническую идею простыми словами. Попросите кандидата рассказать, как он реализует какой⁠-⁠то аспект проекта, максимально понятным языком. Если вместо внятного объяснения слышите сплошной поток непонятного жаргона — повод насторожиться.
• Спросите о конкретном опыте и достижениях. Пусть претендент подробно опишет проект, которым больше всего гордится: что именно он делал и какого результата добился. Размытые общие ответы без деталей должны вас насторожить.
• Обратите внимание, задаёт ли кандидат вопросы о ваших задачах. Хороший разработчик сначала старается разобраться в том, что нужно бизнесу, и уточняет требования. Если же собеседник говорит только о себе и своих технологиях, не вникая в суть вашего проекта — тревожный сигнал.
• Узнайте, как он действует в незнакомых ситуациях. Например, спросите: «Что вы будете делать, если для решения задачи понадобится технология, с которой вы раньше не работали?». Грамотный кандидат ответит примерно так: «сначала почитаю документацию, изучу примеры, попробую небольшой прототип…». А вот самоуверенный «супермен» без раздумий заявит, что ему и так всё понятно. Делайте выводы.
• Осторожно относитесь к слишком радужным обещаниям. Если разработчик заверяет, что сделает сложный проект «очень быстро, дёшево и без проблем» — стоит усомниться. Опытные профессионалы так не говорят: они всегда оговаривают риски и условия успеха.
• Попросите показать демо предыдущих работ. Добросовестный специалист обычно может предъявить хотя бы небольшой фрагмент кода или работающий пример из своего портфолио (либо подробно рассказать о них, если всё под NDA). Главное — увидеть, что за словами стоят реальные результаты.
• Не пренебрегайте рекомендациями. Если есть возможность, свяжитесь с бывшими работодателями или клиентами кандидата. Узнайте из первых рук, как он показал себя в деле. Живой отзыв намного ценнее самых красивых рассказов на собеседовании.
• Дайте тестовое задание или устройте испытательный срок. Даже пара дней практической работы покажет, кто умеет писать код, а кто только говорит. Лучше потратить немного времени (и денег) на проверку, чем потом месяцами бороться с последствиями неудачного найма.
• Привлеките технического эксперта на финальной стадии. Не стесняйтесь попросить о помощи знакомого айтишника (могу стать вашим "знакомым айтишником", не стесняйтесь писать) или нанять внешнего консультанта, если сами не уверены в оценке кандидата. Пусть знающий человек пообщается с претендентом, посмотрит на его код или задаст несколько профессиональных вопросов. Лишнее мнение со стороны убережёт от грубой ошибки.

В конечном счёте выбор за вами. Но, вооружившись этими знаниями, вы значительно повышаете шансы найти разработчика, который "делом" докажет свою компетентность, а не только словами. Пусть в вашей команде окажется именно такой человек — и ваш IT⁠-⁠проект тогда обречён на успех (в хорошем смысле).

Удачи в поиске!