Еще раз о собеседовании

Мне довелось на этой неделе неделе на пару с коллегой - тимлидом дружественной команды собеседовать кандидата на должность Java-разработчика. Для меня это был дебют. В Академосе я, правда, проверял тесты - но это совсем другое. Сидеть на собеседовании с Другой Стороны Стола и задавать вопросы - это куда как более сильно.

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

Мы спросили про опыт работы и готовые проекты. Узнав, что человек занимался системой учета персонала, я зацепился за слово "персонал" и стал выяснять, как бы он сохранил список персонала на диске или передавал бы его по сети. Соответственно, обсудили Serializable (знал) и Externalizable (плавал). Поговорили о паттернах - попутно выяснив, что кандидат не знает UML, хоть в резюме и обещал. Потрепались об MVC на примере компонента JTable, который рисует табличку. Говорили также о многопоточности в Java и особенностях ее в Swing (человек хвастал знаниями Swing'а, но о его вопиющей не-потоко-безопасности - опять ни сном ни духом).

Дал я ему потом задачку, которую сам придумал. Идею дарю. Итак, надо спроектировать Стол. Стол имеет ножки и столешницу. На столешницу в первой версии Стола можно класть листы бумаги и стакан, куда кладут ручки и карандаши. Если б кандидат знал UML - рисовал бы у меня диаграмму классов, а так ему пришлось это все выражать в коде на бумажке. Потом мы обсуждали реализацию, вносили изменения в требования, и смотрели как он с ними справляется. Например, у него было два списка - один список для стаканов, другой - для бумаги. На запрос "поддержать в новой версии Стола возможность класть на него книги" кандидат предложил ввести еще один список - для книг... Ну, короче, такая задачка, на мой взгляд, позволяет немного судить о том, как человек думает и проектирует.

Потом еще про алгоритмы спрашивали (сам виноват - зачем писал в резюме про "знание алгоритмов сортировки, поиска, и т.д."). Про сложность алгоритмов он никогда не слышал, ни один алгоритм сортировки даже не назвал, про binary search не рассказал...

Еще о многом говорили - зацепили Exception'ы, особенности Java 1.5, Eclipse, SWT... Короче, промурыжили мы его около часа, и не взяли. Хочу теперь проводить много собеседований. Как мне кажется, решение "не взять" - гораздо менее ответственное, чем "взять". Поэтому хочу теперь кого-то "взять". Джависты, ау! У нас правильный настрой!!!

UPD 13.02.07: вчера еще одного собеседовал! Этому давал уже две задачки - одну на простой алгоритм, и другую - на простое проектирование, но уже не про стол, а про автобус. Дела идут...

2 коммент. | добавить комментарий :: Еще раз о собеседовании

  1. ну вот колбасишь, колбасишь однотипные интерфейсы от забора и до обеда, а потом простейший стол конструируешь за полчаса(((((
    И то не факт что правильно

    Давайте ваш "автобус"!

  2. Ну что - нужно сделать Автобус, у Автобуса есть двигатель, колеса, кузов, двери. Перевозить он может пассажиров - в первой версии))

    Собственно, вопросы - не путать агрегацию с композицией, уметь перевозить что-то кроме пассажиров, поддерживать замену двигателя, колес... Двери - это объекты класса Дверь или массив булевых переменных? Двигатель - это private или public класс? Нужно ли метод void ремонт() проводить через Автобус, или достаточно иметь его в Двигателе?

    Как-то так...

Отправить комментарий