В предыдущей части статьи мы уже говорили, что ИТ-сертификация – это не цель. Это путь и инструмент. Но путь куда и инструмент для чего?
Представьте спортсмена, желающего добиться высоких результатов. Как он идет к своей цели? Все верно: упорно тренируется. Он составляет план, следует проверенным методикам, советуется с тренерами и читает специальную литературу. Чем это отличается от подготовки к сертификации? Все то же самое: есть апробированные методики; структурированные пособия и видеокурсы, где все разложено по полочкам; есть тысячи общедоступных упражнений, для отслеживания своего прогресса; есть возможность консультироваться с специалистами.
Перед началом освоения той или иной технологии я всегда проверяю, есть ли по этому направлению сертификация или курсы с выпускными тестами, а лучше экзаменами. Вы листали пособия по этим сертификациям? Если еще нет, то я вам завидую: вы сделаете себе отличный подарок. И даже не надо сдавать экзамен, достаточно в полную силу взяться за подготовку к нему.
Я пытаюсь донести простую мысль: ИТ-сертификация – это путь, а не результат. Та самая Дорога из желтого кирпича. Мы все знаем, что Изумрудный город в ее конце оказался фейком. И точно так же мы знаем, что весь смысл приключения, что наши герои шли по этой Дороге. ИТ-сертификация – это не мифический Радужный Мост, по ту сторону которого зарыт некий горшочек с золотом. Здесь все куда реальнее – плоды вашей работы.
А инструментом ИТ-сертификацию можно считать потому, что ее можно использовать для проверки своего потенциала. Обидно за ребят с инженерным потенциалом, которые наслушавшись о темной, оборотной стороне сертификации, начинают видеть только ее. Их путь становится 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… Но мы преследуем на иные цели и намеренно “заваливать” нам не нужно. Если на экзамене человек кидается делает мешанину, не постаравшись перед этим вычленить характерные узлы-индикаторы, то это его ошибка. И на собеседовании это тоже бы “выстрелило”.
Перейдем теперь ко второй претензии – вопросы можно бы формулировать и по-другому.
Никто с этим спорит. Но хочется спросить: а обладают ли экзаменационные вопросы сверхтекучестью? Они же рано или поздно утекают из любого контейнера! И это ведет к негативным последствиям, раскручиваемым противникам ИТ-сертификации. И как же нам бороться с этим "продуктом"? Мы видим только один рациональный выход: экзаменационных вопросов должно быть много. Извлекаются они из Тестового Банка рандомно, и если кому-то прилетела не та формулировка, которая успела полюбиться за долгие годы, то это не факт, что ее у нас нет вообще. Думаю, она сидит где-нибудь в Банке. Так что вряд ли вторая претензия обоснована.
На этой ноте я и закончу; мне ведь еще очередную партию вопросов составлять. Но вы к нам приходите, хотя бы на подготовительные курсы. Там много интересного – и, искренне надеюсь, теперь вы знаете почему.