Questions d'Entrevue SQL Server : Comment Expliquer Votre Raisonnement de Base de Données à Haute Voix

Les questions d'entrevue SQL Server s'arrêtent rarement à la restitution de syntaxe. Un panel sait déjà que vous pouvez rechercher la bonne clause JOIN ou une fonction fenêtrée. Ce qu'ils testent vraiment, c'est si vous pouvez raisonner sur un problème de base de données en temps réel et expliquer ce raisonnement à quelqu'un d'autre, que cette personne soit un autre DBA, un développeur d'application ou une partie prenante non technique.

Pour les rôles axés sur DBA, attendez-vous à plus de poids sur les sauvegardes, les modèles de récupération, la maintenance des index et la configuration du serveur. Pour les rôles axés sur le développeur, attendez-vous à plus de poids sur les modèles T-SQL, la conception des requêtes et la façon dont votre code interagit avec l'optimiseur de requêtes. La plupart des entreprises combinent les deux, car un développeur qui comprend l'indexation écrit des requêtes plus rapides, et un DBA qui comprend la logique applicative donne de meilleurs conseils de tuning.

Une question d'ouverture courante est quelque chose comme « décrivez-moi comment vous concevriez la stratégie d'indexation pour une nouvelle table de rapports. » Il n'y a pas une seule bonne réponse, donc l'intervieweur évalue vraiment votre processus : comment vous clarifiez d'abord les modèles de requête, comment vous évaluez les performances de lecture par rapport aux coûts d'écriture, et comment vous valideriez le choix ensuite avec des données réelles au lieu de deviner.

Le fil conducteur dans chaque bonne réponse est la narration. Dites ce que vous vérifieriez d'abord, pourquoi vous le vérifieriez, et ce que le résultat vous dirait. Les intervieweurs écoutent un processus de décision, pas une définition mémorisée, et cette habitude de penser à haute voix vaut la peine d'être pratiquée avant de vous asseoir devant un panel.

Les questions sur l'indexation sont le point de contrôle technique le plus courant dans une entrevue SQL Server. On vous demandera probablement de décrire la différence entre un index en cluster et un index non en cluster, quand un index couvrant aide, et comment vous accéléreriez une requête qui s'exécute lentement.

Structurez votre réponse autour d'un vrai chemin de diagnostic au lieu d'une définition de manuel. Commencez par le plan d'exécution : « Je récupérerais le plan d'exécution réel et je chercherais un scan où j'attends une recherche, puis je vérifierais si les colonnes du prédicat sont indexées. » Expliquez le coût d'une recherche de clé et quand l'ajout d'une colonne incluse l'élimine. Mentionnez les statistiques : les statistiques périmées peuvent faire en sorte que l'optimiseur choisisse un mauvais plan même quand le bon index existe, et la mise à jour des statistiques obsolètes est l'une des premières choses que les candidats expérimentés vérifient.

Les intervieweurs aiment aussi creuser plus profondément avec des questions de suivi sur les index filtrés, le facteur de remplissage et la fragmentation des index. Soyez prêt à expliquer qu'un index filtré ne couvre qu'un sous-ensemble de lignes et peut réduire drastiquement la taille d'un index sur une colonne principalement nulle ou principalement inactive, et que le facteur de remplissage échange un peu d'espace gaspillé aujourd'hui contre moins de fractionnements de page plus tard sur une table avec de lourdes insertions.

Réponse d'exemple : « Une requête de rapport dépassait le délai d'attente parce qu'elle filtrait sur une colonne sans index et joignait trois grandes tables. J'ai obtenu le plan, j'ai vu un scan d'index en cluster et un tri coûteux, j'ai ajouté un index non en cluster sur la colonne de filtrage avec des colonnes incluses pour la liste SELECT, j'ai mis à jour les statistiques, et le scan est devenu une recherche. La durée est passée de douze secondes à moins d'une. » Ce type d'histoire spécifique de cause à effet est ce qui distingue une réponse forte d'une générique.

Au-delà des déclarations SELECT de base, les intervieweurs explorent généralement plusieurs domaines T-SQL : les fonctions fenêtrées comme ROW_NUMBER, RANK et DENSE_RANK, les expressions de table communes par rapport aux tables temporaires, la logique basée sur les ensembles par rapport aux curseurs, et comment NULL se comporte dans les comparaisons et les agrégats.

Quand on vous demande pourquoi vous éviteriez un curseur, ne dites pas simplement « les curseurs sont lents. » Expliquez le mécanisme : un curseur traite les lignes une à la fois, tandis qu'une requête basée sur les ensembles permet à l'optimiseur de travailler sur tout l'ensemble de résultats à la fois, ce qui est presque toujours plus rapide à grande échelle. Si un curseur est vraiment le bon outil, par exemple dans un script administratif qui doit s'exécuter dans une séquence stricte, dites-le et expliquez pourquoi.

On pourrait aussi vous demander de comparer une table temporaire et une variable de table. Une bonne réponse couvre la portée, le comportement de la journalisation des transactions et le fait que l'optimiseur crée des statistiques pour les tables temporaires mais pas pour les variables de table, ce qui importe pour les plans de requête sur des nombres de lignes plus importants. Gardez l'explication pratique : décrivez quand vous avez réellement choisi l'une plutôt que l'autre et ce qui a changé en conséquence.

Attendez-vous à au moins une question sur les types de jointures et la construction de requêtes : la différence entre un INNER JOIN et un LEFT JOIN, quand un CROSS APPLY est utile pour la logique ligne par ligne qu'une JOIN ordinaire ne peut pas exprimer, et comment une déclaration MERGE peut combiner une insertion, une mise à jour et une suppression en une seule opération. Vous pourriez aussi recevoir une courte question sur la gestion des erreurs avec TRY/CATCH et comment XACT_ABORT change le comportement de restauration dans une transaction. Répondez à chacun en nommant une situation réelle où vous l'avez utilisé, pas seulement la syntaxe.

Les questions de conception testent si vous réfléchissez à un schéma avant de réfléchir à une requête. Attendez-vous à une question sur la normalisation : pourquoi diviser les données en tables liées réduit les anomalies de mise à jour, et quand dénormaliser intentionnellement une table pour la performance de lecture est un compromis raisonnable plutôt qu'une erreur.

Soyez prêt à expliquer la différence entre une clé primaire et une contrainte unique, pourquoi une clé étrangère importe même quand l'application impose la relation dans le code, et comment vous choisiriez entre une clé naturelle et une clé de substitution pour une nouvelle table. Si on vous demande une colonne d'identité par rapport à un GUID comme clé primaire, mentionnez l'impact pratique : une identité séquentielle maintient les insertions d'index en cluster efficaces, tandis qu'un GUID aléatoire peut fragmenter rapidement l'index sauf si vous utilisez une variante séquentielle.

Une question de suivi orientée vers la conception pourrait vous demander d'esquisser un schéma pour un scénario spécifique, comme un système de commandes avec clients, produits et articles de ligne. Racontez votre réflexion : quelles entités ont besoin de leur propre table, quelles colonnes doivent être indexées pour les modèles de requête attendus, et où une contrainte pourrait attraper une mauvaise insertion avant qu'elle ne devienne un problème de qualité des données en aval.

Les questions de sauvegarde et de récupération vérifient si vous comprenez les compromis derrière une stratégie de récupération, pas seulement les commandes. Soyez prêt à expliquer les trois modèles de récupération : simple, complet et enregistré en masse, et comment chacun affecte si la récupération à un moment donné est même possible.

Décrivez la différence entre une sauvegarde complète, une sauvegarde différentielle et une sauvegarde du journal des transactions, et comment elles se combinent pendant une restauration. Les intervieweurs suivent souvent avec un scénario : la base de données a échoué à 14 heures, votre dernière sauvegarde complète était hier soir, et vous avez des sauvegardes de journal toutes les quinze minutes. Répondez en nommant la séquence de restauration et le point de récupération résultant, puis connectez-le à RPO et RTO en termes simples : combien de perte de données est acceptable, et à quelle vitesse le système doit-il revenir ?

Les entrevues plus seniors peuvent aussi vous demander de comparer les options de haute disponibilité à un niveau conceptuel : comment les groupes de disponibilité Always On diffèrent de la copie du journal, et pourquoi une entreprise pourrait toujours choisir l'option plus simple même si elle se récupère plus lentement. Vous n'avez pas besoin d'avoir configuré chaque option, mais vous devriez pouvoir expliquer quel problème chacun résout.

Si vous avez géré une vraie restauration ou un basculement, décrivez-le brièvement : ce qui s'est cassé, la chaîne de sauvegarde que vous avez utilisée, combien de temps a pris la restauration, et ce que vous avez changé après pour réduire la fenêtre de récupération la prochaine fois. Mentionner que vous testez réellement les restaurations selon un calendrier, au lieu d'assumer qu'un fichier de sauvegarde va bien jusqu'à preuve du contraire, est le genre de détail qui signale une vraie expérience opérationnelle.

Les questions de transactions testent si vous comprenez ce qui se passe quand plusieurs utilisateurs touchent les mêmes données en même temps. Commencez par ACID : atomicité, cohérence, isolation et durabilité, puis passez rapidement à quelque chose de plus concret que l'acronyme.

Soyez prêt à comparer les niveaux d'isolation : lecture validée, qui est la valeur par défaut de SQL Server, par rapport à la lecture non validée, la lecture répétable, la sérialisation et l'isolation d'instantané. Expliquez quel problème chacun résout, comme les lectures sales ou les lectures fantômes, et ce qu'il coûte en concurrence. Un bon candidat peut aussi décrire comment l'isolation d'instantané utilise le versioning des lignes dans tempdb au lieu de bloquer les lecteurs contre les rédacteurs, et pourquoi cela peut échanger la mémoire et la charge tempdb contre moins de plaintes de blocage des équipes applicatives.

Les questions d'interblocage reviennent souvent. Décrivez comment vous identifieriez un en utilisant le graphique d'interblocage dans les événements étendus, expliquez ce qu'est vraiment un interblocage, deux sessions tenant chacun un verrou que l'autre a besoin, et décrivez un correctif comme réordonner l'accès aux tables de manière cohérente ou raccourcir la transaction. Si l'intervieweur demande des indices de verrouillage comme NOLOCK ou ROWLOCK, expliquez le compromis clairement : NOLOCK évite le blocage mais peut retourner des lignes non validées ou en double, donc il appartient aux requêtes de rapport où les résultats approximatifs sont acceptables, pas dans les calculs financiers.

Un candidat qui peut raconter une enquête d'interblocage étape par étape, de l'observation du délai d'attente, à l'obtention du graphique, à l'identification de la requête à réécrire, se démarque généralement plus qu'un qui ne définit que le terme.

Une question courante d'entrevue SQL Server vous demande de parcourir le diagnostic d'un serveur qui ralentit soudainement. Traitez-le comme une narration de dépannage en direct, pas comme une liste d'outils. Commencez par ce que vous vérifieriez d'abord : les statistiques d'attente actuelles, les requêtes actives et les sessions de blocage, en utilisant des vues comme sys.dm_exec_requests, sys.dm_exec_sessions et sys.dm_os_wait_stats.

Expliquez comment vous distingueriez un problème lié au CPU, un problème lié à l'E/S et une chaîne de blocage en nommant les types d'attente que vous rechercheriez, comme les attentes PAGEIOLATCH pointant vers la pression disque ou les attentes LCK_M_X pointant vers le blocage. Mentionnez la contention tempdb comme cause courante mais souvent négligée de la lenteur inexplicable, particulièrement sur les serveurs avec une activité lourde de table temporaire ou de tri, et mentionnez le « parameter sniffing » comme cause d'une requête qui s'exécute vite pour une entrée et lentement pour une autre en utilisant le même plan en cache.

Si l'intervieweur insiste, décrivez comment vous isoleriez la requête spécifique : en capturant une session de trace ou d'événements étendus, puis en examinant le plan d'exécution pour la déclaration offensante, et en comparant les nombres de lignes estimés par rapport aux réels pour confirmer si une mauvaise estimation cause la lenteur.

Les intervieweurs posent ces questions basées sur des scénarios parce que lire une définition sur une diapositive est facile, mais raconter une enquête en direct sous la pression du temps ne l'est pas. Pratiquer la séquence à haute voix, dans l'ordre dans lequel vous l'effectueriez réellement, rend la différence évidente pour quiconque écoute.

Constituez une courte liste de vrais scénarios de votre propre travail : une correction d'indexation, une enquête d'interblocage ou de blocage, une situation de sauvegarde ou de restauration, et une réécriture de requête qui a amélioré la performance. Pour chacun, écrivez le symptôme, vos étapes de diagnostic, la correction et le résultat mesurable.

Ensuite, pratiquez en disant chaque histoire à haute voix, pas seulement en la lisant silencieusement. Les entrevues techniques récompensent les candidats qui peuvent expliquer une décision clairement sous la pression du temps, et cette compétence ne vient pas de relire des notes. SayNow vous permet de répéter les questions d'entrevue SQL Server avec des invites de suivi réalistes, donc vous vous habituez à expliquer un plan d'exécution ou un choix de niveau d'isolation en conversation au lieu de dans votre tête pour la première fois pendant la vraie entrevue.

La pratique à haute voix expose aussi les lacunes que l'examen silencieux cache. Il est courant de penser que vous comprenez clairement les niveaux d'isolation jusqu'à ce que vous essayiez d'expliquer l'isolation d'instantané à quelqu'un d'autre et réalisez que votre explication s'essouffle à mi-chemin. L'attraper en pratique est bien mieux que de l'attraper devant un panel de recrutement.

Finalement, préparez quelques questions de votre côté : comment l'équipe surveille la performance des requêtes, à quoi ressemble leur processus de test de sauvegarde et de récupération, ou comment les changements de schéma sont examinés. Les questions réfléchies signalent le même jugement opérationnel que l'entrevue testait en premier lieu.