Prozessvorlagen-Konfiguration

Vollständige Referenz zur Konfiguration von Einstellungsprozessvorlagen mit YAML. Phasentypen, Konfigurationsoptionen, Prüfer und Beispiele.

Überblick

Eine Prozessvorlage legt fest, welche Phasen ein Kandidat in Ihrer Einstellungs-Pipeline durchläuft. Vorlagen werden in YAML geschrieben und bestehen aus einer geordneten Liste von Phasen, jede mit einem Typ, einem Namen und optionaler Konfiguration.

Sobald Sie eine Stellenanzeige erstellen und eine Vorlage auswählen, werden die Phasen der Reihe nach angelegt. Kandidaten durchlaufen die Phasen nacheinander, von der Bewerbung bis zum Angebot.

Grundstruktur

name: My Hiring Process
description: |
  A short description of this template.
  Supports **Markdown** formatting.

tags:
  - engineering
  - remote

stages:
  - type: application_form
    name: "Application"
    config:
      candidate_description: "Tell us about yourself."

  - type: live_interview
    name: "Interview"
    config:
      candidate_description: "A conversation about your background."

  - type: offer
    name: "Offer"

Vorlagen werden beim Speichern validiert, und die Konfigurationsschlüssel werden dabei strikt geprüft: ein falsch geschriebener oder nicht unterstützter Schlüssel lässt die Validierung mit einem Fehler fehlschlagen, statt stillschweigend ignoriert zu werden. Tippfehler fallen so sofort auf.

Schlüssel auf oberster Ebene

Schlüssel	Erforderlich	Beschreibung
`stages`	Ja	Geordnete Liste von Phasendefinitionen (mindestens eine)
`name`	Nein	Vorlagenname (lässt sich auch im Formularfeld festlegen)
`description`	Nein	Markdown-formatierte Beschreibung des Prozesses
`tags`	Nein	Liste von String-Tags zur Kategorisierung
`quick_fields`	Nein	Schnellfelder zum Erfassen von Kandidateninformationen (siehe Schnellfelder weiter unten)

Phasenschlüssel

Jede Phase benötigt name und type. Der optionale config-Hash und die reviewers-Liste hängen vom jeweiligen Phasentyp ab.

Schlüssel	Erforderlich	Beschreibung
`name`	Ja	Anzeigename der Phase
`type`	Ja	Einer der 10 unten aufgeführten Phasentypen
`config`	Nein	Typspezifische Konfigurationsoptionen
`reviewers`	Nein	Liste der Prüferzuweisungen

Kandidaten vergüten

Kit erstellt Auszahlungen aus Phasen, in denen Kandidaten etwas einreichen: Arbeitsproben, Fragebögen, Portfolio-Uploads, Code-Aufgaben, angesehene Videos und aufgenommene Videoantworten. Fügen Sie einer solchen Phase einen verschachtelten payout-Block hinzu. Die Auszahlung entsteht, nachdem der Kandidat die Leistung erfolgreich eingereicht oder abgeschlossen hat. Konfigurieren Sie keine Auszahlungen für Bewertungen, Interviews, Referenzprüfungen, Bewerbungsformulare oder Angebote: Diesen Phasen fehlt das auslösende Ereignis. Wie Kandidaten und das Finanzteam damit arbeiten, erfahren Sie unter Kandidaten-Auszahlungen.

Schlüssel	Typ	Standard	Beschreibung
`enabled`	boolean	false	Vergütung für diese Phase aktivieren
`amount`	integer	Keiner	Zu zahlender Betrag in der angegebenen Währung (z. B. `250`)
`currency`	string	USD	Dreibuchstabiger Währungscode

- type: code_assignment
  name: "Take-Home Assignment"
  config:
    candidate_description: "Complete a practical coding exercise."
    payout:
      enabled: true
      amount: 250
      currency: USD

Private Aufgabenbeschreibungen

candidate_description wird veröffentlicht: Der Text erscheint auf der Stellenseite, in der Vorlagengalerie und in Kandidaten-E-Mails. Eine Arbeitsaufgabe und die zugehörigen Links gehören stattdessen in den verschachtelten brief-Block. Diesen können nur Kandidaten lesen, die die Phase erreicht und die Aufgabe begonnen haben. Verwenden Sie ihn bei work_sample-Phasen. Bestehende portfolio_upload-Phasen mit Aufgabenbeschreibung bleiben unterstützt; bei anderen Phasentypen wird der Block ignoriert. Siehe Phasenbeschreibung und Aufgabenbeschreibung.

Schlüssel	Typ	Standard	Beschreibung
`body`	string	Keiner	Die Aufgabe als eingeschränkte Liquid-Vorlage. Nur Ausgabevariablen der Form `{{ preparation.<key> }}` werden unterstützt; Liquid-Tags und -Filter nicht. Eingefügte URLs werden beim Lesen durch den Kandidaten verlinkt
`estimated_hours`	integer	Keiner	Geschätzter Aufwand, der dem Kandidaten vor dem Start angezeigt wird (min: 1)
`due_days`	integer	5	Tage vom Start der Aufgabe bis zur Frist (min: 1)
`grace_hours`	integer	24	Stunden nach Ablauf der Frist, in denen Uploads noch möglich sind und als verspätet markiert werden
`allow_extension`	boolean	false	Vor Ablauf der Frist eine einmalige selbstständige Verlängerung anbieten
`extension_hours`	integer	72	Dauer dieser Verlängerung (min: 1)
`requires_preparation`	boolean	false	Den Start blockieren, bis eine Personalverantwortliche oder ein Personalverantwortlicher die individuelle Umgebung vorbereitet hat
`preparation_fields`	array	`[]`	Kandidatenspezifische Werte wie Test-URL, Login oder Passwort (siehe unten)

Jedes Vorbereitungsfeld verwendet {key, label, field_type, required}. Jeder Schlüssel wird in der Aufgabenbeschreibung zur Liquid-Variablen; setzen Sie {{ preparation.<key> }} an die Stelle, an der der Kandidat den Wert sehen soll. Vorbereitungswerte werden nicht automatisch angezeigt. field_type ist text, url, multiline oder secret. Passend zu den Bewerbungsformularfeldern wird name als Alias für key und type als Alias für field_type akzeptiert; Leseantworten verwenden immer die kanonischen Namen key und field_type. Personalverantwortliche füllen die Werte vor der Einladung zum Start für jeden Kandidaten einzeln aus. Ein Kandidat sieht nur seine eigenen Werte.

- type: work_sample
  name: "Paid Test Project"
  config:
    candidate_description: "A short paid exercise, roughly half a day of work."
    brief:
      body: |
        Your test shop: {{ preparation.shop_url }}
        Username: {{ preparation.shop_login }}
        Password: {{ preparation.shop_password }}

        Retouch the five sample images in the shop and submit web-ready JPEGs
        plus your layered file.
      estimated_hours: 4
      due_days: 5
      grace_hours: 24
      allow_extension: true
      requires_preparation: true
      preparation_fields:
        - key: shop_url
          label: Test shop URL
          field_type: url
          required: true
        - key: shop_login
          label: Login
          field_type: text
          required: true
        - key: shop_password
          label: Password
          field_type: secret
          required: true
    payout:
      enabled: true
      amount: 150
      currency: PLN

Eine flache Schreibweise dieser Schlüssel gibt es nicht: brief ist immer verschachtelt. Dadurch kollidieren dessen estimated_hours und allow_extension nicht mit den gleichnamigen Schlüsseln von code_assignment.

Wenn Sie über MCP nur die kandidatenspezifische Umgebung ändern, verwenden Sie hiring_update_stage_preparation. Das Tool behält die private Aufgabenbeschreibung und die Fristen bei, statt den gesamten brief-Block zu ersetzen.

Referenz der Phasentypen

application_form

Der Einstiegspunkt für Kandidaten. Erfasst strukturierte Angaben über benutzerdefinierte Formularfelder. Hält Kandidaten optional in einem Screening-Status, bevor sie weiterkommen.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Anweisungen, die dem Kandidaten angezeigt werden
`screening_enabled`	boolean	true	Einreichungen zur manuellen Prüfung zurückhalten, bevor sie weiterkommen. Standardmäßig aktiviert, explizit auf `false` setzen, um das Screening zu deaktivieren
`screening_message`	string	Keiner	Nachricht, die Kandidaten bei aktivem Screening angezeigt wird
`resume_required`	boolean	false	Lebenslauf verlangen, Kandidaten können die Bewerbung nur mit angehängtem PDF- oder Word-Dokument absenden (max. 10 MB)
`fields`	array	Keiner	Liste der Formularfelddefinitionen (siehe unten)

Formularfeldoptionen:

Schlüssel	Erforderlich	Typ	Beschreibung
`name`	Ja	string	Feldbezeichner
`type`	Ja	string	`text`, `textarea`, `file`, `url`, `select`, `checkbox`, `email`, `phone`
`required`	Nein	boolean	Ob das Feld ausgefüllt werden muss. Wird beim Absenden der Bewerbung durchgesetzt, auf jedem Bewerbungsweg einschließlich der öffentlichen API
`label`	Nein	string	Anzeigebeschriftung (Standard ist name)
`placeholder`	Nein	string	Platzhaltertext
`max_length`	Nein	integer	Maximale Zeichenanzahl (min: 1)
`options`	Nein	array	Auswahlmöglichkeiten für `select`-Felder

Wichtig: Um einen Lebenslauf zu verlangen, setzen Sie resume_required: true in der Phasenkonfiguration. Ein Formularfeld mit dem Namen resume wird ignoriert, der Lebenslauf hat auf dem Bewerbungsformular seinen eigenen Upload und wird getrennt von den benutzerdefinierten Feldern angehängt. - name: resume mit type: file und required: true zu deklarieren bleibt daher wirkungslos.

- type: application_form
  name: "Application"
  config:
    candidate_description: "Tell us about yourself."
    screening_enabled: true
    screening_message: "We'll review your application shortly."
    resume_required: true
    fields:
      - name: experience_level
        type: select
        required: true
        options:
          - "Junior (0-2 years)"
          - "Mid (2-5 years)"
          - "Senior (5+ years)"
      - name: cover_letter
        type: textarea
        required: false
        max_length: 500

code_assignment

Eine Take-Home-Programmieraufgabe. Wenn GitHub verbunden ist, wird für jeden Kandidaten ein privates Repository aus einer Vorlage erstellt. Beinhaltet eine Fristenverwaltung.

Wichtig: Das in github_template angegebene Repository muss auf GitHub als Vorlage (Template) markiert sein. Voraussetzungen und Einrichtungsschritte finden Sie unter GitHub Template Repository Setup.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Anweisungen, die dem Kandidaten angezeigt werden
`github_template`	string	Keiner	GitHub-Vorlagen-Repository (z. B. `org/hiring-assignment`)
`duration_days`	integer	7	Verfügbare Tage zur Fertigstellung (min: 1)
`estimated_hours`	integer	Keiner	Geschätzter Aufwand in Stunden (z. B. `5`)
`instructions`	string	Keiner	Anweisungen, die als Commit im Repository des Kandidaten hinterlegt werden
`grace_period_hours`	integer	24	Stunden, die nach Ablauf der Frist noch akzeptiert werden, bevor sie endgültig wird
`allow_extension`	boolean	true	Kandidaten können eine Verlängerung der Frist anfordern

Um Kandidaten für die Aufgabe zu vergüten, fügen Sie einen payout-Block hinzu, siehe „Kandidaten vergüten“ weiter oben. Die älteren Schlüssel paid, payment_amount und payment_currency werden bei code_assignment weiterhin akzeptiert und in eine gleichwertige Auszahlung umgewandelt; verwenden Sie in neuen Vorlagen aber bevorzugt payout.

- type: code_assignment
  name: "Take-Home Assignment"
  config:
    candidate_description: "Complete a practical coding exercise."
    github_template: "mycompany/hiring-challenge"
    duration_days: 7
    estimated_hours: 5
    payout:
      enabled: true
      amount: 250
      currency: USD

work_sample

Kandidaten bearbeiten eine konkrete, stellenbezogene Aufgabe und laden das Ergebnis hoch. Anders als bei einem Portfolio entsteht die Arbeit eigens für dieses Auswahlverfahren. Eine private Aufgabenbeschreibung (brief) ist erforderlich. Sie kann eine Frist, eine einmalige selbstständige Verlängerung, kandidatspezifische Zugangsdaten und eine Vergütung enthalten. Weisen Sie Bewerter zu, wenn die Einreichung bis zum Abschluss aller Bewertungsbögen in Prüfung bleiben soll.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Öffentliche Erwartungen vor Erreichen der Phase; die eigentliche Aufgabe gehört in `brief`
`accept`	array	`pdf, png, jpg, jpeg, gif, webp`	Akzeptierte Dateierweiterungen ohne führenden Punkt; auch `doc`, `docx`, `ppt`, `pptx`, `zip`, `mp4`, `mov`, `webm`, `tiff`, `tif` und `psd` werden erkannt
`max_files`	integer	10	Maximale Dateianzahl (1 bis 50)
`max_file_size_mb`	integer	25	Maximale Größe pro Datei in MB (1 bis 100)
`allow_links`	boolean	true	Kandidaten dürfen zusätzlich externe Links einreichen

- type: work_sample
  name: "Paid Customer Reply Exercise"
  config:
    candidate_description: "Complete a short, paid support exercise."
    brief:
      body: "Draft replies to the three customer scenarios in the attached packet."
      estimated_hours: 2
      due_days: 4
      allow_extension: true
    accept:
      - pdf
    max_files: 3
    payout:
      enabled: true
      amount: 100
      currency: USD

portfolio_upload

Kandidaten teilen bereits vorhandene Arbeitsproben, etwa Design-Dateien oder Texte. Unterstützt Einschränkungen nach Dateityp, Upload-Limits und externe Links. Bestehende Phasen mit einem brief-Block bleiben kompatibel; verwenden Sie für neue Arbeitsaufgaben work_sample, damit Kandidaten beide Anforderungen klar unterscheiden können.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Anweisungen, die dem Kandidaten angezeigt werden
`accept`	array	`pdf, png, jpg, jpeg, gif, webp`	Akzeptierte Dateierweiterungen ohne führenden Punkt. Benennen Sie sie für Aufgabenabgaben ausdrücklich, auch `doc`, `docx`, `ppt`, `pptx`, `zip`, `mp4`, `mov`, `webm`, `tiff`, `tif` und `psd` werden erkannt. Eine Kit unbekannte Erweiterung wird ignoriert und nicht akzeptiert
`max_files`	integer	10	Maximale Dateianzahl (min: 1)
`max_file_size_mb`	integer	25	Maximale Größe pro Datei in MB
`allow_links`	boolean	true	Kandidaten dürfen zusätzlich externe Links einreichen (z. B. Figma, Behance)

- type: portfolio_upload
  name: "Portfolio Review"
  config:
    candidate_description: "Share 3-5 examples of your best work."
    accept:
      - pdf
      - png
      - jpg
    max_files: 5
    max_file_size_mb: 50
    allow_links: true

questionnaire

Schriftliche Fragen, die Kandidaten asynchron beantworten. Nützlich für szenariobasiertes Screening in Support-, Vertriebs- oder Redaktionsrollen.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Anweisungen, die dem Kandidaten angezeigt werden
`questions`	array	Keiner	Liste der Fragendefinitionen
`duration_days`	integer	Keiner	Empfohlene Antwortzeit in Tagen. Erscheint nur in der Vorlagenvorschau und wird nicht durchgesetzt

Fragenoptionen:

Schlüssel	Erforderlich	Typ	Beschreibung
`type`	Ja	string	Fragenkategorie (z. B. `scenario`)
`prompt`	Ja	string	Der Fragetext

- type: questionnaire
  name: "Written Scenarios"
  config:
    candidate_description: "Respond to these real-world scenarios."
    questions:
      - type: scenario
        prompt: "A customer reports a billing error. Walk us through your response."
      - type: scenario
        prompt: "You discover a bug affecting 10% of users. What do you do?"

Ein Fragebogen kann optional Prüfer haben. Ohne Prüfer schließt die Abgabe der Pflichtantworten die Phase wie gewohnt ab. Mit zugewiesenen Prüfern löst die Abgabe Benachrichtigungen aus, und der Kandidat bleibt in der Phase, bis jeder zugewiesene Prüfer seine Scorecard eingereicht hat.

video

Zeigt dem Kandidaten ein Video. Unterstützt hochgeladene Videos (über Mux) oder eingebettete Videos von externen Plattformen.

Die Video-Einstellungen sind unter einem verschachtelten Schlüssel video innerhalb von config gruppiert.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Anweisungen, die dem Kandidaten angezeigt werden
`video`	hash	Keiner	Video-Einstellungen (siehe unten)

video-Optionen:

Schlüssel	Typ	Standard	Beschreibung
`source_type`	string	`mux`	`mux` (hochgeladen) oder `oembed` (externe Einbettung)
`oembed_url`	string	Keiner	URL für das eingebettete Video (wenn die Quelle `oembed` ist)
`description`	string	Keiner	Beschreibung oder Kontext zum Video
`min_watch_percentage`	integer	15	Mindestens erforderlicher Wiedergabeanteil in Prozent (1-100)

- type: video
  name: "Company Introduction"
  config:
    candidate_description: "Watch this video about our team and culture."
    video:
      source_type: oembed
      oembed_url: "https://www.youtube.com/watch?v=example"
      description: "A 5-minute overview of our engineering team."
      min_watch_percentage: 80

video_recording

Kandidaten nehmen eine Videoantwort auf einen Prompt auf oder laden eine hoch. Nützlich für Videovorstellungen, Video-Anschreiben oder asynchrone Video-Interviews. Erfordert die Mux-Integration.

Die Aufnahmeeinstellungen sind unter einem verschachtelten Schlüssel video_recording innerhalb von config gruppiert.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Anweisungen, die dem Kandidaten angezeigt werden
`video_recording`	hash	Keiner	Aufnahmeeinstellungen (siehe unten)

video_recording-Optionen:

Schlüssel	Typ	Standard	Beschreibung
`max_duration_seconds`	integer	120	Maximale Aufnahmelänge in Sekunden
`allow_upload`	boolean	true	Kandidaten das Hochladen einer voraufgezeichneten Videodatei erlauben
`max_retakes`	integer	Keiner	Anzahl erlaubter Neuaufnahmen (leer = unbegrenzt)

- type: video_recording
  name: "Video Introduction"
  config:
    candidate_description: "Record a 2-minute video introducing yourself."
    video_recording:
      max_duration_seconds: 120
      allow_upload: true
      max_retakes: 3

team_review

Eine interne Prüfungsphase, in der Ihr Team einen Kandidaten bewertet. Unterstützt Abstimmungsschwellen und Vetoregeln.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Nachricht, die dem Kandidaten während dieser Phase angezeigt wird
`voting`	hash	Keiner	Abstimmungskonfiguration (siehe unten)

Abstimmungsoptionen:

Schlüssel	Typ	Standard	Beschreibung
`threshold`	integer	2	Mindestanzahl an Ja-Stimmen zum Weiterkommen (1-10)
`require_all_reviewers`	boolean	false	Alle zugewiesenen Prüfer müssen abstimmen
`veto_auto_rejects`	boolean	false	Ein einzelnes Veto lehnt den Kandidaten automatisch ab

- type: team_review
  name: "Code Review"
  config:
    candidate_description: "Our team is reviewing your submission."
    voting:
      threshold: 2
      require_all_reviewers: true
      veto_auto_rejects: true

live_interview

Ein synchrones Interview per Videoanruf oder persönlich. Lässt sich in die Kalenderplanung integrieren.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Anweisungen, die dem Kandidaten angezeigt werden
`provider`	string	`native`	Wer die Zeitfenster verwaltet: `native` (Kit-Verfügbarkeit), `calendly` oder `cal_com`
`duration_minutes`	integer	60	Interviewdauer in Minuten (min: 15)
`interviewers_required`	integer	1	Anzahl der Interviewer, die teilnehmen müssen (min: 1). Über 1 werden nur Zeitfenster angeboten, in denen so viele gleichzeitig frei sind
`includes_roleplay`	boolean	false	Das Interview enthält eine Rollenspiel-Übung

- type: live_interview
  name: "Technical Interview"
  config:
    candidate_description: "A conversation about your technical skills."
    duration_minutes: 90
    interviewers_required: 2

reference_check

Referenzen über das Kandidatenportal einholen. Der Kandidat schlägt Referenzpersonen vor, sieht den genauen Fragensatz und stimmt der Kontaktaufnahme zu. Kit wartet auf die konfigurierte Anzahl abgeschlossener Antworten, bevor die Referenzprüfung für das Recruiting-Team bereit ist.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Anweisungen, die dem Kandidaten angezeigt werden
`references_required`	integer	2	Anzahl abgeschlossener Antworten, nach der die Phase abgeschlossen werden kann (1–5)
`collection_enabled`	boolean	false	Kandidaten im Kandidatenportal um Referenzpersonen bitten
`require_manager`	boolean	true	Mindestens eine Führungskraft unter den vorgeschlagenen Personen verlangen
`allow_manual_send`	boolean	true	Ist der Wert `true`, versucht Kit, den verifizierten Referenzabsender des Kontos zu verwenden, und fällt sonst auf die Plattformadresse zurück. Bei `false` verwendet Kit immer die Plattformadresse. Kit versendet in beiden Fällen

- type: reference_check
  name: "References"
  config:
    candidate_description: "Provide contact details for your references."
    collection_enabled: true
    references_required: 2
    require_manager: true
    allow_manual_send: true

Unter Referenzprüfungen durchführen finden Sie Einzelheiten zu Einwilligung, Zustellung, Erinnerungen, Antworten der Referenzpersonen und der Prüfung im Team.

offer

Die abschließende Phase, in der Sie dem Kandidaten ein Angebot unterbreiten. Hat in der Regel nur minimale Konfiguration.

Konfigurationsschlüssel	Typ	Standard	Beschreibung
`candidate_description`	string	Keiner	Nachricht, die dem Kandidaten angezeigt wird

- type: offer
  name: "Offer"
  config:
    candidate_description: "We'd love to have you join the team."

Prüfer

Sie können Bewertungsphasen einschließlich Fragebögen Prüfer zuweisen. Jeder Prüfer benötigt eine E-Mail-Adresse und eine Rolle. Ein Fragebogen wird erst dann durch eine Bewertung blockiert, wenn mindestens ein Prüfer zugewiesen ist.

Schlüssel	Erforderlich	Beschreibung
`email`	Ja	E-Mail-Adresse des Prüfers (muss einem Teammitglied entsprechen)
`role`	Ja	`reviewer` (Standard) oder `lead` (primärer Entscheidungsträger)

- type: team_review
  name: "Code Review"
  config:
    voting:
      threshold: 2
  reviewers:
    - email: [email protected]
      role: lead
    - email: [email protected]
      role: reviewer
    - email: [email protected]
      role: reviewer

Schnellfelder

Schnellfelder definieren strukturierte Metadaten, die Ihr Team für jeden Bewerber erfasst, etwa Gehaltsvorstellung, Verfügbarkeit, Standortpräferenz oder jedes andere individuelle Signal, das für Ihre Rolle relevant ist. Die Felder erscheinen in der Kandidaten-Seitenleiste.

Wie Sie Felddefinitionen direkt in der Oberfläche verwalten, erfahren Sie unter Kandidaten-Datenfelder.

Schema

Schlüssel	Erforderlich	Typ	Beschreibung
`key`	Ja	string	Eindeutiger Bezeichner (nur Kleinbuchstaben und Unterstriche, z. B. `salary_expectation`)
`label`	Ja	string	Anzeigebeschriftung, die Ihrem Team angezeigt wird
`field_type`	Nein	string	Einer der 4 Feldtypen unten (Standard: `text`)
`placeholder`	Nein	string	Platzhaltertext für die Eingabe
`options`	Nein	array	Auswahlmöglichkeiten für `select`-Felder

Hinweis: Reichhaltigere Feldtypen und Optionen (etwa Zahlen, Bewertungen, KI-Extraktion und Sichtbarkeitsregeln) werden unter metafield_definitions konfiguriert, einem separaten Schlüssel auf oberster Ebene. Siehe Kandidaten-Datenfelder.

Feldtypen

Typ	Beschreibung
`text`	Einzeiliges Texteingabefeld
`textarea`	Mehrzeiliges Texteingabefeld
`select`	Dropdown aus einer festen Auswahlliste
`date`	Datumsauswahl

Beispiele

quick_fields:
  - key: salary_expectation
    label: "Salary Expectation"
    field_type: text
    placeholder: "$80,000 - $100,000"
  - key: start_date
    label: "Earliest Start Date"
    field_type: date
  - key: work_authorization
    label: "Work Authorization"
    field_type: select
    options:
      - "US Citizen"
      - "Permanent Resident"
      - "Requires Sponsorship"
  - key: source
    label: "Source / Referral"
    field_type: text
    placeholder: "e.g. LinkedIn, referral from..."

Vollständiges Beispiel

Eine vollständige Vorlage für die Einstellung eines Software Engineers, einschließlich Screening, einer vergüteten Code-Aufgabe, Teambewertung, zwei Interview-Runden, Referenzen und Angebot.

name: Software Engineer - Standard
description: |
  Comprehensive process for mid-to-senior software engineers.
  Includes a take-home assignment with team code review.

tags:
  - engineering
  - technical
  - assignment

quick_fields:
  - key: salary_expectation
    label: "Salary Expectation"
    field_type: text
    placeholder: "e.g. $120k - $150k"
  - key: notice_period
    label: "Notice Period"
    field_type: text
  - key: location_preference
    label: "Location Preference"
    field_type: text

stages:
  - type: application_form
    name: "Application"
    config:
      candidate_description: "Tell us about yourself and your experience."
      screening_enabled: true
      screening_message: "We're reviewing your application."
      resume_required: true
      fields:
        - name: github_url
          type: url
          required: false
        - name: motivation
          type: textarea
          required: true
          max_length: 500

  - type: code_assignment
    name: "Take-Home Assignment"
    config:
      candidate_description: "Complete a practical coding exercise at your own pace."
      github_template: "mycompany/hiring-assignment"
      duration_days: 8
      estimated_hours: 6
      payout:
        enabled: true
        amount: 250
        currency: USD
    reviewers:
      - email: [email protected]
        role: lead

  - type: team_review
    name: "Code Review"
    config:
      candidate_description: "Our team reviews your code submission."
      voting:
        threshold: 2
        require_all_reviewers: true
        veto_auto_rejects: true
    reviewers:
      - email: [email protected]
        role: lead
      - email: [email protected]
        role: reviewer

  - type: live_interview
    name: "Technical Interview"
    config:
      candidate_description: "A conversation about your technical skills."
      duration_minutes: 90
      interviewers_required: 2

  - type: live_interview
    name: "Culture & Values"
    config:
      candidate_description: "Get to know the team and learn about our culture."
      duration_minutes: 45

  - type: reference_check
    name: "References"
    config:
      references_required: 2

  - type: offer
    name: "Offer"
    config:
      candidate_description: "We'll present you with an offer to join the team."

Tipps

Beginnen Sie mit application_form: das ist der natürliche Einstiegspunkt und ermöglicht das Erfassen von Lebensläufen und grundlegenden Angaben.
Enden Sie mit offer: das hält die Pipeline übersichtlich und gibt Ihnen eine abschließende Phase zur Nachverfolgung.
Nutzen Sie das Screening im Bewerbungsformular, um Kandidaten manuell zu prüfen, bevor sie weiterkommen. So verhindern Sie, dass ungeeignete Kandidaten Aufgaben erhalten.
Vergüten Sie Take-Home-Aufgaben: fügen Sie einer einreichungsbasierten Phase mit Auszahlungsereignis einen payout-Block hinzu, etwa work_sample oder code_assignment. Siehe Kandidaten-Auszahlungen.
Halten Sie Prozesse unter 7 Phasen: lange Pipelines führen zu Kandidatenabbrüchen.
Weisen Sie Prüfer den Phasen team_review, code_assignment und jedem Fragebogen mit menschlicher Scorecard zu, damit die richtigen Personen automatisch benachrichtigt werden.
Verwenden Sie candidate_description in jeder Phase: dies ist die öffentliche Zusammenfassung, die Kandidaten auf der Stellenseite lesen. Klare Kommunikation reduziert Verwirrung und Supportanfragen.
Legen Sie die eigentliche Aufgabe in brief ab: Anweisungen, Dateilinks und alles, was nicht auf der öffentlichen Stellenseite erscheinen soll. Siehe Private Aufgabenbeschreibungen.
Erfassen Sie häufige Signale mit quick_fields: fügen Sie Felder wie Gehaltsvorstellung, Verfügbarkeit und Standort hinzu, damit Ihr Team sie durchgängig in der Kandidaten-Seitenleiste festhält.
Brauchen Sie reichhaltigere Typen oder KI-Extraktion? Zahlen, Bewertungen, automatische KI-Befüllung und Sichtbarkeitsregeln liegen unter metafield_definitions. Siehe Kandidaten-Datenfelder.