Wenn Sie als Personalvermittlung oder IT-Dienstleister ein Beraterprofil auf das Seitenlimit eines Kunden kürzen müssen, streichen Sie zuerst wiederholte Routinetätigkeiten und Details ohne Bezug zur Projektanfrage – nicht pauschal die ältesten Stationen. Erhalten bleiben die geforderten Angaben und der eigene Beitrag zu den entscheidenden Projekten. Erst entscheiden Sie, welche Erfahrung der Kunde beurteilen soll. Danach bringen Sie diese Inhalte in seine Vorlage.
Ein älteres Projekt kann dabei mehr Platz verdienen als das jüngste. Das zeigt der folgende Fall: Gesucht wird Erfahrung mit dem Abgleich von Transaktionen und Abrechnungsdateien. Sie steckt im vorletzten Projekt, nicht im aktuellen Commerce-Projekt.
Die Projektanfrage bestimmt, was Platz bekommt
Das folgende Beispiel ist vollständig fiktiv: Profil F-17, Arbeitgeber, Projekte und Kundenanforderungen sind erfunden.
Der Kunde sucht einen Backend Engineer für ein Team, das Zahlungs-APIs entwickelt. Er möchte erkennen, was die vorgestellte Person selbst mit Java, Spring Boot und PostgreSQL umgesetzt hat und welche Erfahrung sie mit der Abstimmung von Transaktionsdaten und Abrechnungsdateien mitbringt.
Für die Vorstellung gelten diese Vorgaben:
- PDF mit höchstens zwei Seiten in der bestehenden Kundenvorlage.
- Kurzprofil mit höchstens 60 Wörtern.
- Höchstens zwei ausführliche Projektbeschreibungen mit jeweils maximal 80 Wörtern.
- Höchstens acht ausgewählte Kenntnisse.
- Pflichtangaben: Profilkennung, sämtliche Beschäftigungszeiträume und tatsächlich geführten Positionen, Zeitraum und Rolle der ausgewählten Projekte, eigene Tätigkeiten und Technologien, Ausbildung sowie Verfügbarkeit.
- Schriftgröße, Seitenränder und Reihenfolge der Abschnitte bleiben unverändert.
Die zwei Seiten sind hier eine Kundenvorgabe, keine allgemeine Regel für Beraterprofile. Entscheidend ist, innerhalb dieser Grenzen die angefragte Erfahrung nachvollziehbar zu zeigen.
Consulting LIFE beschreibt das Beraterprofil als projektspezifische Unterlage und empfiehlt ein zentrales Basisdokument für sämtliche Projekte und Kenntnisse. Genau diese Trennung hilft hier: Die vollständige Ausgangsfassung bleibt erhalten; die Kundenfassung enthält eine begründete Auswahl an Details.
Das Ausgangsprofil: drei Projekte und der vollständige Werdegang
F-17 – Backend Engineer
Zusammenfassung
Backend-Entwickler mit Erfahrung in Commerce-Anwendungen, im Zahlungsreporting und in internen Service-Anwendungen. Entwickelt und pflegt Java-Services, stimmt API-Änderungen mit anderen Entwicklern ab, schreibt automatisierte Tests und untersucht gemeldete Fehler. Zu den bisherigen Technologien gehören Spring Boot, PostgreSQL, REST-Endpunkte und Code-Reviews über Git. Hat außerdem mit MySQL und einfachem JavaScript gearbeitet. Lernt gern neue Technologien und arbeitet gern im Team. Hat eine Einführungsschulung zu AWS besucht. Sucht ein Entwicklungsprojekt mit der Möglichkeit, technische Kenntnisse auszubauen. Hat an regelmäßigen Teamterminen, Planungsrunden, Backlog-Verfeinerungen und Retrospektiven teilgenommen. Legt Wert auf verständliche Dokumentation und verlässliche Umsetzung.
Kenntnisse
Java, Spring Boot, PostgreSQL, REST, JUnit, Git, MySQL, JavaScript, HTML, CSS, Jira, Confluence, Scrum-Termine, AWS-Einführungsschulung.
Projekt 1: Commerce catalogue services
Zeitraum: 01/2025–10/2026
Rolle: Backend Engineer
Arbeitgeber: Example Commerce A
Technologien: Java, Spring Boot, PostgreSQL, REST, JUnit, Git
Implementierte mit Java und Spring Boot REST-Endpunkte für die Aktualisierung von Produktkatalogen. Ergänzte PostgreSQL-Abfragen und Indizes für den Katalogservice. Schrieb JUnit-Tests für Validierungsregeln und Regressionstests. Untersuchte vom Support gemeldete Fehler und dokumentierte die Änderungen. Beteiligte sich mit den anderen Backend-Entwicklern an Code-Reviews. Stimmte mit dem Frontend-Team die Felder für Anfragen und Antworten ab. Nahm an Planungsrunden, täglichen Abstimmungen und Retrospektiven teil.
Das Gesamtprojekt umfasste auch Checkout- und Zahlungsintegrationen. Der eigene Aufgabenbereich war jedoch der Katalogservice. Die Person implementierte in diesem Projekt weder die Zahlungsabwicklung noch die Abstimmung von Transaktionsdaten und Abrechnungsdateien.
Pflegte die interne Dokumentation der Endpunkte und hielt Testfälle fest. Klärte Tickets mit dem Product Owner. Nutzte Git für Pull Requests und arbeitete Rückmeldungen vor dem Zusammenführen der Änderungen ein. Besuchte einen internen Workshop zum Deployment-Setup des Unternehmens.
Projekt 2: Settlement reporting service
Zeitraum: 01/2022–12/2024
Rolle: Software Engineer
Arbeitgeber: Example Payments B
Technologien: Java, Spring Boot, PostgreSQL, REST, JUnit, Git
Implementierte mit Java und Spring Boot Endpunkte für einen internen Service zur Auswertung von Zahlungsabrechnungen. Schrieb PostgreSQL-Abfragen, die Transaktionsdatensätze mit Abrechnungsdateien abglichen. Untersuchte abweichende Datensätze gemeinsam mit dem Operations-Team und ergänzte nach abgestimmten Fehlerkorrekturen Regressionstests. Dokumentierte Endpunktfelder und Ausnahmen beim Datenabgleich. Beteiligte sich mit erfahrenen Entwicklern an der Prüfung von Änderungen.
Die Person implementierte zugewiesene Komponenten. Für den Entwurf des Services war ein separater Architekt verantwortlich; die produktive Abwicklung der Zahlungsabrechnungen und das Deployment lagen bei einem separaten Operations-Team.
Nahm an Backlog-Verfeinerungen, Planungsrunden und täglichen Abstimmungen teil. Pflegte Ticketnotizen, aktualisierte interne Dokumentation und stellte abgeschlossene Änderungen in Team-Reviews vor. Nutzte Git-Pull-Requests und JUnit-Tests. Befolgte die bestehenden Branching-Konventionen und die Release-Checkliste des Teams. Half Kollegen, Datenabweichungen mit Testdaten nachzustellen. Budget-, Personal- oder Architekturverantwortung sind für diese Tätigkeit nicht angegeben.
Projekt 3: Internal service portal
Zeitraum: 07/2019–12/2021
Rolle: Junior Software Engineer
Arbeitgeber: Example Services C
Technologien: Java, MySQL, JavaScript, Git
Pflegte Java-Code für ein internes Portal zur Erfassung von Serviceanfragen. Behob Fehler in der Formularvalidierung und passte einfache JavaScript-Funktionen im Browser an. Schrieb MySQL-Abfragen für interne Berichte. Bearbeitete Tickets, die ein erfahrener Entwickler vorbereitet hatte, und ließ Änderungen vor dem Zusammenführen prüfen. Aktualisierte nach Änderungen an den Anfrageformularen die Anleitungen für das Support-Team.
Nahm an täglichen Teamterminen teil und machte Notizen bei der Planung. Half, Fehlerkorrekturen mit Beispielanfragen zu testen. Nutzte Git zur Versionsverwaltung und das Ticketsystem des Teams für Fortschrittsmeldungen. Für dieses Projekt sind keine Tätigkeiten im Zahlungsverkehr oder bei der Abstimmung von Zahlungsabrechnungen beschrieben.
Beschäftigung, Ausbildung und weitere Angaben
- 01/2025–10/2026: Backend Engineer, Example Commerce A.
- 01/2022–12/2024: Software Engineer, Example Payments B.
- 07/2019–12/2021: Junior Software Engineer, Example Services C.
Ausbildung: BSc Computer Science, Example University, 2019.
Weiterbildung: AWS-Einführungskurs, 2024. Eine AWS-Zertifizierung ist nicht angegeben.
Sprachen: Polnisch als Muttersprache; Englisch B2 nach eigener Einschätzung.
Verfügbarkeit: Frühester Einsatzbeginn noch nicht bestätigt.
Was bleibt, was wird gekürzt, was entfällt?
Behalten: das ältere Projekt mit dem relevanten Datenabgleich
Der Settlement reporting service beantwortet den fachlich entscheidenden Teil der Anfrage. Deshalb bleibt er ausführlich beschrieben, obwohl das Commerce-Projekt neuer ist. Die PostgreSQL-Abfragen zum Abgleich von Transaktionen und Abrechnungsdateien sowie die Untersuchung von Abweichungen sind konkrete eigene Tätigkeiten.
Ebenso wichtig ist die Grenze dieser Tätigkeit: Komponenten implementieren ist nicht dasselbe wie die Architektur verantworten oder den produktiven Abrechnungsbetrieb führen. Diese Abgrenzung bleibt in der Kurzfassung stehen. Aus „Software Engineer“ wird durch das Kürzen kein „Lead“ und kein „Architect“.
Verdichten: das jüngste Projekt, ohne Erfahrung in der Zahlungsabwicklung hinzuzuerfinden
Der Commerce catalogue service zeigt die jüngere Arbeit mit Java, Spring Boot und PostgreSQL. Er bleibt deshalb das erste ausführliche Projekt. REST-Endpunkte, Datenbankabfragen, Indizes und Tests tragen mehr zur Kundenentscheidung bei als die erneute Aufzählung von Planungsrunden und täglichen Abstimmungen.
Der Satz zur fachlichen Grenze darf dagegen nicht verschwinden: Die Zahlungsintegration gehörte zum Gesamtprojekt, nicht zum eigenen Aufgabenbereich. Eine Verkürzung auf „Backend-Entwicklung für Commerce und Payments“ würde diesen Unterschied verwischen. In der Kurzfassung steht daher ausdrücklich, dass die eigene Arbeit den Katalogservice betraf.
Auf die Chronologie reduzieren: das frühe Serviceportal
Die frühe Station bleibt mit Arbeitgeber, Zeitraum und tatsächlich geführter Position vollständig sichtbar. Nur die ausführliche Beschreibung der Formularpflege und internen Berichte entfällt. Für diese Anfrage ist sie weniger aussagekräftig als der belegte Abgleich von Transaktionsdaten im späteren Projekt.
Damit wird keine Beschäftigungslücke geschaffen. Die fehlende Detailbeschreibung sagt auch nicht aus, dass die Person bestimmte Kenntnisse nicht besitzt. Sie legt lediglich fest, welche Erfahrung diese Kundenfassung erläutert.
Streichen: Wiederholungen und nicht angefragte Zusatzkenntnisse
Die wiederholten Beschreibungen von Teamterminen, Ticketpflege und Dokumentation entfallen weitgehend. Auch allgemeine Aussagen wie „lernt gern neue Technologien“ weichen den konkreten Tätigkeiten.
Von den Kenntnissen bleiben Java, Spring Boot, PostgreSQL, REST, JUnit und Git. Diese sechs sind in den beiden ausgewählten Projekten verankert. Die erlaubten acht Einträge müssen nicht ausgeschöpft werden. MySQL, JavaScript, HTML, CSS, Jira, Confluence und Scrum-Termine bleiben in der Ausgangsfassung, erhalten hier aber keinen eigenen Platz.
Der AWS-Einführungskurs entfällt ebenfalls aus dieser Kundenfassung: Er ist nicht angefragt und belegt weder eine Zertifizierung noch Verantwortung für einen produktiven AWS-Betrieb. Ausbildung und Sprachen bleiben erhalten. Die ungeklärte Verfügbarkeit wird nicht durch ein erfundenes Startdatum ersetzt.
Die vollständige gekürzte Kundenfassung
F-17 – Backend Engineer
Kurzprofil
Backend-Entwickler mit Java, Spring Boot und PostgreSQL in Katalogservices und im Zahlungsabrechnungsreporting. Implementierte im Abrechnungsprojekt Abfragen zum Transaktionsabgleich. Die jüngere Commerce-Tätigkeit betraf Katalog-APIs, nicht die Zahlungsabwicklung. Der eigene Beitrag lag in der Implementierung, nicht in der Architekturverantwortung.
Ausgewählte Kenntnisse
Java, Spring Boot, PostgreSQL, REST, JUnit, Git.
Projekt: Commerce catalogue services
Zeitraum: 01/2025–10/2026
Rolle: Backend Engineer
Implementierte REST-Endpunkte für den Katalogservice, PostgreSQL-Abfragen und Indizes sowie JUnit-Regressionstests. Stimmte API-Felder mit dem Frontend-Team ab und untersuchte vom Support gemeldete Fehler. Der eigene Aufgabenbereich war der Katalogservice, nicht die Zahlungsabwicklung oder die Abstimmung von Zahlungsabrechnungen im Gesamtprojekt.
Technologien: Java, Spring Boot, PostgreSQL, REST, JUnit, Git.
Projekt: Settlement reporting service
Zeitraum: 01/2022–12/2024
Rolle: Software Engineer
Implementierte Java-/Spring-Boot-Endpunkte und PostgreSQL-Abfragen zum Abgleich von Transaktionsdatensätzen mit Abrechnungsdateien. Untersuchte Abweichungen mit dem Operations-Team und ergänzte Regressionstests. Implementierte zugewiesene Komponenten; die Servicearchitektur verantwortete ein separater Architekt. Die produktive Abwicklung der Zahlungsabrechnungen und das Deployment lagen bei einem separaten Operations-Team.
Technologien: Java, Spring Boot, PostgreSQL, REST, JUnit, Git.
Beschäftigungsverlauf
- 01/2025–10/2026: Backend Engineer, Example Commerce A.
- 01/2022–12/2024: Software Engineer, Example Payments B.
- 07/2019–12/2021: Junior Software Engineer, Example Services C; internes Serviceportal mit Java.
Ausbildung: BSc Computer Science, Example University, 2019.
Sprachen: Polnisch als Muttersprache; Englisch B2 nach eigener Einschätzung.
Verfügbarkeit: Frühester Einsatzbeginn noch nicht bestätigt.
Ob die Fassung auf zwei Seiten passt, zeigt erst das PDF
Übertragen Sie die gekürzten Inhalte in die unveränderte Kundenvorlage und öffnen Sie den PDF-Export. Prüfen Sie dort die tatsächliche Seitenzahl, die Lesbarkeit und die Umbrüche der Projektbeschreibungen. Ein kurzer Text allein belegt noch nicht, dass das Dokument die Seitenvorgabe erfüllt.
Falls eine dritte Seite entsteht, kürzen Sie zuerst weitere Details ohne Bezug zur Anfrage. Verkleinern Sie nicht die Schrift und ändern Sie nicht die Ränder, um den Überlauf zu verstecken. Beschäftigungszeiträume, geführte Positionen und die Abgrenzung der eigenen Verantwortung bleiben erhalten.
Für F-17 ist außerdem der früheste Einsatzbeginn zu klären. Das Feld ist sichtbar, die Information aber noch offen. Vor dem Versand holen Sie diese Angabe ein und prüfen die ergänzte Fassung erneut.
Nach der Inhaltsauswahl folgt die Formatierung
Die Entscheidung über die Projektdetails treffen Sie anhand der Anfrage und der Ausgangsunterlagen. Anschließend unterstützt TalentVeil die Übernahme der CV-Inhalte in eine Firmen- oder Kundenvorlage, die Bearbeitung durch den Recruiter und den PDF-Export. Sie prüfen die endgültige Fassung, bevor sie an den Kunden geht.
Danach können Sie die freigegebene Shortlist in einem gebrandeten Kundenportal teilen und die Rückmeldung des Kunden direkt am Profil erhalten. Der Kunde markiert, wen er kennenlernen möchte, und hinterlässt sein Feedback.
Wenn Ihr Team die ausgewählten Inhalte regelmäßig in Kundenvorlagen überträgt, sehen Sie sich die CV-Formatierung für Personalvermittlungen mit TalentVeil an.