Làm thế nào để bạn phỏng vấn một ứng viên Lập trình viên / Quản trị viên Cơ sở dữ liệu?

Trong cuộc phỏng vấn, tôi hỏi các câu hỏi thiết kế cơ sở dữ liệu cơ bản. Chuẩn hóa (Khi-Tại sao) là một trong những mối quan tâm của tôi khi nói đến thiết kế cơ sở dữ liệu. Một số tình huống tôi trang web liên quan đến các máy chủ được đồng bộ hóa và những gì / tại sao / cách họ xem xét các vấn đề liên quan; vấn đề an ninh và như vậy.

1. Bạn có hỏi họ từ ngữ cảnh của một hệ thống cơ sở dữ liệu cụ thể (ví dụ: Oracle) mà họ thích không?
2. Những câu hỏi kỹ thuật sắp xếp nào bạn sẽ hỏi họ?
3. Những kịch bản nào bạn sẽ trang web và những gì bạn sẽ tìm kiếm như là câu trả lời cho những kịch bản đó?
4. Làm thế nào bạn sẽ tìm ra nếu họ có kiến ​​thức trong việc xử lý các vấn đề bảo mật?
5. Các câu hỏi liên quan khác. (ví dụ: Khôi phục / Sao lưu DB)

Cảm ơn bạn.

Dưới đây là 10 câu hỏi phỏng vấn hàng đầu của tôi dành cho quản trị viên cơ sở dữ liệu cao cấp và tại đây 10 câu hỏi hàng đầu Tom LaRock dành cho các DBA cơ sở.

Tôi đã nhận thấy những người khác đề nghị ứng viên nên khắc phục sự cố máy chủ. Nếu bạn thực hiện phương pháp đó, hãy sử dụng máy ảo với ảnh chụp nhanh. Thiết lập một máy chủ một cách cụ thể với các vấn đề về cấu hình hoặc hiệu suất nhất định, chụp ảnh nhanh và sau mỗi cuộc phỏng vấn, bạn có thể quay lại ảnh chụp nhanh.

Nếu bạn làm điều đó, hãy giới hạn các nhiệm vụ với các loại nhiệm vụ mà bạn thực sự có chúng thực hiện. Đừng hỏi DBA sản xuất về việc chuẩn hóa và đừng hỏi DBA phát triển tại sao một nút sẽ không tham gia cụm.

Nhiệm vụ DBA sản xuất có thể là:

• Thiết lập công việc để sao lưu, bảo trì chỉ mục và DBCC. Xem họ có hỏi bạn tần suất bạn muốn sao lưu cơ sở dữ liệu không và liệu bạn có muốn sao lưu cục bộ hoặc trên mạng không. Đừng hỏi họ cách cấu hình một phần mềm sao lưu băng cụ thể trừ khi nó đã có trong sơ yếu lý lịch của họ.
• Tìm hiểu lý do Johnny không thể đăng nhập và chạy truy vấn của mình.
• Ai đó phàn nàn về một truy vấn chậm. Chỉ cho tôi nơi bạn muốn tìm hiểu chuyện gì đang xảy ra. Sau đó nói rằng họ vừa gọi lên và nói rằng truy vấn của họ đã kết thúc, nhưng họ muốn chắc chắn rằng nó không xảy ra lần nữa.
• Khôi phục một bảng duy nhất từ ​​bản sao lưu tối qua.

Nhiệm vụ phát triển có thể là:

• Gỡ lỗi thủ tục lưu trữ này.
• Giải thích kế hoạch thực hiện này.
• Tạo một cái nhìn để tham gia khách hàng để hóa đơn.

Sử dụng lược đồ AdventureWorks. Gần đây, họ không chơi với nó, nhưng ít nhất thì cũng dễ giải thích.

Trong nhóm phần mềm của tôi như một phần của cuộc phỏng vấn, chúng tôi kiểm tra sự hiểu biết về Cơ sở dữ liệu.

Chúng tôi trình bày - một thiết kế rất kém (nghĩ ứng dụng loại CRM) và yêu cầu họ cải thiện thiết kế, sau khoảng 30 phút suy nghĩ.

Sau đó chúng tôi hỏi họ nhiều câu hỏi hơn dựa trên những gì họ nói.

Chúng tôi đang thăm dò để hiểu về

• Hiệu suất V Bình thường
• Thiết kế chính và tính toàn vẹn giới thiệu
• Nơi dành cho ứng dụng - Cấu trúc DB thay thế - Triggers, View, Procuedures
• Các lĩnh vực yếu trong thiết kế - làm thế nào để vượt qua nhiều mối quan hệ
• Làm thế nào điều này ảnh hưởng đến máy chủ - duy trì
• Vấn đề bảo mật dữ liệu
• Các vấn đề bảo mật ứng dụng

Sau đó, chúng tôi với tư cách là một nhóm đã nghĩ về những gì chúng tôi sẽ xem là câu trả lời loại Junior / Senior / Architect cho các loại câu hỏi này.

Vì vậy, cho - Hiệu suất v Định mức -

sẽ thấy vấn đề ngay từ đầu và có thể thảo luận tại sao (Junior)

muốn giới thiệu 4/5 NF nhưng hiểu vấn đề với hiệu suất họ sẽ không bình thường và hiểu cách phát biểu vấn đề (Cao cấp)

họ sẽ đề xuất một kiểu thiết kế khác, ví dụ như Lược đồ ngôi sao và thảo luận về ý nghĩa ở nhiều cấp độ (Kiến trúc sư)

• Thiết kế chính và tính toàn vẹn tham chiếu

Sẽ thấy tính toàn vẹn của ref là cần thiết để thực thi các mối quan hệ dữ liệu và có thể thảo luận về vấn đề này nhưng sẽ không thấy vấn đề với Key Choice and Design (Junior)

Sẽ thảo luận các vấn đề liên quan đến khối lượng dữ liệu và loại dữ liệu v tìm kiếm các khóa tự nhiên trong dữ liệu và có thể thảo luận lý do tại sao chúng đang xem xét các vấn đề này - và các vấn đề tiếp theo với tính toàn vẹn tham chiếu (Cao cấp)

Có thể tranh luận các quan điểm khác nhau để làm với Khóa và Tính toàn vẹn và có thể đưa ra các mô hình thực tế khác nhau để thiết kế nhanh (Kiến trúc sư)

Bạn nhận được hình ảnh.

Nếu bạn muốn tôi thêm nhiều hơn thì hãy đăng bình luận và sẽ nêu chi tiết những gì chúng tôi nghĩ về phần còn lại nhưng chỉ bao gồm hai phần đầu tiên để cho bạn ý tưởng về những gì chúng tôi nghĩ.

Vấn đề là suy nghĩ về 1. các câu hỏi 2. Chúng tôi với tư cách là một nhóm sau đó đã nghĩ về những gì chúng tôi sẽ xem là câu trả lời loại Junior / Senior / Architect cho các loại câu hỏi này.

Tôi nhấn mạnh nhóm vì ứng cử viên và nhóm phải tự tin vào các kỹ năng của người đến, và nếu họ đưa ra những gì họ xem là câu trả lời cho các cấp độ khác nhau, người đến sẽ hy vọng phù hợp với nhóm hơn. Nó cũng mang lại cho nhóm khả năng ảnh hưởng đến sự lựa chọn của ứng viên. Họ cũng đề cử một người có mặt trong bảng câu hỏi. Giúp rất nhiều với đội mua.

Bạn có thể tạo ra một cơ sở dữ liệu hư cấu trong đó có một vài vấn đề bình thường hóa, các trục trặc bảo mật tiềm ẩn nhưng nhìn chung trông khá điển hình, giống như một cơ sở dữ liệu nhân viên. Sau đó, bạn có thể bắt đầu bằng cách hỏi những người được phỏng vấn những câu hỏi đơn giản dọc theo cách họ sẽ nhận được một số dữ liệu nhất định trong cơ sở dữ liệu thông qua các phép nối, tìm ra những câu hỏi khó hơn về các vấn đề bình thường hóa và bí mật.

Xem những điều thông minh và đạt được

... Và hỏi họ những cuốn sách họ đã đọc gần đây, những gì họ đọc blog và những podcast họ nghe. Và hỏi xem họ có tham gia trên stackoverflow.com và serverfault.com ;-)

Điều này không nhất thiết liên quan đến cơ sở dữ liệu, nhưng những điều tôi muốn thêm vào một cuộc phỏng vấn là giải quyết vấn đề thực tiễn và một kịch bản thiết kế.

Đối với vấn đề thực hành, có một hệ thống hoặc hệ thống mà người đó có thể truy cập và yêu cầu họ khắc phục sự cố kết thúc mở. Yêu thích cá nhân của tôi ở đây là vấn đề hiệu suất, vì nó không nhất thiết phải là một cái gì đó có thể được sao chép theo yêu cầu cho một cuộc phỏng vấn và hiếm khi có một câu trả lời đúng. Thay vào đó, bạn có thể xem ứng viên chạy qua quy trình xử lý sự cố của họ và họ cũng sẽ cần mở một cuộc thảo luận với bạn để có thêm thông tin về môi trường. Điều quan trọng là để người phỏng vấn trung thực về vấn đề và không biến kịch bản thành một cuộc săn trứng Phục sinh cho một thiết lập được định cấu hình sai hoặc một cái gì đó tương tự.

Đối với kịch bản thiết kế, tôi cung cấp cho ứng viên một phác thảo chung về một dự án mới (nghĩa là không phụ thuộc di sản) và yêu cầu họ đưa ra một thiết kế chung trong khu vực cụ thể của họ (cho dù là DBA, hệ thống hoặc mạng) đáp ứng các mục tiêu của dự án. Điều quan trọng là giữ cho dự án đủ nhỏ để ai đó có thể giữ toàn bộ kịch bản trong đầu và không mất quá vài phút để giải thích.

Một ví dụ tôi sử dụng ở đây cho các hệ thống và người mạng của mình là để mô tả thiết kế của họ cho một văn phòng chi nhánh nhỏ được thành lập, với những hạn chế nhất định trong hoạt động kinh doanh của chúng tôi. Về phía DBA, có thể sử dụng ứng dụng CRUD nhỏ / rõ ràng. Trong cả hai trường hợp, bạn không tìm kiếm một thiết kế chi tiết mà có cái nhìn tổng quan hơn và xem liệu ứng viên có tìm kiếm các vấn đề phổ biến xuất hiện không.

Điểm quan trọng cho cả hai kịch bản này là mở một cuộc thảo luận về chủ đề này và để ứng viên dẫn dắt cuộc thảo luận với câu hỏi của riêng họ. Cần phải rõ ràng rằng bạn không yêu cầu một câu trả lời chính xác cho một trong hai.

Như bạn có thể chụp ảnh, tôi rất không thích những chuyện vặt vãnh trong các cuộc phỏng vấn, và tôi nghĩ điều này giúp tôi hiểu sâu hơn nhiều về khả năng của ứng viên.

hãy để cô ấy / anh ấy nói chuyện hỏi về kinh nghiệm trong quá khứ, hỏi xem anh ấy đã gặp phải vấn đề gì và cách xử lý đồ. động lực để chọn điều này hay điều đó để giải quyết các vấn đề phổ biến [sao lưu là gì? giám sát? nhân rộng, nhân rộng, bảo mật].

tôi nghĩ bạn có thể nói rất nhiều về người đó chỉ bằng cách lắng nghe.

chắc chắn sau đó nếu bạn đang tìm kiếm chuyên môn cụ thể trong lĩnh vực nhất định, hãy đặt câu hỏi chi tiết - gợi ý từ Stefan Thyberg là rất tốt.