Retour d’expérience sur la préparation, la phase Basic et le test de résolution de problèmes du Boostcamp Web·Mobile 10.
Le mot de passe saisi sert à ouvrir, modifier et supprimer les commentaires secrets.
Aucun commentaire pour le moment.
J’ai terminé la phase Basic du Boostcamp Web·Mobile 10 de Naver, et aujourd’hui est mon premier jour dans la phase Challenge.
Je souhaite partager toute mon expérience : la préparation de la candidature, le déroulement de la phase Basic et mes impressions sur le test de résolution de problèmes. Comme je manquais de confiance dans la rédaction de mon dossier de candidature, j’ai lu de nombreux articles similaires à l’époque. J’espère que ce témoignage pourra être utile aux personnes qui souhaitent postuler lors de la prochaine session.
Contrairement à l’année précédente, où l’on pouvait choisir d’entrer dans la phase Basic grâce à un test de programmation, cette année tous les candidats qui remplissent les conditions doivent d’abord soumettre leur dossier puis participer à la phase Basic.
Pendant environ deux semaines, les participants découvrent Boostcamp dans un format léger qui ressemble à un aperçu de la phase Challenge. Après avoir terminé toutes les missions pendant ces deux semaines, ils passent un test de résolution de problèmes qui détermine l’accès à la phase Challenge.
Mon intérêt pour la programmation a commencé pendant mes cours universitaires où j’ai appris Processing, Arduino et le développement web. Ces cours étant centrés sur le design, l’objectif principal était souvent de créer des résultats visuellement intéressants et originaux.
Cependant, en travaillant sur ces projets, j’ai commencé à m’interroger sur la structure du code et sur son fonctionnement interne. Les structures répétitives et les morceaux de code copiés-collés ont éveillé ma curiosité et m’ont donné envie de comprendre la programmation plus profondément.
Pendant les vacances d’hiver 2021, à une époque où il existait encore peu de bootcamps, j’ai suivi un programme Codeit grâce à une carte de formation gouvernementale. Cependant, le contenu était assez basique et n’a pas vraiment amélioré mes compétences.
Plus tard, lorsque j’ai décidé de m’orienter sérieusement vers le développement pendant ma dernière année d’université, ma carte de formation était déjà utilisée et je n’avais pas encore le niveau nécessaire pour rejoindre les bootcamps les plus connus. J’ai participé à un bootcamp payant pendant ma quatrième année, mais à cause de problèmes de projet et d’autres limites, je me suis retrouvée avec des connaissances en informatique incomplètes, des compétences faibles en algorithmique et un portfolio encore inachevé.
Je pouvais déjà créer des projets front‑end, mais plusieurs difficultés subsistaient :
Dans ces conditions, même si je trouvais un emploi, il serait difficile de progresser correctement. J’ai donc passé environ six mois à améliorer mes anciens projets et à étudier les tests d’algorithmique.
À ce moment‑là, je savais exactement ce dont j’avais besoin :
Boostcamp me semblait être l’environnement idéal pour développer ces compétences.
J’ai passé environ deux semaines à rédiger un premier brouillon, puis je l’ai révisé trois fois avant de le soumettre.
Au départ je pensais qu’un portfolio serait également demandé, donc j’ai consacré plus de temps à préparer mon portfolio qu’à la rédaction du dossier. J’ai ensuite appris que cette promotion ne demandait qu’un dossier écrit, ce qui m’a obligée à finaliser rapidement ma candidature.
J’ai mis l’accent sur la manière dont les développeurs peuvent évoluer à l’ère de l’IA. J’ai également mentionné des valeurs clés de Boostcamp comme l’apprentissage autonome, la progression durable, l’importance des bases et la collaboration.
Plutôt que de parler simplement d’emploi, j’ai insisté sur le fait que Boostcamp est avant tout un programme d’apprentissage et j’ai expliqué quel type de développeuse je souhaitais devenir après cette expérience.
Comme le nombre de caractères était limité, j’ai choisi trois expériences importantes et utilisé un exemple spécifique pour chaque question.
Plutôt que de mentionner plusieurs cas brièvement, j’ai structuré mes réponses autour du schéma suivant :
problème → processus → solution.
Pendant la phase Basic, les participants réalisent chaque jour une mission principale (sauf le week‑end), ainsi que de petites tâches, des sessions de feedback entre pairs et une réflexion quotidienne.
Il ne s’agit pas de résoudre un problème avec une réponse unique, mais d’interpréter le problème, de définir soi‑même la portée de l’implémentation et de proposer sa propre solution.
Par exemple, les participants doivent décider :
Certaines personnes implémentaient seulement les exigences minimales, tandis que d’autres interprétaient les parties ambiguës de différentes manières.
Il n’y avait pas de réponse unique ; l’objectif était l’exploration et la réflexion.
Même si la date limite était flexible, il était préférable de suivre le rythme quotidien. Les missions suivantes reprenaient souvent les concepts des précédentes et le feedback des autres participants était plus actif lorsque les travaux étaient soumis tôt.
Dans notre groupe, une fois que l’ordre de soumission dépassait environ la 8ᵉ ou 10ᵉ position, la quantité de feedback diminuait nettement.
Les participants comparaient leurs réponses et échangeaient des retours.
Au début, les approches étaient très différentes. Mais au fil du temps, chacun a commencé à intégrer les bonnes idées des autres, ce qui a progressivement amélioré la qualité globale des réponses.
Pour ma part, j’ai essayé de rendre mes réponses aussi lisibles que possible, car j’accorde beaucoup d’importance à l’expérience utilisateur et à la clarté de la documentation. Cependant, je manquais de connaissances en informatique théorique et en architecture backend, ce qui m’a parfois posé des difficultés.
Grâce aux retours des autres participants, j’ai pu apprendre différentes façons d’aborder les algorithmes, l’efficacité du code et la résolution de problèmes.
La plupart des missions étaient difficiles à résoudre entièrement seule.
Je considère qu’un développeur moderne doit apprendre à travailler avec l’IA. Plutôt que d’éviter les outils d’IA, j’ai essayé de les utiliser de manière réfléchie.
Au lieu de simplement demander : « Comment faire cela ? », j’essayais d’abord de définir le problème et mon raisonnement, puis je posais des questions comme :
« J’essaie de résoudre ce problème de cette manière ; existe‑t‑il une meilleure approche ? »
Cette méthode m’a permis d’améliorer la qualité de mes questions et ma compréhension globale.
De plus, avoir un environnement où d’autres personnes peuvent lire et commenter mon code a été extrêmement précieux. Cela m’a permis d’évaluer mon niveau de manière plus objective.
Après avoir terminé la phase Basic, les participants passent un test de résolution de problèmes.
Comme je n’avais presque aucune expérience des tests d’algorithmique et que le format avait changé cette année, il était difficile d’anticiper la difficulté. J’ai donc principalement préparé l’examen en résolvant d’anciens problèmes de Kakao.
L’examen comprenait un mélange de questions à choix multiples, de questions ouvertes et de problèmes de programmation. Les recherches sur Internet étaient interdites, mais certains documents de référence et extraits de documentation officielle étaient fournis.
Comme mes connaissances en informatique théorique étaient limitées, j’ai choisi de résoudre d’abord les problèmes que je pouvais traiter rapidement.
La plupart des candidats ont résolu environ deux problèmes, et j’ai également terminé avec deux solutions.
La difficulté n’était pas extrêmement élevée en soi ; le véritable défi consistait surtout à lire attentivement de longues descriptions et à identifier clairement les exigences du problème.
Il est évidemment impossible d’apprendre tout en seulement deux semaines, mais j’ai senti que ma manière d’aborder les problèmes avait déjà beaucoup évolué.
Dans le design UX, la première étape consiste toujours à définir le problème. Pourtant, en programmation, je me rendais compte que je sautais souvent cette étape pour passer directement à l’implémentation.
Cette expérience m’a permis de comprendre à quel point la phase de conception est essentielle.
La phase Challenge commence aujourd’hui. Je suis un peu inquiète, mais j’espère pouvoir aller jusqu’au bout sans abandonner et écrire plus tard un nouveau retour d’expérience.
