L5 / IC4 · 5 à 8 ans
Préparation entretien Senior iOS Engineer, ce qui vous attend
Si vous visez Senior iOS Engineer, l’entretien cherche un autre signal qu’au niveau mid. La question n’est plus de savoir si vous savez livrer une feature, mais si vous avez porté une app ou un domaine de bout en bout sur plusieurs versions, pris les décisions d’architecture sur lesquelles les autres ingénieurs s’appuient désormais, et géré la production au niveau où un mauvais rollout réveille quelqu’un la nuit.
Attendez-vous à au moins un round sur un système ou un sous-domaine que vous avez architecturé : un échange de 60 minutes où le staff iOS engineer questionne chacun de vos choix de design. Certains process ajoutent un second system design à plus large périmètre (multi-modules, dépendances, temps de build). Le round comportemental glisse des « récits de mise en prod » vers « les décisions d’architecture que vous reverriez aujourd’hui ».
Version personnalisée
Ce guide couvre la barre générale pour Senior iOS. L'extension Chrome applique la même préparation à chaque offre que vous ouvrez, questions prédites pour cette entreprise précise, entraînement vocal avec votre coach IA sur chaque réponse, benchmark de salaire, analyse des écarts, plus brouillons de lettre de motivation et d'auto-présentation. Premier rapport gratuit ; plans payants à partir de 3,99 $. Ou lancez un scan unique sur une offre, sans installer.
Mise à jour 2026
Ce guide couvre la barre générale pour Senior iOS. Quelques choses ont changé en France en 2026, l'AI Act encadre le recrutement IA à partir du 2 août, 31 % des candidats utilisent déjà l'IA pour préparer (APEC), les mises en situation remplacent les tests classiques, et le cycle de recrutement reste à 12 semaines. Lire ce qui a changé en 2026 →
Ce qui sera attendu de vous
- Porter une app ou un domaine de bout en bout : architecture, budget de performance, cadence de release
- Encadrer techniquement 2 à 4 ingénieurs iOS mid-level : revoir les designs, écrire les conventions que les autres suivent
- Piloter les décisions cross-équipes sur les modules partagés (réseau, chargement d’images, analytics) et les packages SPM
- Fixer la barre de qualité iOS en production : objectifs de crash rate, budgets de perf, préparation à la review App Store
- Mentorer les ingénieurs iOS mid-level ; participer aux loops d’entretien iOS comme intervieweur régulier
- Travailler avec le back-end, le design et le produit sur des chantiers de plusieurs trimestres ; influencer le design d’API en amont
Process d'entretien typique
La plupart des entreprises suivent une trame similaire pour les entretiens Senior iOS. Délai calendaire total : 4 à 6 semaines du pré-screen recruteur jusqu'à l'offre.
Questions types à anticiper
Représentatives de ce que les entreprises demandent à ce niveau, pas une liste exhaustive. Lancez le scan gratuit ci-dessus pour des questions prédites liées à une offre d'emploi précise. L'extension Chrome ajoute l'entraînement vocal avec coaching IA sur chaque réponse (technique, design système, comportemental, motivation).
- “Expliquez la stricte concurrence de Swift 6 : qu’est-ce que le compilateur vérifie désormais, qu’est-ce qu’un type Sendable, et comment migreriez-vous un singleton legacy en mutation depuis plusieurs threads sans tout casser ?”
- “Détaillez async/await et les actors. Vous avez un service qui sérialise des écritures dans un cache partagé : quand prenez-vous un actor plutôt qu’une serial queue, et comment évitez-vous le réentrant et les data races sur l’état mutable ?”
- “En SwiftUI, comparez @State, @Observable et un store partagé pour la gestion d’état. Où se forment les recompositions inutiles, et où mettriez-vous encore du UIKit (UIHostingController) parce que SwiftUI ne tient pas le budget de frame ?”
- “Une app voit sa mémoire grimper sous charge sans crasher. Comment distinguez-vous une fuite, un retain cycle (closures, pipelines Combine) et une simple croissance de cache ? Quels outils Instruments, dans quel ordre, et que regardez-vous en premier ?”
- “On vous demande de découper une app monolithe de 200 ingénieurs en modules SPM. Comment tracez-vous les frontières de modules, gérez-vous les dépendances circulaires, et protégez-vous le temps de build incrémental ?”
- “Designez l’architecture d’un codebase iOS de 200 ingénieurs où chaque équipe veut livrer ses features indépendamment. Couvrez la modularisation SPM, l’impact sur le temps de build, et la navigation cross-modules.”
- “Designez la sync offline-first d’une app comme Doctolib ou BlaBlaCar : l’utilisateur modifie ses données hors-ligne, ça remonte au retour du réseau. Couvrez le stockage local, la résolution de conflits, et ce qui se passe si une sync est interrompue en plein vol ou par la mort du process.”
- “Designez le feed d’images d’une app sociale (style Vinted ou le feed Leboncoin) à grande échelle : préchargement, recyclage des cellules, décodage hors main thread, pagination en scroll rapide, et un budget mémoire qui tient sur un iPhone d’entrée de gamme.”
- “Designez un système de feature flags et de remote config pour une app à plusieurs millions d’utilisateurs : doit gérer l’offline, supporter un rollout progressif, et ne pas bloquer le démarrage de l’app. Déroulez le stockage, la stratégie de fetch et le chemin de fallback.”
- “Parlez-moi d’une décision d’architecture que vous avez portée et que vous reverriez 18 mois plus tard. Quel signal vous a dit qu’il fallait y revenir ?”
- “Décrivez un incident iOS en production dont vous avez piloté la réponse : pic de crashs, régression de perf, ou refus App Store. Déroulez la détection, la mitigation et le postmortem.”
- “Racontez une fois où vous avez tenu tête sur un design d’API back-end. Comment avez-vous opéré jusqu’au bout ?”
- “Parlez-moi de comment vous avez fait monter la barre de qualité iOS dans votre équipe : budgets de perf, règles de lint, standards de code review, n’importe quoi de systémique.”
Benchmark de salaire
Salaire médian pour Senior iOS dans les grandes boîtes tech US, chiffres principaux en USD. Paris / Berlin / Singapour paient typiquement 30 à 50 % de moins en base ; les ratios d'equity varient selon le stade de l'entreprise.
Pour repère, un iOS L5 en FAANG tourne autour de 400–550 k$ de TC au 50e percentile, et suit de près la grille Senior SWE. À Paris, un Senior iOS Engineer se situe plutôt autour de 65–90 k€ de base selon l’employeur (scale-up produit, grand compte, ou filiale tech américaine). Apple paie un cran au-dessus de cette bande au niveau ICT4 équivalent, avec une structure d’equity différente ; le travail mobile orienté IA on-device (modèles ML embarqués) dans les boîtes de pointe paie en haut de fourchette.
Comment se préparer, cinq conseils tactiques
Ouvrez vos réponses comportementales avec la méthode STAR, Situation, Tâche, Action, Résultat. Les conseils tactiques ci-dessous s'appuient sur cette structure pour ce rôle précis.
- Choisissez 1 ou 2 surfaces iOS que vous avez architecturées et répétez le deep-dive à froid : chaque choix de design, chaque trade-off, chaque alternative que vous avez écartée
- Maîtrisez 3 ou 4 system designs iOS canoniques à l’échelle : modularisation SPM, sync offline-first, feature flags, pipeline d’images / vidéos. Vous pattern-matcherez le reste
- Préparez 6 à 8 récits STAR tagués sur les signaux senior : décision d’architecture revue, incident de prod, conflit cross-fonctionnel, mentorat, travail de performance
- Soyez au point sur la concurrence Swift moderne : async/await, actors, Sendable, stricte concurrence de Swift 6. C’est le sujet technique le plus probé à ce niveau
- Regardez les 3 dernières années de WWDC sur les briques que la boîte utilise (Observation, Swift Macros, isolation MainActor, migration Swift 6) ; les rounds vérifient souvent si vous êtes resté à jour
- Lisez les articles d’ingénierie iOS de la boîte (les blogs tech de Doctolib, BlaBlaCar, Back Market sont fournis) : chaque loop senior a au moins un round qui gagne à nommer les patterns que l’équipe a déjà shipés
Les pièges fréquents au niveau Senior iOS
Quelques erreurs fréquentes qui font recaler les candidats Senior iOS même quand ils sont par ailleurs solides. Mieux vaut les repérer en mock interview avant qu'elles n'apparaissent en vrai.
Dérouler son travail iOS passé en « j’ai construit X » sans jamais nommer les décisions d’architecture qui comptaient.
Pourquoi ça rate
Les entretiens iOS senior sont calibrés sur l’ownership d’architecture, pas sur le nombre de features. « J’ai construit le nouveau feed » est une histoire de niveau mid. « J’ai défendu un data source paginé plutôt qu’un recompute réactif parce que Combine ne tenait pas notre budget de 16 ms par frame sur iPhone 12, et cette décision a débloqué l’adoption de SwiftUI sur le feed par l’équipe » est une histoire senior. Le signal senior, c’est le choix, pas la construction.
Comment rattraper
Pour chaque histoire d’architecture, allez au-delà de « ce que j’ai construit » jusqu’à « quel choix j’ai fait et pourquoi ». Si vous ne pouvez nommer aucun trade-off précis (perf vs ergonomie de dev, sûreté du typage vs temps de build, MVVM vs TCA), c’était du travail d’implémentation, pas d’architecture. Prenez une autre histoire.
Défendre un pattern d’architecture (MVVM, TCA, MVI) en disant « c’est ce que l’équipe utilise » au lieu de donner le raisonnement sur les trade-offs.
Pourquoi ça rate
Les entretiens iOS senior cherchent à savoir si vous avez réfléchi à pourquoi le pattern de votre équipe marche pour votre équipe. Le pattern en lui-même est rarement le sujet : le signal senior, c’est de comprendre ses trade-offs face aux alternatives, et d’être prêt à le remettre en cause si les trade-offs changeaient. Faire du MVVM par cargo-culting « parce qu’Apple le fait » donne l’image de quelqu’un qui descend d’un niveau.
Comment rattraper
Préparez une défense de 60 secondes de votre architecture : ce qu’elle optimise (testabilité, vitesse de build, scalabilité d’équipe), ce qu’elle sacrifie (boilerplate, courbe d’apprentissage, coût runtime), et ce qui vous ferait reconsidérer. Même si l’intervieweur préfère un autre pattern, le raisonnement montre une réflexion de niveau senior.
Faire du system design iOS sans jamais mentionner la taille de l’app, la batterie, ou le rollout App Store.
Pourquoi ça rate
Le system design iOS au L5 est noté sur les contraintes de production, pas seulement l’architecture abstraite. Un design qui ne reconnaît pas le budget de taille d’app, la consommation batterie, le timing de review App Store, ou le scénario de rollout progressif et de kill-switch donne l’image d’un « architecte back-end qui design pour iOS par hasard ». Le pattern senior, c’est de poser ces contraintes comme des sujets de premier plan.
Comment rattraper
Dans tout system design iOS au niveau senior, nommez les contraintes de production d’entrée : impact sur la taille de l’app, profil batterie (CPU + réseau + background), surface de review App Store (faut-il un nouvel entitlement ?), et le chemin kill-switch / rollout progressif. Même 60 secondes là-dessus gagnent le signal senior.
Ressources recommandées
Livres, cours et outils qui reviennent le plus dans la préparation Senior iOS. Sans lien d'affiliation.
- 01Swift Concurrency (Apple Developer) →La doc canonique sur async/await, actors, MainActor et Sendable. À relire avant tout loop senior : la concurrence et la stricte concurrence de Swift 6 tombent à chaque round de coding récent.
- 02Archive vidéo WWDC (Apple Developer) →Revoyez les sessions Performance, Concurrency et Build System des 2 dernières WWDC : les rounds senior vérifient si vous êtes resté à jour sur les évolutions de la plateforme.
- 03Point-Free (The Composable Architecture + Swift avancé) →Le meilleur contenu praticien sur le Swift avancé et TCA. Utile pour défendre une architecture en system design : même si vous n’utilisez pas TCA au travail, connaître l’alternative est le signal senior.
- 04objc.io, Advanced Swift →Référence sur les détails du langage que les rounds senior creusent : generics, protocol witnesses, sémantique de valeur, layout mémoire.
- 05iOS Interview Questions (GitHub) →Repo communautaire de questions d’entretien iOS classées par thème. À parcourir pour pattern-matcher les questions de concurrence et d’architecture qui tombent vraiment au niveau senior.
Scénarios courants
Je suis dev iOS senior dans une scale-up française (Leboncoin, Back Market, Lydia, Aircall) depuis 6 ans, mais je n’ai jamais « possédé » l’architecture, j’ai surtout livré des features. Comment je me prépare à un loop senior où on attend de l’ownership d’architecture ?
C’est l’écart le plus fréquent : vous avez le niveau d’exécution, mais vos histoires sont des histoires de features, et au L5 on calibre sur les décisions, pas sur les livraisons. Avant le loop, reprenez vos 3 ou 4 plus gros chantiers et cherchez les vrais points de décision : avez-vous choisi le modèle de concurrence d’un module, tranché entre UIKit et SwiftUI sur un écran critique, imposé une frontière de module ? Même si vous n’étiez pas seul à décider, identifiez ce que vous avez porté et défendez-le en « je ». Si vous ne trouvez aucune décision d’architecture défendable sur 6 ans, c’est un signal en soi : passez les semaines avant le loop à prendre une vraie décision d’archi sur votre codebase actuel (migration vers async/await, découpage d’un module SPM) que vous pourrez raconter. Sur le deep-dive, l’intervieweur va creuser les trade-offs ; entraînez-vous à nommer ce que votre choix sacrifiait. Côté concurrence, soyez irréprochable sur async/await, les actors et la mort du process : c’est là qu’un senior iOS français se fait souvent surprendre, parce que beaucoup de codebases tournent encore sur du GCD legacy.
Notre app a un gros legacy Objective-C et beaucoup d’UIKit, alors que les offres senior parlent de Swift moderne et de SwiftUI. Est-ce que mon expérience compte encore pour un poste chez Sorare, Qonto ou une filiale tech américaine à Paris ?
Oui, et c’est même un atout si vous le présentez bien. La réalité des grosses apps françaises (Doctolib, BlaBlaCar, Leboncoin) c’est exactement ça : du Objective-C historique sur les écrans critiques, une migration Swift en cours, du UIKit ancien et du SwiftUI sur les nouvelles features. Les intervieweurs senior savent que personne ne travaille sur du greenfield 100 % SwiftUI. Ce qu’ils testent, c’est si vous savez piloter une migration sans tout casser : comment vous tracez la frontière Objective-C / Swift, comment vous introduisez async/await dans une base qui tourne sur des completion handlers, où vous mettez des ponts (UIHostingController, UIViewRepresentable). Préparez une histoire de migration concrète : ce que vous avez migré en premier, pourquoi, et comment vous avez évité de bloquer les autres équipes. Le piège, c’est de présenter le legacy comme un boulet en s’excusant ; reformatez-le en « j’ai géré une migration à risque sur une app en prod », c’est précisément le signal senior que les boîtes produit cherchent.
Je code en SwiftUI depuis 3 ans mais sur des apps relativement petites. Pour un loop senior on me dit qu’il faut parler de modularisation et de temps de build, et là je sèche. Comment je comble ce gap ?
C’est un vrai gap et il vaut mieux le combler que le bluffer, parce que le round de system design senior va droit dessus. La modularisation et le temps de build deviennent un sujet de premier plan dès qu’un codebase dépasse quelques dizaines d’ingénieurs : c’est précisément le passage du mid au senior. Travaillez trois choses concrètes. D’abord, comprenez pourquoi on modularise (temps de build incrémental, frontières d’ownership entre équipes, réutilisation) et les outils (SPM en local packages, la différence entre target et package, les dépendances circulaires à éviter). Ensuite, sachez raisonner sur ce qui fait exploser un temps de build (héritage de types Swift coûteux, inférence de type, modules trop couplés) et comment vous le mesureriez. Enfin, lisez les retours d’expérience de modularisation des grosses apps (les blogs tech français en parlent, Doctolib et BlaBlaCar ont publié dessus). Vous n’avez pas besoin d’avoir modularisé un codebase de 200 ingénieurs vous-même, mais vous devez pouvoir raisonner comme si vous deviez le faire demain.
Je suis Staff candidate sur le papier mais je passe un loop Senior iOS pour assurer le coup. Comment je me positionne sans donner l’impression de descendre d’un niveau ?
Bonne intuition de viser le niveau où l’offre est la plus sûre, mais attention à ne pas saboter le signal. Le risque, ce n’est pas de paraître trop senior, c’est de parler en généralités stratégiques là où le round attend de la profondeur technique. Au Senior iOS, le deep-dive d’architecture et le coding round veulent du concret : montrez que vous mettez encore les mains dans le code, que vous pouvez défendre un choix de concurrence ligne par ligne, que vous connaissez les pièges mémoire à jour. Gardez les histoires d’influence à l’échelle de l’org pour le round comportemental, et même là, ancrez-les dans des décisions techniques précises plutôt que dans du « j’ai aligné trois équipes ». Si le loop se passe très bien, beaucoup de boîtes proposent un up-level à la fin sans que vous ayez à le demander, donc inutile de forcer la posture Staff dès le premier round. Le plus important : ne donnez jamais l’image de quelqu’un qui trouve les exercices en dessous de lui, c’est le moyen le plus rapide de transformer une offre senior en refus.
Questions fréquentes
Je suis actuellement iOS Engineer (L4 / IC3). Dois-je lire ce guide ou celui de iOS Engineer en premier ?
Lisez d'abord le guide iOS Engineer. Les entreprises calibrent les candidats L5 / IC4 contre la barre L4 / IC3, en ciblant clairement l'écart de scope, elles veulent voir où vous êtes aujourd'hui, puis creuser le gap jusqu'au L5 / IC4. Lisez ce guide APRÈS avoir compris la baseline L4 / IC3, comme ça vous saurez exactement quels signaux démontrer pour le step-up.
Combien de temps prévoir avant un onsite Senior iOS ?
Le process prend 4 à 6 semaines. Ajoutez 6 à 8 semaines de prep : le deep-dive d’architecture est le round à plus fort levier. Choisissez 1 ou 2 surfaces que vous avez portées et répétez-les à froid : chaque choix, chaque trade-off, chaque alternative écartée. Et soyez irréprochable sur la concurrence Swift moderne (async/await, actors, stricte concurrence de Swift 6).
Quelle est l'erreur la plus fréquente des candidats au niveau Senior iOS ?
Décrire du travail d’implémentation comme du travail d’architecture. Les entretiens iOS senior calibrent sur les choix que vous avez faits, pas sur les features que vous avez livrées. De solides histoires de niveau L4 « j’ai construit X à l’échelle » vous feront descendre d’un niveau si vous ne savez pas articuler le trade-off d’architecture derrière X.
Et si mon process d'entretien diffère de celui décrit ici ?
L'essentiel de la variation est marginal. Les grandes boîtes tech (FAANG, scale-ups, SaaS mid-size) suivent un process à 1–2 rounds près de ce qui est décrit. Les petites startups tournent souvent sur moins de rounds (3 à 4) mais la barre par round reste similaire ; les boîtes moins matures tech sautent parfois system design ou comportemental. Lisez l'offre et demandez au recruteur lors du pré-screen, il vous dira ce qui vient.
Comment ce guide se compare-t-il au scan gratuit ?
Ce guide couvre la barre générale au niveau L5 / IC4. Le scan gratuit lit votre offre d'emploi spécifique et renvoie les questions prédites pour ce poste + cette entreprise, un benchmark de salaire calibré et (avec votre CV) une analyse des écarts d'expérience et un passage ATS de CV. PDF par e-mail.
Prêt à préparer un vrai poste ?
Collez n'importe quelle offre Senior iOS, découvrez votre coach en moins de 30 secondes.
Déposez une URL LinkedIn, Greenhouse, Lever ou Levels.fyi, ou collez le texte de l'offre. Votre coach prédit les questions pour cette entreprise, fait ressortir vos écarts d'expérience, et calibre un benchmark de salaire pour le poste et la localisation. PDF par e-mail. L'entraînement vocal avec retour IA sur chaque réponse vit dans l'extension Chrome.
Installation libre · Aperçu sur chaque offre · Plans payants à partir de 3,99 $