Interviewfragen für Technische Redakteure, mit ausgearbeiteten Antworten

So nutzt du diese Fragen

Die meisten Runden enthalten einen Schreibtest, etwa eine verwirrende Seite neu schreiben oder eine kleine Aufgabe aus einer Demo dokumentieren, und ein Gespräch über deine Schreibproben. Wähle Proben, die du zeigen darfst, und sag, wer der Leser war und was du nach den Reviews geändert hast. Nenne bei den anderen Fragen ein echtes Dokument aus deiner Arbeit, deinen Teil daran und was danach kam.

Was ein Technischer Redakteur können muss

• Der Leser: technische DokumentationHandbücher, Anleitungen und Hilfen schreiben, mit denen ein Leser eine Aufgabe sicher erledigt, ohne jemanden zu fragen., die auf Zielgruppen und Aufgaben aufbaut.
• Die Struktur: topic-basiertes Schreiben in DITAIn Topics mit DITA schreiben und sie über Produkte, Versionen und Sprachen hinweg wiederverwenden. oder MarkdownSeiten in Markdown schreiben und gliedern, dem Textformat, das viele Docs-as-Code-Teams nutzen. und Wiederverwendung.
• Das Produkt: genug, um es zu dokumentieren, in der Software auch API-DokumentationErklären, was eine Schnittstelle tut, wie man anfängt und was jeder Teil bedeutet, für Entwickler, die schnell lesen..
• Der Prozess: Reviews, Versionen in GitDokumente wie Code in Git führen: Branches, Reviews und eine Historie jeder Änderung. und Planung in JiraDie Entwicklungsarbeit in Jira verfolgen und die Dokumentation zu jeder Änderung planen..

Anzeigen nennen die Werkzeuge nebeneinander, und keins ist überall Pflicht: DITA-Editoren, Markdown in Git, MadCap Flare, Confluence und SharePoint haben jeweils ihren Platz. Wer eins davon gut gelernt hat, lernt das nächste in Wochen, und das wissen die Interviewer.

Leser, Experten und Reviews

Wie findest du heraus, wer deine Zielgruppe ist und was sie von einem Dokument braucht?

Worauf sie achten: Recherche vor dem Schreiben.

Kurze Antwort: „Ich frage Support, Vertrieb und das Produktteam, wer das Produkt nutzt, was die Leute tun wollen und wo sie hängen bleiben, lese Supporttickets und Suchbegriffe und schaue, wenn ich kann, ein paar Nutzern zu. Dann schreibe ich eine kurze Liste der Leser und ihrer wichtigsten Aufgaben.“

Die ausführliche Antwort: Verschiedene Leser brauchen verschiedene Dokumente: Wer installiert, wer täglich damit arbeitet und wer es administriert, will nicht dieselbe Seite.

Schwache Antwort: „Ich dokumentiere jede Funktion der Reihe nach.“ Nachfrage: „Das Produkt hat Anfänger und Experten.“ Sag, wie du beiden gerecht wirst.

Ein Fachexperte hat keine Zeit für dich. Wie kommst du an die Informationen?

Worauf sie achten: dass du es beschäftigten Experten leicht machst.

Kurze Antwort: „Ein Fachexperte ist der Ingenieur oder Entwickler, der die Fakten kennt. Ich bereite mich vor, indem ich die Anforderungen lese und das Produkt ausprobiere, bringe eine kurze Liste konkreter Fragen mit und bitte um fünfzehn Minuten, nicht um eine Stunde. Dann schicke ich einen Entwurf, den er nur noch korrigieren muss.“

Die ausführliche Antwort: Geh zu seinen Meetings oder Demos, wo du kannst, und dank ihm öffentlich, wenn die Dokumentation hilft.

Schwache Antwort: „Ich warte, bis er auf meine E-Mail antwortet.“ Nachfrage: „Der Experte verlässt nächste Woche die Firma.“ Sag, was du jetzt tust.

Wie führst du ein Review so, dass es das Dokument verbessert und der Termin hält?

Worauf sie achten: ein Review-Prozess, der funktioniert.

Kurze Antwort: „Ich sage den Prüfern, was sie prüfen sollen, fachliche Fakten bei Experten und Verständlichkeit bei einem Lektor, gebe ihnen einen Termin und sammle die Kommentare an einem Ort. Über widersprüchliche Kommentare entscheide ich mit dem Verantwortlichen und halte fest, warum.“

Die ausführliche Antwort: Ein Test durch jemanden, der das Produkt nicht kennt, findet, was Experten nicht mehr sehen.

Schwache Antwort: „Ich schicke es an alle und warte.“ Nachfrage: „Zwei Experten widersprechen sich.“ Sag, wie du das klärst.

Stil, Struktur und Wiederverwendung

Warum braucht ein Team einen Styleguide, und was gehört hinein?

Worauf sie achten: Einheitlichkeit als Dienst am Leser.

Kurze Antwort: „Ein Styleguide legt fest, wie wir schreiben: Ton, Begriffe, wie Schritte und Warnhinweise aussehen und welche Wörter wir meiden. Er lässt viele Redakteure wie einer klingen, und er macht die Übersetzung günstiger, weil dasselbe immer gleich gesagt wird.“

Die ausführliche Antwort: Halte ihn kurz, mit Beispielen, und ergänze eine Terminologieliste. Viele Teams folgen dem Minimalismus: nur schreiben, was der Leser zum Handeln braucht.

Schwache Antwort: „Jeder schreibt in seinem eigenen Stil.“ Nachfrage: „Entwickler ignorieren den Styleguide in den Texten, die sie schreiben.“ Sag, was du tust.

Was ist topic-basiertes Schreiben, und wie planst du die Wiederverwendung von Inhalten?

Worauf sie achten: Struktur über einzelne Dokumente hinaus.

Kurze Antwort: „Topic-basiertes Schreiben heißt: kurze Topics, die jeweils eine Frage beantworten, eine Aufgabe, ein Konzept oder eine Referenz. Wiederverwendung heißt, ein Topic einmal zu schreiben und es in mehreren Dokumenten zu nutzen, also Single Source Publishing. Ich plane, welche Topics geteilt werden, und halte ihren Wortlaut neutral, damit sie überall passen.“

Die ausführliche Antwort: DITA unterstützt das mit seinen Topic-Typen; andere Werkzeuge tun es mit Snippets oder Variablen. Zu viel Wiederverwendung macht Seiten schwer lesbar, nutze sie also dort, wo sie echte Arbeit spart.

Schwache Antwort: „Ich kopiere zwischen Handbüchern hin und her.“ Nachfrage: „Ein geteiltes Topic ist für ein Produkt falsch.“ Sag, wie du damit umgehst.

Wie ordnest du eine große Hilfe-Website, damit Leser Antworten über Suche und Navigation finden?

Worauf sie achten: Informationsarchitektur in einfachen Worten.

Kurze Antwort: „Informationsarchitektur heißt, wie Inhalte gruppiert und gefunden werden. Ich gruppiere Seiten nach den Aufgaben der Leser, halte die Navigation flach, schreibe Titel in den Wörtern, nach denen Leser suchen, und prüfe in den Suchprotokollen, welche Begriffe nichts finden.“

Die ausführliche Antwort: Teste mit echten Lesern: Gib ihnen eine Aufgabe und beobachte, wo sie suchen.

Schwache Antwort: „Ich bilde die Menüs des Produkts ab.“ Nachfrage: „Die meistbesuchte Seite ist die Suchseite.“ Sag, was dir das sagt.

Docs-as-Code, APIs und Release Notes

Was ist Docs-as-Code, und wann würdest du es nutzen?

Worauf sie achten: dass du den Ablauf kennst, ohne Code auf der Seite.

Kurze Antwort: „Docs-as-Code heißt: Dokumentation als reinen Text schreiben, oft in Markdown, sie in Git neben dem Produkt führen, Änderungen prüfen, wie Entwickler Code prüfen, und automatisch veröffentlichen. Es passt zu Softwareteams, in denen auch Entwickler die Dokumente bearbeiten.“

Die ausführliche Antwort: Es braucht etwas Einrichtung und Hilfe von Entwicklern; für stark übersetzte Handbücher von Maschinen passt ein strukturiertes Werkzeug oft besser.

Schwache Antwort: „Es heißt, dass Entwickler die Doku schreiben.“ Nachfrage: „Prüfer außerhalb des Teams nutzen kein Git.“ Sag, wie du sie einbindest.

Wie dokumentierst du eine API für Entwickler, die nicht viel lesen wollen?

Worauf sie achten: Schreiben für die Aufgaben von Entwicklern.

Kurze Antwort: „API-Dokumentation erklärt, was eine Schnittstelle tut, wie man anfängt und was jeder Teil bedeutet. Ich schreibe einen kurzen Einstieg, der zu einem ersten funktionierenden Aufruf führt, Anleitungen für häufige Aufgaben und eine vollständige Referenz, oft aus der Beschreibung der API erzeugt und auf Verständlichkeit überarbeitet.“

Die ausführliche Antwort: Teste den Einstieg selbst auf einer frischen Umgebung und halte die Referenz mit jeder Version aktuell.

Schwache Antwort: „Die Referenz reicht.“ Nachfrage: „Entwickler stellen dem Support immer wieder dieselbe Frage.“ Sag, was du ergänzt.

Wie schreibst du Release Notes, die Kunden wirklich lesen?

Worauf sie achten: dass du weißt, was für Leser zählt.

Kurze Antwort: „Ich fange mit dem an, was sich für den Leser ändert: neue Dinge, die er tun kann, und alles, worauf er reagieren muss, in einfachen Worten, nach Wichtigkeit geordnet. Interne Ticket-Titel kommen nicht unbearbeitet hinein.“

Die ausführliche Antwort: Verlinke jeden Punkt mit der aktualisierten Hilfeseite und markiere Änderungen, die etwas brechen, deutlich.

Schwache Antwort: „Ich exportiere die Ticketliste.“ Nachfrage: „Eine Änderung entfernt eine Funktion, die Kunden nutzen.“ Sag, wie du das schreibst.

Sicherheit, Übersetzung und Feedback

Wie schreibst du Warnhinweise in einer Betriebsanleitung für eine Maschine?

Worauf sie achten: Sicherheitshinweise, die Menschen schützen.

Kurze Antwort: „Warnhinweise kommen aus der Risikobeurteilung, nicht aus der Fantasie. Jeder nennt die Gefahr, was passiert, wenn man sie missachtet, und wie man sie vermeidet, mit einem Signalwort, das zum Risiko passt, und steht dort, wo der Leser ihn braucht, direkt vor dem Schritt.“

Die ausführliche Antwort: IEC/IEEE 82079-1, die internationale Norm für Gebrauchsinformationen, legt fest, wie man solche Informationen plant und prüft. Zu viele Warnhinweise verstecken die wichtigen. Das ist keine Rechtsberatung.

Schwache Antwort: „Ich setze alle Warnhinweise auf die erste Seite.“ Nachfrage: „Die Konstruktion will vor jeden Schritt einen Warnhinweis setzen.“ Sag, was du rätst.

Wie bereitest du Dokumentation auf die Übersetzung in viele Sprachen vor?

Worauf sie achten: Schreiben, das sich gut übersetzen lässt.

Kurze Antwort: „Kurze Sätze, ein Begriff für eine Sache, keine Witze oder Redewendungen und kein Text in Bildern und Screenshots. Ich gebe den Übersetzern die Terminologieliste, beantworte ihre Fragen schnell und verwende Topics wieder, damit derselbe Satz nur einmal übersetzt wird.“

Die ausführliche Antwort: Plane die Termine der Übersetzung im Release-Plan ein; späte Änderungen sind in jeder Sprache teuer.

Schwache Antwort: „Die Übersetzer bügeln den Stil schon aus.“ Nachfrage: „Eine Übersetzung ist in einem Warnhinweis falsch.“ Sag, was du tust.

Woran erkennst du mit Feedback und Daten, ob Dokumentation funktioniert?

Worauf sie achten: dass du den Erfolg der Leser misst.

Kurze Antwort: „Ich schaue auf Supporttickets zu dokumentierten Themen, Feedback auf den Seiten, Suchbegriffe ohne Treffer und bei Software darauf, wo Leute in einem Einstieg aufhören. Dann verbessere ich zuerst die Seiten, die die meisten Probleme machen.“

Die ausführliche Antwort: Vereinbare ein paar Kennzahlen mit Support und Produkt und berichte, was sich geändert hat.

Schwache Antwort: „Die Seitenaufrufe sind gestiegen.“ Nachfrage: „Leser bewerten eine Seite schlecht, aber niemand sagt, warum.“ Sag, wie du es herausfindest.

Runden für Senior-Rollen

Wie würdest du als Senior-Redakteur oder Lead Technical Writer KI-Werkzeuge in einem Team der Dokumentation einsetzen, und was würdest du sie nie tun lassen?

Worauf sie achten: nützlicher und vorsichtiger Einsatz, und dass du andere führen kannst.

Kurze Antwort: „KI-Werkzeuge können erste Fassungen aus Spezifikationen entwerfen, klarere Sätze vorschlagen und Begriffe gegen den Styleguide prüfen. Ein Mensch prüft jede Tatsache, jeden Schritt und jeden Warnhinweis, und vertrauliche Informationen über das Produkt kommen nur in Werkzeuge, die die Firma freigegeben hat.“

Die ausführliche Antwort: Leg Regeln für das Team fest, miss, ob die Werkzeuge Zeit sparen, und behalte die Prüfung durch die Experten bei. Verbände wie die tekom in Deutschland und das ISTC in Großbritannien teilen Methoden und Weiterbildungen, die einem Team helfen, sich auf seine Regeln zu einigen.

Schwache Antwort: „Die KI schreibt jetzt die Handbücher.“ Nachfrage: „Ein erzeugter Schritt ist falsch, und ein Kunde wird verletzt.“ Sag, was das über deinen Prozess zeigt.

Das Release ist in zwei Tagen, und die Dokumentation ist nicht fertig. Was tust du wegen des Termins?

Worauf sie achten: Prioritäten unter Druck.

Kurze Antwort: „Ich liste auf, was Leser am ersten Tag haben müssen: neue Aufgaben, geänderte Schritte, Warnhinweise und Release Notes. Das wird fertig und geprüft; der Rest folgt in einem vereinbarten Update, und ich sage Produkt und Support, was noch fehlt.“

Die ausführliche Antwort: Vereinbare danach mit dem Produktteam, die Dokumentation früher einzubinden, mit dem Versionsplan.

Schwache Antwort: „Ich lasse das Review weg.“ Nachfrage: „Der Produktmanager will trotzdem alles zum Termin.“ Sag, was du ihm sagst.

Dein Lebenslauf für diese Fragen

Jeder Job in deinem Lebenslauf lädt zu den Fragen oben ein: welche Leser, welche Dokumente, welche Verbesserungen. Gib diesen Geschichten je eine Zeile, so geschrieben, dass eine Leitung der Dokumentation mehr hören will:

Prüf deinen Lebenslauf mit der kostenlosen Bewertung an einem Job als Technischer Redakteur, den du willst; jeder Bereich, den sie als dünn findet, ist der, den du zuerst üben solltest, mit einem echten Dokument und einer Probe, die du zeigen darfst.