Comment interviewez-vous un candidat programmeur / administrateur de base de données?

Pendant l'entretien, je pose des questions de base sur la conception de bases de données. La normalisation (quand-pourquoi) est l'une de mes préoccupations en matière de conception de base de données. Quelques scénarios que je site qui impliquent des serveurs synchronisés et ce / pourquoi / comment ils prennent en compte les problèmes connexes; problèmes de sécurité et ainsi de suite.

1. Les interrogeriez-vous dans le contexte d'un système de base de données particulier (par exemple Oracle) qu'ils préfèrent?
2. Quelles questions techniques voudriez-vous leur poser?
3. Quels scénarios situeriez-vous et que rechercheriez-vous comme réponses à ces scénarios?
4. Comment sauriez-vous s'ils connaissent bien les problèmes de sécurité?
5. Autres questions connexes. (par exemple, restauration / sauvegarde de base de données)

Je vous remercie.

Voici mes 10 principales questions d'entrevue pour les administrateurs de bases de données seniors, et voici les 10 principales questions de Tom LaRock pour les administrateurs de bases de données juniors.

J'ai remarqué que d'autres personnes suggéraient au candidat de dépanner un serveur. Si vous adoptez cette approche, utilisez une machine virtuelle avec un instantané. Configurez un serveur d'une manière spécifique avec certains problèmes de configuration ou de performances, prenez-en un instantané, puis après chaque entretien, vous pouvez revenir à l'instantané.

Si vous faites cela, limitez les tâches aux types de tâches que vous leur demanderiez de faire. Ne demandez pas à un DBA de production de normaliser et ne demandez pas à un DBA de développement pourquoi un nœud ne rejoindra pas le cluster.

Les tâches DBA de production peuvent être:

• Configurez des travaux pour les sauvegardes, la maintenance des index et les DBCC. Vérifiez s'ils vous demandent à quelle fréquence vous souhaitez que la base de données soit sauvegardée et si vous souhaitez la sauvegarder localement ou sur le réseau. Ne leur demandez pas comment configurer un logiciel de sauvegarde sur bande particulier, sauf s'il est déjà sur leur CV.
• Découvrez pourquoi Johnny ne peut pas se connecter et exécuter sa requête.
• Quelqu'un se plaint d'une requête lente. Montrez-moi où vous regarderiez pour savoir ce qui se passe. Dites ensuite qu'ils viennent d'appeler et que leur requête est terminée, mais ils veulent s'assurer que cela ne se reproduise plus.
• Restaurez une seule table à partir de la sauvegarde de la nuit dernière.

Les tâches de développement peuvent être:

• Déboguez cette procédure stockée.
• Interprétez ce plan d'exécution.
• Créez une vue pour joindre les clients aux factures.

Utilisez le schéma AdventureWorks. Il y a de fortes chances qu'ils n'aient pas joué avec, récemment, mais au moins c'est facile à expliquer.

Dans mon équipe logicielle, dans le cadre de l'entretien, nous testons la compréhension des bases de données.

Nous présentons - une conception très médiocre (pensez à une application de type CRM) et leur demandons d'améliorer la conception, après environ 30 minutes de réflexion.

Nous leur posons ensuite plus de questions en fonction de ce dont ils parlent.

Nous cherchons à comprendre

• Performance V Normalistion
• Conception clé et intégrité référentielle
• Places for Improvment -ie Alternative DB Structure - Triggers, View, Procuedures
• Les domaines qui sont faibles dans la conception - comment surmonter plusieurs relations
• Comment cela affecte le serveur - Maintenir
• Problèmes de sécurité des données
• Problèmes de sécurité des applications

En tant qu'équipe, nous avons ensuite réfléchi à ce que nous considérerions comme des réponses de type Junior / Senior / Architecte à ces types de questions.

Donc pour - Performance contre normalisation -

verrait le problème en premier lieu et serait en mesure de discuter pourquoi (Junior)

recommanderait 4/5 NF mais comprendrait le problème de performance dénormaliserait-il et comprendrait comment articuler le problème (Senior)

recommanderaient-ils un type de conception différent, par exemple un schéma en étoile, et discuteraient-ils des implications à plusieurs niveaux (architecte)

• Conception clé et intégrité référentielle

Verrait l'intégrité de la référence est nécessaire pour appliquer les relations de données et serait en mesure d'en discuter, mais ne verrait pas le problème avec Key Choice and Design (Junior)

Discuterait des problèmes liés aux volumes de données et aux types de données v à la recherche de clés naturelles dans les données et serait en mesure de discuter des raisons pour lesquelles ils les examinent - et des problèmes qui suivent avec l'intégrité référentielle (senior)

Pourrait discuter de divers points de vue concernant les clés et l'intégrité et être en mesure de proposer divers modèles réels pour une conception rapide (architecte)

Vous obtenez l'image.

Si vous voulez que j'ajoute plus, postez un commentaire et détaillerez ce que nous pensons du reste, mais incluez simplement les deux premiers pour vous donner une idée de ce que nous avons pensé.

Le point est de réfléchir aux questions 1. 2. Nous en équipe avons alors pensé à ce que nous considérons comme Junior / réponses senior / type d'architecte à ces types de questions.

J'insiste sur l'équipe en tant que candidat et l'équipe doit être confiante dans les compétences de la personne qui arrive, et si elle a trouvé ce qu'elle considère comme des réponses à différents niveaux, la personne qui vient s'intégrera, espérons-le, avec l'équipe. Cela donne également à l'équipe la possibilité d'influencer le choix du candidat. Ils nomment également une personne pour faire partie du panel de questions. Aide beaucoup avec l'adhésion de l'équipe.

Vous pouvez créer une base de données fictive dans laquelle il y a eu quelques problèmes de normalisation, des problèmes de sécurité potentiels mais qui en général semblent assez typiques, comme une base de données d'employés. Vous pouvez ensuite commencer par poser à l'interviewé des questions simples sur la façon dont il procéderait pour obtenir certaines données dans la base de données via des jointures, en progressant vers des questions plus difficiles sur les problèmes de normalisation et de sécurité.

Voir intelligent et faire avancer les choses

... et demandez-leur quels livres ils ont lus récemment, quels blogs ils lisent et quels podcasts ils écoutent. Et demandez-leur s'ils participent sur stackoverflow.com et serverfault.com ;-)

Ce n'est pas nécessairement lié à la base de données, mais j'aime ajouter à une interview une résolution pratique de problèmes et un scénario de conception.

Pour le problème pratique, disposez d'un ou de plusieurs systèmes auxquels la personne peut accéder et demandez-lui de résoudre un problème ouvert. Mes favoris personnels ici sont les problèmes de performance, car ce n'est pas nécessairement quelque chose qui peut être reproduit sur demande pour une interview et il y a rarement une bonne réponse. Au lieu de cela, vous pouvez regarder le candidat exécuter son processus de dépannage et il devra également ouvrir une discussion avec vous pour obtenir plus d'informations sur l'environnement. L'important est que l'intervieweur soit honnête au sujet du problème et ne transforme pas le scénario en une chasse aux œufs de Pâques pour le paramètre mal configuré ou quelque chose comme ça.

Pour le scénario de conception, je donne au candidat un aperçu général d'un nouveau projet (c'est-à-dire pas de dépendances héritées) et je lui demande de proposer une conception générale dans leur domaine particulier (qu'il s'agisse de DBA, de systèmes ou de réseau) qui répond aux objectifs du projet. La clé est de garder le projet suffisamment petit pour que quelqu'un puisse garder tout le scénario dans sa tête et cela ne prend pas plus de quelques minutes à expliquer.

Un exemple que j'utilise ici pour mes employés de systèmes et de réseau est de décrire leur conception pour une petite succursale en cours de création, compte tenu de certaines contraintes de notre entreprise. Côté DBA, utilisez peut-être une application CRUD petite / évidente. Dans les deux cas, vous ne recherchez pas une conception détaillée mais plutôt une vue d'ensemble et voyez si le candidat recherche les problèmes courants qui surviennent.

Le point important pour ces deux scénarios est d'ouvrir une discussion sur le sujet et de laisser le candidat diriger la discussion avec ses propres questions. Il doit être clair que vous ne demandez pas non plus de réponse exacte.

Comme vous pouvez l'imagerie, je n'aime pas beaucoup les anecdotes dans les entretiens, et je pense que cela me donne une compréhension beaucoup plus profonde des capacités des candidats.

laissez-le parler. renseignez-vous sur l'expérience passée, demandez quels problèmes il a rencontrés et comment ils ont été traités. quelle était la motivation pour choisir ceci ou cela pour résoudre des problèmes courants [sauvegarde? surveillance? extension, extension, sécurité].

je pense que vous pouvez en dire beaucoup sur la personne en écoutant simplement.

alors si vous cherchez une expertise spécifique dans un domaine donné, posez des questions détaillées - la suggestion de Stefan Thyberg est très bonne.