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#-функции. Цель — выявить, замечает ли кандидат несоответствия, задаёт ли уточняющие вопросы и умеет ли кратко и по существу описывать код, а не пересказывать его построчно.
Developer Interview Questions: Testing Attention to Detail
Вопросы для собеседования разработчика: проверяем внимание к деталям
In Personality Traits of the Best Software Developers we looked at four key personality traits of the best corporate software developers. One of the comments, posted by Paul Norrie, raised an important question about interviewing: How can we test for attention to detail?
В статье Personality Traits of the Best Software Developers мы рассмотрели четыре ключевые черты характера лучших корпоративных разработчиков. Один из комментариев, оставленный Paul Norrie, поднял важный вопрос о собеседованиях: как проверить внимание к деталям?
Attention to Detail
Внимание к деталям
Someone who pays attention to detail stands less of a chance of forgetting to check their code into source control, checking their code into the wrong place, misspelling method, variable, or column names, having poor quality or missing comments, etc…
Тот, кто внимателен к деталям, с меньшей вероятностью забудет закоммитить код в систему контроля версий, положит его не в то место, ошибётся в написании имён методов, переменных или колонок, оставит некачественные или вовсе пропустит комментарии и так далее.
Here are a few interview questions to get you off in the right direction, realizing you should ask multiple of this type to avoid false negatives:
Вот несколько вопросов для собеседования, которые зададут правильное направление, — учитывая, что подобных вопросов стоит задавать сразу несколько, чтобы избежать ложноотрицательных результатов:
Data Model – Provide a simple, two table data model with two column names spelled slightly differently (e.g., UserKey and UsrKey). Ask the candidate to write an inner join using the misspelled column. Most candidates will notice right away that something is wrong, but if they write the query and match the spellings to the data model you have to give them the benefit of the doubt and assume they didn’t want to offend you by pointing out a mistake. If they write the entire query and spell both columns the same (UserKey and UserKey), you have a problem.
Модель данных — предоставьте простую модель данных из двух таблиц, в которой названия двух колонок написаны слегка по-разному (например, UserKey и UsrKey). Попросите кандидата написать inner join с использованием неверно написанной колонки. Большинство кандидатов сразу заметят, что что-то не так, но если они напишут запрос и подгонят написание под модель данных, придётся дать им презумпцию невиновности и предположить, что они просто не хотели вас обидеть, указывая на ошибку. Если же кандидат напишет весь запрос и напишет обе колонки одинаково (UserKey и UserKey) — у вас проблема.
Paper Form – Give the candidate a very brief paper form asking for their contact information, but instead of asking for their current address ask only for their previous address. The candidate should raise a question about this. If they don’t, ask them if the address they wrote down is their current or previous address.
Бумажная форма — дайте кандидату очень короткую бумажную форму для контактных данных, но вместо текущего адреса попросите указать только предыдущий. Кандидат должен задать уточняющий вопрос. Если он этого не сделает, спросите его, текущий или предыдущий адрес он записал.
Scenario – Give the candidate a scenario: you’re developing software at an enterprise software shop. You have all the standard tools: an IDE, database, source control, unit testing suite and bug tracker. Ask the candidate to provide every step in the process of creating a “Hello World!” application and getting it into QA. Note: There are no right or wrong answers to this question, but some commonly missed steps are: checking the code into source control, labeling the code, creating and checking in unit tests, emailing the appropriate person in QA or Change Management to move the code to QA, checking compiled assemblies into source control (some companies don’t perform this step), and creating and checking in documentation (some companies don’t perform this step – try not to work at those companies).
Сценарий — предложите кандидату ситуацию: вы разрабатываете ПО в enterprise-конторе. У вас есть все стандартные инструменты: IDE, база данных, система контроля версий, набор для модульного тестирования и баг-трекер. Попросите кандидата описать каждый шаг процесса создания приложения «Hello World!» и передачи его в QA. Примечание: правильных или неправильных ответов здесь нет, но часто упускаются такие шаги: коммит кода в систему контроля версий, проставление меток (label), создание и коммит модульных тестов, письмо ответственному в QA или Change Management о переводе кода в QA, коммит скомпилированных сборок в систему контроля версий (в некоторых компаниях этого не делают) и создание и коммит документации (в некоторых компаниях этого тоже не делают — постарайтесь в таких не работать).
Comments – Provide the candidate with a non-trivial function and ask them to write a comment block describing what it does. If at all possible give the candidate a laptop or workstation so they don’t have to write longhand on paper. Misspellings are not the issue here – a succinct, informative description is key. If their comment describes the method line by line that should raise a red flag. A C# sample method I’ve used in the past is:
Комментарии — дайте кандидату нетривиальную функцию и попросите написать блок комментария, описывающий её работу. По возможности дайте кандидату ноутбук или рабочую станцию, чтобы ему не пришлось писать от руки на бумаге. Орфографические ошибки здесь не главное — ключевым является краткое и содержательное описание. Если комментарий описывает метод построчно, это должно стать тревожным сигналом. Вот пример метода на 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); } } }
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); } } }
If you have other ideas please post them in the comments.
Если у вас есть другие идеи, делитесь ими в комментариях.
Paper Form - Give the candidate a very brief paper form asking for their contact information, but instead of asking for their current address ask only for their previous address. The candidate should raise a question about this. If they don't, ask them if the address they wrote down is their current or previous address.
Бумажная форма — дайте кандидату очень короткую бумажную форму для контактных данных, но вместо текущего адреса попросите указать только предыдущий. Кандидат должен задать уточняющий вопрос. Если он этого не сделает, спросите его, текущий или предыдущий адрес он записал.
Scenario - Give the candidate a scenario: you're developing software at an enterprise software shop. You have all the standard tools: an IDE, database, source control, unit testing suite and bug tracker. Ask the candidate to provide every step in the process of creating a "Hello World!" application and getting it into QA. Note: There are no right or wrong answers to this question, but some commonly missed steps are: checking the code into source control, labeling the code, creating and checking in unit tests, emailing the appropriate person in QA or Change Management to move the code to QA, checking compiled assemblies into source control (some companies don't perform this step), and creating and checking in documentation (some companies don't perform this step - try not to work at those companies).
Сценарий — предложите кандидату ситуацию: вы разрабатываете ПО в enterprise-конторе. У вас есть все стандартные инструменты: IDE, база данных, система контроля версий, набор для модульного тестирования и баг-трекер. Попросите кандидата описать каждый шаг процесса создания приложения "Hello World!" и передачи его в QA. Примечание: правильных или неправильных ответов здесь нет, но часто упускаются такие шаги: коммит кода в систему контроля версий, проставление меток (label), создание и коммит модульных тестов, письмо ответственному в QA или Change Management о переводе кода в QA, коммит скомпилированных сборок в систему контроля версий (в некоторых компаниях этого не делают) и создание и коммит документации (в некоторых компаниях этого тоже не делают — постарайтесь в таких не работать).
Comments - Provide the candidate with a non-trivial function and ask them to write a comment block describing what it does. If at all possible give the candidate a laptop or workstation so they don't have to write longhand on paper. Misspellings are not the issue here - a succinct, informative description is key. If their comment describes the method line by line that should raise a red flag. A C# sample method I've used in the past is:
Комментарии — дайте кандидату нетривиальную функцию и попросите написать блок комментария, описывающий её работу. По возможности дайте кандидату ноутбук или рабочую станцию, чтобы ему не пришлось писать от руки на бумаге. Орфографические ошибки здесь не главное — ключевым является краткое и содержательное описание. Если комментарий описывает метод построчно, это должно стать тревожным сигналом. Вот пример метода на C#, который я использовал в прошлом:
private void X(Control parent){Label lbl;
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);}}}
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);}}}
If you have other ideas please post them in the comments.
Если у вас есть другие идеи, делитесь ими в комментариях.