Entrevues

3 concepts communs de Data Science testés sur toutes les interviews

Posted by admin

Les enquêteurs testent généralement plusieurs concepts lors des entretiens de science des données, mais comme ils n’auront peut-être que le temps de poser 1 à 2 questions, ils essaieront de regrouper les concepts en une seule question. Il est donc important de connaître ces concepts afin de pouvoir y prêter attention lors d’un entretien.

Alors, que testent-ils vraiment? Ce que recherche vraiment un intervieweur, ce sont les personnes interrogées qui ont une compréhension approfondie de la conception métrique et de la mise en œuvre de scénarios réalistes qui seraient présents dans les données. L’expression clé ici est “scénario du monde réel”, ce qui signifie qu’il y aura probablement plusieurs cas et scénarios extrêmes que vous devrez prendre en compte pour résoudre le problème. Ils testent trois concepts généraux pour tester votre compréhension de l’implémentation de code qui résout des scénarios du monde réel.

Puisqu’ils n’ont que le temps de poser 1 à 2 questions dans une interview avant la fin de leur temps, vous voyez souvent les trois concepts regroupés en une seule question. Je vois cette question ou une version de cette question (platform.stratascratch.com/coding-question?id=10300&python=) sur presque chaque entretien que j’ai eu ou donné. Suivez-moi et voyez si vous pouvez répondre à cette question.

Les 3 concepts que vous devez connaître sont les instructions CASE, les JOIN et les sous-requêtes / CTE. Passons en revue une vraie question d’entretien qui couvre ces 3 concepts et discutons-en en profondeur. Le lien vers la question est ici ((platform.stratascratch.com/coding-question?id=10300&python=) si vous souhaitez vous inscrire.

Agrégats issus d’énoncés de cas

Vous obtiendrez probablement une sorte de question de catégorisation où vous devez catégoriser les données en fonction des valeurs que vous voyez dans le tableau. C’est très courant dans la pratique et vous classerez et nettoierez probablement toujours les données. Une instruction CASE est donc la technique la plus simple à tester.

Ajoutez l’ajout d’agrégats comme sum () et count () et ils testeront pour voir si vous savez vraiment ce qui est retourné dans un cas quand, pas seulement son implémentation. En fonction des instructions de cas, vous pouvez toujours ajouter des fonctions agrégées, telles qu’un décompte ou une somme.

Voici un exemple d’instruction CASE avec une simple agrégation dans la clause SELECT de la question.

Vous pouvez voir dans la déclaration CASe ci-dessous que nous catégorisons les utilisateurs selon qu’ils paient des clients ou apk. Ensuite, nous appliquons une somme () car c’est un moyen rapide de compter le nombre de clients payants par rapport aux clients non payants en une seule recherche. Si nous n’avions pas l’instruction CASE, nous aurions besoin de deux recherches pour trouver les deux nombres.

SELECT date, somme (CASE

WHEN pay_customer = ‘yes’ ALORS téléchargements

FIN) SI vous payez,

somme (CAS

WHEN pay_customer = ‘no’ ALORS téléchargements

END) IF non_paying

FROM ms_user_dimension a

Rejoint

Le deuxième concept est la fusion de tables. Pouvez-vous joindre des tables? C’est la barre la plus basse sur laquelle vous devez sauter pour devenir analyste, et encore moins data scientist. Cette barre est essentiellement au sol, vous pouvez donc vraiment la franchir.

Donc, dans les entretiens, font-ils généralement un JOIN LEFT, CROSS JOIN, INNER JOIN? La plupart de votre travail utilisera une jointure à gauche, donc ils vous testent pour l’aspect pratique. Vous n’utiliserez presque jamais une connexion croisée. Vous utiliserez un peu une jointure interne, mais la jointure de gauche est un peu plus compliquée, donc ils l’utilisent simplement comme filtre supplémentaire.

Les auto-jointures sont courantes car il n’est pas toujours évident que vous les utilisiez. Mais ils sont courants dans la pratique.

Dans l’exemple ci-dessous, nous ajoutons des tables à l’instruction CASE. Nous joignons deux tables à notre table principale avec une jointure à gauche.

SELECT date, somme (CASE

WHEN pay_customer = ‘yes’ ALORS téléchargements

FIN) SI vous payez,

somme (CAS

WHEN pay_customer = ‘no’ ALORS téléchargements

END) IF non_paying

FROM ms_user_dimension a

JOINT GAUCHE ms_acc_dimension b ON a.acc_id = b.acc_id

JOINT GAUCHE ms_download_facts c ON a.user_id = c.user_id

GROUPE PAR DATE

COMMANDEZ PAR DATE

Sous-requête / CTE

Le dernier concept général est une sous-requête / CTE, essentiellement un concept dans lequel vous faites un peu de travail et que vous devez ensuite y travailler davantage. Ceci est un test pour voir si vous pouvez diviser votre problème en étapes logiques. Certaines solutions nécessitent plusieurs étapes à résoudre, elles testent donc si vous pouvez écrire du code qui suit un flux logique. Pas nécessairement compliqué ou complexe, mais en plusieurs étapes et pragmatique. Ceci est particulièrement utile dans la pratique car vous écrivez du code à 100% qui fait plus de centaines de lignes et vous devez être en mesure de créer des solutions qui suivent en douceur.

Dans l’exemple ci-dessous, je vais prendre la question que nous avons écrite ci-dessus et la mettre dans une sous-requête afin que nous puissions interroger ses données. De cette façon, nous pouvons appliquer un filtre supplémentaire dans la clause HAVING et conserver toute la solution à une question.

SELECT date, impayé,

Payer

DE

(SELECT date, somme (CASE

WHEN pay_customer = ‘yes’ ALORS téléchargements

FIN) SI vous payez,

somme (CAS

WHEN pay_customer = ‘no’ ALORS téléchargements

END) IF non_paying

FROM ms_user_dimension a

JOINT GAUCHE ms_acc_dimension b ON a.acc_id = b.acc_id

JOINT GAUCHE ms_download_facts c ON a.user_id = c.user_id

GROUPE PAR DATE

COMMANDER PAR DATE) t

GROUP BY date,

t. Payer,

t. non payée

HAVING (non_paid – payant)> 0

COMMANDER LE t.date ASC

Leave A Comment