Technische Interviews in der Schweiz 2026: So läuft der Prozess wirklich ab
17. Oktober 2026 · 10 Min. Lesezeit · 0 AufrufeRecruiter-Screening, System-Design, Live-Coding mit oder ohne KI: So läuft der technische Bewerbungsprozess in der Schweizer IT 2026 ab – inklusive Tipps zur Lohnverhandlung.
Fünf Termine, drei Wochen, ein Pair-Programming mit eingeschaltetem Copilot – und am Schluss die Frage «Welche Lohnvorstellung haben Sie?», ohne Vorwarnung. So kann ein Bewerbungsprozess für eine Senior-Entwicklerstelle in Zürich heute aussehen. Wer nur die erste Stufe vorbereitet, scheitert meist an der dritten.
Dieser Guide richtet sich an IT-Fachkräfte, die sich aktiv bewerben oder einen Wechsel planen, ebenso an Quereinsteigende und Absolvierende von FH, HF und Uni. Technische Interviews in der Schweiz folgen einer Logik, die man lernen kann: klar unterscheidbare Stufen, pro Stufe eine Kernfrage – und je nach Arbeitgebertyp ganz unterschiedliche Massstäbe. Wer diese Logik kennt, bereitet sich gezielt statt panisch vor und verhandelt am Ende auch besser.
Die sechs Stufen technischer Interviews in der Schweiz
Jede Stufe prüft etwas anderes. Das klingt banal, wird aber von vielen unterschätzt, die in jedem Gespräch dieselbe Geschichte erzählen. Wer weiss, worum es gerade geht, schneidet seine Antworten darauf zu.
Recruiter-Screening (rund 20–30 Minuten): Passt das Profil grob? Motivation, Lohnrahmen, Verfügbarkeit, Standort und Remote-Anteil.
Tech-Screen (rund 45–60 Minuten): Kann die Person tatsächlich coden oder architektonisch mitdenken? Meist mit einer Entwicklerin, telefonisch oder per Video.
System-Design (45–90 Minuten): Denkt die Person in Systemen, Trade-offs und Skalierung – nicht nur in Code-Zeilen?
Live-Coding oder Pair-Programming (60–90 Minuten): Wie arbeitet die Person im Code, mit welchen Werkzeugen, wie geht sie mit Feedback um?
Culture-Fit (30–45 Minuten): Wie läuft die Zusammenarbeit, wie der Umgang mit Konflikten und Druck?
Hiring-Manager-Gespräch (30–60 Minuten): Will die Person genau hierher, versteht sie Team und Rollenerwartung?
Nicht jede Firma fährt alle sechs Stufen. Kleinere Arbeitgeber kombinieren Tech-Screen und Live-Coding, Konzerne schieben zusätzliche Runden ein. Gerechnet werden sollte mit mehreren Wochen – besonders wenn Ferienzeiten dazwischenliegen oder mehrere Entscheidungsträger ihre Kalender synchronisieren müssen.
Wer mehrere Prozesse parallel führt, steuert die Taktung aktiv: beim Recruiter nach dem nächsten Schritt fragen und realistische Fristen nennen. Und man darf Warnsignale ernst nehmen. Vier Interviewrunden für eine 60-Prozent-Stelle, eine unbezahlte Take-Home-Aufgabe über mehrere Arbeitstage oder ein Recruiter, der nach dem dritten Gespräch immer noch keine Lohnspanne nennen kann: Das sagt viel über die interne Kultur.
Grosskonzern, KMU-Dienstleister oder Startup: drei verschiedene Spiele
Die häufigste Fehleinschätzung: überall gleich vorbereiten. Dabei prüfen ein internationaler Tech-Konzern in Zürich und ein zehnköpfiges Startup fast nichts auf dieselbe Art.
Internationale Tech-Firmen und grössere Scale-ups (etwa Google in Zürich): stark standardisierte Runden mit festen Bewertungsrastern, deutlicher Fokus auf Algorithmen und Datenstrukturen, Gespräche meist auf Englisch, Entscheid über ein Gremium statt über das Bauchgefühl einer einzelnen Person.
Banken, Versicherer, Pharma und Telko (UBS, Swisscom, Roche und vergleichbare Häuser): weniger Whiteboard-Algorithmik, dafür Architektur, Regulatorik, Legacy-Landschaften, Security-Anforderungen und die Kommunikation mit Fachbereichen.
KMU-IT-Dienstleister: oft nur zwei bis drei Gespräche, häufig mit einer Fallstudie aus einem echten Kundenprojekt. Breite schlägt Tiefe, und die Frage «Kann die Person beim Kunden bestehen?» wird explizit geprüft.
Startups: Take-Home-Aufgabe oder Pair-Programming nahe am produktiven Code, danach ein Gespräch mit der Gründerin oder dem Gründer. Tempo und Eigenverantwortung zählen mehr als Prozesstreue – dafür steckt in der Vergütung häufiger ein Optionsanteil statt reinem Cash.
Wer zwischen diesen Welten wechselt, muss auch den eigenen Auftritt anpassen. Im Gremium eines Konzerns zählt die präzise, nachvollziehbare Herleitung. Im Gründergespräch zählt, ob man in zwanzig Minuten versteht, welches Problem das Produkt löst – und dazu eine eigene Meinung hat.
Der neue Streitpunkt: KI-Assistenten im Live-Coding
Seit Copilot, Cursor und ChatGPT im Entwickleralltag angekommen sind, haben sich im Live-Coding zwei Lager gebildet. Die einen erlauben KI-Assistenten ausdrücklich, weil sie den realen Arbeitsalltag abbilden wollen. Die anderen verlangen ein assistenzfreies Setting, weil sie Grundlagenwissen unabhängig vom Werkzeug sehen wollen. Beide Varianten begegnen einem derzeit – auf beide sollte man vorbereitet sein.
KI-erlaubtes Setting: Bewertet wird nicht die Tippgeschwindigkeit, sondern die Qualität der Prompts, das kritische Review des generierten Codes, das Erkennen von Fehlern und erfundenen APIs sowie die Begründung der gewählten Lösung.
KI-freies Setting: Es zählen Grundlagen, saubere Datenstrukturen, Debugging ohne Autocomplete, API-Kenntnis aus dem Kopf und lautes Denken während der Problemlösung.
Vor dem Termin schriftlich nachfragen, welche Werkzeuge erlaubt sind. Das wirkt vorbereitet, nicht unsicher.
Beide Modi trainieren: eine Aufgabe bewusst ohne Assistent lösen, eine andere bewusst mit – und den Unterschied im eigenen Tempo spüren.
Ein Punkt verdient Ehrlichkeit: Wer heimlich ein zweites Fenster offen hat, obwohl das Setting es verbietet, geht ein hohes Risiko ein. Erfahrene Interviewerinnen stutzen bei untypischen Codemustern, bei Lösungen, die ohne jede Denkpause erscheinen, oder bei Formulierungen, die nicht zum bisherigen Gesprächsstil passen. Der Vertrauensverlust wiegt schwerer als eine mittelmässige, aber ehrliche Lösung. Geprüft wird ohnehin weniger das Tempo als der Umgang mit dem Moment, in dem etwas nicht funktioniert.
Beispielfragen und zwei System-Design-Aufgaben, durchgespielt
Tech-Screens unterscheiden sich stark nach Rolle. Im Backend geht es häufig um Nebenläufigkeit, Caching, Idempotenz und Testbarkeit. Im Frontend um Rendering-Performance, State-Management und Accessibility. DevOps- und Cloud-Rollen müssen Infrastructure as Code, CI/CD und Kostenkontrolle erklären können, Data-Rollen eher Datenmodellierung, Pipelines und Datenqualität.
Backend: «Wie stellst du sicher, dass ein Zahlungs-Request nicht doppelt verarbeitet wird, wenn der Client zweimal sendet?»
Frontend: «Wie würdest du eine Liste mit 50'000 Einträgen performant rendern?»
DevOps/Cloud: «Wie gehst du vor, wenn ein Deployment in der Nacht fehlschlägt und niemand erreichbar ist?»
Data: «Wie erkennst du, dass eine Datenpipeline stillschweigend falsche Daten liefert?»
Aufgabe 1: Terminbuchung für eine Kette von Arztpraxen
Anforderungen klären: Wie viele Praxen, wie viele Buchungen pro Tag, mobil oder Desktop, decken Ärztinnen mehrere Standorte ab?
Datenmodell skizzieren: Patient, Praxis, Arzt, Slot, Buchung – mit klaren Beziehungen und Statusfeldern.
Doppelbuchungen verhindern: optimistisches Locking auf dem Slot oder eine Unique-Constraint in der Datenbank statt reiner Applikationslogik.
Ausfallsicherheit: Was passiert, wenn die Bestätigung per SMS oder E-Mail scheitert? Retry-Mechanismus mit Idempotenz-Key.
Datenschutz: Gesundheitsdaten gelten nach revDSG als besonders schützenswert – Verschlüsselung, Zugriffsprotokollierung und ein bewusst gewählter Datenstandort mit klarer vertraglicher Grundlage gehören ins Design.
Skalierung zum Schluss: Caching der Verfügbarkeitsübersicht, Lesereplikas bei hohem Buchungsaufkommen.
Aufgabe 2: Event-Pipeline für Telemetriedaten von IoT-Geräten
Volumen abschätzen: Anzahl Geräte mal Messfrequenz ergibt eine grobe Zahl an Events pro Sekunde – laut vorrechnen, statt eine exakte Zahl zu raten.
Queue-Wahl begründen: Managed Message Queue mit Partitionierung für hohen Durchsatz, Trade-off zwischen Latenz und Durchsatz erklären.
Backpressure behandeln: Was passiert, wenn die Consumer langsamer sind als die Producer? Pufferung, Drosselung oder Priorisierung kritischer Events.
Idempotenz sicherstellen: jedes Event mit eindeutiger ID versehen, damit eine erneute Verarbeitung nach einem Fehler keine Duplikate erzeugt.
Kosten benennen: Rohdaten kurzfristig günstig halten, Aggregate langfristig behalten – statt «alles für immer speichern».
Das Bewertungsraster ist in beiden Fällen ähnlich. Zuerst Anforderungen klären, bevor überhaupt gezeichnet wird. Annahmen laut aussprechen, statt sie stillschweigend zu treffen. Trade-offs benennen, statt eine Lösung als alternativlos zu präsentieren. Und die Skalierungsfrage erst angehen, wenn das Grundgerüst steht.
System-Design-Interviews leben vom lauten Denken, nicht von der perfekten Zeichnung.
Vier Wochen Vorbereitung: eine Checkliste, die man durchhält
Woche 1: Zielfirmen und Rollenprofil klären, CV und Projektliste schärfen, zwei bis drei Kernprojekte als STAR-Story (Situation, Task, Action, Result) aufschreiben.
Woche 2: Coding-Grundlagen auffrischen, drei bis vier Aufgaben unter Zeitdruck lösen, mindestens die Hälfte davon bewusst ohne KI-Assistent.
Woche 3: System-Design trainieren, zwei Aufgaben laut durchsprechen und dabei aufnehmen, eigene Architekturdiagramme aus dem Berufsalltag erklären können.
Woche 4: Mock-Interview mit einer Kollegin durchführen, Fragen an die Firma vorbereiten, Lohnspanne recherchieren, Technik und Zeitpuffer testen.
Zwei bis drei STAR-Stories für Dauerbrenner bereithalten: Konflikt im Team, Fehler samt Lehre, Projekt unter Zeitdruck geliefert.
Eigene Projekte auf GitHub oder im Portfolio aktuell halten und in zwei Minuten erklären können.
Pro Gespräch mindestens drei eigene Fragen vorbereiten, die über «Wie ist die Kultur?» hinausgehen.
Die eigene Lohnspanne mit Marktdaten hinterlegen, bevor das erste Telefonat stattfindet.
Typische Fehler von Schweizer Kandidatinnen und Kandidaten
Einige Muster tauchen immer wieder auf, gerade bei Leuten, die in der Schweiz sozialisiert sind. Fatal ist keines davon, Punkte kosten sie trotzdem.
Understatement am falschen Ort: eigene Leistungen als reine Teamleistung kleinreden, während internationale Mitbewerbende ihren Beitrag konkret benennen.
Zu wenig nachfragen, zu früh zustimmen, Konfliktfragen ausweichend beantworten statt ein Beispiel mit Ausgang zu schildern.
Sprachfalle: breiter Dialekt im Gespräch mit einem internationalen Team – oder umgekehrt unnötiges Englisch bei einem lokal verankerten KMU, das explizit Deutsch sucht.
Technisch: direkt losprogrammieren ohne Rückfragen, minutenlanges Schweigen statt lautem Denken, die Lösung am Schluss nicht testen, Over-Engineering im System-Design.
Prozessual: nur einen Bewerbungsprozess gleichzeitig führen und dadurch beim Lohn ohne jeden Hebel dastehen.
Der letzte Punkt wird am meisten unterschätzt. Wer nur mit einer Firma im Gespräch ist, verhandelt gegen sich selbst. Parallele Prozesse sind üblich, und Recruiter rechnen damit.
Lohnverhandlung: Jahrespaket statt Monatslohn denken
Vor dem ersten Gespräch sollte die eigene Spanne stehen: ein Zielwert und ein Minimum, unter das man nicht geht. Diese Spanne belegt man mit Marktdaten für die eigene Rolle und Region – nicht mit dem bisherigen Lohn. Schweizer IT-Löhne variieren stark nach Erfahrung, Rolle und Standort; die Orientierung holt man sich besser aus aktuellen Lohndaten als aus Einzelaussagen im Bekanntenkreis.
Das Gesamtpaket zählt: 12 oder 13 Monatslöhne, Bonusmodell (garantiert oder leistungsabhängig), Arbeitgeberbeiträge an die Pensionskasse.
Nebenleistungen mitrechnen: Ferientage über dem gesetzlichen Minimum, Weiterbildungsbudget, Homeoffice-Anteil, Spesenregelung.
Regionale Unterschiede sind real: Zürich, Zug und Genf liegen tendenziell über Bern, der Ostschweiz oder dem Tessin – und die Steuerlast am Wohnort verschiebt das Netto zusätzlich.
Die Frage nach der Lohnvorstellung möglichst zurückgeben: «Welche Spanne haben Sie für diese Rolle budgetiert?» Eine eigene Zahl erst nennen, wenn das Interesse klar erkennbar ist.
Das schriftliche Angebot abwarten, sachlich reagieren und höchstens einmal konstruktiv nachverhandeln, statt in den Poker-Modus zu wechseln.
Ist die Spanne fix – etwa bei öffentlichen Arbeitgebern oder stark strukturierten Lohnbändern –, lohnt der Blick auf nicht-monetäre Hebel: ein grösseres Weiterbildungsbudget, ein klarer definierter Titel oder ein früherer Review-Termin für die nächste Lohnrunde lassen sich oft eher verhandeln als die Grundzahl. Verhandelt wird am Ende nie der Monatslohn allein, sondern das Jahrespaket inklusive Bonus und Nebenleistungen.
FAQ: Fragen, die vor fast jedem Interview auftauchen
Darf ich fragen, ob KI-Tools im Live-Coding erlaubt sind? Ja – am besten schriftlich vor dem Termin beim Recruiter.
Wie gross darf eine Take-Home-Aufgabe sein? Ein paar Stunden sind verbreitet. Wird daraus ein ganzes Wochenende, darf man nach einer Entschädigung fragen oder absagen.
Englisch oder Deutsch, wenn beides möglich ist? Nach dem Team entscheiden, nicht nach der eigenen Komfortzone: internationales Team Englisch, lokal verankertes KMU meist Deutsch.
Was tun, wenn man im Live-Coding stecken bleibt? Laut denken, die Blockade benennen, nach einem Hinweis fragen. Der Umgang damit wird oft stärker gewichtet als die fertige Lösung.
Wie geht man mit parallelen Prozessen um, ohne unseriös zu wirken? Offen sagen, dass weitere Gespräche laufen, und realistische Fristen nennen.
Zertifikat oder gepflegtes GitHub-Profil? Ein nachvollziehbares, dokumentiertes Projekt überzeugt meist mehr als ein Zertifikat ohne praktischen Nachweis.
Technische Interviews in der Schweiz sind anspruchsvoller geworden – aber auch berechenbarer, sobald man die Logik hinter den Stufen kennt. Wer vorab klärt, ob KI-Assistenten erlaubt sind, im System-Design Annahmen laut ausspricht und am Schluss über das ganze Paket statt über den Monatslohn verhandelt, geht gestärkt aus dem Prozess. Der nächste Schritt ist klein: eine Zielfirma auswählen, die Vier-Wochen-Checkliste starten und den ersten Termin vereinbaren.
