Java-сертификация: "за" и "против”. Часть 1

Подписывайтесь на наш канал в Telegram:
больше материалов экспертов, анонсы бесплатных вебинаров и задачки для IT-специалистов

Подписаться

Характерное и показательное мнение, которое я хочу вам представить, принадлежит Джефу Этвуду, одному из основателей StackOverflow. Речь идет про одну из страничек его блога "Ужасы кодинга". Обратите внимание на дату: середина января 2007-го. Другими словами, это тема давно тревожит ИТ-сообщество. 

Этвуд открытым текстом говорит, что не верит в сертификацию, что она не может заменить портфолио и профессиональный опыт. Он также приводит слова из чужого блога, тем самым, по сути, подписываясь под ними: "Certification is for the weak", т.е., "Сертификация — это для слабаков".

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

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

Давайте обратимся к еще одному источнику — книге "Cracking the Coding Interview" Гейл Лаакман-Макдауэлл. Помимо книг, она известна тем, что берет на аутсорсинг проведение технических интервью с кандидатами Google и других крупных компаний. В в 6-м издании своей книги (стр. 29) она говорит буквально следующее: "Certifications for software engineers can be anything from a positive, to a neutral, to a negative. This goes hand-in-hand with being too language focused; the companies that are biased against candidates with a very lengthy list of technologies tend to also be biased against certifications. This means that in some cases, you should actually remove this sort of experience from your resume."

Я выделил последнее предложение. Его можно перевести как: "Это означает, что в ряде случаев вам и впрямь следует убрать из своей анкеты упоминания о таком жизненном опыте". В смысле, о сертификации. 

В итоге, мы видим убедительные доказательства. Но что дальше? Мы знаем про недостатки, где же достоинства?

ИТ-сертификация — это лучший подарок подаренный самому себе, и сделанный своими силами. Ценность этого подарка — знания, навыки, квалификация… Их никто никогда у тебя не отнимет, ни при каких условиях. Чтобы все это получить, требуется лишь одно: осознанное понимание того, зачем и с какой целью ты это делаешь. 

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

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

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

Для этого мы переработали вопросы традиционных экзаменов от Oracle и добавили новые темы, такие как: Git, Maven, работа с СУБД и фреймворками, модульное тестирование на базе JUnit, виртуализация, Docker-контейнеры и Kubernetes, а также принципы создания безопасного кода и паттерны проектирования. 

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

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

Например, софтверным домам нужны спринговики. Потому что в тренде облака, SaaS, PaaS и микросервисы. Именно поэтому в нашей сертификации есть такие вопросы об этих инструментах. 

В рамках собеседования проверить навыки владения всеми инструментами не возможно. Для этого нужно предложить соискателю поработать в соответствующем проекте. Но как это сделать в рамках экзамена с форматом multiple choice?

Дать проект в качестве домашнего задания? Такое практикуется на уровне Master или Senior, но делать это для Junior и в массовом порядке — очень сложно. Здесь на помощь приходит сертификация.

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

И если потенциальный соискатель вдруг да не пройдет нашу сертификацию, вовсе не означает, что такому человеку не место в ИТ-отрасли.

А знаете, я ведь свою первую сертификацию Java завалил. Одного процента не дотянул. И вот только тогда началось самое интересное. Только тогда я прозрел и понял, как устроен сертификационный экзамен, чего он в действительности хочет и как его надо сдавать, но об этом мы поговорим во второй части статьи.