Fragen an den Arbeitgeber: Welche du in der Bewerbung als ITler stellen solltest – und welche nicht

Warum deine Fragen im Bewerbungsprozess den Unterschied machen

„Haben Sie noch Fragen?“ – dieser Moment ist kein Smalltalk‑Abspann, sondern die Chance, Fachkompetenz, Prioritäten und Kulturfit sichtbar zu machen. Gute Rückfragen zeigen Vorbereitung, helfen dir, Fehlschlüsse zu vermeiden und geben dir Daten für deine Entscheidung. Sie wirken stärker, wenn sie präzise, kontextbezogen und zur Gesprächsphase passend sind.

Was Recruiter und Hiring Manager wirklich hören wollen

Je nach Gesprächsphase verschieben sich Fokus und Tiefe:

Screening (Recruiter/HR): Motivation, Passung zu Rolle und Rahmen, Verständnis für Unternehmen und Prozess. Kürzere, strukturierende Fragen, wenig Technik‑Tiefe.
Technisches Interview (Teamlead/Peers): Architektur, Arbeitsweise, Code‑Qualität, Ownership. Hier zählen konkrete, fachliche Fragen.
Abschlussgespräch (Hiring Manager/HR): Impact, Prioritäten der Rolle, Entwicklung, Kompensation und Modalitäten. Strategische Fragen und sauberes Erwartungsmanagement.

HR achtet stärker auf Ton, Reife und Prioritäten. Technische Gesprächspartner:innen erwarten, dass du die richtigen Details aufgreifst, ohne dich in Tool‑Name‑Dropping zu verlieren. Eine hilfreiche Orientierung bietet die IT‑spezifische Praxisperspektive, wie sie etwa Branchenportale zusammenfassen (z. B. „get in IT“).

Welche Fragen im IT‑Kontext wirklich weiterhelfen

Tech‑Stack und Architektur

Frage nicht nur „Welche Tools nutzt ihr?“, sondern nach Entscheidungen, Stabilität und Entwicklung des Stacks. So zeigst du Systemverständnis und bekommst ein realistisches Bild der täglichen Arbeit.

Beispiele:

Wie sieht eure Architektur heute aus (z. B. Services, Datenflüsse) – und welche großen Änderungen sind in den nächsten 12 Monaten geplant?
Welche Engineering‑Entscheidungen der letzten Zeit würdet ihr heute wieder so treffen – und welche nicht? Warum?
Wie priorisiert ihr technische Schuld gegen neue Features? Wer entscheidet das und auf Basis welcher Metriken?

Worauf du hören solltest: Klarer Entscheidungsprozess, dokumentierte Standards, gepflegte CI/CD‑Pipelines, nachvollziehbare Trade‑offs. Vage Antworten oder „Wir machen das je nach Person“ deuten auf inkonsistente Qualität.

Arbeitsweise, Prozesse und Qualität

Fragen zur Delivery‑Kette zeigen, wie stabil dein künftiger Alltag ist.

Beispiele:

Wie laufen Code Reviews ab (z. B. Pairing, Reviewer‑Rotation, Definition of Done)?
Wie testen und deployt ihr typischerweise? Welche Rollback‑Strategie habt ihr?
Wie messt ihr die Wirkung eurer Arbeit (z. B. DORA‑Metriken, Incident‑KPIs, Kundensignale)?

Achte auf: Regelmäßige Retros, reproduzierbare Pipelines, dokumentierte On‑Call‑Regeln, Zeit für Refactoring und Tests.

Team, Onboarding und Entwicklung

IT‑Teams stehen und fallen mit Zusammenarbeit und Lernkurve.

Beispiele:

Wie ist das Team zusammengesetzt (Erfahrung, Rollen) und wer wäre mein nächster Sparringspartner im Onboarding?
Wie sieht ein typisches Onboarding in den ersten 30/60/90 Tagen aus? Gibt es Buddy‑ oder Mentoring‑Formate?
Welche Entwicklungspfade sind realistisch (z. B. Individual Contributor vs. Führung)? Wie macht ihr Beförderungskriterien transparent?

Produkt, Roadmap und Verantwortungsumfang

Hier klärst du, wie viel Einfluss du wirklich hast.

Beispiele:

Wie entsteht die Roadmap – wer priorisiert, wie fließt Engineering‑Feedback ein?
Wo liegt die Verantwortung dieser Rolle entlang des Lifecycles (Discovery, Delivery, Betrieb)?
Welches Problem löst das Team aktuell mit höchster Priorität – und warum jetzt?

Arbeitsbedingungen, Remote und Infrastruktur

Konkrete Rahmenbedingungen beeinflussen Produktivität und Zufriedenheit.

Beispiele:

Welche Remote‑/Hybrid‑Regel gilt faktisch im Team? Wie organisiert ihr Kollaboration an geteilten Tagen?
Welche Hardware/Entwicklungsumgebungen stellt ihr standardmäßig bereit? Wie flexibel ist die Tool‑Auswahl?
Wie geht ihr mit Rufbereitschaft/Incident‑Handling um (Rotation, Kompensation, Supportprozesse)?

Formulierungs‑ und Timing‑Tipps

Kurz, konkret, evidenzbasiert: Beziehe dich auf Gehörtes („Sie erwähnten drei Services…“), und frage offen („Wie…?“, „Woran…?“) statt binär („Gibt es…?“).
Tiefgang angemessen dosieren: Im Screening high‑level bleiben. Im Tech‑Interview darfst du Architektur‑ oder Prozessdetails adressieren – aber nur dort.
Follow‑ups gezielt ableiten: „Wenn X Priorität hat, wie stellt ihr sicher, dass Y nicht liegen bleibt?“ So zeigt du Systemdenken und echtes Interesse.
Fragen bündeln: Zwei bis vier priorisierte Fragen pro Phase, statt am Ende eine Batterie abzufeuern.

Was du vermeiden oder sehr vorsichtig formulieren solltest

Rechtlich heikle und unangemessene Themen

In Deutschland sind bestimmte Fragen im Bewerbungsverfahren unzulässig oder nur in engen Grenzen relevant. Der Beschäftigtendatenschutz (u. a. § 26 BDSG, DSGVO‑Bezug) setzt klare Leitplanken. Laut der Datenschutzaufsicht des Bundes dürfen Fragen nur gestellt und Daten nur verarbeitet werden, wenn sie für den konkreten Arbeitsplatz erforderlich sind. Besonders sensibel sind Gesundheitsdaten. Unzulässig ist etwa die generelle Frage nach Schwangerschaft; Fragen nach einer Behinderung sind nur zulässig, wenn die Tätigkeit sonst unmöglich wäre. Eine kompakte Orientierung bietet die amtliche FAQ zum Beschäftigtendatenschutz des BfDI (bfdi.bund.de).

Für dich heißt das: Vermeide Fragen nach Schwangerschaft und gesundheitsbezogenen Details; Fragen zur Behinderung sind nur zulässig, wenn die konkrete Tätigkeit sonst nicht ausgeübt werden könnte („unmöglich“). Weitere besonders sensible Informationen (z. B. zu Weltanschauung oder politischen Ansichten) sind in der Regel nicht erforderlich. Orientiere dich am Erforderlichkeitsprinzip und an der BfDI‑Orientierung – pauschale „Tabu‑Listen“ ersetzen keine Prüfpflicht im Einzelfall.

Fragen, die Arroganz oder Desinteresse signalisieren

„Was macht ihr eigentlich genau?“ – wirkt wie fehlende Vorbereitung, wenn die Antwort auf der Website/Stellenanzeige steht.
„Wird Überstundenzeit grundsätzlich ausbezahlt?“ als Einstiegsfrage – signalisiert Fokus auf Kosten/Nutzen vor Passung und Aufgabe.
„Wann kann ich Teamleitung werden?“ in Runde 1 – klingt nach Titeljagd ohne Kontext. Besser: Entwicklungspfade im Abschlussgespräch besprechen.

Zu frühes Nachbohren bei Gehalt und Benefits

Konditionen gehören in den Prozess – aber mit Timing. Wenn nicht ohnehin erfragt, sind Gehalt und Benefits spätestens im Abschlussgespräch oder nach einem Angebot sinnvoll. Vorher solltest du klären, ob Aufgaben, Arbeitsweise und Kultur für dich stimmen. So vermeidest du das Signal, primär „zu shoppen“.

Konkrete Checkliste: Gute vs. riskante Fragen

Gute Fragen (je nach Phase):

„Wie definiert ihr Erfolg für diese Rolle in den ersten 90 Tagen?“
„Welche Qualitätsstandards sichern euch in Reviews und Tests ab?“
„Wie werden technische Schulden priorisiert – und wer hat dafür Budget?“
„Wie sieht die Zusammenarbeit mit Product/Design/Data konkret aus?“
„Welche Lern‑ und Weiterbildungsangebote nutzt das Team tatsächlich?“

Vorsicht oder meiden:

„Wie schnell kann ich befördert werden?“ (ohne die Rolle verstanden zu haben)
„Wie streng kontrolliert ihr die Arbeitszeit?“ als erste Frage
„Habt ihr Burnout‑Fälle?“ – besser neutral nach Arbeitslaststeuerung fragen
„Wie hoch ist der Frauenanteil im Team?“ – sensibler, faktenbasiert und kontextualisiert fragen: „Wie stellt ihr Vielfalt und Inklusion im Hiring sicher?“

Praxis: Drei Mini‑Skripte für typische IT‑Interviews

Early‑Screening (Recruiter/HR)

Ziel: Rollenverständnis, Erwartungsklarheit, Prozess.

Sechs passende Fragen:

„Welche drei Fähigkeiten unterscheiden gute von sehr guten Personen in dieser Rolle bei euch?“
„Welche Ziele verfolgt das Team mit dieser Besetzung in den nächsten sechs Monaten?“
„Wie sieht das Onboarding aus – wer ist mein Buddy, welche Systeme sind in Woche 1 relevant?“
„Wie ist die Remote‑Regel im Team gelebt (Meeting‑Rhythmus, Präsenztage)?“
„Welche Schnittstellen sind für die Rolle am kritischsten?“
„Wie laufen die nächsten Schritte und bis wann rechnet ihr mit einer Entscheidung?“

Zwei Tabu‑Beispiele zu diesem Zeitpunkt:

„Wie viele Urlaubstage habe ich genau und kann ich direkt zwei Wochen im Juni nehmen?“
„Kann ich die Stelle auch als 100% Remote aus dem Ausland machen?“ (falls nicht explizit erwähnt)

Technisches Interview (Teamlead/Peers)

Ziel: Arbeitsweise, technische Tiefe, Qualitätskultur.

Sechs passende Fragen mit Formulierungen:

„Könnt ihr kurz skizzieren, wie ein Feature von Ticket bis Deployment läuft – und wo es typischerweise hakt?“
„Wie trefft ihr Architekturentscheidungen (ADR, Gremien, RFC‑Prozess)?“
„Wie groß sind die Services/Module typischerweise und wie teilt ihr Ownership?“
„Wie sehen Testpyramide und Deployment‑Strategie aus – und wie geht ihr mit Incidents/On‑Call um?“
„Welche technischen Schulden habt ihr bewusst liegen gelassen – und warum?“
„Wie haltet ihr den Stack aktuell, ohne die Delivery zu gefährden (z. B. geplante Upgrade‑Zyklen)?“

Abschlussgespräch (Hiring Manager/HR)

Ziel: Erwartungsmanagement, Entwicklung, Konditionen und Kultur.

Sechs passende Fragen:

„Welche Ergebnisse würden Sie in Quartal 1 als Erfolg werten?“
„Wie messen Sie Leistung fair über Teams hinweg?“
„Welche Entwicklungspfade sind in den letzten 12 Monaten real genutzt worden?“
„Wie sichern Sie Fokus gegen ständig wechselnde Prioritäten?“
„Wie sieht das Angebotspaket üblicherweise aus (Fixum, variable Bestandteile, Zusatzleistungen)?“
„Welche Risiken sehen Sie in der Rolle – und wie können wir sie gemeinsam mitigieren?“

Timing‑Feinheiten: Wann technisch tief gehen – und wann high level bleiben

High level im Screening: Produkt, Teamauftrag, Onboarding, Prozess.
Mittel‑ bis Tiefgang im Tech‑Interview: Architekturmuster, Quality Gates, Incident‑Handling, Priorisierung technischer Schulden.
Strategisch im Abschluss: Wirkung, Ziele, Entscheidungswege, Entwicklung, Kompensation.

Wenn dir im Verlauf Antworten geliefert werden, hake nicht redundant nach. Notiere stattdessen kurze Follow‑ups („Sie sagten: wöchentliche Releases – mit Feature‑Flags oder Branch‑Releases?“) und platziere sie, sobald sich ein natürlicher Anknüpfungspunkt ergibt.

Kurzleitfaden für heikle Themen

Gehalt/Benefits: Wenn nicht adressiert, im Abschlussgespräch oder nach technischer Zusage ansprechen. Formulierung: „Damit wir beidseitig Klarheit haben: In welcher Spanne bewegen wir uns für diese Seniorität?“
Arbeitszeit/Überstunden: Nicht defensiv („Ich mache keine Überstunden.“), sondern prozessorientiert fragen: „Wie plant und kompensiert ihr Lastspitzen?“
Remote/Workation/Ausland: Erst prüfen, was offiziell möglich ist. Dann konkretisieren: „Welche Modelle sind erprobt und welche Grenzen gibt es (Steuer/Sozialversicherung)?“

Optionaler Mini‑Anhang: Datenschutz im Bewerbungsprozess – das Wichtigste in Kürze

Erforderlichkeit: Arbeitgeber dürfen nur Daten erheben/verarbeiten, die für die Entscheidung über das Beschäftigungsverhältnis erforderlich sind (u. a. § 26 BDSG, DSGVO‑Bezug). Die amtliche Orientierung findest du beim BfDI.
Video‑Interviews: Bei Live‑Tools können Chat‑Protokolle beim Anbieter liegen; die Einwilligung muss freiwillig sein – Alternativen (Telefon/Präsenz) müssen angeboten werden, damit die Freiwilligkeit gewahrt ist.
Besondere Kategorien: Fragen zu Schwangerschaft sind unzulässig; zu Behinderungen nur, wenn sie unmittelbar tätigkeitsrelevant sind.
Löschung: Nach Abschluss eines erfolglosen Verfahrens sind Bewerbungsdaten entsprechend den gesetzlichen Vorgaben zu löschen bzw. Unterlagen zurückzugeben (vgl. BfDI, Abschnitt „Rückgabe bzw. Löschung der Bewerbungsunterlagen“).
Talentpools: In der Regel setzen Talentpools eine informierte, freiwillige Einwilligung voraus (vgl. BfDI zur Einwilligung nach DSGVO/BDSG).

Fazit: Dein Gesprächsleitfaden als IT‑Bewerber:in

Eigene Fragen sind kein Pflichtprogramm, sondern dein Werkzeug, um fachliche Tiefe, Arbeitsweise und Kultur zu prüfen – und zugleich Professionalität zu zeigen. Priorisiere drei Dinge: (1) Rolle und Wirkung verstehen, (2) Qualität der Zusammenarbeit erkennen, (3) Entwicklung und Rahmenbedingungen sauber klären. Platziere heikle Themen mit Timing, meide rechtlich sensible Felder und fokussiere auf Prozesse statt auf bloße Tool‑Listen. Eine gute Zusatzinspiration für IT‑spezifische Rückfragen liefert das Branchenportal „get in IT“.

Wenn du so fragst, sammelst du nicht nur Pluspunkte – du triffst auch die bessere Entscheidung für deinen nächsten Schritt.