Come si fa a intervistare un programmatore di database / un candidato amministratore?

Durante l'intervista, faccio domande di base sulla progettazione del database. La normalizzazione (quando-perché) è una delle mie preoccupazioni quando si tratta di progettazione di database. Alcuni scenari nel sito che coinvolgono server sincronizzati e cosa / perché / come prendono in considerazione i problemi correlati; problemi di sicurezza e così via.

1. Vorresti chiedere loro dal contesto di un particolare sistema di database (ad es. Oracle) che preferiscono?
2. Quali domande tecniche vorresti porre loro?
3. Quali scenari vorresti collocare e cosa cercheresti come risposte a tali scenari?
4. Come scopriresti se sono competenti nella gestione dei problemi di sicurezza?
5. Altre domande correlate. (ad es. DB Restore / Backup)

Grazie.

Ecco le mie 10 domande di intervista principali per gli amministratori di database senior, ed ecco le 10 domande principali di Tom LaRock per i DBA junior.

Ho notato che altre persone suggeriscono che il candidato dovrebbe risolvere un server. Se segui questo approccio, usa una macchina virtuale con un'istantanea. Configurare un server in un modo specifico con determinati problemi di configurazione o delle prestazioni, fare uno snapshot e quindi dopo ogni colloquio è possibile tornare allo snapshot.

Se lo fai, limita le attività al tipo di attività che avresti effettivamente fatto. Non chiedere a un DBA di produzione la normalizzazione e non chiedere a un DBA di sviluppo perché un nodo non si unirà al cluster.

Le attività DBA di produzione potrebbero essere:

• Impostare i processi per backup, manutenzione dell'indice e DBCC. Verifica se ti chiedono con quale frequenza desideri eseguire il backup del database e se desideri eseguirne il backup a livello locale o attraverso la rete. Non chiedere loro come configurare un particolare software di backup su nastro a meno che non sia già sul loro curriculum.
• Scopri perché Johnny non può accedere ed eseguire la sua query.
• Qualcuno si lamenta di una domanda lenta. Fammi vedere dove guarderesti per scoprire cosa sta succedendo. Quindi dire che hanno appena chiamato e hanno detto che la loro query è terminata, ma vogliono assicurarsi che non accada di nuovo.
• Ripristina una singola tabella dal backup di ieri sera.

Le attività di sviluppo potrebbero essere:

• Debug di questa procedura memorizzata.
• Interpreta questo piano di esecuzione.
• Crea una vista per unire i clienti alle fatture.

Utilizzare lo schema AdventureWorks. Le probabilità sono che non ci abbiano giocato di recente, ma almeno è facile da spiegare.

Nel mio team di software nell'ambito dell'intervista testiamo la comprensione dei database.

Presentiamo - un design molto scarso (pensa al tipo di applicazione CRM) e chiediamo loro di migliorarlo, dopo circa 30 minuti di riflessione.

Facciamo quindi loro altre domande in base a ciò di cui parlano.

Stiamo cercando di capire

• Performance V Normalistion
• Progettazione chiave e integrità referenziale
• Luoghi per l'improvvisazione -ie Struttura DB alternativa - Trigger, vista, procedure
• Aree che sono deboli nella progettazione: come superare molte o molte relazioni
• In che modo ciò influisce sul server - maintaince
• Problemi di sicurezza dei dati
• Problemi di sicurezza delle applicazioni

In qualità di team abbiamo quindi pensato a quelle che considereremmo risposte di tipo Junior / Senior / Architect a questi tipi di domande.

Quindi per - Performance v Normisalation -

vedrebbe il problema in primo luogo e sarebbe in grado di discutere il perché (Junior)

raccomanderebbe 4/5 NF ma capirebbe il problema con le prestazioni denormalizzerebbero e capirebbero come articolare il problema (Senior)

consiglierebbero un diverso tipo di design, ad esempio Star Schema, e discuteranno le implicazioni su molti livelli (Architect)

• Progettazione chiave e integrità referenziale

Vedrebbe l'integrità di riferimento necessaria per far rispettare le relazioni con i dati ed essere in grado di discuterne, ma non vedrebbe il problema con Key Choice and Design (Junior)

Discuterebbe delle problematiche relative ai volumi di dati e ai tipi di dati v alla ricerca di chiavi naturali nei dati e sarebbe in grado di discutere il motivo per cui le stanno esaminando - e le questioni che seguono con integrità referenziale (Senior)

Potrebbero discutere vari punti di vista a che fare con Keys e Integrity ed essere in grado di elaborare vari modelli reali per un design veloce (Architect)

Ottieni l'immagine.

Se vuoi che ne aggiunga di più, pubblica un commento e descriverà in dettaglio ciò che pensiamo del resto, ma ho appena incluso i primi due per darti l'idea su ciò che abbiamo pensato.

Il punto è pensare alle 1. domande 2. In qualità di team abbiamo quindi pensato a quelle che considereremmo risposte di tipo Junior / Senior / Architect a questi tipi di domande.

Sottolineo la squadra come candidato e la squadra deve essere fiduciosa nelle capacità della persona che entra, e se hanno escogitato ciò che vedono come risposte a diversi livelli, la persona che entra si spera si adatterà meglio alla squadra. Offre inoltre alla squadra la possibilità di influenzare la scelta del candidato. Nominano anche una persona a far parte del pannello delle domande. Aiuta molto con il buy-in della squadra.

Potresti creare un database fittizio in cui c'erano alcuni problemi di normalizzazione, potenziali problemi di sicurezza ma che in generale sembra abbastanza tipico, come un database di dipendenti. Potresti quindi iniziare ponendo all'intervistato semplici domande sulla falsariga di come farebbero per ottenere determinati dati nel database attraverso i join, facendoti strada fino a domande più difficili sulla normalizzazione e sui problemi di sicurezza.

Vedi Smart e ottiene le cose fatte

... e chiedi loro quali libri hanno letto di recente, quali blog hanno letto e quali podcast ascoltano. E chiedi se partecipano su stackoverflow.com e serverfault.com ;-)

Questo non è necessariamente correlato al database, ma le cose che mi piace aggiungere a un'intervista sono la risoluzione pratica dei problemi e uno scenario di progettazione.

Per il problema pratico, disporre di uno o più sistemi a cui la persona può accedere e chiedere loro di risolvere un problema a risposta aperta. I miei preferiti personali qui sono problemi di prestazioni, in quanto non necessariamente qualcosa che può essere riprodotto su richiesta per un'intervista e raramente c'è una risposta corretta. Invece, puoi guardare il candidato mentre esegue il processo di risoluzione dei problemi e dovranno anche aprire una discussione con te per ottenere ulteriori informazioni sull'ambiente. La chiave è che l'intervistatore sia onesto sul problema e non trasformi lo scenario in una caccia alle uova di Pasqua per l'unica impostazione errata o qualcosa del genere.

Per lo scenario di progettazione, offro al candidato uno schema generale di un nuovo progetto (ovvero nessuna dipendenza legacy) e chiedo loro di elaborare un progetto generale nella loro area specifica (DBA, sistemi o rete) che soddisfi gli obiettivi del progetto. La chiave è mantenere il progetto abbastanza piccolo da consentire a qualcuno di tenere in mente l'intero scenario e non ci vogliono più di pochi minuti per spiegare.

Un esempio che uso qui per i miei sistemi e persone di rete è descrivere il loro design per una piccola filiale in fase di creazione, dati alcuni vincoli della nostra attività. Sul lato DBA, forse utilizzare un'applicazione CRUD piccola / ovvia. In entrambi i casi, non stai cercando un progetto dettagliato ma più una panoramica e vedi se il candidato cerca i problemi comuni che si presentano.

Il punto importante per entrambi questi scenari è aprire una discussione sull'argomento e lasciare che il candidato conduca la discussione con le proprie domande. Dovrebbe essere chiaro che non stai chiedendo una risposta esatta a nessuno dei due.

Come puoi immaginare, non mi piace molto la curiosità nelle interviste e penso che questo mi dia una comprensione molto più profonda delle capacità dei candidati.

lascialo parlare. chiedi delle esperienze passate, chiedi quali problemi ha incontrato e come sono stati gestiti. qual è stata la motivazione a scegliere questo o quello per risolvere problemi comuni [backup? il monitoraggio? ridimensionamento, ridimensionamento, sicurezza].

penso che puoi dire molto della persona semplicemente ascoltando.

sicuramente se stai cercando competenze specifiche in una determinata area, fai domande dettagliate - il suggerimento di Stefan Thyberg è molto buono.