Как вы проводите собеседование с кандидатом в программист базы данных / администратором?

Во время собеседования я задаю основные вопросы дизайна базы данных. Нормализация (когда и почему) - одна из моих проблем, когда дело доходит до проектирования базы данных. Некоторые сценарии I сайта, которые включают синхронизированные серверы и что / почему / как они принимают во внимание связанные проблемы; вопросы безопасности и тд.

1. Вы бы спросили их из контекста конкретной системы баз данных (например, Oracle), что они предпочитают?
2. Какие технические вопросы вы бы им задали?
3. Какие сценарии вы бы разместили на сайте и что бы вы искали в качестве ответов на эти сценарии?
4. Как бы вы узнали, если они разбираются в вопросах безопасности?
5. Другие связанные вопросы. (например, Восстановление БД / Резервное копирование)

Спасибо.

Вот мои 10 лучших вопросов для старших администраторов баз данных и 10 лучших вопросов для Тома Ларока для начинающих администраторов баз данных.

Я заметил, что другие люди предполагают, что кандидат должен устранить неполадки на сервере. Если вы используете такой подход, используйте виртуальную машину со снимком. Настройте сервер определенным образом с определенными проблемами конфигурации или производительности, сделайте его снимок, а затем после каждого собеседования вы сможете вернуться к снимку.

Если вы сделаете это, ограничьте задачи теми видами задач, которые вы на самом деле выполняли бы. Не спрашивайте производственного администратора баз данных о нормализации и не спрашивайте администраторов разработки, почему один узел не присоединится к кластеру.

Задачи производственного DBA могут быть:

• Настройте задания для резервного копирования, обслуживания индекса и DBCC. Посмотрите, спрашивают ли они вас, как часто вы хотите выполнять резервное копирование базы данных, и хотите ли вы делать ее резервное копирование локально или по сети. Не спрашивайте их, как настроить конкретное программное обеспечение для резервного копирования на ленту, если оно уже не находится в их резюме.
• Узнайте, почему Джонни не может войти в систему и выполнить свой запрос.
• Кто-то жалуется на медленный запрос. Покажите мне, где вы будете искать, чтобы узнать, что происходит. Затем скажите, что они просто позвонили и сказали, что их запрос завершен, но они хотят убедиться, что это больше не повторится.
• Восстановите одну таблицу из резервной копии прошлой ночью.

Задачи разработки могут быть:

• Отладьте эту хранимую процедуру.
• Интерпретировать этот план выполнения.
• Создайте представление, чтобы присоединить клиентов к счетам.

Используйте схему AdventureWorks. Скорее всего, они не играли с этим в последнее время, но, по крайней мере, это легко объяснить.

В моей команде разработчиков программного обеспечения мы проводим тестирование на понимание баз данных.

Мы представляем - очень плохой дизайн (например, приложение типа CRM) и просим их улучшить дизайн после 30 минут размышлений.

Затем мы задаем им больше вопросов, основываясь на том, о чем они говорят.

Мы ищем понимание

• Performance V Normalistion
• Ключевой дизайн и референтная целостность
• Места для улучшения -ie Альтернативная структура БД - триггеры, просмотр, процедуры
• Области, которые являются слабыми в дизайне - как преодолеть многие отношения
• Как это влияет на сервер - поддержка
• Проблемы безопасности данных
• Проблемы безопасности приложений

Затем мы, как команда, подумали о том, что мы считаем ответами типа «младший / старший / архитектор» на эти типы вопросов.

Так для - Производительность v Нормализация -

будет видеть проблему в первую очередь и сможет обсудить почему (младший)

рекомендовал бы 4/5 NF, но понял бы проблему с производительностью, они бы денормализовали и поняли, как сформулировать проблему (Старший)

рекомендуют ли они другой тип дизайна, например, Star Schema, и обсудят последствия на многих уровнях (Архитектор)

• Ключевые дизайн и ссылочная целостность

Предполагается, что целостность ссылки необходима для обеспечения взаимосвязи данных и возможности обсудить это, но не увидит проблему с Key Choice and Design (Junior)

Обсудили бы вопросы, связанные с объемами данных и типами данных v в поисках естественных ключей в данных, и смогли бы обсудить, почему они смотрят на них - и вопросы, которые следуют с ссылочной целостностью (Старший)

Мог спорить с различными точками зрения, связанными с ключами и целостностью, и иметь возможность предлагать различные актуальные модели для быстрого проектирования (архитектор)

Вы получаете картину.

Если вы хотите, чтобы я добавил больше, оставьте комментарий и подробно опишите, что мы думаем об остальном, а просто включите первые два, чтобы дать вам представление о том, что мы думали.

Смысл в том, чтобы подумать о 1. вопросах 2. Затем мы, как команда , подумали о том, что мы считаем ответами типа «младший / старший / архитектор» на эти типы вопросов.

Я подчеркиваю, что команда как кандидат, и команда должна быть уверена в навыках вступающего в игру человека, и, если они придумали то, что они считают ответами на разные уровни, человек, который вступает, будет лучше соответствовать команде. Это также дает команде возможность влиять на выбор кандидата. Они также назначают человека, который будет включен в панель вопросов. Очень помогает с командным бай-ином.

Вы можете создать вымышленную базу данных, в которой было несколько проблем с нормализацией, потенциальные проблемы с безопасностью, но в целом это выглядит довольно типично, как база данных сотрудников. Затем вы могли бы начать задавать респонденту простые вопросы в соответствии с тем, как они будут получать определенные данные в базе данных с помощью объединений, прокладывая себе путь к более сложным вопросам, касающимся вопросов нормализации и безопасности.

См Смарт и Готово

... и спросите их, какие книги они читали в последнее время, какие блоги они читают и какие подкасты они слушают. И спросите, участвуют ли они на stackoverflow.com и serverfault.com ;-)

Это не обязательно связано с базой данных, но я хотел бы добавить к интервью практическое решение проблем и сценарий проектирования.

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

Для сценария проектирования я даю кандидату общую схему нового проекта (то есть без унаследованных зависимостей) и прошу его разработать общий дизайн в своей конкретной области (будь то администратор БД, системы или сеть), который соответствует целям проекта. Главное, чтобы проект был достаточно маленьким, чтобы кто-то мог держать весь сценарий в голове, и объяснение заняло не более нескольких минут.

Пример, который я использую здесь для своих систем и сетевых специалистов, - это описание их дизайна для небольшого филиала, который создается с учетом определенных ограничений нашего бизнеса. Со стороны DBA, возможно, используйте небольшое / очевидное приложение CRUD. В любом случае, вы ищете не детальный дизайн, а скорее общий обзор и посмотрите, ищет ли кандидат общие проблемы, которые возникают.

Важный момент для обоих этих сценариев состоит в том, чтобы открыть обсуждение по теме и позволить кандидату вести обсуждение со своими собственными вопросами. Должно быть ясно, что вы не запрашиваете точного ответа ни на один из них.

Как вы видите, мне очень не нравятся мелочи в интервью, и я думаю, что это дает мне более глубокое понимание способностей кандидатов.

дайте ей / ему поговорить. спросите о прошлом опыте, спросите, с какими проблемами он столкнулся и как с ними справился. Какова была мотивация выбора того или иного решения общих проблем? мониторинг? масштабирование, масштабирование, безопасность.

Я думаю, что вы можете многое рассказать о человеке, просто слушая.

тогда, если вы ищете конкретный опыт в данной области, задайте подробные вопросы - предложение от Стефана Тиберга очень хорошо.