Bir Veritabanı Programcısı / Yönetici adayıyla nasıl görüşürsünüz?

Görüşme sırasında temel veritabanı tasarımı soruları soruyorum. Veritabanı tasarımı söz konusu olduğunda normalleştirme (When-Why) benim endişelerimden biri. Senkronize edilmiş sunucuları içeren bazı senaryolar I sitesi ve ilgili sorunları ne / neden / nasıl dikkate aldıklarını; güvenlik sorunları vb.

1. Onlardan tercih ettikleri belirli bir veritabanı sistemi (örneğin Oracle) bağlamından ister misiniz?
2. Onlara hangi sorta teknik sorular sorardınız?
3. Hangi senaryoları siteye eklersiniz ve bu senaryolara cevap olarak ne ararsınız?
4. Güvenlik sorunlarını ele alma konusunda bilgili olup olmadıklarını nasıl öğrenirsiniz?
5. İlgili diğer sorular. (örn. DB Geri Yükleme / Yedekleme)

Teşekkür ederim.

İşte üst düzey veritabanı yöneticileri için ilk 10 röportaj sorularım ve işte Tom LaRock'un genç DBA'lar için en iyi 10 sorusu.

Başkalarının, adayın bir sunucuda sorun gidermesini önerdiğini fark ettim. Bu yaklaşımı kullanırsanız, anlık görüntüye sahip bir sanal makine kullanın. Bir sunucuyu belirli yapılandırma veya performans sorunlarıyla belirli bir şekilde kurun, anlık görüntüsünü alın ve her görüşmeden sonra anlık görüntüye geri dönebilirsiniz.

Bunu yaparsanız, görevleri gerçekte sahip olacağınız türden görevlerle sınırlayın. Üretim DBA'sına normalleştirme hakkında sormayın ve geliştirme DBA'sına neden bir düğümün kümeye katılmayacağını sormayın.

Üretim DBA görevleri şunlar olabilir:

• Yedeklemeler, dizin bakımı ve DBCC'ler için işler ayarlayın. Veritabanının ne sıklıkta yedeklenmesini istediğinizi ve yerel olarak veya ağ genelinde yedeklenmesini isteyip istemediklerini görün. Zaten devam etmedikçe belirli bir teyp yedekleme yazılımını nasıl yapılandıracaklarını sormayın.
• Johnny'nin neden giriş yapılamadığını ve sorgusunu çalıştıramayacağını öğrenin.
• Birisi yavaş bir sorgudan şikayet ediyor. Neler olup bittiğini öğrenmek için nereye bakacağınızı gösterin. Sonra sadece aradılar ve sorgularının bittiğini söylediler, ancak tekrar yapılmadığından emin olmak istiyorlar.
• Dün geceki yedeklemeden tek bir tabloyu geri yükle.

Geliştirme görevleri şunlar olabilir:

• Bu saklı yordamda hata ayıklayın.
• Bu yürütme planını yorumlar.
• Müşterileri faturalara katılmak için bir görünüm oluşturun.

AdventureWorks şemasını kullanın. Oranlar, son zamanlarda onunla oynamamışlardır, ancak en azından açıklamak kolaydır.

Röportajın bir parçası olarak yazılım ekibimde Veritabanları anlayışını test ediyoruz.

Sunuyoruz - çok zayıf bir tasarım (CRM tipi uygulamasını düşünün) ve yaklaşık 30 dakika düşünme süresinden sonra tasarımı geliştirmelerini isteyin.

Daha sonra onlara ne hakkında konuştuklarına dayanarak daha fazla soru soruyoruz.

Anlamak için araştırma yapıyoruz

• Performans V Normalistion
• Anahtar Tasarım ve Referanslı Bütünlük
• İyileştirme Yerleri - Alternatif DB Yapısı - Tetikleyiciler, Görünüm, Procuedures
• Tasarımda zayıf alanlar - çoktan çoğa ilişkilerin üstesinden nasıl gelinir
• Bu sunucuyu nasıl etkiler - bakım
• Veri Güvenliği Sorunları
• Uygulama Güvenliği Sorunları

Daha sonra bir ekip olarak bu tür sorulara Junior / Senior / Architect tipi cevaplar olarak neyi düşüneceğimizi düşündük.

Öyleyse - Performans v Normizasyon -

konuyu en başta görecek ve nedenini tartışabilecektir (Junior)

4/5 NF'yi öneririm, ancak performansla ilgili sorunu anlarlar, sorunun nasıl ifade edileceğini anlarlar ve sorunu nasıl ifade edeceğini anlarlar (Kıdemli)

Star Schema gibi farklı bir tasarım önerebilirler ve birçok düzeydeki etkileri tartışırlar (Mimar)

• Anahtar Tasarım ve Referans Bütünlüğü

Veri ilişkilerini güçlendirmek ve bunu tartışabilmek için ref bütünlüğünün gerekli olduğunu görür müydü, ancak Kilit Seçim ve Tasarım (Junior) ile ilgili sorunu görmeyecekti

Veri hacimleri ve veri türleriyle ilgili sorunları v verilerde doğal anahtarlar aramak ve neden bunlara baktıklarını ve referans bütünlüğü ile takip eden konuları tartışabilecektir (Senior).

Anahtarlar ve Dürüstlük ile ilgili çeşitli bakış açılarını tartışabilir ve hızlı tasarım için çeşitli gerçek modeller üretebilir (Mimar)

Resmi aldınız.

Daha fazlasını eklememi istiyorsan, yorum yaz ve geri kalanı hakkında ne düşündüğümüzü detaylandıracağım, ancak sadece düşündüğümüz hakkında fikir vermek için ilk ikisini dahil ettik.

Mesele şu 1. soruları düşünmektir 2. Bir ekip olarak bu tür sorulara Junior / Senior / Architect tipi cevaplar olarak neyi düşüneceğimizi düşündük.

Ekibin aday olarak vurgulandığını ve ekibin, gelen kişinin becerilerine güvenmesi gerektiğine ve eğer farklı seviyelere cevap olarak gördüklerini bulmuşlarsa, gelen kişi umarım ekibe daha iyi uyacaktır. Ayrıca ekibe aday seçimini etkileme yeteneği de verir. Ayrıca bir kişiyi soru panelinde olmaya aday gösterirler. Ekip katılımıyla çok yardımcı olur.

Birkaç normalizasyon probleminin, potansiyel güvenlik hatalarının olduğu, ancak genel olarak bir çalışan veritabanı gibi oldukça tipik görünen kurgusal bir veritabanı oluşturabilirsiniz. Daha sonra, mülakat yapılan kişiye veritabanında belirli verileri birleştirme yoluyla nasıl elde edecekleri, normalleştirme ve güvenlik konularında daha zor sorulara kadar ilerleyecekleri yol boyunca basit sorular sorarak başlayabilirsiniz.

Akıllıya Bakın ve İşleri Yapın

... ve son zamanlarda hangi kitapları okuduklarını, hangi blogları okuduklarını ve hangi podcast'leri dinlediklerini sorun. Ve stackoverflow.com ve serverfault.com ;-) 'e katılıp katılmadıklarını sorun

Bu mutlaka veritabanı ile ilgili değildir, ancak bir röportaja eklemek istediğim şeyler uygulamalı problem çözme ve bir tasarım senaryosudur.

Uygulamalı sorun için, kişinin erişebileceği bir sistem veya sistemlere sahip olun ve açık uçlu bir sorunu gidermelerini sağlayın. Buradaki kişisel favorilerim performans sorunları, çünkü bir röportaj için talep üzerine çoğaltılabilecek bir şey değil ve nadiren tek bir doğru cevap var. Bunun yerine, adayın sorun giderme süreci boyunca çalışmasını izleyebilir ve ayrıca çevre hakkında daha fazla bilgi almak için sizinle bir tartışma açmaları gerekir. Kilit nokta, görüşmecinin sorun hakkında dürüst olması ve senaryoyu yanlış yapılandırılmış bir ortam veya bunun gibi bir şey için bir Paskalya yumurtası avına dönüştürmektir.

Tasarım senaryosu için, adaya yeni bir projenin genel bir taslağını veriyorum (yani eski bağımlılıklar yok) ve onlardan proje hedeflerini karşılayan kendi alanlarında (DBA, sistemler veya ağ) genel bir tasarım oluşturmalarını istiyorum. Anahtar, projeyi, birisinin tüm senaryoyu başlarında tutabilecek kadar küçük tutmak ve açıklanması birkaç dakikadan fazla sürmez.

Burada sistemlerim ve ağ çalışanları için kullandığım bir örnek, işimizin belirli kısıtlamaları göz önüne alındığında, kurulan küçük bir şube ofisi için tasarımlarını anlatmaktır. DBA tarafında, belki küçük / açık bir CRUD uygulaması kullanın. Her iki durumda da, ayrıntılı bir tasarım değil, daha fazla genel bakış arıyorsunuz ve adayın ortaya çıkan ortak sorunları arayıp aramayacağını görüyorsunuz.

Bu senaryoların her ikisi için de önemli olan konu hakkında bir tartışma açmak ve adayın kendi soruları ile tartışmaya öncülük etmesidir. Her ikisine de kesin bir cevap istemediğiniz açık olmalıdır.

Görüntüleyebildiğiniz gibi, röportajlarda önemsiz şeylerden çok hoşlanmıyorum ve bence bu bana adayların yeteneklerini daha derin bir anlayış kazandırıyor.

bırak konuşsun. geçmiş tecrübelerini sorun, hangi problemlerle karşılaştığını ve hangi malzemeleri ele aldıklarını sorun. bunu ya da sık karşılaşılan sorunları çözme motivasyonu neydi? izleme? ölçeklendirme, ölçeklendirme, güvenlik].

bence sadece dinleyerek kişi hakkında çok şey söyleyebilirsin.

somurtkan o zaman belirli bir alanda belirli bir uzmanlık arıyorsanız ayrıntılı sorular sorun - Stefan Thyberg'den öneri çok iyi.