Як ви проводите інтерв'ю у програміста / адміністратора бази даних?

Під час співбесіди я задаю основні питання дизайну бази даних. Нормалізація (коли-чому) - одна з моїх проблем, коли справа стосується дизайну баз даних. Деякі сценарії I сайту, які включають синхронізовані сервери та що / чому / як вони приймають до уваги пов'язані проблеми; питання безпеки тощо.

1. Ви б запитали їх у контексті певної системи баз даних (наприклад, Oracle), яку вони віддають перевагу?
2. Які б технічні питання ви б їм не задали?
3. Які сценарії ви б розмістили на сайті та що б ви шукали як відповіді на ці сценарії?
4. Як би ви дізналися, чи володіють вони знаннями з питань безпеки?
5. Інші пов'язані питання. (наприклад, відновлення / резервне копіювання DB)

Дякую.

Ось мої топ-10 запитань щодо інтерв'ю для старших адміністраторів баз даних, а ось топ-10 питань Тома Ларока для молодших DBA.

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

Якщо ви це зробите, обмежте завдання типом завдань, які ви насправді виконували б. Не запитуйте виробничу DBA про нормалізацію та не запитуйте DBA розробника, чому один вузол не приєднається до кластеру.

Завданнями DBA для виробництва можуть бути:

• Налаштування завдань для резервного копіювання, обслуговування індексів та DBCC. Подивіться, чи запитують вони, як часто ви хочете створити резервну копію бази даних та чи бажаєте ви створити резервну копію локально або через мережу. Не запитуйте їх, як налаштувати певне програмне забезпечення для резервного копіювання стрічки, якщо воно вже не відновлено.
• Дізнайтеся, чому Джонні не може увійти та запустити свій запит.
• Хтось скаржиться на повільний запит. Покажіть мені, куди б ви шукали, щоб дізнатися, що відбувається. Потім скажіть, що вони просто зателефонували і сказали, що їхній запит закінчений, але вони хочуть переконатися, що він не повториться.
• Відновіть єдину таблицю з резервної копії минулої ночі.

Завданнями для розробки можуть бути:

• Налагодження цієї збереженої процедури.
• Інтерпретуйте цей план виконання.
• Створіть подання, щоб приєднати клієнтів до рахунків-фактур.

Використовуйте схему AdventureWorks. Шанси, що вони не грали з цим останнім часом, але принаймні це легко пояснити.

У моїй команді програмного забезпечення в рамках інтерв'ю ми перевіряємо розуміння Баз даних.

Ми представляємо - дуже поганий дизайн (думаю, CRM-додаток) і просимо їх покращити дизайн, приблизно через 30 хвилин мислення.

Потім ми задаємо їм більше запитань на основі того, про що вони говорять.

Ми намагаємось зрозуміти

• Виконання V Нормалізація
• Ключова конструкція та референтна цілісність
• Місця для покращення - це альтернативна структура БД - тригери, перегляд, процедури
• Сфери, які слабкі в дизайні - як подолати багато до багатьох стосунків
• Як це впливає на сервер - supportce
• Питання безпеки даних
• Проблеми безпеки додатків

Тоді ми, як команда, подумали над тим, що б ми вважали відповідями типу молодший / старший / архітектор на ці типи питань.

Так для - Ефективність проти нормалізації -

побачив це питання в першу чергу і зможе обговорити, чому (Юніор)

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

Чи рекомендують вони інший тип дизайну, наприклад, Зоряну схему та обговорюють наслідки на багатьох рівнях (Архітектор)

• Основний дизайн та референтна цілісність

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

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

Чи могли б сперечатися різні точки зору щодо клавіш та цілісності та мати можливість придумати різні фактичні моделі для швидкого дизайну (Архітектор)

Ви отримуєте картину.

Якщо ви хочете, щоб я додавав більше, опублікуйте коментар і докладно розповім, що ми думаємо про решту, але просто включив перші два, щоб дати вам уявлення про те, що ми думали.

Сенс у тому, щоб подумати над 1. питаннями 2. Ми тоді, як команда , подумали про те, що б ми вважали відповідями типу молодший / старший / архітектор на ці типи питань.

Я наголошую на команді як кандидата та команди повинні бути впевнені у навичках людини, яка приходить, і якщо вони придумають відповіді на різні рівні, людина, яка приходить, сподівається, що вона краще підійде до команди. Це також дає команді можливість впливати на вибір кандидата. Вони також призначають особу, яка буде на панелі запитань. Дуже допомагає при командному придбанні.

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

Див. Розділ Розумні та отримує зроблене

... і запитайте у них, які книги вони читали останнім часом, які блоги вони читали та які подкасти слухають. І запитайте, чи беруть участь вони на stackoverflow.com та serverfault.com ;-)

Це не обов'язково пов'язано з базою даних, але те, що я хотів би додати до інтерв'ю, - це практичне вирішення проблем та проектний сценарій.

Для проблем, що склалися, створіть систему чи системи, до яких людина може отримати доступ та надати їм проблеми з відкритим випуском. Мої особисті фаворити - це питання ефективності, оскільки це не обов'язково щось, що можна відтворити на вимогу інтерв'ю, і рідко є одна правильна відповідь. Натомість ви можете спостерігати за тим, як кандидат проходить процес їх усунення несправностей, і їм також потрібно буде відкрити з вами обговорення, щоб отримати додаткову інформацію про навколишнє середовище. Головне, щоб інтерв'юер був чесним щодо проблеми, а не перетворював сценарій на великодні полювання на яйця для одного неправильно налаштованого налаштування чи чогось подібного.

Що стосується сценарію проектування, я даю кандидату загальний план нового проекту (тобто не має застарілих залежностей) і прошу їх розробити загальний проект у своїй конкретній області (будь то DBA, системи чи мережа), що відповідає цілям проекту. Ключовим моментом є те, щоб проект був достатньо малим, щоб хтось міг тримати весь сценарій у своїй голові, і на це не потрібно більше кількох хвилин.

Приклад, який я використовую тут для своїх системних та мережевих людей, - це описати їх дизайн для невеликого відділення, яке створюється, з огляду на певні обмеження нашого бізнесу. Що стосується DBA, можливо, використовуйте невеликий / очевидний додаток CRUD. В будь-якому випадку ви не шукаєте детального проекту, а більш детального огляду і бачите, чи шукає кандидат ті найпоширеніші проблеми.

Важливим моментом для обох цих сценаріїв є відкриття дискусії з даної теми та дозволення кандидату вести дискусію своїми власними питаннями. Повинно бути зрозуміло, що ви не просите точної відповіді на жодне.

Як ви можете уявити, мені дуже не подобаються дрібниці в інтерв'ю, і я думаю, що це дає мені набагато глибше розуміння здібностей кандидатів.

нехай вона / він поговорить. запитайте про минулий досвід, запитайте, з якими проблемами він стикався і як вирішував посуд. яка мотивація була обрати ту чи іншу для вирішення загальних проблем [резервне копіювання? моніторинг? масштабування, масштабування, безпека].

я думаю, ви можете багато чого розповісти про людину, просто слухаючи.

похмуро, якщо ви шукаєте конкретних знань у даній області, задайте детальні запитання - пропозиція від Стефана Тіберга дуже гарна.