Quelles sont les questions pour tester les connaissances d'un programmeur en SQL? [fermé]
14
Quelles sont les questions pour tester les connaissances d'un programmeur en SQL? Quelle est la réponse à la question? Et que signifierait l'absence d'une réponse correcte en termes de temps susceptible de comprendre le ou les concepts liés à la question?
Je donnerais certainement un exemple réel et demanderais d'écrire une requête complexe. Par exemple, demandez à sélectionner le mois le plus rentable pour chacune des 10 dernières années, si vous avez le tableau des achats. MAIS puisque vous posez également des questions sur les questions et les réponses, cela signifie probablement que vous n'êtes pas expert et ne pouvez pas juger. Dans ce cas, vous pouvez essayer un service de test tiers, au moins comme filtre initial avant l'entretien. Je suggérerais tests4geeks.com . Ils ont un test SQL.
Dhaval Patel
Réponses:
20
Cela dépend de la difficulté avec laquelle vous le souhaitez. De plus, je me méfie un peu de vous donner la réponse car la plupart des problèmes SQL ont plusieurs façons acceptables de faire les choses et il existe également des moyens de résoudre les problèmes SQL de manière bâclée qui entraîneront d'autres problèmes. La personne qui «note» la réponse doit absolument pouvoir la résoudre par elle-même.
Cela dit, voici quelques-uns que j'ai inventés du haut de ma tête.
Niveau extrêmement facile: étant
donné une table d'employés avec les colonnes EmpID, FirstName, Lastname, HireDate et TerminationDate:
Écrivez une requête pour renvoyer tous les employés travaillant encore pour l'entreprise avec des noms commençant par "Smith" triés par nom puis prénom.
Niveau facile
Étant donné le tableau Employé ci-dessus, plus un nouveau tableau "AnnualReviews" avec les colonnes EmpID et ReviewDate:
Écrivez une requête pour renvoyer tous les employés qui n'ont jamais eu d'avis révisés par HireDate.
Niveau moyen
Compte tenu du tableau des employés ci-dessus, écrivez une requête pour calculer la différence (en jours) entre l'employé le plus ancien et le moins titulaire travaillant toujours pour l'entreprise?
Niveau difficile
Compte tenu du tableau des employés ci-dessus, écrivez une requête pour calculer la période la plus longue (en jours) pendant laquelle l'entreprise a passé sans embaucher ou licencier quelqu'un.
Niveau plus difficile
Encore une fois en utilisant les mêmes tableaux, écrivez une requête qui renvoie chaque employé et pour chaque ligne / employé inclut le plus grand nombre d'employés qui ont travaillé pour l'entreprise à tout moment au cours de leur mandat et la première date à laquelle ce maximum a été atteint. Points supplémentaires pour ne pas utiliser de curseurs.
Bien, répondez - vraiment comme l'évolution des questions. Pourquoi la personne qui pose les questions doit-elle pouvoir y répondre? Pourquoi ne pas simplement écrire un test unitaire basé sur la sortie et l'exécution? De plus, que diriez-vous du nombre de semaines connectives de progression de la maîtrise des concepts SQL, il faudrait au programmeur moyen pour atteindre le niveau le plus difficile que vous lui donniez? Croiriez-vous également qu'un programmeur capable de répondre à la question la plus difficile que vous lui poseriez serait en mesure de traiter efficacement une très grande majorité des tâches liées à SQL?
bévues
3
La raison pour laquelle je voudrais que le demandeur (ou du moins le «correcteur») puisse y répondre est que l'approche peut vous en dire autant que le résultat. Je m'inquiète également qu'un intervieweur non technicien ait une réponse pré-écrite et n'accepte pas d'autres réponses potentiellement correctes (la carte dit "Moop").
JohnFx
Quant à savoir si ces questions démontrent la capacité de traiter une très grande majorité des tâches liées à SQL. Si leur travail consistera à écrire des requêtes, probablement. Si vous vous attendez à ce qu'ils administrent un serveur de base de données, vous devrez alors poser des questions spécifiques à cela.
JohnFx
Merci pour les clarifications, l'intervieweur non technicien dans ce cas ne serait pas une personne, mais un système, d'où le test unitaire et le temps d'exécution. Il est clair que les systèmes n'écrivent ni ne lisent de code, les humains le sont, mais il y a tellement de programmeurs dans le monde, et le besoin à mon avis de les avoir sur place est au mieux limité. Devinez si une personne a échoué au test, mais pensait qu'elle avait raison, elle pouvait toujours signaler comme correcte.
bévue
Et oui, la cible des questions serait un programmeur, pas un administrateur de base de données.
bévues
4
Je ne m'assois généralement que sur des entretiens pour des spécialistes des données, donc mes questions ont tendance à être difficiles. Mais une chose que j'exigerais de quiconque écrira SQL est la connaissance des jointures et quand utiliser une jointure gauche par rapport à une jointure interne. Quiconque ne comprend pas cela n'a aucune raison d'interroger une base de données de quelque manière que ce soit.
Une autre chose que je ferais est de m'assurer qu'ils comprennent comment faire un GROUP BY et utiliser les fonctions d'agrégation.
Et la différence entre UNION et UNION ALL a éliminé beaucoup de mauvais candidats à mon travail.
Je demanderais "Pourquoi et comment devriez-vous désinfecter les valeurs d'entrée fournies par l'utilisateur qui seront utilisées dans une requête SQL?"
Cela est nécessaire pour éviter les injections SQL, et d' être en mesure de répondre à cette demande une bonne connaissance de la syntaxe SQL et les commandes ( par exemple SELECT, UPDATE, DROP, DELETE, etc.), ainsi comment ceux -ci peuvent être contournées par l' utilisation des commentaires SQL pour casser une requête et injecter ce que l'utilisateur malin voudra peut-être faire.
N'est-ce pas la réponse: ne désinfectez jamais les intrants, utilisez une instruction préparée?
Kevin Cline
@Emmad Kareem, quiconque ne peut pas répondre à cette question ne devrait pas écrire SQL.
HLGEM
@gablin, je ne vois vraiment pas pourquoi. Pourriez-vous expliquer un peu? Combien de livres SQL discutent de ce sujet?
NoChance
2
J'ai participé au développement d'un test technique pour les programmeurs de bases de données. Les questions étaient ce que je considère assez basiques: écrire les instructions CREATE TABLE pour une structure de table donnée; faites quelques requêtes simples; etc.
La plupart des candidats à l'emploi qui se disaient experts en SQL ont échoué au test. L'un d'eux a dit que bien qu'il ait été développeur SQL pendant de nombreuses années, il n'avait jamais écrit une instruction CREATE TABLE parce que l'interface graphique l'avait fait pour lui.
Nous avons eu des expériences similaires avec d'autres tests techniques. Pour le personnel de support Windows, les tâches sont similaires à «créer un utilisateur de domaine», «ajouter une imprimante», «modifier les autorisations sur un fichier». La plupart des gens ne peuvent pas faire ces tâches, surtout sous pression. Nous pensons que si vous pouvez faire même des choses simples, vous êtes probablement assez compétent.
J'ai bien peur d'être du côté du développeur qui utilise l'interface graphique. Vous pouvez passer une carrière entière sans écrire régulièrement des scripts CREATE TABLE. De nombreuses personnes développent des modèles de données dans les outils CASE qui génèrent automatiquement la DDL pour vous. En général, je répugne à tous les tests qui reposent principalement sur la mémorisation de la syntaxe, en faveur de ceux qui testent une compréhension plus large des problèmes impliqués
cjmUK
+1 @Barry Brown: Je suis d'accord, et c'est un point intéressant.
bévues
0
Si vous préférez poser des questions plus ouvertes: posez des questions générales sur les types de données DATE, DATETIME ... Renseignez-vous sur les différences entre les différentes implémentations / produits des fournisseurs. Parlez des outils de ligne de commande, des chargeurs en vrac, des jolies imprimantes ... peut-être que vous pouvez apprendre une nouvelle astuce pendant l'entretien.
Réponses:
Cela dépend de la difficulté avec laquelle vous le souhaitez. De plus, je me méfie un peu de vous donner la réponse car la plupart des problèmes SQL ont plusieurs façons acceptables de faire les choses et il existe également des moyens de résoudre les problèmes SQL de manière bâclée qui entraîneront d'autres problèmes. La personne qui «note» la réponse doit absolument pouvoir la résoudre par elle-même.
Cela dit, voici quelques-uns que j'ai inventés du haut de ma tête.
Niveau extrêmement facile: étant
donné une table d'employés avec les colonnes EmpID, FirstName, Lastname, HireDate et TerminationDate:
Écrivez une requête pour renvoyer tous les employés travaillant encore pour l'entreprise avec des noms commençant par "Smith" triés par nom puis prénom.
Niveau facile
Étant donné le tableau Employé ci-dessus, plus un nouveau tableau "AnnualReviews" avec les colonnes EmpID et ReviewDate:
Écrivez une requête pour renvoyer tous les employés qui n'ont jamais eu d'avis révisés par HireDate.
Niveau moyen Compte tenu du tableau des employés ci-dessus, écrivez une requête pour calculer la différence (en jours) entre l'employé le plus ancien et le moins titulaire travaillant toujours pour l'entreprise?
Niveau difficile
Compte tenu du tableau des employés ci-dessus, écrivez une requête pour calculer la période la plus longue (en jours) pendant laquelle l'entreprise a passé sans embaucher ou licencier quelqu'un.
Niveau plus difficile
Encore une fois en utilisant les mêmes tableaux, écrivez une requête qui renvoie chaque employé et pour chaque ligne / employé inclut le plus grand nombre d'employés qui ont travaillé pour l'entreprise à tout moment au cours de leur mandat et la première date à laquelle ce maximum a été atteint. Points supplémentaires pour ne pas utiliser de curseurs.
la source
Je ne m'assois généralement que sur des entretiens pour des spécialistes des données, donc mes questions ont tendance à être difficiles. Mais une chose que j'exigerais de quiconque écrira SQL est la connaissance des jointures et quand utiliser une jointure gauche par rapport à une jointure interne. Quiconque ne comprend pas cela n'a aucune raison d'interroger une base de données de quelque manière que ce soit.
Une autre chose que je ferais est de m'assurer qu'ils comprennent comment faire un GROUP BY et utiliser les fonctions d'agrégation.
Et la différence entre UNION et UNION ALL a éliminé beaucoup de mauvais candidats à mon travail.
la source
Je demanderais "Pourquoi et comment devriez-vous désinfecter les valeurs d'entrée fournies par l'utilisateur qui seront utilisées dans une requête SQL?"
Cela est nécessaire pour éviter les injections SQL, et d' être en mesure de répondre à cette demande une bonne connaissance de la syntaxe SQL et les commandes ( par exemple
SELECT,UPDATE,DROP,DELETE, etc.), ainsi comment ceux -ci peuvent être contournées par l' utilisation des commentaires SQL pour casser une requête et injecter ce que l'utilisateur malin voudra peut-être faire.la source
J'ai participé au développement d'un test technique pour les programmeurs de bases de données. Les questions étaient ce que je considère assez basiques: écrire les instructions CREATE TABLE pour une structure de table donnée; faites quelques requêtes simples; etc.
La plupart des candidats à l'emploi qui se disaient experts en SQL ont échoué au test. L'un d'eux a dit que bien qu'il ait été développeur SQL pendant de nombreuses années, il n'avait jamais écrit une instruction CREATE TABLE parce que l'interface graphique l'avait fait pour lui.
Nous avons eu des expériences similaires avec d'autres tests techniques. Pour le personnel de support Windows, les tâches sont similaires à «créer un utilisateur de domaine», «ajouter une imprimante», «modifier les autorisations sur un fichier». La plupart des gens ne peuvent pas faire ces tâches, surtout sous pression. Nous pensons que si vous pouvez faire même des choses simples, vous êtes probablement assez compétent.
la source
Si vous préférez poser des questions plus ouvertes: posez des questions générales sur les types de données DATE, DATETIME ... Renseignez-vous sur les différences entre les différentes implémentations / produits des fournisseurs. Parlez des outils de ligne de commande, des chargeurs en vrac, des jolies imprimantes ... peut-être que vous pouvez apprendre une nouvelle astuce pendant l'entretien.
la source