PHP-Entwickler finden: Worauf Sie achten sollten

“Der Entwickler hat uns versichert, er kennt PHP. Nach 3 Monaten hatten wir 50.000 Euro ausgegeben und eine App, die bei 10 gleichzeitigen Nutzern zusammenbricht.” Diesen Satz höre ich mindestens einmal im Quartal von Kunden, die zu mir wechseln. Das Problem ist nicht PHP. Das Problem ist, dass “Ich kann PHP” heute alles bedeuten kann: von “Ich habe mal ein WordPress-Plugin installiert” bis “Ich baue seit 15 Jahren Enterprise-Systeme.”

Executive Summary

Die 3 wichtigsten Erkenntnisse:

1. Portfolio schlägt Zertifikate: Ein GitHub-Profil mit echtem Code sagt mehr als 10 Zertifikate
2. Framework-Fanatiker meiden: Wer nur Laravel kann, kann nicht zwangsweise auch PHP
3. Fragen Sie nach Fehlern: Gute Entwickler erzählen von Projekten, die schiefgingen

Kosten für einen guten PHP-Entwickler (2025):

Erfahrung	Stundensatz Freelancer	Gehalt Festanstellung
Junior (0 bis 2 Jahre)	50 bis 70 Euro	40.000 bis 50.000 Euro
Mid-Level (3 bis 5 Jahre)	70 bis 100 Euro	50.000 bis 65.000 Euro
Senior (5+ Jahre)	100 bis 150 Euro	65.000 bis 90.000 Euro
Spezialist (10+ Jahre)	120 bis 180 Euro	80.000 bis 110.000 Euro

Die 5 größten Fehler bei der Entwicklersuche

Fehler 1: Nur auf Frameworks achten

Das Problem: “Wir suchen einen Laravel-Entwickler” ist wie “Wir suchen einen Schraubenzieher-Handwerker”. Ein guter Handwerker kann mit jedem Werkzeug arbeiten.

// Framework-Entwickler vs. PHP-Entwickler

// Framework-Entwickler: Kennt nur Laravel
class LaravelOnlyDeveloper {
    public function problem(): string {
        return 'Ohne Eloquent weiß ich nicht, wie Datenbanken funktionieren';
    }

    public function loesungsansatz(): string {
        return 'Wir müssen alles in Laravel neu bauen';
        // Auch wenn das bestehende System funktioniert
    }
}

// PHP-Entwickler: Versteht die Grundlagen
class RealPhpDeveloper {
    public function problem(): string {
        return 'Ich verstehe PDO, kann aber auch Eloquent, Doctrine oder raw SQL';
    }

    public function loesungsansatz(): string {
        return 'Welches Tool passt am besten zum Problem?';
        // Framework ist Mittel zum Zweck, nicht Selbstzweck
    }
}

Die Wahrheit: Ein Entwickler, der nur Laravel kann, wird Ihnen für jedes Problem Laravel verkaufen. Auch wenn ein schlanker Ansatz besser wäre.

Fehler 2: Zertifikate überbewerten

Das Problem: Zend-Zertifizierung, AWS-Badges, Udemy-Kurse. Klingt beeindruckend, sagt aber wenig über praktische Fähigkeiten.

Was Zertifikate zeigen:

• Kann Prüfungen bestehen
• Hat Zeit für Kurse investiert
• Kennt die Theorie

Was Zertifikate NICHT zeigen:

• Kann unter Druck debuggen
• Trifft gute Architekturentscheidungen
• Schreibt wartbaren Code
• Kommuniziert mit Nicht-Technikern

Besser: Fragen Sie nach dem GitHub-Profil oder lassen Sie eine kleine Coding-Aufgabe lösen.

Fehler 3: Billig einkaufen

Das Problem: “Ich habe einen Entwickler in [Land] gefunden, der macht es für 15 Euro/Stunde.”

Die Rechnung, die niemand macht:

Faktor	Teurer Entwickler (100 Euro/h)	Billiger Entwickler (15 Euro/h)
Stunden für Feature	10h	40h (mehr Bugs, Nacharbeit)
Kosten Feature	1.000 Euro	600 Euro
Kommunikationsaufwand	1h	10h (Zeitzone, Sprache)
Ihre Zeit (80 Euro/h)	80 Euro	800 Euro
Code-Review/Fixes	0h	15h
Gesamtkosten	1.080 Euro	2.650 Euro

Die Wahrheit: Billige Entwickler sind teuer. Gute Entwickler sind günstig.

Fehler 4: Keine technische Prüfung

Das Problem: Das Bewerbungsgespräch führt der Geschäftsführer, der selbst kein PHP kann.

// Was der Bewerber sagt vs. was er kann

class BewerberRealitaet {
    public function imGespraech(): array {
        return [
            'Ich kenne alle Design Patterns',
            'Ich habe mit großen Datenbanken gearbeitet',
            'Security ist mir sehr wichtig',
            'Ich bin Teamplayer',
        ];
    }

    public function inWirklichkeit(): array {
        return [
            'Ich habe mal von Singleton gehört',
            'Meine größte Tabelle hatte 10.000 Zeilen',
            'Ich speichere Passwörter als MD5',
            'Ich arbeite am liebsten alleine im Keller',
        ];
    }
}

Lösung: Lassen Sie einen technischen Mitarbeiter oder externen Berater das Gespräch führen. Oder nutzen Sie die 12 Fragen weiter unten.

Fehler 5: Nur auf Erfahrungsjahre schauen

Das Problem: “10 Jahre PHP-Erfahrung” kann bedeuten:

• 10 Jahre kontinuierliches Lernen und Wachstum
• 1 Jahr Erfahrung, 10 mal wiederholt

Die Wahrheit: Ein motivierter Junior mit 2 Jahren kann besser sein als ein Senior mit 10 Jahren, der seit 2015 nichts Neues gelernt hat.

Fragen Sie stattdessen:

• Was haben Sie im letzten Jahr Neues gelernt?
• Welches Projekt hat Sie technisch am meisten gefordert?
• Wie halten Sie sich auf dem Laufenden?

Red Flags: Wann Sie ablehnen sollten

🚩 Red Flag 1: “Das mache ich immer so”

Symptom: Auf die Frage “Warum dieser Ansatz?” kommt: “Das mache ich immer so” oder “Das haben wir schon immer so gemacht.”

Problem: Kein kritisches Denken, keine Anpassungsfähigkeit

// Red Flag: Copy-Paste aus alten Projekten
class RedFlagDeveloper {
    public function handleRequest(): void {
        // "Das funktioniert, fass es nicht an"
        mysql_query("SELECT * FROM users WHERE id = " . $_GET['id']);
        // SQL Injection? Was ist das?
    }
}

// Green Flag: Versteht Best Practices
class GreenFlagDeveloper {
    public function handleRequest(PDO $db, int $userId): array {
        $stmt = $db->prepare("SELECT * FROM users WHERE id = :id");
        $stmt->execute(['id' => $userId]);
        return $stmt->fetch(PDO::FETCH_ASSOC) ?: [];
    }
}

🚩 Red Flag 2: Kann keine Fehler nennen

Symptom: Auf die Frage “Erzählen Sie von einem Projekt, das nicht gut lief” kommt: “Bei mir läuft alles immer gut.”

Problem: Entweder lügt die Person, oder sie hat noch nie ein echtes Projekt gemacht.

Gute Antwort: “Wir haben die Datenbank falsch designed und mussten nach 6 Monaten migrieren. Seitdem mache ich immer erst ein Schema-Review.”

🚩 Red Flag 3: Framework über alles

Symptom: Jede Antwort enthält “In Laravel würde man…” oder “Mit Symfony geht das einfacher…”

Test-Frage: “Wie würden Sie das ohne Framework lösen?”

// Red Flag: Kann nur mit Framework
class FrameworkAbhaengig {
    public function ohneFramework(): string {
        return 'Das geht nicht ohne Laravel';
        // Spoiler: Geht sehr wohl
    }
}

// Green Flag: Versteht beide Welten
class FlexiblerEntwickler {
    public function mitFramework(): string {
        return 'Laravel macht hier Sinn wegen X, Y, Z';
    }

    public function ohneFramework(): string {
        return 'Ohne Framework spart man Overhead,
                aber muss mehr selbst bauen';
    }

    public function entscheidung(): string {
        return 'Kommt auf das Projekt an';
    }
}

🚩 Red Flag 4: Keine Fragen zum Projekt

Symptom: Der Entwickler fragt nichts über Ihr Business, Ihre Nutzer oder Ihre Ziele.

Problem: Will nur Code schreiben, nicht Probleme lösen.

Gute Entwickler fragen:

• Wer sind die Hauptnutzer?
• Was ist der größte Pain Point?
• Gibt es Legacy-Systeme, die integriert werden müssen?
• Wie sieht der Zeitrahmen aus?

🚩 Red Flag 5: “Das ist trivial”

Symptom: Auf komplexe Anforderungen kommt: “Das ist trivial” oder “Das mache ich an einem Nachmittag.”

Problem: Unterschätzt Komplexität, wird Budget und Timeline sprengen.

Die Wahrheit: Erfahrene Entwickler wissen, dass nichts trivial ist. Sie fragen nach Details, bevor sie schätzen.

Green Flags: Zeichen für gute Entwickler

✅ Green Flag 1: Fragt “Warum?”

Bevor ein guter Entwickler anfängt zu bauen, will er verstehen:

• Warum brauchen Sie dieses Feature?
• Welches Problem löst es?
• Gibt es vielleicht eine einfachere Lösung?

✅ Green Flag 2: Spricht über Trade-offs

// Green Flag: Versteht Trade-offs
class ErfahrenerEntwickler {
    public function architekturEntscheidung(): array {
        return [
            'option_a' => [
                'vorteil' => 'Schneller zu entwickeln',
                'nachteil' => 'Schwerer zu skalieren',
            ],
            'option_b' => [
                'vorteil' => 'Skaliert besser',
                'nachteil' => 'Dauert länger initial',
            ],
            'empfehlung' => 'Für Ihr MVP: Option A.
                           Bei Erfolg: Migration zu Option B.',
        ];
    }
}

✅ Green Flag 3: Hat Lieblingsfehler

Klingt paradox, aber: Gute Entwickler haben Geschichten über Fehler, die sie gemacht haben. Und was sie daraus gelernt haben.

Beispiel: “Ich habe mal vergessen, Indizes auf eine Join-Tabelle zu setzen. Bei 100.000 Einträgen wurde die Query von 50ms zu 45 Sekunden. Seitdem ist Index-Review Teil meiner Checkliste.”

✅ Green Flag 4: Sagt “Ich weiß es nicht”

Ein Entwickler, der alles zu wissen behauptet, lügt. Ein guter Entwickler sagt: “Das weiß ich nicht, aber ich finde es heraus.”

✅ Green Flag 5: Lesbarkeit vor Cleverness

// Red Flag: Zu clever
$result = array_reduce(array_filter(array_map(fn($x) => $x * 2, $arr), fn($x) => $x > 10), fn($a, $b) => $a + $b, 0);

// Green Flag: Lesbar
$doubled = array_map(fn($x) => $x * 2, $arr);
$filtered = array_filter($doubled, fn($x) => $x > 10);
$result = array_sum($filtered);

// Noch besser: Mit sprechenden Namen
$verdoppelteWerte = array_map(fn($wert) => $wert * 2, $eingaben);
$groesseAlsZehn = array_filter($verdoppelteWerte, fn($wert) => $wert > 10);
$summe = array_sum($groesseAlsZehn);

12 Fragen fürs Erstgespräch

Technische Grundlagen

1. “Erklären Sie den Unterschied zwischen == und === in PHP.”

✅ Gute Antwort: ”== vergleicht nur Werte, === vergleicht Wert UND Typ. Bei == ist ‘5’ == 5 true, bei === ist ‘5’ === 5 false. Ich nutze fast immer ===, um Typ-Bugs zu vermeiden.”

🚩 Schlechte Antwort: “Äh… das eine hat mehr Gleichheitszeichen?”

2. “Wie verhindern Sie SQL Injection?”

✅ Gute Antwort: “Prepared Statements mit Parameterbindung. Niemals User-Input direkt in Queries einbauen. Bei PDO mit execute() und Named Parameters oder Fragezeichen.”

🚩 Schlechte Antwort: “mysql_real_escape_string?” (veraltet seit 10+ Jahren)

3. “Was ist der Unterschied zwischen require und include?”

✅ Gute Antwort: “require wirft einen Fatal Error wenn die Datei nicht existiert, include nur eine Warning. Für kritische Dependencies nutze ich require_once, für optionale include.”

Architektur und Design

4. “Wann würden Sie KEIN Framework nutzen?”

✅ Gute Antwort: “Bei sehr kleinen Projekten, APIs mit wenigen Endpoints, oder wenn Performance kritisch ist und der Framework-Overhead stört. Auch bei Legacy-Integration, wenn das Framework nicht reinpasst.”

🚩 Schlechte Antwort: “Niemals, Frameworks sind immer besser.” (Framework-Fanatiker)

5. “Wie strukturieren Sie ein neues Projekt?”

✅ Gute Antwort: “Erst verstehen was gebaut werden soll. Dann Datenmodell skizzieren. Klare Trennung von Concerns: Routing, Business-Logik, Datenzugriff. Bei größeren Projekten Domain-Driven Design.”

6. “Erklären Sie Dependency Injection mit einem Beispiel.”

✅ Gute Antwort: “Statt dass eine Klasse ihre Abhängigkeiten selbst erstellt, werden sie von außen übergeben. Macht Testing einfacher und Komponenten austauschbar.”

// Ohne DI (schlecht)
class UserService {
    private $db;
    public function __construct() {
        $this->db = new PDO('mysql:host=localhost'); // Hardcoded!
    }
}

// Mit DI (gut)
class UserService {
    public function __construct(private PDO $db) {}
}
// DB wird von außen übergeben, kann auch Mock sein

Praxis und Erfahrung

7. “Erzählen Sie von einem Performance-Problem, das Sie gelöst haben.”

✅ Gute Antwort: Konkrete Geschichte mit Problem, Analyse, Lösung und Ergebnis. Z.B.: “Query lief 3 Sekunden, nach EXPLAIN sah ich Full Table Scan, Index hinzugefügt, runter auf 50ms.”

🚩 Schlechte Antwort: “Hatte ich noch nie” (unwahrscheinlich) oder nur vage Aussagen.

8. “Was war Ihr größter Fehler in einem Projekt?”

✅ Gute Antwort: Ehrliche Geschichte mit Lerneffekt. Z.B.: “Habe keine Backups getestet, bei Migration gab es Datenverlust. Seitdem teste ich Restores monatlich.”

🚩 Schlechte Antwort: “Ich mache keine Fehler.”

9. “Wie gehen Sie mit Legacy-Code um?”

✅ Gute Antwort: “Erst verstehen, nicht sofort umschreiben. Tests schreiben für kritische Teile. Schrittweise refactoren, nicht Big Bang. Dokumentieren was ich finde.”

Zusammenarbeit und Kommunikation

10. “Ein Nicht-Techniker fragt, warum die App langsam ist. Wie erklären Sie es?”

✅ Gute Antwort: Nutzt Analogien, vermeidet Fachjargon. Z.B.: “Stellen Sie sich vor, Sie suchen ein Buch in einer Bibliothek ohne Sortierung. Wir müssen ein Inhaltsverzeichnis (Index) erstellen.”

11. “Der Kunde will Feature X, Sie halten es für falsch. Was tun Sie?”

✅ Gute Antwort: “Erst verstehen warum er es will. Vielleicht löst Feature Y das eigentliche Problem besser. Meine Bedenken klar kommunizieren, aber am Ende entscheidet der Kunde.”

🚩 Schlechte Antwort: “Ich baue was der Kunde will” (zu passiv) oder “Ich mache es trotzdem anders” (zu eigenmächtig).

Die Bonus-Frage

12. “Was würden Sie mich fragen, wenn Sie an meiner Stelle wären?”

Diese Frage zeigt, ob der Entwickler mitdenkt. Gute Antworten:

• “Wie sieht Ihr Tech-Stack aktuell aus?”
• “Gibt es bestehende Systeme, die integriert werden müssen?”
• “Wer sind die Hauptnutzer?”
• “Wie wird getestet und deployed?“

15-Minuten-Screening: 80% der Blender rausfiltern

Dieses Pack können Sie am Telefon oder im Erstcall nutzen. Ziel: In 15 Minuten erkennen, ob ein tieferes Gespräch lohnt.

Die 5 Killer-Fragen

1. “Erklären Sie == vs === und wann verwenden Sie welches?”

Antwort-Qualität	Was Sie hören	Bewertung
✅ Sehr gut	”=== prüft Typ und Wert, == nur Wert. Ich nutze fast immer === um Type-Juggling-Bugs zu vermeiden. Bei == ist ‘0’ == false true, das führt zu Überraschungen.”	Weiter
⚠️ Okay	”Das eine ist strikt, das andere nicht.”	Nachfragen
🚩 Raus	”Äh… mehr Gleichheitszeichen ist strenger?”	Abbruch

2. “Wie verhindern Sie SQL-Injection? Bitte konkret mit PDO.”

// Das wollen Sie hören:
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute(['email' => $userInput]);

// Das ist ein Ausschlusskriterium:
$pdo->query("SELECT * FROM users WHERE email = '$userInput'");

3. “Letzter Produktionsfehler, der auf Ihren Code zurückging? Was haben Sie seitdem geändert?”

Antwort-Qualität	Was Sie hören	Bewertung
✅ Sehr gut	”Ich hatte vergessen, einen Index auf die Fremdschlüssel-Spalte zu setzen. Bei 500k Zeilen wurde der Join unerträglich langsam. Seitdem ist Index-Review Teil meiner Checkliste vor jedem Deployment.”	Weiter
⚠️ Okay	”Mal einen Typo in Produktion gehabt.”	Nachfragen: Was genau?
🚩 Raus	”Mir passieren keine Fehler.” / Keine konkrete Antwort	Abbruch

4. “Ohne Framework: Wie routen Sie /users/{id} und lesen sicher aus der DB?”

// Erwartete Antwort (sinngemäß):
$uri = parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH);

if (preg_match('#^/users/(\d+)$#', $uri, $matches)) {
    $userId = (int) $matches[1];

    $stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
    $stmt->execute(['id' => $userId]);
    $user = $stmt->fetch(PDO::FETCH_ASSOC);

    header('Content-Type: application/json');
    echo json_encode($user);
}

Wer das nicht spontan skizzieren kann, kennt nur Frameworks, nicht PHP.

5. “Was haben Sie im letzten Jahr konkret neu gelernt? Kein Buzzword, bitte ein Beispiel.”

Antwort-Qualität	Was Sie hören	Bewertung
✅ Sehr gut	”Ich habe mich in PHP 8.3 Typed Class Constants eingearbeitet und nutze jetzt readonly classes für DTOs. Spart Boilerplate.”	Weiter
⚠️ Okay	”Ich habe einen Kurs zu Docker gemacht.”	Nachfragen: Was konkret umgesetzt?
🚩 Raus	”KI, Blockchain, Cloud…” (nur Buzzwords)	Abbruch

Auswertung nach 15 Minuten

Ergebnis	Empfehlung
5/5 oder 4/5 gut	Einladen zum Tech-Interview
3/5 gut	Nur bei Kandidatenmangel weiter
< 3/5 gut	Absagen, Zeit sparen

60-Minuten-Tech-Interview: Live-Pairing

Für Kandidaten, die das Screening bestanden haben. Dieses Interview zeigt, wie jemand wirklich arbeitet.

Ablauf-Struktur

┌─────────────────────────────────────────────────────────────┐
│  0-10 Min: Lebenslauf rückwärts                            │
├─────────────────────────────────────────────────────────────┤
│ 10-30 Min: Code-Reading (Bug finden)                       │
├─────────────────────────────────────────────────────────────┤
│ 30-45 Min: Mini-Refactor (live)                            │
├─────────────────────────────────────────────────────────────┤
│ 45-55 Min: Architektur-Trade-off                           │
├─────────────────────────────────────────────────────────────┤
│ 55-60 Min: Fragen des Kandidaten                           │
└─────────────────────────────────────────────────────────────┘

Teil 1: Lebenslauf rückwärts (10 Minuten)

Fokus: Die letzten 12 Monate, nicht die Karriere seit 2010.

Fragen:

• “Was war Ihr anspruchsvollstes Projekt im letzten Jahr?”
• “Wo war Ihre größte Lernkurve?”
• “Was würden Sie heute anders machen?”

Worauf achten:

• Kann konkrete technische Details nennen
• Reflektiert über eigene Entscheidungen
• Keine auswendig gelernten Floskeln

Teil 2: Code-Reading (20 Minuten)

Zeigen Sie dem Kandidaten fremden Code mit einem versteckten Problem. Der Kandidat soll:

1. Den Code verstehen und erklären
2. Das Problem finden
3. Eine Lösung vorschlagen

Beispiel A: N+1 Query Problem

// Code zum Analysieren (Bug: N+1)
class OrderService {
    public function getOrdersWithCustomers(PDO $db): array {
        $orders = $db->query("SELECT * FROM orders")->fetchAll();

        foreach ($orders as &$order) {
            $stmt = $db->prepare("SELECT * FROM customers WHERE id = :id");
            $stmt->execute(['id' => $order['customer_id']]);
            $order['customer'] = $stmt->fetch();
        }

        return $orders;
    }
}

// Bei 1.000 Orders = 1.001 Queries!

Erwartete Erkenntnis: “Das ist ein N+1 Problem. Bei 1.000 Orders sind das 1.001 Queries. Besser: JOIN oder alle Customer-IDs sammeln und mit IN-Clause laden.”

Beispiel B: Fehlendes Prepared Statement

// Code zum Analysieren (Bug: SQL Injection)
class UserSearch {
    public function findByName(PDO $db, string $name): array {
        $sql = "SELECT * FROM users WHERE name LIKE '%{$name}%'";
        return $db->query($sql)->fetchAll();
    }
}

Erwartete Erkenntnis: “SQL Injection möglich. Der $name wird direkt eingebaut. Muss ein Prepared Statement sein.”

Teil 3: Mini-Refactor (15 Minuten)

Der Kandidat soll den problematischen Code live refactoren. Dabei zeigt sich:

• Wie denkt die Person?
• Kann sie ihre Entscheidungen erklären?
• Arbeitet sie in kleinen, nachvollziehbaren Schritten?

Beispiel-Refactor für N+1:

// Schritt 1: Problem isolieren
// "Erst sammle ich alle Customer-IDs"
$customerIds = array_unique(array_column($orders, 'customer_id'));

// Schritt 2: Batch-Query
// "Dann lade ich alle Kunden in einer Query"
$placeholders = implode(',', array_fill(0, count($customerIds), '?'));
$stmt = $db->prepare("SELECT * FROM customers WHERE id IN ($placeholders)");
$stmt->execute($customerIds);
$customers = $stmt->fetchAll(PDO::FETCH_ASSOC);

// Schritt 3: Zuordnen
// "Jetzt mappe ich die Kunden zu den Orders"
$customerMap = array_column($customers, null, 'id');
foreach ($orders as &$order) {
    $order['customer'] = $customerMap[$order['customer_id']] ?? null;
}

Bewertungskriterien:

Aspekt	Gut	Schlecht
Vorgehensweise	Kleine Schritte, erklärt jeden	Großer Wurf ohne Erklärung
Fehlertoleranz	”Moment, das war falsch, ich korrigiere”	Versucht Fehler zu verstecken
Codequalität	Lesbar, sprechende Namen	Kryptisch, $a, $b, $tmp

Teil 4: Architektur-Trade-off (10 Minuten)

Szenario: “Sie sollen ein MVP für ein Kundenportal bauen. 500 User, Budget 40k, Timeline 10 Wochen. Monolith oder Microservices?”

Erwartete Antwort (sinngemäß):

class ArchitekturEntscheidung {
    public function fuerMvp(): string {
        return 'Monolith';
    }

    public function begruendung(): array {
        return [
            'Geschwindigkeit' => 'Monolith ist schneller zu entwickeln',
            'Komplexität' => 'Kein Service-Discovery, kein API-Gateway nötig',
            'Team' => 'Ein Entwickler kann alles überblicken',
            'Budget' => '40k reicht nicht für Microservice-Infrastruktur',
            'Skalierung' => 'Bei 500 Usern irrelevant, ein Server reicht',
        ];
    }

    public function wannMicroservices(): string {
        return 'Wenn wir 50.000 User haben und 5 Teams parallel arbeiten';
    }
}

Red Flags:

• “Microservices sind immer besser” (Dogma)
• Keine Begründung, nur Meinung
• Kann keine Trade-offs nennen

Teil 5: Kandidaten-Fragen (5 Minuten)

Was der Kandidat fragt, zeigt sein Mindset:

Frage	Was sie zeigt
”Wie sieht der Tech-Stack aus?”	Technisches Interesse
”Wie wird deployed?”	Denkt an den ganzen Lifecycle
”Wie ist das Team aufgestellt?”	Teamplayer
”Was ist die größte technische Herausforderung?”	Will lernen
”Wie ist die Work-Life-Balance?”	Legitim, aber nicht als erste Frage
Keine Fragen	🚩 Desinteresse

Auswertung Tech-Interview

Teil	Gewichtung	Bestanden wenn
Lebenslauf	10%	Konkret, reflektiert
Code-Reading	30%	Bug gefunden und erklärt
Refactor	30%	Saubere Lösung, nachvollziehbar
Architektur	20%	Trade-offs verstanden
Fragen	10%	Relevante Fragen gestellt

Einstellungsempfehlung: Mindestens 70% der Punkte, keine 🚩 Red Flags.

Wo Sie gute PHP-Entwickler finden

Plattformen nach Qualität

Plattform	Qualität	Preis	Kommentar
Persönliche Empfehlung	⭐⭐⭐⭐⭐	Hoch	Beste Quelle, aber begrenzt
GitHub/Stack Overflow	⭐⭐⭐⭐	Mittel bis Hoch	Code sichtbar, aber Ansprache nötig
XING/LinkedIn	⭐⭐⭐	Mittel bis Hoch	Viel Rauschen, aber gute Profile dabei
Freelancer-Portale (DE)	⭐⭐⭐	Mittel	gulp.de, freelance.de
Upwork/Fiverr	⭐⭐	Niedrig bis Mittel	Viel Auswahl, viel Schrott
Offshore-Agenturen	⭐	Niedrig	Kommunikation oft Problem

Die beste Strategie

1. Netzwerk fragen: “Kennt jemand einen guten PHP-Entwickler?”
2. GitHub durchsuchen: Nach Projekten in Ihrer Domain suchen
3. Lokale Meetups: PHP User Groups, Laravel Meetups
4. Stellenausschreibung: Aber bitte keine “PHP-Ninja-Rockstar” Anzeigen

Checkliste: Vor der Zusammenarbeit

Muss vorhanden sein

• Kann sauberes PHP ohne Framework schreiben
• Versteht SQL und Datenbank-Grundlagen
• Kennt Security-Basics (SQL Injection, XSS, CSRF)
• Hat echten Code zum Zeigen (GitHub, Referenzen)
• Kommuniziert klar und fragt nach

Sollte vorhanden sein

• Erfahrung mit PostgreSQL oder MySQL in Produktion
• Versteht Versionskontrolle (Git)
• Kann eigenen Code erklären
• Hat Erfahrung mit Testing

Nice to have

• Kennt Ihr spezifisches Framework (falls vorhanden)
• DevOps-Grundlagen (Deployment, Server)
• Frontend-Kenntnisse (HTML, CSS, JS)

Fazit: Qualität hat ihren Preis

Die Suche nach einem guten PHP-Entwickler ist wie die Suche nach einem guten Handwerker: Es gibt viele, die behaupten es zu können, aber wenige, die es wirklich können.

Meine Top-3-Tipps:

1. Investieren Sie in die Auswahl: 2 bis 3 Stunden für ein gutes Gespräch sparen Monate an Frustration
2. Zahlen Sie angemessen: Ein Senior für 120 Euro/h ist günstiger als drei Juniors für je 50 Euro/h
3. Vertrauen Sie Ihrem Bauchgefühl: Wenn etwas komisch riecht, ist es das meist auch

Der beste Indikator: Fragen Sie: “Was war Ihr letztes Projekt, das schiefging?” Wer darauf eine ehrliche, lehrreiche Antwort hat, hat echte Erfahrung.

---

Sie sind unsicher, ob ein Entwickler der Richtige ist? Ich biete technische Interviews als Service an: 90 Minuten, strukturierte Prüfung, schriftliche Einschätzung. Damit Sie sicher sein können.