Il n'y a pas de recette pour répondre aux questions d'entretien sur le codage en science des données. Il n'y a pas une seule approche qui fonctionnera toujours. Cependant, il existe quelques principes directeurs qui, dans la plupart des cas, vous aideront à mieux répondre aux questions de codage.

Ces directives sont formées sur l'expérience d'aller aux entrevues et de répondre aux questions de codage. Nous avons divisé ces lignes directrices en quatre sections. Vous pouvez utiliser ces directives comme liste de contrôle, surtout si vous n'êtes pas très expérimenté avec questions d'entretien sur le codage en science des données. Plus tard, vous pourrez bien sûr trouver votre propre approche, peut-être ignorer certains points ou même inclure quelque chose qui vous convient mieux.

Mais quelle que soit votre expérience, si vous suivez cette liste de contrôle, vous augmentez vos chances de donner une bonne réponse à une question de codage.

La liste de contrôle en quatre parties

 
Les quatre parties de cette liste de contrôle sont les suivantes :

1. Analyse des questions
2. Approche de la solution
3. Écrire un code
4. Examen de votre code

Maintenant que vous avez le plan de la liste de contrôle, nous allons examiner chaque section et expliquer les points de la liste de contrôle qu'elle contient.

1. Analyse des questions

 
La partie Analyse de la question de la liste de contrôle consiste à prendre quelques minutes et à bien réfléchir à la question que vous venez de recevoir. Comme vous le verrez lorsque vous traiterez de vrais problèmes d'affaires, il est toujours préférable de penser d'abord au problème et de « perdre » du temps pour le voir sous tous les angles. N'oubliez pas que réfléchir n'est jamais une perte de temps !

Ces quelques minutes seront payantes plus tard. Si vous passez immédiatement à l'écriture de la solution, il y a de fortes chances que vous deviez recommencer à zéro une fois que vous aurez réalisé que votre approche ne mène pas à la solution souhaitée. Ou que vous devez constamment changer et réécrire votre code.

Les points qui vous aideront à vous exercer à réfléchir au problème sont les suivants :

1. Comprendre la question
2. Analysez les tables et les données avec lesquelles vous travaillez
3. Pensez au résultat du code

je. Comprendre la question

Pour vous assurer que vous comprenez la question, vous devrez lire la question très attentivement. Lisez-le lentement. Et lisez-le 2-3 fois pour vous assurer de ne rien manquer. Ceci s'applique à tous questions d'entretien en science des données, qu'ils soient faciles ou difficiles. Le fait est que vous ne saurez pas si la question que vous avez est difficile ou facile. Certaines des questions peuvent sembler trompeusement simples, mais elles ont un piège qui est là exactement pour éliminer les candidats qui ne sont pas assez approfondis et ont tendance à être superficiels.

Si la question n'est pas écrite, n'hésitez pas non plus à demander à l'intervieweur de la répéter si vous n'avez pas saisi quelque chose. Dans ce cas, il est également conseillé, une fois que vous avez compris la question, de la répéter à l'intervieweur. De cette façon, vous vous assurerez que vous avez bien compris et permettrez à l'intervieweur de se corriger au cas où il ne vous aurait pas donné toutes les informations nécessaires.

ii. Analysez les tables et les données avec lesquelles vous travaillez

Une fois que vous comprenez la question, la prochaine étape logique consiste à analyser les tableaux qui vous sont donnés. Cela signifie que vous devez analyser combien de tables il y a et comment elles sont connectées les unes aux autres (clé étrangère et clé primaire).

Vous voudrez également voir quelles données se trouvent dans ces tables. Signifiant quelles colonnes sont là dans chaque table. Quel type de données se trouve dans chaque colonne. Ceci est important car votre code dépendra du fait que vous manipulez des données de chaîne, des entiers, de l'argent ou tout autre type de données. Peut-être aurez-vous même besoin de convertir un type de données en un autre pour obtenir le résultat souhaité.

Outre le type de données, il est également important de comprendre comment les données sont organisées, ordonnées et granulées. Cela signifie-t-il qu'il y a des valeurs en double dans le tableau ? Les données sont-elles présentées, par exemple, au niveau du client, au niveau de la transaction, etc. ?

iii. Pensez au résultat du code

Avant de commencer à coder, vous devez savoir à quoi vous voulez que votre résultat ressemble. Bien sûr, cela dépend aussi de la question à laquelle vous voulez répondre.

Mais en pensant au résultat littéraire moyen, s'agira-t-il d'une seule valeur sur une ligne ou d'un tableau à plusieurs colonnes. S'il s'agit d'un tableau, vous devez à nouveau réfléchir à la manière dont vos données seront agrégées et ordonnées, au nombre de colonnes que vous devez afficher, etc.

 
Analyse des questions – Exemple

Pour vous montrer comment cette première section de la liste de contrôle doit être appliquée, nous utiliserons la question de codage Dropbox. La question va comme ceci:

« Écrivez une requête qui calcule la différence entre les salaires les plus élevés trouvés dans les départements marketing et ingénierie. Sortie juste la différence de salaires.

Lien vers la question : https://platform.stratascratch.com/coding/10308-salaries-differences

Si vous lisez attentivement la question, vous vous rendrez compte que vous devez trouver le salaire le plus élevé. OK, mais pas le salaire le plus élevé dans tous les départements mais seulement dans deux départements : marketing et ingénierie. Une fois que vous avez trouvé le salaire le plus élevé dans ces deux départements, vous devez calculer la différence entre eux.

Maintenant que vous comprenez la question, vous pouvez analyser les tableaux et les données qu'ils contiennent. Les tables avec lesquelles vous travaillerez sont db_employee et db_dept. La table db_employee contient des données sur les employés de l'entreprise. Il comporte cinq colonnes :

Vous voyez, les colonnes de nom sont de type de données varchar, tandis que le salaire est un entier. Il pourrait être important de savoir qu'il n'y a pas de décimales dans les valeurs salariales. Si vous utilisez l'option de prévisualisation disponible ici, vous verrez que ces données sont uniques : chaque employé n'a qu'une seule valeur de salaire qui lui est attribuée. Aussi, une chose importante à savoir; il peut également s'agir de données historiques où vous aurez tous les salaires précédents au fil des ans pour chaque employé. Il y a une colonne department_id, qui est une clé étrangère qui relie cette table à la table db_dept :

Seulement deux colonnes dans ce tableau. Il s'agit uniquement d'une liste de départements, pas de doublons, avec six départements indiqués dans le tableau.

Bien, vous avez analysé les données. Maintenant, revenez à la question et lisez la deuxième phrase. Oui, ceci est une instruction sur ce que votre solution doit être. Vous n'avez pas besoin d'afficher le salaire le plus élevé d'un département dans une colonne, puis le salaire le plus élevé de l'autre dans la deuxième colonne, puis la différence entre eux dans la troisième colonne. Non, la sortie ne sera que la différence :

Il n'y avait aucune instruction sur le nom de cette colonne de sortie. Donc, ce ne sera pas une erreur, peu importe comment vous l'appelez ou si vous ne le nommez pas du tout. L'important est que vous obteniez ce résultat et rien d'autre.

Avec cela, vous avez les bases pour écrire un code de qualité. Il est maintenant temps de parler de stratégie : comment allez-vous écrire un code ?
 

2. Approche de la solution

 
Avant de commencer à écrire un code, il est également important que vous ayez une idée claire de ce à quoi ressemblera votre code. Le codage ne devrait traduire que votre idée (claire !) de la solution au langage de programmation.

Lorsque vous réfléchissez à la manière dont vous devriez aborder votre solution (ou écrire un code), tenez compte des points suivants :

1. Existe-t-il plusieurs manières d'écrire un code ?
2. Énoncez vos hypothèses
3. Décomposez votre solution en étapes
4. Commencer le codage

je. Existe-t-il plusieurs manières d'écrire un code ?

Lorsque l'on réfléchit à la solution, ce qui vient d'abord à l'esprit est parfois la meilleure solution. Et parfois ce n'est pas le cas. Comment pourriez-vous savoir? Une fois que vous avez la première idée, l'astuce consiste à se demander s'il existe un autre moyen de résoudre le problème. Dans langages de programmation, la plupart du temps, il existe plusieurs solutions possibles.

Gardez cela à l'esprit. Il y a plusieurs raisons pour lesquelles cela est important. Tout d'abord, il pourrait y avoir une astuce ou une fonction simple qui résout facilement quelque chose que vous pensez résoudre avec un code long, par exemple, en utilisant fonctions de fenêtre ou CTE au lieu d'écrire un code avec des sous-requêtes sans fin.

Optez toujours pour ce qui est plus facile à écrire, avec le moins de lignes de code possible. Lorsque vous êtes à l'entretien, vous devez également gérer le temps dont vous disposez. C'est l'un des moyens.
Bien sûr, s'il existe plusieurs solutions plus ou moins également complexes, réfléchissez à la manière dont le code fonctionnera. Sur de grandes quantités de données, différents codes peuvent prendre beaucoup plus de temps et de mémoire que d'autres.

En bref, vous devriez penser à l'efficacité du code de deux manières. L'un est l'efficacité personnelle, ou la vitesse à laquelle vous pouvez écrire un code. Le second est l'efficacité du code ou la vitesse à laquelle le code exécutera ce que vous voulez.

ii. Énoncez vos hypothèses

Énoncer vos hypothèses est important pour plusieurs raisons. La première consiste à les dire à haute voix et à les écrire, ce qui vous aidera à voir les problèmes potentiels de votre approche.

La deuxième raison importante est qu'elle invite votre interlocuteur à communiquer avec vous et même à vous offrir de l'aide, ce qu'il fait habituellement. S'ils ne savent pas ce que vous voulez faire et pourquoi, ils ne peuvent pas vous aider. Comme nous l'avons déjà mentionné, il existe généralement plusieurs solutions qui renvoient le même résultat. Communiquer vos hypothèses permet à l'intervieweur de vous orienter dans la bonne direction en fonction de l'approche que vous avez choisie. Ou même vous éloigner des hypothèses complètement fausses qui gâcheront votre solution.

La troisième raison est que parfois la question peut être intentionnellement définie pour être vague. Ces questions ne concernent pas tant la bonne solution que la façon dont vous pensez. Donc, si vous énoncez vos hypothèses, cela montrera à l'intervieweur ce que vous pensez, ce qui l'intéresse généralement beaucoup.

La quatrième et dernière raison pour énoncer vos hypothèses est que même si vous obtenez la réponse complètement fausse mais correcte dans les hypothèses que vous avez énoncées, il y a de fortes chances que vous obteniez encore des points pour cela. La pensée, dans ce cas, tourne autour de ces lignes : OK, peut-être que le candidat a complètement mal compris ce qui a été demandé, mais la solution est en fait correcte dans le contexte de ce qu'il a compris.

Tout cela conduit à s'assurer de donner la bonne réponse à une question d'entrevue.

iii. Décomposez votre solution en étapes

C'est également un point utile qui vous permettra d'avoir une idée claire de la solution et, plus tard, d'écrire un code propre.

Décomposer, dans ce cas, signifie écrire. Oui, notez toutes les étapes et fonctions clés de votre solution. Demandez-vous si vous devez joindre des tables, combien de tables et quelle jointure vous utiliserez. Devez-vous écrire une sous-requête ou un CTE ? Notez votre choix. Pensez aux fonctions d'agrégation que vous devrez utiliser, si vous devrez convertir des types de données, si les données doivent être ordonnées d'une manière spécifique, si elles doivent être filtrées et regroupées, etc.

Toutes ces étapes sont distinctes, alors écrivez-les, ainsi que les principaux mots-clés que vous utiliserez à chaque étape.

iv. Commencer à coder

Celui-ci est un point d'urgence, en quelque sorte. Si vous avez réfléchi à votre approche de la solution, mais que vous ne pouvez tout simplement pas voir la solution complète sous vos yeux, alors vous devriez simplement commencer à écrire un code.

L'idée derrière cela est que même si vous donnez une solution incomplète, cela vaut certainement plus que de ne pas écrire une seule ligne de code. De plus, certaines questions peuvent être vraiment difficiles, et il est difficile, même pour les plus expérimentés, de voir immédiatement toute la solution. Commencez à coder, et il y a une chance que vous trouviez une idée en cours de route. Et sinon, encore une fois, vous avez au moins quelque chose à montrer.

Une raison supplémentaire que vous devriez avoir à l'esprit : certaines questions ne sont même pas destinées à recevoir une réponse. Certains d'entre eux sont tout simplement (et intentionnellement !) trop difficiles à résoudre dans le temps imparti à l'entretien. Personne ne les résout complètement. La solution partielle est la meilleure que quiconque obtiendra. Ainsi, vous serez marqué sur la distance parcourue par rapport aux autres solutions incomplètes.

 
Approche de la solution - Exemple

Maintenant que vous savez comment vous devriez penser à votre approche de solution, utilisons une question d'entretien pour démontrer comment cela fonctionne dans la pratique. Nous utiliserons la question de l'entretien de codage Amazon :

« Trouvez le coût total des commandes de chaque client. Affichez l'identifiant, le prénom et le coût total de la commande du client. Triez les enregistrements par prénom du client par ordre alphabétique.

Lien vers la question : https://platform.stratascratch.com/coding/10183-total-cost-of-orders

Nous devrons utiliser les données de deux tables, les clients de table et les commandes de table avec cette question. Nous pouvons écrire un code avec des sous-requêtes pour surmonter ce problème. Cependant, vous savez probablement que si la requête et la sous-requête utilisent des données provenant de plusieurs tables, la solution peut également être écrite à l'aide de JOIN. Ayant à l'esprit le conseil d'écrire le moins de lignes de code possible, il est préférable d'utiliser JOIN.

Quelles sont les hypothèses de cette solution ? Une hypothèse pourrait être qu'il peut y avoir des clients qui n'ont aucune commande. Cela signifie qu'il pourrait y avoir des clients dans la table des clients qui n'apparaîtront pas dans les commandes de la table. La deuxième hypothèse est que nous ne montrerons pas les clients avec zéro commande puisque la question ne le disait pas explicitement.

Maintenant, cela nous amène déjà à une ventilation de la solution. Nous devons sortir deux colonnes déjà existantes, donc nous utiliserons certainement SELECT. Nous devons trouver le total des commandes de chaque client. Nous devrons le résumer en utilisant la fonction d'agrégation SUM(). OK, les tables doivent être jointes. Nous allons le faire en utilisant le mot-clé JOIN. Pourquoi pas une autre jointure ? Parce que notre hypothèse le dit, nous ne voulons que les clients qui ont au moins une commande. L'utilisation de JOIN nous donnera exactement cela : il joindra deux tables et ne trouvera que les valeurs (clients) qui se trouvent dans les deux tables. Et ensuite ? J'ai utilisé la fonction d'agrégation, donc je vais devoir utiliser GROUP BY. Et le résultat doit être classé par ordre alphabétique, donc j'utiliserai ORDER BY et ASC.

La répartition de la solution résultante pourrait alors ressembler à ceci :

• SELECT
• SOMME (coût_total_de_la_commande)
• INSCRIPTION
• PAR GROUPE
• COMMANDER PAR ASC

Dans votre cas, ce n'est pas une urgence puisque vous avez tout compris, vous pouvez donc passer à la section suivante de la liste de contrôle. Ou vous pouvez également trouver les plus courants Questions d'entretien SQL JOIN ici.

3. Écrire un code

 
Après avoir évalué la question et défini la stratégie de votre code, il est temps de commencer à l'écrire.

1. S'en tenir à un dialecte choisi
2. Allez ligne par ligne lors du codage
3. Parlez pendant que vous codez
4. Rendre lisible
5. Être cohérent avec les conventions choisies

je. S'en tenir à un dialecte choisi

Ceci est particulièrement important si vous participez à l'entretien de codage SQL. Comme vous le savez déjà, il existe une norme SQL ANSI/ISO et de nombreux dialectes SQL. Pratiquement chaque SGBDR utilise son propre dialecte SQL. Bien sûr, vous ne pouvez pas tous les connaître. Et l'entreprise pour laquelle vous interviewez utilise probablement l'un de ces dialectes.

Si l'intervieweur ne se soucie pas du dialecte que vous utilisez, choisissez celui avec lequel vous êtes le plus à l'aise. N'essayez pas de faire appel à l'intervieweur en choisissant le dialecte SQL qu'il utilise si vous n'êtes pas très fort avec le codage dans ce dialecte. Il est préférable de choisir le dialecte que vous connaissez le mieux et de résoudre le problème plutôt que d'utiliser un autre dialecte dont vous n'êtes pas sûr. Si vous choisissez ce dernier, il y a de fortes chances que vous soyez plus nerveux que nécessaire. De plus, ne pas être familier avec le dialecte SQL particulier pourrait vous faire gâcher la solution.

Une fois que vous avez choisi le dialecte SQL, respectez-le. Par exemple, si vous choisissez d'écrire en PostgreSQL, ne le confondez pas avec T-SQL.

ii. Aller ligne par ligne

Avoir une répartition claire de la solution vous aidera à vérifier ce point presque inaperçu. Comme vous avez déjà décrit les fonctions et les sections de votre code, il vous suffit de rester calme et d'écrire systématiquement un code en suivant les grandes lignes de la solution. Le code n'est rien de plus qu'une version en langage de programmation de vos pensées. Si vos pensées et votre plan de solution sont clairs, votre code le sera aussi.

Si vous commencez à sauter d'une ligne à l'autre, vous serez confus, ainsi que l'intervieweur. Ce qui conduira probablement à ne pas écrire le bon code.

iii. Parlez pendant que vous codez

Lorsque vous écrivez votre code ligne par ligne, vous devez également parler de ce que vous faites. Ceci est important car lorsque vous dites à haute voix ce que vous faites, il vous est plus facile de voir si vous faites quelque chose de mal. Tout pourrait bien sonner dans votre tête. Mais lorsque vous l'exprimez, les idées pas si bonnes ressortent vraiment ! Cela vous donne la possibilité de corriger le code au fur et à mesure. Sinon, vous pourriez terminer votre code sans même vous rendre compte que vous avez fait quelque chose de mal.

L'une des raisons pour lesquelles il est important d'expliquer chaque ligne au fur et à mesure que vous l'écrivez est qu'elle invite à nouveau l'intervieweur à participer à votre solution. Cela leur permet de comprendre ce que vous faites et de vous donner quelques indices. Si vous écrivez simplement un code et que vous gardez pour vous ce que vous faites, l'intervieweur se fermera probablement et attendra simplement que vous terminiez le code pour vous faire savoir comment vous avez fait.

iv. Rendez-le lisible

Avoir un code bien structuré est une joie à voir simplement du point de vue esthétique. Non seulement cela, mais cela facilite la lecture de votre code pour vous et pour l'intervieweur.

La principale chose qui rend votre code lisible est mentionnée dans l'un des points ci-dessus : écrivez-le aussi simplement que possible. Cependant, certaines solutions ne peuvent pas être simples. Et même quelques lignes de code pourraient être un cauchemar à lire si vous ne faites pas un effort pour le rendre lisible.

L'un des conseils à garder à l'esprit est d'utiliser l'espace, la tabulation et la saisie. Et profitez-en beaucoup ! Ces clés sont là pour séparer votre code en sections, ce qui facilite la compréhension de ce que fait le code. Pensez-y comme à tout ce que vous dites ou écrivez. Espace, tabulation et entrée feront en sorte que votre code contienne des virgules, des phrases et des paragraphes.

Si possible, utilisez des alias pour les tables. Mais essayez de les rendre explicites. Évitez d'utiliser des alias à une seule lettre, mais ne faites pas non plus d'alias trop verbeux et descriptifs. Il en va de même pour les noms de variables.

Bien que SQL ne soit pas sensible à la casse, il est toujours préférable d'écrire les mots-clés SQL en majuscules. Cela les fera également ressortir dans le code, surtout si tous les noms de colonnes et de tables sont écrits en minuscules.

Consultez notre publication "Meilleures pratiques pour écrire des requêtes SQL : comment structurer votre code” qui se concentre sur la façon dont vos requêtes SQL peuvent être améliorées, notamment en termes de performances et de lisibilité.

v. Être cohérent avec les conventions choisies

Il n'y a pas de règles qui vous obligent à écrire en majuscules ou en minuscules ; il n'y a pas de convention de dénomination prescrite, c'est donc à vous de décider comment vous l'aimez. Mais quoi que vous fassiez, soyez cohérent avec cela.

Si vous souhaitez écrire tous les nouveaux noms de colonnes en minuscules et séparer les mots par des traits de soulignement, faites-le et conservez-le ainsi. Nommer une colonne salaire_par_employé semble plutôt bien. Mais essayez d'éviter de nommer une colonne salaire_per_employee, l'autre SalaryPerDepartment, la troisième 'Total Salary' et la quatrième MAX_sALAryPerdeparment. Vous vous blesserez en essayant de lire le code, surtout avec le dernier.

Il en va de même lorsque vous écrivez des noms de table, utilisez des alias, etc. Le maintien de la cohérence ajoutera également à la lisibilité de votre code.

En parlant de cohérence, nous allons vous montrer comment cette section de liste de contrôle fonctionne dans la pratique.

 
Écrire un code – Exemple

Voici une question de codage par Facebook :

"Facebook envoie des SMS lorsque les utilisateurs tentent de 2FA (authentification à 2 facteurs) sur la plate-forme pour se connecter. Pour réussir la 2FA, ils doivent confirmer qu'ils ont reçu le SMS. Les textes de confirmation ne sont valables qu'à la date à laquelle ils ont été envoyés. Malheureusement, il y a eu un problème ETL avec la base de données où des demandes d'amis et des enregistrements de confirmation invalides ont été insérés dans les journaux, qui sont stockés dans la table 'fb_sms_sends'. Ces types de messages ne doivent pas figurer dans le tableau. Heureusement, la table 'fb_confirmers' contient des enregistrements de confirmation valides, vous pouvez donc utiliser cette table pour identifier les SMS qui ont été confirmés par l'utilisateur.

Calculez le pourcentage de SMS confirmés pour le 4 août 2020. »

Lien vers la question : https://platform.stratascratch.com/coding/10291-sms-confirmations-from-users

Si vous écrivez un code comme celui-ci, il couvrira tout ce que nous avons mentionné dans cette section de la liste de contrôle :

SELECT cust_id, SUM(total_order_cost) AS revenue
FROM orders
WHERE EXTRACT('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019
GROUP BY cust_id
ORDER BY revenue DESC

Imaginons que Facebook utilise SQL Server, mais c'est à vous de décider dans quel dialecte SQL vous écrirez votre code. Vous n'êtes pas familier avec T-SQL, vous décidez donc d'écrire en PostgreSQL.

Par exemple, EXTRACT() et le double-virgule (::) sont des fonctions typiques de PostgreSQL. Le premier extrait la partie de la date du type de données datetime. Il n'existe pas dans T-SQL ! Donc, si vous dites à l'intervieweur que vous écrivez en T-SQL et que vous utilisez ensuite cette fonction, vous ferez une erreur. Dans T-SQL, vous devez utiliser la fonction DATEPART(). Et vous devez savoir que cette fonction dans PostgreSQL s'appelle DATE_PART(). Un trait de soulignement pourrait signifier une différence entre votre code qui fonctionne et ne fonctionne pas.

De même, le double-virgule (::) dans PostgreSQL est utilisé pour la conversion du type de données. En T-SQL, cela ne fonctionne pas ; vous devrez utiliser CAST() ou CONVERT().

Avoir une répartition de la solution pour ce code vous permettra de l'écrire facilement ligne par ligne. C'est facile, en fait. Tout d'abord, vous devez sélectionner des données dans un tableau, les filtrer, les regrouper et enfin les ordonner. N'écrivez pas d'abord la clause WHERE, puis passez à l'instruction SELECT, puis à la conversion du type de données ou à toute autre manière bizarre d'aborder votre code.

Pendant que vous codez, vous pouvez parler à l'intervieweur comme ceci : je sélectionne la colonne cust_id à l'aide de la fonction SUM() pour calculer les revenus des commandes de table. Ensuite, j'utilise la clause WHERE pour filtrer les données en fonction du mois et de l'année à partir de la colonne order_date. Après cela, je regroupe les données au niveau du client et je classe le résultat dans un ordre décroissant.

Vous voyez qu'il y a une indentation dans ce code, il y a une nouvelle ligne pour chaque élément clé du code et les conventions de dénomination sont cohérentes. Voulez-vous voir à quoi ressemblerait le code si nous ne suivions pas cela ? C'est ici:

SELECT id_client,SUM(coût_total_commande) AS REVENUE FROM ORDERS WHERE EXTRACT('MONTH' FROM order_date :: TIMESTAMP) = 3 AND EXTRACT('YEAR' FROM order_date :: TIMESTAMP) = 2019 GROUP BY id_client commande BY Revenue DESC

Bonne chance pour le lire!

4. Révision de votre code

 
Après avoir écrit le code, il est temps de le réviser avant qu'il ne devienne votre réponse finale. Si vous avez suivi tous les éléments d'une liste de contrôle jusqu'à présent, il vous sera facile de la revoir.

Passer en revue votre code, c'est en quelque sorte le comparer à certains points de votre liste de contrôle :

1. Vérifiez combien de temps il vous reste
2. Vérifiez-le par rapport à la sortie requise
3. Vérifiez-le par rapport aux hypothèses énoncées
4. Vérifiez sa lisibilité
5. Guider l'intervieweur à travers la solution
6. Optimisez votre code

je. Vérifiez combien de temps il vous reste

Tous les autres points de cette partie de la liste de contrôle dépendent de celle-ci. Si vous n'avez plus de temps, vous ne pouvez rien faire. Vous avez fait ce que vous avez fait, et votre code est la réponse que vous avez, que cela vous plaise ou non.

La gestion du temps est importante, vous devez donc intentionnellement laisser du temps pour réviser un code. Idéalement, vous aurez le temps d'effectuer les trois vérifications suivantes.

ii. Vérifiez le code par rapport à la sortie requise

Vous devriez revenir à votre question et voir si votre code renvoie vraiment ce qui est requis. Avez-vous oublié d'inclure certaines colonnes obligatoires ? Avez-vous vraiment commandé le résultat comme il est demandé ? Ces questions et d'autres similaires sont que vous devriez vous poser.

Si vous avez le temps, corrigez les erreurs que vous avez commises. Si vous n'avez pas le temps, laissez le code tel quel, mais notez ce que vous avez fait de mal.

iii. Vérifiez le code par rapport aux hypothèses énoncées

Vous avez écrit votre code sur la base de certaines hypothèses. Revenez à votre liste d'hypothèses et vérifiez si vous les avez suivies.

Ce serait parfait si vous le faisiez. Mais lors de l'écriture de code plus complexe, il est possible que vous ayez rejeté certaines hypothèses ou en ayez introduit de nouvelles. Ecrivez-le aussi. Si vous n'avez pas suivi toutes les hypothèses, mais que vous pensez que vous auriez dû et que vous avez le temps de changer le code, faites-le. Si ce n'est pas le cas, laissez-le tel quel.

iv. Vérifiez la lisibilité du code

Ici, vous devez vérifier si vous comprenez ce que vous venez d'écrire. Revenez à votre code, vérifiez à nouveau chaque ligne pour sa syntaxe et sa logique. Au fur et à mesure que vous avancez ligne par ligne, évaluez si la lisibilité du code pourrait être améliorée. Avez-vous été cohérent dans les conventions de nommage ? Vos alias sont-ils clairs à comprendre ? Y a-t-il une ambiguïté ? Le code est-il structuré de manière logique et en parties logiques ?

Encore une fois, si vous avez le temps, améliorez la lisibilité du code. Si vous n'avez pas le temps, essayez d'écrire ou de simplement vous souvenir de ce que vous auriez pu faire mieux.

v. Diriger l'enquêteur tout au long de la solution

Si vous avez suivi toutes les étapes ci-dessus, celle-ci devrait vous venir naturellement. La chose la plus importante est que vous soyez honnête lorsque vous expliquez votre code.

Quelles que soient les erreurs que vous avez trouvées dans votre code lors de sa révision, indiquez-les explicitement. Ne comptez pas sur votre interlocuteur pour ne pas les remarquer. N'essayez pas de les cacher. Assumez vos erreurs et montrez que vous savez ce que vous avez fait de mal. Tout le monde fait des erreurs, mais tout le monde ne peut pas réaliser qu'il en a fait et l'admettre. Cela montre que vous savez ce que vous faites même si vous avez fait une erreur. En parlant d'erreurs, voici les plus courantes que les gens font dans les entretiens de science des données.

Si vous avez inclus une colonne inutile dans votre sortie, dites-le et continuez à expliquer la sortie que vous avez. Vous vous êtes éloigné de vos hypothèses initiales ou en avez inclus de nouvelles ? Dites-le et expliquez pourquoi. Si vous l'avez fait par erreur, dites que ce n'était pas intentionnel, mais vous voyez que votre solution devrait inclure des hypothèses supplémentaires. Indiquez ce qu'ils doivent être pour que votre code fonctionne. Il en va de même pour la lisibilité : si vous voyez que vous pourriez améliorer votre code, expliquez comment.

En faisant tout cela, vous montrerez non seulement votre capacité de codage, mais aussi à quelle vitesse vous pensez, que vous êtes responsable et honnête. Ce sont toutes des caractéristiques très appréciées par toutes les entreprises.

vi. Optimisez votre code

La dernière question de l'entretien de codage est généralement celle qui vous demande d'optimiser votre code. De cette façon, l'intervieweur testera vos connaissances théoriques SQL. Par exemple, si vous savez que les JOIN peuvent prendre beaucoup de temps de calcul ? Il vous sera demandé de savoir s'il existe un moyen d'éliminer JOIN ou une sous-requête. Par exemple, vous pouvez généralement supprimer une sous-requête dans la clause WHERE avec une fonction, telle qu'une fonction de classement, si vous essayez de trouver la valeur maximale.

Ou si vous savez à quelle vitesse les opérations sont effectuées sur certains types de données. Par exemple, la comparaison de chaînes est plus lente que la comparaison d'entiers, alors peut-être existe-t-il un moyen de le faire sur des données de chaîne ?

Conclusion

 
Tout cela se résume à ceci : écrire un code devrait presque être une technicité si vous structurez bien votre démarche. L'accent est davantage mis sur la réflexion et moins sur le codage. Et écrire un code doit se faire de manière très organisée.

Vous devez réfléchir à la question, aux données que vous avez devant vous, à la ou aux solutions possibles, à vos hypothèses et aux fonctions dont vous aurez besoin. Ce n'est qu'après cela que vous devriez commencer à coder. Une fois que vous avez commencé à coder, vous devriez être en mesure d'inclure l'intervieweur dans ce que vous faites et de lui faire savoir chaque étape que vous faites. Comme dans la vraie vie, vous devrez vérifier et optimiser votre code avant de commencer à l'utiliser en production. Cette interview est votre production ; gérer votre temps afin que vous puissiez revoir votre solution.

Ce sont les choses que vous devriez faire. Il y a aussi plus de conseils de préparation dans notre article : 5 conseils pour se préparer à un entretien en science des données.

Tout cela n'est pas facile. Cela demande de l'expérience et de la pratique; personne ne peut simuler cela. Mais suivre cette liste de contrôle ajoutera à coup sûr une structure solide à votre réflexion et à vos performances en entretien, quelle que soit votre expérience. Cela ne peut que vous rendre plus performant.

 
 
Nate Rosidi est data scientist et en stratégie produit. Il est également professeur adjoint enseignant l'analytique et fondateur de StrataScratch, une plate-forme aidant les data scientists à préparer leurs entretiens avec de vraies questions d'entretien posées par les meilleures entreprises. Connectez-vous avec lui sur Twitter : StrataScratch or LinkedIn.

ORIGINALE. Republié avec permission.

Source : https://www.kdnuggets.com/2022/01/answer-data-science-coding-interview-questions.html