как узнать свой уровень программирования
Как мы определяем уровень профессионализма разработчика?
2016-10-04 08:17:01 2021-08-30 11:24:34
«Жил-был принц, он хотел взять себе в жены принцессу. Вот он и объехал весь свет. Да повсюду было что-то не то: принцесс было полно, а вот настоящие ли они, этого он никак не мог распознать до конца, всегда с ними было что-то не в порядке»
Г. Х. Андерсен. Принцесса на горошине
Пытаясь найти опытного разработчика, сталкиваешься с похожей проблемой. На объявление о вакансии много откликов. Как определить соответствие кандидата необходимому уровню профессионализма? Специальность программиста считается перспективной. Количество соискателей с двухмесячными курсами за плечами больше, чем фальшивых принцесс в период феодальной раздробленности.
Когда в EDISON требуется программист, в объявлении указывается степень квалификации. Например, Middle-разработчик. Возникают вопросы от соискателей о дифференциации уровней. Единой классификации степени профессионализма нет. Можно сказать, что Junior — начинающий разработчик с опытом до 2 лет, Middle — от 2. Стаж Senior начинается с 5. На вершине системы уровень Lead, подразумевающий руководство командой специалистов. Но стаж не гарантирует обладание необходимыми навыками. Можно 5 лет плодить сайты-одностраничники и не стать Senior-разработчиком. И наоборот: попав к грамотному наставнику и принимаясь за серьезные задачи, через год достичь уровня «Middle». Об отборе кандидатов в EDISON кратко написано здесь.
Практика предварительной беседы с соискателями не подошла из-за временных затрат. Этап первичного отбора передали специалисту кадровой службы. Сначала соискатель проходит анкетирование, самостоятельно оценивая компетентность в областях программирования по 5-балльной шкале. Указывает срок использования технологии, заполняет таблицу «Выполненные проекты». Полученные сведения дают общее представление об опыте соискателя и профессиональном кругозоре. Начинающим разработчикам свойственно завышать оценку. К примеру, кандидат считает уровень знания Рython на 4, «готов решить любую задачу», а опыт использования языка указывает 2 недели.
Компетентность соискателя оценивается на практике. Кандидат выполняет тестовое задание. На основании анализа определяется уровень.
Первый фактор оценки — время выполнения
На идентичное задание Junior-разработчику понадобится неделя. Senior выполнит тест за несколько часов. Показательна и оценка срока выполнения тестового задания от соискателя. Разработчик уровня «Junior» смотрит на поставленную задачу чересчур оптимистично, недооценивает сложность. И из-за нехватки опыта не укладывается в сроки. Специалист уровня «Middle» склонен пессимистично смотреть на задачу. Сказывается опыт в качестве Junior-разработчика. Чрезмерно увеличивает прогнозируемый срок реализации. Senior-разработчик реалистичен. Закладывает риски разумно без лишнего завышения сроков.
Второй момент — качество кода
Несколько лет для оценки соискатели писали простую браузерную игру «Крестики-нолики». В зависимости от вакансии рекомендовалось использовать определенный язык или технологию. Если планировалось значительное расширение штата, у кандидатов была свобода выбора инструментария.
Сейчас у нас десятки вариантов выполнения проверочного задания. Тестировщики EDISON выбрали 3 фрагмента кода (обработка запроса веб-приложения), написанные на PHP разработчиками разного уровня, и добавили комментарии.
Начнем с примера так называемого «говнокода».
Хранение логина и пароля пользователя в куках. Явная ошибка безопасности. Куки передаются от браузера к серверу при запросе (открытии/обновлении страницы). Потенциальная возможность перехвата.
Определение действий сайта на основе параметра POST-запроса последовательными условными блоками. Код усложняется, становясь громоздким и нечитаемым. Для облегчения реализации задачи опытные программисты придумали маршрутизацию и паттерны, например MVC.
Громоздкий код для элементарных операций. Опытный программист напишет блок в одну строку.
Подстановка параметра GET-запроса (строки, приходящей от пользователя при открытии страницы в браузере) прямо в SQL-запрос (обращение к базе данных). Потенциальная уязвимость в безопасности (SQL-инъекция).
Хардкод URL’ов. Адрес страницы приложения может меняться. Для отсылки на новый адрес программисту придется искать и менять данные в коде вхождения старого URL.
Именование переменных на разных языках — частный случай использования транслита в коде. Распространенная ошибка начинающих говнокодеров.
Пример кода уровня «Junior».
Определение действий, исходя из параметров GET-запроса последовательными условными блоками. Аналогично прошлому примеру.
«Echo» в коде является не лучшим решением для вывода текста или верстки в браузер. Усложняет процесс изменения внешнего вида сайта. Верстка должна находиться в отдельных файлах-шаблонах. По аналогии справедливо и для JS-, CSS-вставок. Обязательно разделение по разным файлам, желателен разброс по папкам.
Захардкоденный обработчик события click. Аналогично предыдущему пункту. Весь JS нужно выносить в отдельные файлы.
Код Middle-разработчика прост для понимания и содержит комментарии для разбора сложных участков. Используется ORM (Object-relational mapping) взамен написания нативных запросов к базе. Значительно снижается риск SQL-инъекций. Применяется ООП и MVC.
Различия между Middle- и Senior-разработчиком по фрагменту кода прослеживаются слабо и заключаются в выборе верных архитектурных решений.
Обобщенные критерии оценки сведены в таблицу. Список не ограничивается приведенными примерами.
Критерий оценки | Junior | Middle | Senior |
Декомпозиция задачи | Последовательные строчки кода. Copy/paste — для повторного использования кода. | Создает многократно используемые функции/объекты, решающие общие задачи. | Использует соответствующие структуры данных и алгоритмы. Создает общий/объектно-ориентированный код, инкапсулирующий условия задачи. |
Декомпозиция системы | Не способен думать о системе сложнее одного класса или файла. | Производит декомпозицию задачи и проектирует систему в пределах одной платформы или технологии. | Визуализирует и проектирует сложные системы с несколькими линейками продуктов, интегрирует с внешними системами. Проектирует системы поддержки работы: мониторинг, генерация отчетов, аварийные переходы на запасные ресурсы. |
Общение | Не может выразить свои мысли/идеи. Плохо с правописанием и грамматикой. | Его понимают. Хорошее правописание и грамматика. Общается эффективно. | Понимает и объясняет мысли/дизайн/идеи/специфику в точно выраженной форме. В общении соответствует ситуации. |
Организация кода в файле | Нет четкой организации в файле. | Методы сгруппированы логически и по вызовам. | Код разделен на регионы. Имеет грамотные комментарии со ссылками на файлы-исходники. |
Организация кода между файлами | Нет четкой организации кода с делением на файлы. | Физический файл выполняет одну функцию. Например, служит для объявления класса или для реализации одного функционала и т. д. | Организация кода на физическом уровне соответствует проекту. Наглядность способа проектирования реализации через имена файлов и структуру папок. |
Читабельность кода | Односложные имена. | Хорошие имена файлов, переменных, классов, методов и т. д. Нет длинных функций. Нестандартный код, багфиксы и допущения в коде поясняются комментариями. | Допущения в коде сопровождаются командами Assert. Поток операций в коде естественный (без глубокой вложенности условий или методов). |
Безопасное программирование | Не понимает данной концепции. | Проверяет аргументы методов, возвращаемое значение и обработку исключений в потенциально важном коде. | Имеет собственную библиотеку, помогающую в безопасном программировании. Пишет юнит-тесты для имитации сбоев. |
Обработка ошибок | Пишет код для «идеального» случая без сбоев. | Обработка ошибок в коде (кидает исключение или генерирует ошибку). | Пишет код с функцией раннего определения ошибок. Придерживается последовательной обработки исключений в слоях кода и формулирует принципы процесса в системе. |
Требования | Понимает выставленные требования и пишет код в соответствии со спецификацией. | Видит картину в целом и сразу выявляет дополнительные аспекты с последующим описанием в спецификации. Задает вопросы, касающиеся неучтенных случаев. | Предлагает альтернативы и следует выставленным требованиям, основываясь на собственном опыте. |
Базы данных | Знает основы баз данных, транзакции. Пишет простые select-запросы. | Проектирует нормализованные схемы БД с учетом запросов. Умело использует представления, хранимые процедуры, триггеры и собственные типы данных. Понимает разницу между кластеризованными и некластеризованными индексами. Специалист в использовании ORM инструментов. | Осуществляет администрирование, увеличивает производительность и оптимизирует индексы БД. Пишет сложные select-запросы. Заменяет использование курсора вызовами функций SQL. Понимает принципы внутреннего хранения данных и индексов. Имеет представление о создании «зеркал» и репликации БД и т.д. |
Оценка уровня соискателя субъективна в размере допустимой погрешности. Но претенденты, как правило, соглашаются с результатом тестирования. На испытательном сроке в большинстве случаев кандидат имеет возможность быстро продемонстрировать уровень, превышающий оценочный.
Оценка уровня программиста?
Каким образом можно оценить свой уровень знаний в программировании?
Я достаточно молодой специалист (21 год, 6 курс, чуть меньше года работаю), работаю в довольно большом банке в отделе экваринга (банкоматы, POS-терминалы), но по сути я занимаюсь разработкой внутреннего ПО, для нашего отдела и отчасти процессинга. Пишу в основном на Perl и Java. Как хобби изучаю дома Python и опять же Java. По характеру работы мне приходится иметь дело со всевозможным многообразием языком (человек-комбайн), начиная от C/C++ и заканчивая VB в Экселе, JS, HTML, CSS. Плюс слежение за сервером, обновления, прокладка сетей. В общем куча разноплановой работы и дизайн, и верстка, и программирование.
Сам я свои знания оцениваю как низкие, т.к. часто пользуюсь гуглом, большинство решений беру оттуда и внедряю к себе(стараясь правда понять как оно работает), встречаю довольно часто незнакомые слова и методы на Хабре, да и считаю что невозможно при всем многообразии работы разбираться во всем хорошо.
С другой стороны, со всеми задачами которые мне поручают я справляюсь в срок и больших затруднений они у меня не вызывают, готовые решения в большинстве случаев строятся по тому же алгоритму что я представлял, за пол года вырос со специалиста до ведущего инженера(хотя в банке принято не менее года работы в банке и 3х лет общего стажа).
В общем, подскажите пожалуйста какие-нибудь ресурсы для объективной оценки своих знаний и навыков, или вообще какие-нибудь методы. Хочется позднее уйти в IT компанию, но не могу даже представить по какому из направлений и на кого могу претендовать Junior|Middle.
Оценка стоимости и знаний сотрудника у каждой компании своя. Где то больше будут ценить понимание вами паттернов проектирования и знания той предметной области где вы будете работать. Где то самым важным будет ваше стремление развиваться и доводить до конца.
Некоторым компаниям гораздо важнее, что бы вы понимали особенности и подводные камни языка на котором вам придется писать. А есть компании в которые вы никогда не попадете если не работали с системами контроля версии и баг треккингом, будь вы даже трижды гений!
Человек стоит ровно столько, сколько ему готовы платить. Я в этом убедился на собственной шкуре. Самое плохое что с вами может произойти, если вы поймете, что знаете уже очень много. В этот момент вы умрете как специалист.
Лично мой совет будет таким: походите на собеседования, даже не ради того что бы сменить работу, а просто что бы пообщаться с умными людьми и понять основные запросы рынка. Я думаю после этого вы сами составите адекватную оценку себе.
И паттернов я не знаю, хотя часто слышу о них, но все времени нет, и как-то более насущные вещи нужно изучить. Пытался использовать систему контроля версий, но так и не понял зачем она нужна когда работаешь один и помнишь все изменения =)
По поводу вашегоь совета — большое спасибо. Буквально пару месяцев назад ходил на пару собеседований, но впечатления остались самые пакостные. Многого я рассказать о своих проектах не могу, ибо NDA. Лишь о паре, и то в общих чертах. На одном из них начальник сам не знал даже модель OSI, а на втором чуть ли не с гавном смешали. Хотя на все вопросы вроде отвечал правильно и развернуто, да и не сложные они были. По итогу сказали, что даже тест мне дадут, ибо ничего не знаю, стажа нет. опыта тоже. Однако вечером позвонили и сказали что я подхожу.
Так что желания просто так по собеседованиям ходить как-то не хочется =( Да и времени нет. работаю с 9 до 18, часто после работы остаюсь. А собеседуют в основном в рабочее время. Но все равно, большое спасибо за совет.
Да есть компании, которые любят смешивать людей с продуктами жизнедеятельности. Старайтесь не воспринимать их всерьез как правило работать в таких компаниях, тоже неприятно.
Паттерны рекомендую почитать, осознать, попробовать, а потом снова перечитать. В остальном я считаю походы на собеседования самым интереснейшим занятием. За последние 3 года я посетил не менее 50 и почти каждый раз выносил для себя что то новое.
А не злятся на то, что «тратите их время»? Им ведь нужно найти работника. Или Вы сразу предупреждаете что хотите просто прособеседоваться?
Навыки программирования очень сложно оценить. Знание языка, вообще, почти не коррелируют с уровнем программиста. Знание паттернов — тоже. Частота использования гугла — тоже. Я, например, будучи программистом 10 лет, все еще по каждой мелочи пользуюсь гуглом, и так будет всегда.
Хорошего программиста определяет умение качественно решать, различного рода, задачи. Чем лучше программист, тем шире список решаемых им задач, и тем лучше качество решений, но и это все не объективно.
Единственное, что могу посоветовать — поискать ответы на вопросы такого рода.
Позвольте и мне высказать свою точку зрения. Как правильно отметили выше, объективно оценить знания программиста по числовой шкале (хоть по 100..0-бальной), пожалуй, невозможно. Да и наверное не нужно, так как в каждой компании требуют различные знания (кто еще кроме компаний будет вас оценивать?).
Тем не менее, можно выделить несколько категорий знаний, по которым можно составить более-менее объективную картину программиста. Например, сюда можно отнести:
— владение различными ЯП;
— опыт работы с каждым из них;
— работа в команде;
— участие в OpenSource-проектах;
— наличие собственных разработок;
— знание паттернов;
— знание алгоритмов, структур данных;
— знание методологий разработки;
— знакомство с системами контроля версий, тестирования;
— и т.д.
Несомненно, картина получается далеко не полная — важную роль играют, например, и личные качества или другие индивидуальные характеристики, + в каждой организации требуется что-то свое. Но по вышеперечисленным категориям можно сопоставить себя и другого программиста, понять свой уровень относительно кого-то еще.
По поводу места работы. Лично мое мнение такое, что если вы хотите быть высококвалифицированным специалистом конкретной области (в данном случае, программистом), то лучше работу искать в «профильных» организациях (для данного случая, занимающихся разработкой софта). По своему (не особо богатому пока) опыту уже могу сказать, что специфика работы в таких «профильных» организациях сильно отличается от «непрофильных».
Наверное, это можно объяснить тем, что профильные живут тем, что получают деньги со своих продуктов, и программисты в них играют ключевую роль. Поэтому, самой компании выгодно, чтобы их специалисты развивались и были высококвалифицированными и выполняли задачи разработки как можно эффективнее («работает — неплохо, но старайся сделать еще лучше, думай как»).
В непрофильных же — работа программиста чаще всего необходима для поддержания внутренней информационной инфраструктуры, от ИТ-специалистов требуется лишь, чтобы они просто выполняли свою работу («работает — ну и хорошо, следи, чтобы не сломалось»).
Из этого очевидно, что в профильных компаниях вам намного проще расти как специалисту — в этом заинтересованы обе стороны (чем ты «круче», тем больше платят). Во втором случае, в этом заинтересованы только вы, да и то не всегда (зачем, если платить будут столько же).
По поводу собеседований. Ходить на них — весело, если выбрать верный настрой. Представьте себе, что вы вообще не хотите попасть в эту компанию, а пришли лишь показать все, что вы умеете, «какой вы из себя хороший специалист». Конечно, не стоит выпячивать свое ЧСВ при собеседовании — ведите себя естественно; в тоже время, убиваться в случае неудачи не стоит — вы же совсем и не хотели к ним идти работать.
А чтобы было о чем рассказать, в свободное время (оно же у вас есть?) разрабатывайте «для себя» разные программки. Ну например, напишите какой-нибудь парсер, поработайте с API различных систем (того же Яндекса), сделайте собственный таск-менеджер, придумайте сами интересную вам небольшую идею и доведите ее до конца. В каждой такой задаче можно найти много тонких моментов — оптимизация скорости алгоритма, структуры БД, применение паттернов, взаимодействие компонент, написанных на разных ЯП и т.д.
Как узнать свой уровень знаний в программировании?
Кто тут не новенький, подскажите пожалуйста где можно проверить свой уровень знаний в программировании, мне именно нужно узнать, хватает ли моих знаний в разработке игр на Unity, чтобы попробовать себя в какой либо конторе на уровне Junior.
Сам занимаюсь около года и хочется узнать общий уровень наработанных знаний в сфере, может сайты какие есть с тестами или еще чего, буду очень рад отклику 🙂
плюсую, так же очень не лишним будет просить у компаний обратную связь с фидбеком.
Делеко не все захотят его предоставлять, но за спрос не бьют в нос.
Только лучше не ходить сходу в компании, которые рассматриваются как релиз-кандидаты. Лучше попозже, уже с опытом.
В норм компании могут наоборот подсказать, какие навыки прокачать и что почитать, чтобы пройти собес через условные полгода.
Всяк бывает, согласен. Просто несколько раз сталкивался с классными командами разработки, но не с самым адекватным рекрутингом. Потому и посчитал нужным отметить, что первое впечатление в некоторых местах уже не исправить (пока не получишь опыт работы где-то ещё).
Да, рекрутинг у нас это ад ) Во время работы в одной компании был свидетелем такой сцены: hr уговаривал лида проекта взять одного джуна вместо другого из-за того, что первому необходимо снимать квартиру, а у второго она уже есть. Говорил, мол, мотивация выше будет.
В некоторых компаниях действует система банов на собесы. Если не проходишь собеседование, то в ближайший год тебя снова собеседовать не будут.
А на позицию джуна доучиваться нужно всяко меньше года
Ходишь в конторки попроще/средней руки со схожим пулом обязанностей, отвечаешь (или нет) на вопросики, делаешь тесты и понимаешь среднюю температуру по больнице + опыт прохождения интервью + примерно понимаешь, что ты стоишь и можешь стоить + многие на собеседованиях дают полезные советы и обратную связь.
А уже потом ищешь либо что-то приличное, либо компанию Мечты)
многие на собеседованиях дают полезные советы и обратную связь.
Я даже проверил, в той ли реальности я нахожусь. 😀
Так надо правильные вопросы задавать
По факту, у каждой конторы свои понятия о ранжировании. Где-то ты можешь быть мидлом, где-то тебя станут считать сеньором, а пойдёшь в место посолиднее так и вообще зелёным джуном окрестят. Всё зависит от требований компании, от того чем она занимается.
Опять же, мне известны компании в которых внутри каждого ранга находится ещё три ранга программистов)
Идёшь на собеседование и запоминаешь, что спрашивают, потом дочитываешь дома, если не взяли. Повторять, пока не возьмут на работу. Зачастую собеседования имеют очень отдаленное отношение к тому, чем придется заниматься, поэтому нужно прокачивать именно скилл прохождения собеседований и заучивать типовые вопросы. Как бы печально и глупо это не звучало, но большая часть собеседований подчиняется этим правилам. Это, конечно же, если есть достаточно вариантов.
А так, к джунам высоких требований все равно не предъявляют, поэтому обычно достаточно произвести впечатление что ты способен к обучению.
Ну, есть же не смешная «шутка», что на собесе спросят все, от асинхронности и мультитрэдов, до алгоритмов и шаблонов проектирования, а по факту потом с утра до вечера пишешь геттеры и сеттеры.
кстати, я бы поспорил о том, что к джунам высоких требований не предъявляют. Вот буквально на днях и искренним интересом наблюдал вакансию, где на стажера(. ) хотели чтобы ты написал тестовое, в котором нужно при помощи нейронной сети вытаскивать звуки для контекста их системы (реклама). Я от таких заяв слегка так припух
Это, вероятно, кто-то сильно умный захотел нанять хорошего специалиста «за копейки»
я не буду искать этот бред на хэдхантере, но там на пайтон была вакансия, именно на стажера и еще с зп какой-то смешной, тысяч 30 или около того. вот с таким вот тестовым.
я в этом не смыслю от слова совсем. но ради прикола захожу в вакансии айтишные всякие. там реально что ли надо все это знать за 30-40к? ( ͡° ͜ʖ ͡°)
Не всегда. зависит от специализации.
ну и часто эй-чары пишут от балды список требований.
«Какой у вас знак зодиака?»
«Понятия не имею, родился в феврале 19»
«Ой, вы у нас овен, а они не сходятся с начальниками-весами, и по радио сегодня говорили «иногда водолеям стоит говорить твёрдое нет на работе», а я водолей, так что нет! Пошёл вон отсюда, хам!»
Как оценить навыки программирования – обзор лучших методик
Пример кода написанного на языке Java
“Программирование сегодня — это гонка разработчиков, стремящихся писать программы с большей и лучшей идиотоустойчивостью, и вселенной, которая пытается создать больше отборных идиотов. Пока вселенная побеждает” (Рик Кук)
Знаете ли вы, что стоимость найма разработчика программного обеспечения может достигать 60 тысяч долларов? Если вы не имеете большого бюджета для найма работников, вы не можете позволить себе нанимать кандидатов, чьи навыки не подтверждены и просто надеяться на лучшее. Фактически, умение применять навыки программирования, будь то front end, back end или full stack разработка, является фундаментальным для каждого успешного процесса IT рекрутмента.
Как работодатели могут проверить чьи-то способности заранее? Это сложнее, чем просто заглянуть в резюме программиста.
“Многие разработчики посещают курсы обучения программистов для расширения своих навыков, уже имея постоянную работу ” (Квинси Ларсон)[1]
В этой статье мы рассмотрим наиболее оптимальные методы оценки навыков IT-специалистов, в том числе тесты по написанию кода и технические интервью. Следуя нашему совету, вы минимизируете риск найма недо- или пере- оцененного кандидата, или просто того, кто не подходит вашей компании.
Оглавление
Как оценить навыки программирования – методы и советы
Давайте сначала посмотрим на приложения, которые ваши кандидаты могут использовать для демонстрации кода.
Портфолио
Вам стоит посмотреть на прошлые или текущие проекты кандидата через призму задач, которые им необходимо будет решать в новой роли.
Работали ли они раньше над чем-то похожим на ваш проект? Или возможно они смогут продемонстрировать уникальный подход к поставленной задаче? Получение ответов на эти вопросы должно дать вам хорошее первое впечатление о том, кто ваш кандидат.
GitHub
Воспринимайте GitHub как расширение для портфолио вашего кандидата. Вам стоит взглянуть на следующие детали их профиля:
Количество контрибуций и активность кандидата, иллюстрация с сервиса GitHub
Держа все это в голове, важно, чтобы вы также знали об ограничениях GitHub.
В проектах с открытым исходным кодом не всегда ясно, кто выполнил большую часть работы над проектом или сколько времени потребовалось для выполнения. Вы также не сможете проверить, как ваш кандидат работал вместе с другими. В конце концов, хотя GitHub и полезен, он не является надежным методом оценки навыков.
“Лучшие программисты не чуть-чуть лучше хороших. Они на порядок лучше по любым меркам: концептуальное мышление, скорость, изобретательность и способность находить решения.” (Рэндал И. Стросс)
Stack Overflow
“Большинство профессиональных разработчиков занимаются программированием не так давно. 55% кодит менее 8 лет, а 1/3 — менее 5” (Квинси Ларсон)[2]
Функционал сервиса Stack Overflow
Тесты по алгоритмам программирования (не рекомендуется)
“Измерять продуктивность программиста подсчетом строк кода — это так же, как оценивать постройку самолета по его весу” (Билл Гейтс)
Тесты по алгоритмам программирования – популярный метод оценки уровня владения выбранным языком или фреймворком. Однако, мы категорически рекомендуем вам не полностью полагаться на них при проверке компетенций вашего кандидата. Почему? Потому что они не имеют контекста и позволяют проверять только те навыки, которые в лучшем случае связаны с разработкой программного обеспечения.
Твит пользователя Max Howell: “Google: 90% наших разработчиков пользуются вашим программным обеспечением (Homebrew), но вы не можете инвертировать “двоичное дерево” на доске, так что замолчите”
Вот отличная аналогия: алгоритмы похожи на слова и фразы на английском языке. Давать вашему кандидату общий тест по программированию перед приемом на работу – все равно что дать автору контента тест, который проверяет их знание грамматики английского языка или словарный запас. Говоря вам, что человек знает много слов, они никак не покажут, может ли он написать отличную статью.
Итак, как вы можете проверить реальные навыки вашего кандидата в разработке программного обеспечения? Давая на выполнение пробные рабочие тесты кода.
Пробные рабочие тесты
Согласно исследованию Университета Айовы, пробные рабочие тесты также являются лучшим показателем будущей эффективности кандидата.
Итак, как они работают?
Эти тесты кодирования позволяют смоделировать день из жизни разработчика программного обеспечения в вашей компании, давая новобранцам практическое задание, будь то проект разработки или задача DevOps по настройке системы. Им предоставляется доступ к той же среде, которую обычно используют ваши разработчики – библиотекам, фреймворкам, GitHub или Stack Overflow. Все это позволяет им увидеть, как может выглядеть «первый день», если бы они работали на вас.
Во время пробного рабочего теста кандидатам дается ограничение по времени, которое отражает, как долго вы обычно ожидаете, чтобы ваш разработчик предоставил подобное решение.
Однако важно отметить, что они проинформированы о требованиях до начала теста. Таким образом, они смогут освоиться в вашей среде разработки программного обеспечения.
По выполнению задания, каждый кандидат получает оценку – не только простое «сдал» или «не сдал». Это означает, что рекрутеры могут быстро сравнить оценки всех кандидатов и решить, с кем продолжать.
Они также могут быстро предоставить обратную связь кандидатам – что важно, потому что лучшие технические таланты уходят с рынка почти мгновенно!
“Большая часть разработчиков работает на постоянной работе, примерно 10% — фрилансеры. Только 5% разработчиков желающих работать сейчас в поиске — статистика на много лучше, чем практически в любой другой сфере деятельности” (Квинси Ларсон)[3]
Вот несколько других причин, по которым вам следует включить пробный рабочий тест в свой процесс набора:
Диаграмма улучшений CodeValue в облaсти найма разработчиков, связанных с использованием сервиса DevSkiller
Собеседования
После того, как вы предварительно квалифицируете своих кандидатов с помощью теста, вам следует провести два типа собеседований – собеседование с HR-специалистом, отвечающее за межличностные навыки / культурные особенности, и техническое интервью с менеджером по найму, техническим директором, техническим руководителем или руководителем группы.
Собеседование о культурных особенностях должно проверить, выглядит ли кандидат так, чтобы другие хотели с ним работать. Самое главное, оно должно установить, как кандидаты могут подходить к конфликтам или разногласиям в команде разработчиков программного обеспечения.
Что касается целей технического собеседования, оно должно проверить:
Кодирование в реальном времени
Целью кодирования в реальном времени не является тщательное изучение каждой строки кода, которую предоставляет кандидат. В конце концов, ошибки случаются даже с лучшими из нас, не говоря уже о кандидатах, которые могут быть подвержены стрессу во время процесса в реальном времени.
Это должно дать представление, как кандидат принимает поставленную перед ним задачу и какие вопросы он задает, чтобы понять, что делает конечное программное обеспечение. Это также позволяет рекрутерам видеть, проверяет ли кандидат правильность кода перед завершением задачи.
Все эти элементы раскрывают коммуникативные навыки вашего кандидата, модели поведения и позволяют увидеть, как он разрабатывает стратегию для работы, которую им поручили.
Пример кода написанного на языке Java
Как оценить навыки программирования: краткое изложение
Поиск квалифицированного разработчика программного обеспечения может оказаться сложной и дорогостоящей задачей. Если вы нанимаете кого-то, кто недостаточно или слишком квалифицирован для этой должности, вы рискуете не только высоким уровнем выбытия сотрудников. Вы также тратите значительные финансовые ресурсы из-за неудачного найма. К счастью для ИТ-работодателей, которые хотят знать, как оценивать навыки программирования, есть много способов проверить навыки программирования своих кандидатов.
Самый эффективный метод оценки – это выполнение пробных рабочих тестов, которые позволяют вам проверить навыки ваших кандидатов в решении проблем, а не только их знание языка или структуры.
Изображения принадлежат Кевину Ку на Unsplash
[1] Цитата из статьи “Insights from Stack Overflow’s 2018 survey of 100,000 developers”
[2] Цитата из статьи “Insights from Stack Overflow’s 2018 survey of 100,000 developers”
[3] Цитата из статьи “Insights from Stack Overflow’s 2018 survey of 100,000 developers”
Обзор составили HR Эксперты ONLINE PERSONAL
Самойленко Геннадий, Данилова Варвара
Бонусные видео
Как оценить навыки разработчика? Какие приемы можно использовать при проведении первичного скрининга для подбора технических специалистов? Где найти достойных специалистов и как выбрать наиболее подходящих?
Если вы хотите узнать ответ на эти вопросы, а также услышать экспертное мнение о том, как правильно подобрать работника на должность разработчика, смотрите вебинар Алексея Исаева, рекрутера с более чем 6-летним опытом, который сталкивается с этими проблемами практически каждый день. В своем честном монологе Алексей рассказывает про различные ресурсы, помогающие в оценке навыков разработчиков, а также отвечает на актуальные вопросы слушателей.
Ссылка на видео “Первичный скрининг: как оценить навыки разработчика”: