Во время собеседования я задаю основные вопросы по проектированию баз данных. Нормализация (когда-почему) - одна из моих проблем, когда дело касается дизайна базы данных. Некоторые сценарии I сайта, которые включают синхронизированные серверы и что / почему / как они учитывают связанные проблемы; вопросы безопасности и так далее.
Спасибо.
Вот 10 моих главных вопросов на собеседовании для старших администраторов баз данных, и вот 10 главных вопросов Тома ЛаРока для младших администраторов баз данных.
Я заметил, что другие люди предлагают кандидату устранить неполадки на сервере. Если вы выберете такой подход, используйте виртуальную машину со снимком. Настройте сервер определенным образом с определенными проблемами конфигурации или производительности, сделайте его снимок, а затем после каждого интервью вы можете откатиться к снимку.
Если вы это сделаете, ограничьте задачи теми задачами, которые вы действительно должны выполнять. Не спрашивайте производственного администратора баз данных о нормализации и не спрашивайте администратора базы данных-разработчика, почему один узел не присоединяется к кластеру.
Задачи производственного администратора базы данных могут быть следующими:
Задачи разработки могут быть:
Используйте схему AdventureWorks. Скорее всего, они не играли с этим в последнее время, но, по крайней мере, это легко объяснить.
В моей команде разработчиков программного обеспечения в рамках собеседования мы проверяем понимание баз данных.
Мы представляем - очень плохой дизайн (подумайте о приложении типа CRM) и просим их улучшить дизайн после примерно 30 минут размышлений.
Затем мы задаем им дополнительные вопросы, основанные на том, о чем они говорят.
Мы пытаемся понять
Затем мы как команда подумали о том, что мы будем считать ответами типа младший / старший / архитектор на эти типы вопросов.
Итак, для - Производительность v Нормализация -
увидит проблему в первую очередь и сможет обсудить, почему (Младший)
рекомендовал бы 4/5 NF, но поймете проблему с производительностью, если бы они денормализовали, и поймете, как сформулировать проблему (старший)
порекомендуют ли они другой тип дизайна, например, звездную схему, и обсудят последствия на многих уровнях (архитектор)
Увидел бы, что для обеспечения взаимосвязей данных необходима целостность ссылки, и смог бы обсудить это, но не увидел бы проблемы с Key Choice and Design (Junior)
Обсудил бы вопросы, связанные с объемами данных и типами данных v поиск естественных ключей в данных и смог бы обсудить, почему они смотрят на них - и проблемы, которые следуют за ссылочной целостностью (старший)
Могут спорить с разными точками зрения на ключи и целостность и иметь возможность предлагать различные актуальные модели для быстрого проектирования (архитектор)
Вы уловили картину.
Если вы хотите, чтобы я добавил больше, то оставьте комментарий и подробно расскажу, что мы думаем об остальном, но просто включил первые два, чтобы дать вам представление о том, что мы думали.
Дело в том, чтобы подумать о 1. вопросах 2. Мы как команда затем подумали о том, что мы будем считать ответами типа младший / старший / архитектор на эти типы вопросов.
Я подчеркиваю, что команда как кандидат, и команда должна быть уверена в навыках приходящего человека, и если они придумали то, что они видят в качестве ответов на разные уровни, то приходящий человек, надеюсь, лучше подойдет команде. Это также дает команде возможность влиять на выбор кандидата. Они также назначают человека в группу вопросов. Очень помогает с командным бай-ином.
Вы можете создать вымышленную базу данных, в которой есть несколько проблем с нормализацией, потенциальных сбоев в системе безопасности, но в целом это выглядит довольно типично, как база данных сотрудников. Затем вы можете начать с того, чтобы задать респонденту простые вопросы о том, как они будут собирать определенные данные в базе данных посредством объединений, и постепенно переходите к более сложным вопросам о проблемах нормализации и безопасности.
Видеть Умный и добивается цели
... и спросите их, какие книги они читали в последнее время, какие блоги они читают и какие подкасты слушают. И спросите, участвуют ли они в stackoverflow.com и serverfault.com ;-)
Это не обязательно связано с базой данных, но я люблю добавлять к собеседованию практическое решение проблем и сценарий проектирования.
Для решения практических задач имейте систему или системы, к которым пользователь может получить доступ, и попросите их устранить нерешенную проблему. Мои личные фавориты здесь - это проблемы с производительностью, поскольку это не обязательно что-то, что можно воспроизвести по запросу на собеседовании, и редко есть один правильный ответ. Вместо этого вы можете наблюдать, как кандидат выполняет свой процесс устранения неполадок, и ему также необходимо будет начать обсуждение с вами, чтобы получить дополнительную информацию о среде. Ключ к тому, чтобы интервьюер был честен в отношении проблемы и не превращал сценарий в поиск пасхальных яиц из-за одного неверно настроенного окружения или чего-то подобного.
Что касается сценария проектирования, я даю кандидату общую схему нового проекта (то есть без устаревших зависимостей) и прошу его разработать общий дизайн в своей конкретной области (будь то администратор баз данных, системы или сеть), который соответствует целям проекта. Ключ в том, чтобы проект был достаточно небольшим, чтобы кто-то мог держать весь сценарий в своей голове, и на его объяснение уходит не больше нескольких минут.
Пример, который я использую здесь для своих системных и сетевых специалистов, - это описание их дизайна для небольшого филиала, который создается с учетом определенных ограничений нашего бизнеса. Со стороны администратора баз данных можно использовать небольшое / очевидное приложение CRUD. В любом случае вам нужен не подробный дизайн, а более подробный обзор и посмотрите, ищет ли кандидат общие возникающие проблемы.
Важным моментом для обоих этих сценариев является начало обсуждения темы и предоставление кандидату возможности вести обсуждение, задавая свои вопросы. Должно быть ясно, что вы не просите точного ответа ни на один из них.
Как вы понимаете, я очень не люблю мелочи на собеседовании, и я думаю, что это дает мне гораздо более глубокое понимание способностей кандидатов.
позвольте ей / ему говорить. спросите о прошлом опыте, спросите, с какими проблемами он сталкивался и как они справлялись. что побудило выбрать то или иное решение общих проблем [резервное копирование? мониторинг? масштабирование, масштабирование, безопасность].
Я думаю, вы можете многое рассказать о человеке, просто слушая.
угрюмо, тогда, если вы ищете конкретный опыт в данной области, задавайте подробные вопросы - предложение Стефана Тиберга очень хорошо.