В предыдущей части статьи мы уже говорили, что ИТ-сертификация – это не цель. Это путь и инструмент. Но путь куда и инструмент для чего?

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

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

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

А инструментом ИТ-сертификацию можно считать потому, что ее можно использовать для проверки своего потенциала. Обидно за ребят с инженерным потенциалом, которые наслушавшись о темной, оборотной стороне сертификации, начинают видеть только ее. Их путь становится 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… Но мы преследуем на иные цели и намеренно “заваливать” нам не нужно. Если на экзамене человек кидается делает мешанину, не постаравшись перед этим вычленить характерные узлы-индикаторы, то это его ошибка. И на собеседовании это тоже бы “выстрелило”.

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

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

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