Developer Interview Questions: Testing Attention to Detail | Rob Walling
Роб Уоллинг рассматривает, как на собеседовании проверить у разработчика внимание к деталям — качество, которое отличает лучших корпоративных программистов. Вопрос поднял в комментариях Пол Норри к предыдущей статье «Personality Traits of the Best Software Developers». Автор предлагает четыре практических задания: показать модель данных с двумя похожими, но по-разному написанными названиями колонок (UserKey и UsrKey) и попросить написать inner join; дать бумажную форму, где вместо текущего адреса спрашивается предыдущий; попросить расписать все шаги доставки приложения «Hello World!» в QA в типичном enterprise-окружении; и предложить написать комментарий к нетривиальной C#-функции. Цель — выявить, замечает ли кандидат несоответствия, задаёт ли уточняющие вопросы и умеет ли кратко и по существу описывать код, а не пересказывать его построчно.
Вопросы для собеседования разработчика: проверяем внимание к деталям
В статье Personality Traits of the Best Software Developers мы рассмотрели четыре ключевые черты характера лучших корпоративных разработчиков. Один из комментариев, оставленный Paul Norrie, поднял важный вопрос о собеседованиях: как проверить внимание к деталям?
Внимание к деталям
Тот, кто внимателен к деталям, с меньшей вероятностью забудет закоммитить код в систему контроля версий, положит его не в то место, ошибётся в написании имён методов, переменных или колонок, оставит некачественные или вовсе пропустит комментарии и так далее.
Вот несколько вопросов для собеседования, которые зададут правильное направление, — учитывая, что подобных вопросов стоит задавать сразу несколько, чтобы избежать ложноотрицательных результатов:
Модель данных — предоставьте простую модель данных из двух таблиц, в которой названия двух колонок написаны слегка по-разному (например, UserKey и UsrKey). Попросите кандидата написать inner join с использованием неверно написанной колонки. Большинство кандидатов сразу заметят, что что-то не так, но если они напишут запрос и подгонят написание под модель данных, придётся дать им презумпцию невиновности и предположить, что они просто не хотели вас обидеть, указывая на ошибку. Если же кандидат напишет весь запрос и напишет обе колонки одинаково (UserKey и UserKey) — у вас проблема.
Бумажная форма — дайте кандидату очень короткую бумажную форму для контактных данных, но вместо текущего адреса попросите указать только предыдущий. Кандидат должен задать уточняющий вопрос. Если он этого не сделает, спросите его, текущий или предыдущий адрес он записал.
Сценарий — предложите кандидату ситуацию: вы разрабатываете ПО в enterprise-конторе. У вас есть все стандартные инструменты: IDE, база данных, система контроля версий, набор для модульного тестирования и баг-трекер. Попросите кандидата описать каждый шаг процесса создания приложения «Hello World!» и передачи его в QA. Примечание: правильных или неправильных ответов здесь нет, но часто упускаются такие шаги: коммит кода в систему контроля версий, проставление меток (label), создание и коммит модульных тестов, письмо ответственному в QA или Change Management о переводе кода в QA, коммит скомпилированных сборок в систему контроля версий (в некоторых компаниях этого не делают) и создание и коммит документации (в некоторых компаниях этого тоже не делают — постарайтесь в таких не работать).
Комментарии — дайте кандидату нетривиальную функцию и попросите написать блок комментария, описывающий её работу. По возможности дайте кандидату ноутбук или рабочую станцию, чтобы ему не пришлось писать от руки на бумаге. Орфографические ошибки здесь не главное — ключевым является краткое и содержательное описание. Если комментарий описывает метод построчно, это должно стать тревожным сигналом. Вот пример метода на C#, который я использовал в прошлом:
private void X(Control parent) { Label lbl; foreach (Control ctl in parent.Controls) { if ((ctl) is Label) { lbl = ((Label)(ctl)); if (lbl.CssClass == “error”) { lbl.CssClass = “formlabel”; } } else if (ctl.Controls.Count > 0) { X(ctl); } } }
Если у вас есть другие идеи, делитесь ими в комментариях.
Бумажная форма — дайте кандидату очень короткую бумажную форму для контактных данных, но вместо текущего адреса попросите указать только предыдущий. Кандидат должен задать уточняющий вопрос. Если он этого не сделает, спросите его, текущий или предыдущий адрес он записал.
Сценарий — предложите кандидату ситуацию: вы разрабатываете ПО в enterprise-конторе. У вас есть все стандартные инструменты: IDE, база данных, система контроля версий, набор для модульного тестирования и баг-трекер. Попросите кандидата описать каждый шаг процесса создания приложения "Hello World!" и передачи его в QA. Примечание: правильных или неправильных ответов здесь нет, но часто упускаются такие шаги: коммит кода в систему контроля версий, проставление меток (label), создание и коммит модульных тестов, письмо ответственному в QA или Change Management о переводе кода в QA, коммит скомпилированных сборок в систему контроля версий (в некоторых компаниях этого не делают) и создание и коммит документации (в некоторых компаниях этого тоже не делают — постарайтесь в таких не работать).
Комментарии — дайте кандидату нетривиальную функцию и попросите написать блок комментария, описывающий её работу. По возможности дайте кандидату ноутбук или рабочую станцию, чтобы ему не пришлось писать от руки на бумаге. Орфографические ошибки здесь не главное — ключевым является краткое и содержательное описание. Если комментарий описывает метод построчно, это должно стать тревожным сигналом. Вот пример метода на C#, который я использовал в прошлом:
private void X(Control parent){Label lbl;
foreach (Control ctl in parent.Controls) {if ((ctl) is Label) {lbl = ((Label)(ctl));if (lbl.CssClass == "error") {lbl.CssClass = "formlabel";}} else if (ctl.Controls.Count > 0) {X(ctl);}}}
Если у вас есть другие идеи, делитесь ими в комментариях.