Как определить хорошего разработчика на собеседовании

Редакция Executive.ru продолжает цикл статей о подборе сотрудников в ключевые отделы компании. Ранее на сайте уже выходили публикации о том, как подбирать менеджера по продажам, как не ошибиться с выбором маркетолога и как определить подходящих кандидатов на роль бухгалтераHR-специалиста и менеджера проектов.

В этот раз мы попросили руководителей IT-компаний рассказать, какие методы помогают им выбирать разработчиков и программистов. На что обращать внимание во время собеседования? Как понять, что кандидат не подойдет или что у него нет опыта? Какие качества оценивать в первую очередь?

Признаки хорошего разработчика

Дмитрий ЗавалишинДмитрий Завалишин, основатель и генеральный директор группы компаний DZ Systems

Хороший разработчик:

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

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

Алексей ОносовАлексей Оносов, основатель компании «Юнисофт»

Хороший разработчик обладает аналитическим мышлением и должен уметь:

  • Разбивать сложные задачи на простые подзадачи.
  • Находить оптимальные решения.
  • Предвидеть потенциальные проблемы.

Мы оцениваем эти качества, предлагая кандидату решить несколько логических задач и обсуждая его подход к решению. Ценим разработчиков, которые:

  • Предлагают улучшения в процессах и продуктах.
  • Берут на себя ответственность за результат.
  • Не боятся сложных задач.

Об этом многое может сказать опыт работы над pet-проектами или участие в open-source.

Алексей ГришанковАлексей Гришанков, руководитель Android-подразделения мобильной разработки в Notamedia.Agency

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

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

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

Алгоритм оценки разработчика

Алексей ОносовАлексей Оносов, основатель компании «Юнисофт»

1. Определите, кто вам нужен

Прежде чем начинать поиск, четко сформулируйте, какой именно специалист вам требуется. «Хороший программист» – понятие относительное. Мы всегда начинаем с составления детального профиля вакансии. Какие технологии должен знать кандидат? Какой опыт необходим? Какие личные качества важны для успешной работы в нашей команде? Например:

  • Python-разработчик с опытом работы в Data Science от 3 лет, знанием SQL и умением работать в команде.
  • Frontend-разработчик со знанием React, опытом создания адаптивных интерфейсов и навыками UI/UX дизайна.

Четкое понимание требований поможет сфокусироваться на действительно важных критериях при оценке кандидатов.

2. Наведите справки о кандидате

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

  • Над какими проектами работал кандидат?
  • Насколько самостоятельно он справлялся с задачами?
  • Были ли сложности в коммуникации?
  • Почему закончилось сотрудничество?

Такой подход позволяет составить более полную картину о профессиональных качествах разработчика еще до личной встречи.

3. Проведите тестирование

Теоретические знания важны, но еще важнее – практические навыки. Поэтому мы всегда проводим техническое тестирование кандидатов. Возможно использовать платформу HackerRank для оценки навыков программирования. Кандидату предлагается решить несколько задач разной сложности. Это позволяет оценить:

  • Знание синтаксиса языка.
  • Умение писать эффективный код.
  • Навыки отладки и оптимизации.
  • Скорость решения задач.

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

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

4. Проведите личное собеседование

Техническое интервью – ключевой этап отбора. Его проводит непосредственный руководитель будущего сотрудника, а иногда и вся команда разработки.

На что мы обращаем внимание:

  • Умение четко и структурированно излагать мысли. Разработчик должен уметь объяснять сложные технические концепции простым языком.
  • Подход к решению задач. Мы предлагаем кандидату решить несколько алгоритмических задач, наблюдая за ходом его мыслей. Важно не столько получить правильный ответ, сколько увидеть логику рассуждений.
  • Знание основ. Понимание базовых структур данных, алгоритмов, принципов ООП – обязательно для хорошего разработчика.
  • Опыт работы с инструментами разработки. Git, CI/CD, Docker – без этого сегодня никуда.
  • Умение работать в команде. Мы задаем вопросы о прошлом опыте, о том, как кандидат решал конфликтные ситуации.
  • Мотивация и желание развиваться. Хороший разработчик должен следить за новыми технологиями, постоянно учиться.

Важно создать комфортную атмосферу на собеседовании. Стресс-интервью не наш метод – мы хотим увидеть реальные способности кандидата, а не его реакцию на стресс.

5. Дайте тестовое задание

Финальный этап отбора – выполнение тестового задания. Это может быть мини-проект или решение реальной задачи из практики компании. Тестовое задание позволяет оценить:

  • Качество кода.
  • Умение следовать требованиям ТЗ.
  • Навыки проектирования архитектуры.
  • Умение писать тесты.
  • Навыки документирования.

Мы всегда ограничиваем время на выполнение задания (обычно 3-5 дней) и просим кандидата вести лог работы. Это позволяет оценить, сколько времени ушло на разные этапы, и убедиться, что задание выполнено самостоятельно.

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

На что обратить особое внимание

Иван ФеденковИван Феденков, тимлид разработки в IT-компании HFLabs

На этапе изучения резюме обращаем внимание, написал ли кандидат конкретику и рассказал ли, что именно он делал. Хорошим знаком будет, если в резюме есть реальные достижения:

  • «Провел рефакторинг модуля, и это позволило вносить доработки проще и быстрее».
  • «Оптимизировал работу программы, что ускорило формирование отчета в 10 раз».

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

На этапе собеседования:

  • В обязательном порядке проверяем базу, даже у сеньоров. Для нас важно знание java-core, умение работать с коллекциями, понимание разницы между проверяемыми и непроверяемыми исключениями и умение объяснить эту разницу «на пальцах».
  • Задаем каверзные вопросы, которые позволяют понять, работал ли кандидат со сложными задачами. Оцениваем технический кругозор. За час это позволяет сформировать картину об опыте кандидата и понять, интересен ли он нам.
  • Оценить софт-скиллы на техническом собеседовании обычно не хватает времени, но иногда в процессе общения понимаешь, что нам с кандидатом не по пути. Обычно это ситуации, когда человек увиливает от прямых ответов, а вместо этого ударяется в философствование и пытается «заболтать». 

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

Алексей ГришанковАлексей Гришанков, руководитель Android-подразделения мобильной разработки в Notamedia.Agency

В первую очередь оцениваю технические знания. Для мобильного разработчика это базовые навыки работы с платформой (будь то Android или iOS), знание популярных библиотек, понимание архитектурных паттернов и принципов работы с сетевыми запросами. На практике было много случаев, когда кандидат демонстрировал глубокие знания, но оказался недостаточно гибок в применении разных подходов.

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

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

Я смотрю, насколько кандидат внимательно слушает вопросы и как отвечает. Важно, чтобы кандидат не пытался впечатлить обилием технических терминов, а мог объяснить логику своих решений простыми словами. В одной из бесед мы обсуждали использование архитектуры MVI (Model-View-Intent) в мобильной разработке, и кандидат, без сложных терминов, объяснил, почему этот паттерн помогает ему избежать путаницы с состоянием экрана при сложной навигации. Подобные ответы показывают не только знания, но и умение «приземлить» их на конкретные задачи и требования платформы.

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

Как вычислить новичка, у которого нет опыта

Иван ФеденковИван Феденков, тимлид разработки в IT-компании HFLabs

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

Вычислить выпускников курсов можно и еще по нескольким признакам. Например, они указывают в качестве своего работодателя компании, которые невозможно найти через поиск в Интернете. Или пишут опыт работы в той организации, где сейчас числятся. Скажем, работает человек на заводе по производству труб и «рисует», что он делал там CRM-систему. Часто выпускники курсов просто пишут про стек технологий. И, самое главное, они всегда идут «пачкой» – и резюме у всех одинаковое.

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

Какие вопросы задать кандидату на роль разработчика

Иван ГринкевичИван Гринкевич, CEO & Founder PHPdev.org

Когда я собеседую программистов, моя цель — определить не только их технический уровень, но и особенности их мышления, восприятие рабочей среды и мотивацию. Хороший кандидат — это не только профессионал с нужными навыками, но и человек с определенными софт-скиллами.

Я заостряю внимание на этих вопросах:

  • «Почему ты ушел с прошлого места работы?». Если кандидат сразу описывает прошлую компанию как «полный бардак», для меня это повод уточнить, что конкретно его не устраивало. Если кандидат акцентируется исключительно на негативе, жалуется на команду или руководство, это сигнал возможной токсичности.
  • «Как ты решал задачи, которые перед тобой стояли?». Здесь мне важно услышать о реальном опыте: типах задач, с которыми ему приходилось сталкиваться, и подходах к их решению. Кандидат с релевантным опытом сможет объяснить, как он подходил к решению задач, какие методы и лайфхаки применял, какие ошибки совершал и что из этого вынес.
  • «Какие задачи ты выполнял на предыдущей должности?». Каков был результат? Я обязательно спрашиваю кандидата о его достижениях: смог ли он привнести что-то полезное для компании, каких конкретных успехов достиг. Хороший кандидат способен показать, как он сделал что-то значимое, привел к положительным изменениям, а не просто выполнял задачи ради процесса.
  • «Чего ты ждешь от работы у нас?». Выясняю, какую зарплату кандидат считает справедливой и за какие достижения.
  • «При каких условиях ты бы задумался о смене работы?».

Анатолий КурочкинАнатолий Курочкин, эксперт Executive.ru

Этот ряд вопросов считаю очень полезным:

  • «В каких фреймворках вы работали? С какими языками?». Ответ может помочь определить насколько кандидат увлечен программированием, на сколько ему это интересно.
  • «В каких коммерческих проектах вы участвовали? В каких ролях? Были ли самостоятельные разработки или только в команде?». Эти вопросы помогут определить границу опыта кандидата.
  • «С какими СУБД вы работали? Как вы оцениваете свой опыт работы с ними?».
  • «К каким способам документирования вы привыкли?». Необязательно у хорошего программиста должна быть склонность к написанию больших текстов, но одних только комментариев в тексте программы явно мало. Он должен уметь в паре абзацев пояснить логику своей программы или отдельного модуля.
  • «Есть ли у вас дополнительный опыт, например, в написании скриптов для тестирования? Как вы работаете с отладкой программы?».

У меня есть и шуточный вопрос: «Чем отличается число с плавающей точкой от числа с плавающей запятой?». Этот вопрос идет первым и позволяет разрядить атмосферу.

Алексей ОносовАлексей Оносов, основатель компании «Юнисофт»

Технологии постоянно меняются, поэтому важно, чтобы разработчик умел и любил учиться. Мы спрашиваем:

  • Как кандидат осваивает новые технологии?
  • Какую профессиональную литературу читает?
  • Участвует ли в конференциях, митапах?

Какие ответы кандидата говорят о том, что он не подойдет

Иван ГринкевичИван Гринкевич, CEO & Founder PHPdev.org

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

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

Если кандидат отвечает уклончиво или не может объяснить, зачем ему эта работа, это может сигнализировать что он рассматривает эту роль как временную.

Алексей ГришанковАлексей Гришанков, руководитель Android-подразделения мобильной разработки в Notamedia.Agency

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

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

Алексей ОносовАлексей Оносов, основатель компании «Юнисофт»

Есть несколько «красных флажков», на которые мы обращаем внимание:

  • Неумение признавать ошибки. Если кандидат не может признать, что чего-то не знает или в чем-то ошибся – это плохой знак. Хороший разработчик должен уметь учиться на ошибках.
  • Отсутствие интереса к новым технологиям. Если человек не следит за трендами в своей области, не читает профессиональную литературу – он быстро устареет как специалист.
  • Неумение работать в команде. Фразы вроде «я предпочитаю работать один» или истории о конфликтах с коллегами говорят о проблемах с мягкими навыками.
  • Отсутствие собственного мнения. Если кандидат на все вопросы отвечает «как скажете» – это признак отсутствия инициативности.
  • Нежелание брать на себя ответственность. Хороший разработчик должен уметь принимать решения и отвечать за результат.
  • Неумение объяснить простыми словами проекты, над которыми он работал – это признак поверхностных знаний.
  • Отсутствие вопросов о компании и проекте. Заинтересованный кандидат всегда задает встречные вопросы.
  • Неадекватные зарплатные ожидания. Это говорит либо о переоценке своих навыков, либо о недостаточном понимании рынка.

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


Материал подготовлен с помощью сервиса «Лига экспертов» Executive.ru.
Вы тоже можете оставить комментарии на запросы редакции:

Посмотреть открытые запросы

Читайте также:

Расскажите коллегам:
Комментарии
Аналитик, Москва
Сергей Средний пишет:
Анатолий Курочкин пишет:
При этом я не призываю всем переходить на ассемблер, поймите меня правильно. Но не знать его, или хотя бы понимать, стыдно. Это кругозор, это глубина знаний. 

Ну да. И обязательно уметь огонь добывать трением. Тоже для кругозора.
Анатолий, если кроме шуток -- ну всему свое время. Зачем жить прошлым?

Анатолий Курочкин пишет:
Чужой код - хуже некуда. 

Это самое интересное.
Поэтому настаиваю: хотите найти хорошего разработчика -- посмотрите его код на ГитХабе.

Вчера у меня свобода слова закончилась. )))

Про ГитХаб интересное предложение. Можно и посмотреть, только что вы там увидите, будете весь код разбирать? И что?
И я не сторонник звонить бывшим, искать компромат в интернете, выслеживать., распрашивать за спиной. НЕ воровал ли мой будущий коллега колхозные колоски с полей. Мне тоже приходилось проходить на собеседованиях "многофакторную идентификацию". Противно. Нет, я так не работаю.

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

Чуть сойду со своей позиции в сторону. Понимаю, что сейчас огромное количество разработок использует один и тот же набор паттернов. Но если вы  хотите разработать свой, уникальный какой-нибудь "рус.фотошоп", или разработать свою СУБД (почему бы и нет?), свою ОС, то знания программиста должны основываться именно на знании ассемблера, как родного для всех процессоров. 
Ну а для многочисленных систем учёта гороха, или выданных кредитов знанние ассемблера не нужно.
.....

И ещё чуток в сторону. Большинство нанимателей программистов сейчас требуют быстрого встраивания в работу команды с её уникальностью, с её набором инструментов, с её текущим этапом. Даже смириться с её заблуждениями. Я не люблю проводить тестирование. Пустая трата времени. Это простая сверка часов что-ли. Оно не даёт понимание перспективности программиста. Мне ближе практика, когда человек сначала погружается в прикладную область. Это касается и программистов в чистом виде, и бизнес-аналитиков, и руководителей ИТ-проектов. 

Бывали случаи, когда приходил на новую работу и видел, что то, что сделано не понравится заказчику, сделано плохо. Но коллеги всё равно настаивали на свом мнении, типа лишь бы сдать. 

Кстати, авторы публикации об этом тоже пишут.

IT-менеджер, Москва
Сергей Средний пишет:

Как определить хорошего разработчика на собеседовании?

По портфолио на GitHub.
Нету ножек (портфолию на GitHub) -- нет конфетки (предложения).

Что это вам даст? Куски чужого кода? Проба пера? Как вы оцените этот код и будете считать его правильным, хорошим, красивым? Или просто сам факт, что человек что-то делал? 

Многие эксперты здесь отмечают многочисленное, многоэтапное, многоуровневое тестирование кандидата. Я проходил черз аналогичное. Плюс анкеты в службе персонала (кем вы видите себя через 5 лет), плюс замороченные тесты. А потом оказывалось, что компания ничем особенным в области программирования не заниматся, линейные руководители знают меньше, чем ты, просто их опыт заточен на какую-то конкоретную, сиюминутную задачу. 

Аналитик, Москва
Николай Зоин пишет:
Многие эксперты здесь отмечают многочисленное, многоэтапное, многоуровневое тестирование кандидата. Я проходил черз аналогичное. Плюс анкеты в службе персонала (кем вы видите себя через 5 лет), плюс замороченные тесты. А потом оказывалось, что компания ничем особенным в области программирования не заниматся, линейные руководители знают меньше, чем ты, просто их опыт заточен на какую-то конкоретную, сиюминутную задачу. 

Проходил как-то конкурсные этапы в одну федеральную службу. Примерно месяц - куча бумаг, тесты, включая знание ворда и екселя. Знание законов и Конституции. 

Сдал всё с высоким баллом (имею гос.чин), но не прошёл. И потом, когда забирал документы, мне добрая женщина сказала, что кандидат был назначен заранее, а всё это цирк с конями.

Аналитик, Москва
Анатолий Курочкин пишет:
Большинство нанимателей программистов сейчас требуют быстрого встраивания в работу команды с её уникальностью, с её набором инструментов, с её текущим этапом. Даже смириться с её заблуждениями. Я не люблю проводить тестирование. Пустая трата времени. Это простая сверка часов что-ли. Оно не даёт понимание перспективности программиста. Мне ближе практика, когда человек сначала погружается в прикладную область. Это касается и программистов в чистом виде, и бизнес-аналитиков, и руководителей ИТ-проектов. 

Дожился, сам себя цитирую. )))

Однажды собеседовался в одном из известнейших НИИ, оборонка. Меня очень впечатлила беседа, вспоминаю её до сих пор. Мы сидели в уютной обстановке, передо мной двое учёных (кандидат и доктор наук). Они подробно распрашивали меня по профилю моего опыта, без попыток подловить, без желания в чем-то уличить. Мы просто беседовали. Они, на мой взгляд, хотели понять мой уровень подготовки, от которого они будут работать со мной. А я поражался "умности" и уместности их вопросов, вопросы задевали самую суть и чётко выясняли границы моих познаний.
Впечатления были у обеих сторон очень положительные. 

Researcher, Москва
Николай Зоин пишет:
Что это вам даст?

Как что?
Представление о том что умеет кандидат, с чем работает.
По сути ГитХаб -- это профиль практических навыков разработчика. В каком-то смысле его резюме.
Если он пустой (как ваш профиль здесь) -- то это не пойми кто.
Можно сделать ставку и начать задвать вопросы о жизни, но лучше потратить время на тех, у кого там уже что-то есть -- они более мотивированы.
Даже, если разраб заимствовует чужой код под свои задачи и эффектвино их решает -- это тоже не плохо, а даже хорошо. Значит в курсе как работают другие и экономит свое время. Можно изобретать велосипед, а можно взять готовый, подшаманить и поехать.

Евгений Равич пишет:
И что вы там увидите, если не сравниваете с аналогами в данной предметной  области? Нужно понимать, что человек написал сам, а что взял без изменений.

Предполагается, что смотреть профиль на ГитХабе будет руководитель кандидата, а не HR с педобразованием и специализацией руссий язык и литература.
Позадавать глубокие вопросы (в том числе по портфолио) с неочевидными ответами. Предложить кейс. И посмотреть как он с ним справился.
Иначе столкнетесь с теоретиком, который дует щеки и хорошо ..т в уши, но не разбирается глубоко в предмете и ничего не умеет сделать. Как некоторые здесь :)

Анатолий Курочкин пишет:
Можно и посмотреть, только что вы там увидите, будете весь код разбирать?

Весь нет. Но многое будет понятно.

Например, мне достаточно одного взгляда на Sales, Product и Demand аналитику специалиста, чтобы понять какими иснтрументами он владеет и насколько глубоко понимает предмет. А короткий разговор по его же отчету окончательно расставит все точки над Й.
Ну и контрольный в голову -- пара кейсов, один блиц прямо на собеседовании, а второй в виде домашней работы на 2-3 дня.

Меня удручают глупые вопросы, если честно.
Серьезные компании, которые публикуют вакансии для разрабов, щас уже часто требуют показать профиль на ГитХабе. Это обязательное условие, чтобы попасть в пул первого отбора. Здесь все на пенсии штоле?

Аналитик, Москва
Сергей Средний пишет:
Анатолий Курочкин пишет:
Можно и посмотреть, только что вы там увидите, будете весь код разбирать?

Весь нет. Но многое будет понятно.
Например, мне достаточно одного взгляда на Sales, Product и Demand аналитику специалиста, чтобы понять какими иснтрументами он пользуется и насколько глубоко понимает предмет. А короткий разговор по его же отчету окончательно расставит все точки над Й.
Ну и контрольный в голову -- пара кейсов, один блиц прямо на собеседовании, а второй в виде домашней работы на 2-3 дня.

Меня удручают глупые вопросы, если честно.

Давайте без лишних слов. Вот вам код, оцените его и какие выводы вы сможете сделать? После вашего возможного ответа, я скажу где его вязл.

Researcher, Москва
Анатолий Курочкин пишет:
Вот вам код, оцените его и какие выводы вы сможете сделать?

Я не разраб, Анатолий. Я не пишу код.
У меня в профиле подробно написано с чем я работаю.

Но код, который вы привели напоминает какой-то парсер или, возможно, загрузчик рекламных баннеров с адаптивной настройкой отображения.
Вас не учили комментировать свой код?
Не знаете для чего это нужно делать?
А надо...

Аналитик, Москва
Сергей Средний пишет:
Анатолий Курочкин пишет:
Вот вам код, оцените его и какие выводы вы сможете сделать?

Я не разраб, Анатолий. Я не пишу код.
У меня в профиле подробно написано с чем я работаю.

Но код, который вы привели напоминает какой-то парсер.

Сергей Средний пишет:
Анатолий Курочкин пишет:
Можно и посмотреть, только что вы там увидите, будете весь код разбирать?

Весь нет. Но многое будет понятно.
...
Меня удручают глупые вопросы, если честно.
Серьезные компании, которые публикуют вакансии для разрабов, щас уже часто требуют показать профиль на ГитХабе. Это обязательное условие, чтобы попасть в пул первого отбора. Здесь все на пенсии штоле?

Нет, не парсер. Это код нашей, именнно вот этой текущей страницы. 

Я уже писал, что ваша идея заслуживает внимания, но она может дать только косвеннное подтверждение опыта программиста и то далеко не всегда. Правильно коллеги пишут - 90 процентов программистов используют типовые обращениия к типовым библиотекам. Обращу внимание, что я не считаю это недостатком - написание своих библиотек, конечно, хорошо, но для коммерческих, командных разработок от этого больше вреда.

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

Сергей Средний пишет:
мне достаточно одного взгляда на Sales, Product и Demand аналитику специалиста, чтобы понять какими иснтрументами он владеет и насколько глубоко понимает предмет

А вот про инструменты, кторыми владеет кандидат, дейстивтельно важны. Так об этом практически все эксперты сказали. Вы правы.

Сергей Средний пишет:
Вас не учили комментировать свой код?Не знаете для чего это нужно делать?

Сергей, а почему всегда, когда вы становитесь в невыгодную вам позицию, вы начинаете сначала слегка, а потом всё резче грубить?

Researcher, Москва
Анатолий Курочкин пишет:
Нет, не парсер.
Сергей Средний пишет:
загрузчик рекламных баннеров с адаптивной настройкой отображения

Вторая версия в яблочко. Имею право на ошибку. Написание кода -- не мой хлеб.
Я думал он ваш. Код надо комментить, хотя бы парой слов. В чём тут грубость?
Но соглашусь -- у меня специфическое чувство юмора. Пора бы привыкнуть :)

Анатолий Курочкин пишет:
Ни разу не встречал компании, которые требуют показать профиль на гитхабе.

Вы давно не выходили на открытый рынок, судя по всему. Всё быстро меняется.
Анатолий, и верните фоточгу на аватарку пжлст.

IT-менеджер, Москва
Анатолий Курочкин пишет:
Ни разу не встречал компании, которые требуют показать профиль на гитхабе.  У не самого большого проекта сотни фрагментов кода. Уважаемые программисты, кто может опровергнуть мой скромный опыт?

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

Я тоже не очень понимаю, как можно по коду в гите определить квалификацию.

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Игорь Семенов
А в чем смысл? Даже если устроить весь этот танец с бубнами, итоговая сумма НДС, уплаченная в бю...
Все дискуссии
HR-новости
В России упростили процесс трудоустройства для жителей из новых регионов

Изменения коснутся жителей ДНР и ЛНР, Запорожской и Херсонской областей.

Российским компаниям не хватает более 100 тыс. разработчиков ПО

Экономика страны столкнулась с острой нехваткой IT-специалистов.

Автодилеры начали сокращать сотрудников из-за падения продаж

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

HeadHunter назвал лучших работодателей России-2024

В него вошли 1729 компаний со всей страны, что на 15% больше, чем годом ранее и на 60% больше, чем в 2022 году.