judith

Обычно наоборот стараются по клику на контейнер отмечать checkbox, так юзабельнее и правильнее.
Тем не менее, в качестве примера

$("input.input-checkbox").click(function(){ 
    $(this).parent("li").addClass("checked");
},function(){
    $(this).parent("li"). removeClass("checked");
});

Не проверял, но должно работать.

<jоke>А в этот вечер на стажёра найдёт просветление, он полезет в гугл за регулярками, наткнётся на хабр, зайдёт в qa, и....</jоke>
Хотя…

(Есть шанс, что вы взяли «не того» стажера. Судя по вашим комментариям выше я понял что опыт в программировании у него 0. И дело не в наличии/отсутсвии «опыта работы», а в том, что человек которому интересно этим заниматься — часто пишет программы «для себя». «Сильный интерес» — это одно из главных слагаемых успеха, а самостоятельно написанные хобби-программы — как раз признак наличия интереса.)

Как с ним работать (особенно хорошо если сроков жестких нет)
Cформулировать задание (желательно связанное с программированием, а не с изменением width:200px на wiidth 300px в css файле) (скорей всего на первых порах оно будет связано с процедурным программированием), попросить подумать над решением и (т.к. опыт 0) и записать его своими словами на листе бумаги/в текстовом файле в виде словесного описания алгоритма.
Как будет готов — вы просматриваете что он придумал. В этот момент вы сможете увидеть места в которых он пытается реализовать билиотечные функции и для этих мест посоветуете ему ознакомиться с соответсвующей документацией. Кроме того если в этот момент вы видите что получается ерунда, можно или наводящими вопросами подвести его к правильной мысли. Или если вопрос достаточно сложен — предложить свой вараинт и спросить что он по этому поводу думает: достоинства-недостатки-что-лучше.
Как только оно алгоритм скорректирован — ему останется просто, пользуясь словарём, перевести с одного языка на другой.

Когда с процедурным стилем будет получаться лучше — пришло время ознакомить его со стандартами кодирования принятыми в компании (Очень хорошо если они будут без глупостей и фанатизма).

ООП. Если вы уверены что у вас правильное ООП и оно вам действительно нужно, то «когда придёт время», то предварительно пусть ознакомится с принципами SOLID и основами UML (диаграммы классов, объектов, последовательностей) — этом поможет вам обсуждать архитектурные решения. А дальше тоже самое: формулируется задание. Он его обдумывает, рассазывает как решил делать декомпозицию и почему. Вы предлагаете свой вариант. Всё это обсуждается опираясь на принципы SOLID.

Вот примерно так. Не позволяем себе высокомерия и фразочек вроде «чему вас только в институте учат» и «ну кто так пишет», не забываем хвалить когда он всё делает правильно.

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

Я не хочу Вас обидеть, но посоветовать новичку регулярки использовать, это надо было догадаться.

А если конструктивно, то долбить, долбить и долбить, как правильно писать код. Парное программирование, код ревью и прочее. Повторение — мать учения.
Ну и книги какие-то вручить. Например, классический Code Complete.

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

Ну я кота к лотку приучил так:
Тыкал в говнокод и бил! Теперь он великолепно программирует на лотке

Вы родственника взяли, что ли?