Vous avez maîtrisé LeetCode, réussi le processus d’entretien et obtenu un stage dans une entreprise incroyable. Félicitations! Mais maintenant, c’est la troisième semaine de votre stage, vous n’avez aucune idée de comment cela fonctionne et vous avez écrit une ligne de code au cours des deux derniers jours.
Comment demander de l’aide ? À qui demandez-vous de l’aide? Devriez-vous même demander de l’aide?
En travaillant chez Slack, j’ai découvert que savoir naviguer dans ces situations et se débloquer est essentiel pour réussir son stage. Apprendre à apprendre semblait souvent plus important que d’apprendre le matériel technique lui-même.
Arrière plan
|
Mon projet
- J’ai effectué un stage au sein de l’équipe iOS Application Infrastructure. Mon projet était centré sur l’onglet Mentions (également connu sous le nom d’onglet Activités)
- J’ai été chargé de changer le fournisseur de données pour l’onglet Activités
- Avant : données actualisées à partir d’un appel d’API déclenché par une extraction manuelle ou un minuteur de 60 secondes
- Après : utiliser entrant WebSocket événements avec des données de message pour mettre à jour l’écran, au lieu d’attendre le prochain appel d’API
La première partie de mon projet était centrée sur l’ajout de l’écoute des mises à jour des modèles de messages associés aux activités existantes. La partie technique de ce projet n’était pas si difficile en soi. Cela m’a quand même pris environ la moitié de mon stage, car je me familiarisais avec la base de code et, plus important encore, j’apprenais à apprendre.
La deuxième partie de mon projet consistait à ajouter un nouveau fournisseur de données qui diffusait toutes les activités des événements WebSocket, puis le combinait avec le flux de données existant. C’était une tâche beaucoup plus difficile que la première partie, mais parce que j’avais appris à me débloquer, tout est allé beaucoup plus vite ; Je n’ai jamais été coincé aussi longtemps.
J’espère que certaines des choses que j’ai apprises cet été pourront aider les futurs stagiaires à atteindre ce stade plus tôt dans leur stage !
Quand demander de l’aide
La première étape pour savoir quand demander de l’aide est d’apprendre que l’industrie est un monde complètement différent de celui de l’école. Il n’y a pas de triche, il n’y a pas de notes individuelles, il n’y a pas de tests. Tout, surtout chez Slack, est collaboratif. S’il vous faut deux jours pour corriger un bogue, mais qu’un autre ingénieur peut vous dire ce qui ne va pas en deux minutes, vous demandez de l’aide.
La question la plus importante à vous poser lorsque vous décidez de demander de l’aide est la suivante :
Est-ce que j’apprendrai quelque chose en passant plus de temps là-dessus ?
Votre travail en tant que stagiaire est d’apprendre autant que vous le pouvez. Parfois, vous apprendrez beaucoup en prenant le temps de résoudre un problème. D’autres fois, vous pourriez perdre une journée entière dans le débogueur sur un problème simple qui peut être résolu avec une explication d’une phrase de votre mentor.
Types de problèmes auxquels vous ne devriez pas passer beaucoup de temps à vous attaquer par vous-même :
- Mise en page
- Syntaxe
- Quelle fonction appeler pour obtenir un certain type de données
Types de problèmes que vous voudrez peut-être passer du temps à résoudre par vous-même :
- Comment une fonction que vous appelez réellement obtient les données dont vous avez besoin
- Comment les changements d’état d’une partie de l’application sont reflétés dans l’interface utilisateur
La principale différence entre ces deux types de problèmes est la différence entre connaissances et entente. Vous ne devriez passer du temps à résoudre un problème par vous-même que si cela vous permet de mieux comprendre comment les choses fonctionnent.
Même si aborder les problèmes par vous-même peut vous aider à apprendre, vous pourriez parfois avoir besoin de l’aide de quelqu’un d’autre pour avancer. C’est tout à fait bien ! Les applications comme Slack sont incroyablement compliquées et les stagiaires ne sont pas censés être capables de tout comprendre par eux-mêmes. Tant que vous demandez de l’aide de la bonne manière, il n’y a rien de mal à cela.
Comment demander de l’aide
Posez des questions auxquelles il est facile de répondre.
Si vous posez une question basée sur les connaissances, c’est assez facile car il y a normalement une réponse simple. Par exemple, voici une question que j’ai posée au début de mon stage :
Lorsque vous êtes bloqué sur un problème plus compliqué, poser la bonne question devient beaucoup plus difficile. J’ai vraiment eu du mal à saisir la complexité des problèmes tout en offrant à quelqu’un d’autre un moyen simple de répondre.
La première étape qui m’a aidé consistait simplement à passer du temps à essayer de comprendre le problème. Si vous comprenez 95 % du changement que vous essayez d’apporter, il est beaucoup plus facile pour quelqu’un d’autre de clarifier ces derniers 5 % que de suivre l’intégralité du processus. D’après mon expérience, les gens sont très disposés à vous aider s’il est clair que vous avez passé du temps à comprendre les systèmes avec lesquels vous travaillez avant de leur demander de l’aide. Parfois, vous répondrez même à votre propre question en essayant de comprendre le problème !
Si vous avez encore besoin d’aide après avoir essayé de comprendre le problème sur lequel vous travaillez, l’étape suivante consiste à fournir autant de contexte que possible lorsque vous posez votre question.
Cela peut impliquer de décrire :
- Ce que vous comprenez du problème
- Ce que vous ne comprenez pas au problème
- Ce que tu as changé
- Le comportement attendu par rapport à la sortie réelle
Au lieu de dire quelque chose comme « J’ai du mal à mettre en œuvre <fonctionnalité>, pouvez-vous m’aider ? » dites quelque chose comme : « J’ai essayé d’utiliser pour implémenter <fonctionnalité>, mais au lieu de , c’est le qui se produit. Avez-vous une idée de comment aborder cela ? »</fonctionnalité></fonctionnalité>
Une autre stratégie pour vous débloquer est la programmation en binôme ou l’appel avec quelqu’un de votre équipe. Je recommanderais certainement de le faire autant que possible, en particulier pour vos problèmes les plus difficiles.
À qui demander de l’aide
Lors de mon dernier stage, mon manager était également le seul autre ingénieur iOS de l’entreprise. En d’autres termes, dans 99% des situations, la seule personne à qui j’ai demandé de l’aide était mon manager. Cet été, je me suis retrouvé dans une équipe de 14 personnes, toutes avec des connaissances dans différents domaines. Il n’était plus simple de savoir à qui demander de l’aide.
Ce que j’ai appris:
- N’ayez pas peur de demander de l’aide dans un canal. Si vous ne savez pas à qui demander, il est préférable de demander dans un canal public plutôt que d’envoyer un DM à la moitié de votre équipe jusqu’à ce que quelqu’un puisse vous aider.
- N’ayez pas peur de demander à votre mentor ou à votre responsable à qui vous devriez vous adresser.
- Si quelqu’un vous a déjà aidé dans un certain domaine, n’ayez pas peur de lui demander à nouveau de l’aide sur le même sujet.
Comparer deux exemples
Permettez-moi de vous donner deux exemples de cet été. La première est une situation où j’aurais dû demander de l’aide plus tôt, mais je ne l’ai pas fait. L’autre est celui où j’ai réussi à prendre le temps de comprendre le problème avant de demander de l’aide.
Cas 1
Cette situation date du tout début de mon stage. Pour le contexte, dans l’application iOS de Slack, il existe différents modèles de données pour un message et une activité (c’est-à-dire un message qui vous mentionne ou une réaction à votre message). Pour chaque activité, nous avons un identifiant associé qui ressemble à :
J’essayais de changer le fournisseur de données d’activités pour écouter les mises à jour de tous les messages associés aux activités. Les messages ont également un identifiant, j’ai donc ajouté un flux de modèles de message avec le même identifiant que les modèles d’activité actuels. De manière inattendue cependant, le flux ne renvoyait aucun message. J’ai parcouru le débogueur pendant un certain temps et j’ai finalement vu que dans d’autres parties de l’application qui utilisaient MessagesDataProvider, les identifiants de message semblaient différents. ils n’avaient tous aucun type et ressemblaient juste à :
Je ne savais pas si cette différence d’identifiant provenait d’une erreur que j’avais commise lors de modifications locales des données de message, ou si c’était parce que les identifiants étaient différents dans les activités et les messages. À ce stade, j’aurais simplement dû demander : “Les identifiants d’activité et de message sont-ils différents ?” pour voir comment aborder ce problème. Au lieu de poser une question de clarification, j’ai sauté directement dans la recherche d’une solution. J’ai fini par utiliser un autre champ d’activité messageIdentifier comme ID pour diffuser des messages, ce qui semblait fonctionner.
Le problème était que parce que je n’ai jamais posé de question, je n’ai pas vraiment comprendre pourquoi les identifiants étaient différents, même s’il semblait que j’avais trouvé une solution. Plus tard, j’ai rencontré un tas de problèmes car lorsque j’ai commencé à créer des activités à partir de messages, j’ai copié tous les champs Message, y compris id ! Cela a causé des problèmes avec des activités en double, car j’écrivais la même activité avec deux identifiants différents (un avec le type, un sans).
Il s’avère, comme vous l’avez peut-être deviné, que les identifiants d’activité et de message sont simplement formatés différemment et que j’avais besoin de convertir entre les deux. J’ai finalement clarifié cela en demandant à quelqu’un. Cependant, je me serais sauvé des heures et des heures de temps si j’avais simplement posé cette question dès que j’ai vu l’écart d’identification. C’était un connaissancesbasée sur une question et non une entente-basée sur la question, j’aurais donc dû demander dès que j’avais besoin d’éclaircissements. Je suis content que cela se soit produit vers le début de mon stage, car j’ai pu en tirer des leçons et être plus disposé à poser des questions basées sur les connaissances à l’avenir.
Cas 2
Cette situation vient de la moitié de mon stage. Je venais de terminer la première partie de mon projet et commençais la deuxième partie : ajouter la possibilité de diffuser des activités créées à partir d’une source différente (événements WebSocket) de celle que nous faisons normalement.
Sur la base d’une suggestion de mon responsable, j’ai pris une journée entière pour rédiger un document expliquant exactement comment les données circulent depuis la requête réseau qui renvoie les activités à l’interface utilisateur dans l’onglet mentions. Cela m’a permis de mieux comprendre avant de commencer le problème. Une fois que j’ai commencé, j’ai passé quelques jours à mettre en œuvre une solution de base qui semblait fonctionner à partir de mes tests. C’est à ce stade, après avoir acquis une certaine compréhension de ce que je changeais, que j’ai demandé un examen de mes modifications.
L’examen des relations publiques est revenu et il s’est avéré que je l’avais complètement mal fait. Cependant, parce que j’avais une solide compréhension du système, j’ai immédiatement demandé de l’aide et j’ai rejoint un Huddle avec deux ingénieurs de mon équipe. Nous avons discuté de la meilleure façon d’aborder le problème; il s’est avéré que j’ai dû écrire un nouveau fournisseur de données pour l’onglet activités qui combinait un flux d’activités du dernier appel API avec un flux d’activités filtré sur le dernier horodatage de l’autre flux.
Ce Huddle m’a probablement fait gagner des semaines de temps que j’aurais passé si j’avais simplement essayé de résoudre le problème et de créer une solution parfaite par moi-même. Cependant, si j’avais demandé de l’aide avant de comprendre le problème, je n’aurais pas pu tirer grand-chose de l’appel.
Le point à retenir de cette situation est que vous devez essayer de trouver le bon moment pour demander de l’aide : vous devez comprendre suffisamment que d’autres personnes peuvent vous aider efficacement, mais aussi demander suffisamment tôt pour que leur aide vous fasse gagner du temps.
Gros plats à emporter
Apprendre à travailler dans l’industrie est aussi important, sinon plus, que d’apprendre le côté technique du génie logiciel. Je me suis également trouvé beaucoup moins stressé lorsque je suis devenu plus à l’aise pour demander de l’aide. Une fois à l’aise, je me sentais bien plus comme un membre d’une équipe que comme un ingénieur individuel et je m’amusais beaucoup plus au quotidien.
Mon dernier conseil est simplement de profiter de votre temps en tant que stagiaire ! Douze semaines passent vite et c’est vraiment une formidable opportunité d’être stagiaire chez Slack. J’ai passé un été incroyable et j’espère que tous les futurs stagiaires lisant ceci le seront aussi !
Si vous souhaitez travailler sur les applications mobiles de Slack, consultez nos postes vacants ! Appliquer maintenant
