Сертификат Java: за и против

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

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

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

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

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

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

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

Давайте обратимся к еще одному источнику — книге «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»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Представьте спортсмена, желающего добиться высоких результатов. Как он идет к своей цели? Все верно: упорно тренируется. Он составляет план, следует проверенным методикам, советуется с тренерами и читает специальную литературу. Чем это отличается от подготовки к сертификации? Все то же самое: есть апробированные методики; структурированные пособия и видеокурсы, где все разложено по полочкам; есть тысячи общедоступных упражнений для отслеживания своего прогресса; есть возможность консультироваться со специалистами.

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

Я пытаюсь донести простую мысль: ИТ-сертификация — это путь, а не результат. Та самая Дорога из желтого кирпича. Мы все знаем, что Изумрудный город в ее конце оказался фейком. И точно так же мы знаем, что весь смысл приключения, что наши герои шли по этой Дороге. ИТ-сертификация — это не мифический Радужный мост, по ту сторону которого зарыт некий горшочек с золотом. Здесь все куда реальнее — плоды вашей работы.

А инструментом ИТ-сертификацию можно считать потому, что ее можно использовать для проверки своего потенциала. Обидно за ребят с инженерным потенциалом, которые, наслушавшись о темной, оборотной стороне сертификации, начинают видеть только ее. Их путь становится zero-sum game, игрой с нулевым исходом, где сертификация — просто трата времени, хотя ресурсы, доступ к которым она открывает, нашу жизнь могут только украсить и расцветить. Это не цель, а средство.

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

Rules for String are mean ’n tough,
Learn by heart this bloody stuff:
No delete() and no insert() –
That’s the way to Java cert.
add() to List to feel no pain,
Use remove() – or clear() its brain.
And remember that replace()
Can explode right in your face:
While in String it overloads,
SB follows other roads.

А теперь ближе к теме. После каждого экзамена мы собираем фидбэк. И вот пример отзыва (не дословно, но близко к тексту): «…Такое впечатление, что вопросы про вложенные циклы специально придуманы, чтобы тратить время, приходится выписывать на бумажку и подсчитывать вручную… Вопросы про вызовы конструкторов и ключевые слова this и super можно было задавать и по-другому…»

Обратимся к первому пункту. Подозреваю, что знаю, о каком вопросе идет речь (их у нас там пара-тройка «особенных»). Вот как он выглядит:

Дано:

class KillingMeSoftlyWithHisWords{
public static void main(String[] args) {
 	// ответ вставлять СЮДА
 	int x = 0, y = 3;
 	while(x < a) {
     	do {
         	int k = 0;
         	while (k < c) {
             	System.out.print(k + " ");
             	k++;
         	}
                System.out.println("");
         	y--;
     	} while (b >= y);
            System.out.println("-------");
     	x++;
 	}
}
}

Надо напечатать следующую табличку:

0 1 2 3
-------
0 1 2 3
-------

Какая опция, если ее вставить в указанное место, позволит это сделать?

A. int a = 1, b = 3, c = 2;
B. int a = 2, b = 0, c = 4;
C. int a = 3, b = 2, c = 4;
D. int a = 3, b = 3, c = 3;

На экзамене есть несколько правил, о которых следует помнить. Например, поскольку время тестирования ограничено, ответы на вопросы не должны выходить за границу. В нашем случае 3 часа на 75 вопросов — следовательно, один вопрос — 140 секунд. В действительности мы редко когда выходим за 120 секунд, причем многие вопросы требуют лишь 20-30 секунд или того меньше. Это позволяет сэкономить время и для перепроверки.

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

Отсюда простое следствие: ни один вопрос не подразумевает самоистязание. Когда мы видим «сложный» вопрос, надо сразу сказать себе: «Ага! Это и есть слабое место, нужно будет исправить».

Удобным индикатором выступают операторы печати: они своего рода зонды, встроенные в поток бизнес-логики. Давайте присмотримся: в консоль прилетают две строки из дефисов — внешний while() отрабатывает сколько раз? И если условие гласит x < a, причем x проинициализирован значением 0, то чему должна быть равна переменная a? И сколько таких возможных опций среди предложенных вариантов?..

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

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

public int m(int f, int g) {
try {
   int[] far = new int[f];
   far[g] = 1;
   return f;
   }catch(NegativeArraySizeException e) {
   f = -f;
   g = -g;
   return (-m(f, g) == -f) ? -g : -f;
   }catch(IndexOutOfBoundsException e) {
   return (m(g, 0) == 0) ? f : g;
   }
}

Он вычисляет максимум в двухэлементном кортеже входных параметров, сиречь f и g… Но мы преследуем иные цели, и намеренно «заваливать» нам не нужно. Если на экзамене человек кидается, делает мешанину, не постаравшись перед этим вычленить характерные узлы-индикаторы, то это его ошибка. И на собеседовании это тоже бы «выстрелило».

Перейдем теперь ко второй претензии — вопросы можно бы формулировать и по-другому.

Никто с этим спорит. Но хочется спросить: а обладают ли экзаменационные вопросы сверхтекучестью? Они же рано или поздно утекают из любого контейнера! И это ведет к негативным последствиям, раскручиваемым противниками ИТ-сертификации. И как же нам бороться с этим «продуктом»? Мы видим только один рациональный выход: экзаменационных вопросов должно быть много. Извлекаются они из Тестового банка рандомно, и если кому-то прилетела не та формулировка, которая успела полюбиться за долгие годы, то не факт, что ее у нас нет вообще. Думаю, она сидит где-нибудь в Банке. Так что вряд ли вторая претензия обоснована.

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

Источник: https://habr.com/ru/companies/ibs/articles/750544/


Интересные статьи

Интересные статьи

История про «восстание машин» давно знакома всем любителям научной фантастики, но после взрывного роста возможностей нейросетевых языковых моделей (вроде ChatGPT) об этом риске заговорили и вполне сер...
Прочтите эту статью и узнайте о необычных вещах в Java, которые могут оказаться на удивление полезными.Есть вещи, которые вы можете делать в Java, но вы их редко видите. В основном потому, что в них н...
iPhone быстрые? Да! Но почему? Apple мало что рассказывает нам про внутренности своих девайсов. Как будто скрывает от нас страшную тайну! Например, знали ли вы что в iPhone и в ...
Приветствую, Дорогие Друзья. Продолжаем цикл статей, освещающий деятельность (бурную) нашей некоммерческой организации. Как и обещал — переходим от простого (логирование) к более сложному: мета...
Amazon надоело доминировать только на онлайн-рынке. После открытия своего первого уникального магазина без касс в Сиэтле в начале прошлого года, эти супермаркеты IT-гиганта, следящие за вашим...