Mobile-Developer-Test-Resultate interpretieren: Score zu Hiring
Score ohne Kontext ist Rauschen
72/100 gut? Falsche Frage. Richtig: was wissen sie für diese Rolle?
Rubric zuerst
iOS-Rubric
Correctness (30): kompiliert (10), Requirements (15), Edge-Cases (5) Architecture (25): State (10), Testable (10), Overengineering (5) Knowledge (20): Lifecycle (8), Memory (7), Async (5) Quality (25): Readability (10), Bugs (10), Commits (5)
Pass: 65-70.
Android-Rubric
Correctness (30), Architecture (25): ViewModel/Repository, DI Knowledge (20): Coroutines, Lifecycle Quality (25)
Was Scores bedeuten
85+: Strong-Hire
Mergeable. Next-Round.
70-84: Adequate mit Lücken
Hängt von Seniority ab.
60-69: Passing technisch, concerning strategisch
Tief interviewen.
<60: Nicht bereit
Pass.
Walk-Through: wo Scores zu Entscheidungen werden
"Walk me through, wie du User-Preference gespeichert hast."
Strong (72→80+): "UserDefaults für simple, Codable+JSON für komplex, Errors gecheckt." Weak (72→55): "Nicht sicher, nicht über Errors nachgedacht."
Interpretations-Fehler
- "Didn't finish" vs "doesn't know" — unterschiedliche Signale
- Overweighting eines Aspekts
- Grading wrong für Plattform
- Weak Score = weak Engineer (nicht immer)
Borderline-Scores
65-70
Zweite Bewertung oder Live-Coding.
60-64
Gap analysieren. Lernbar?
Validity bauen
High-Scorer succeed? Low-Scorer struggle? Rubric anpassen.
Rote Flaggen
- "Hässlich aber funktioniert"
- Kein Async-Await
- Anderer Weg ≠ falsch
- Library benutzt — penalisieren ist backwards
Im Hiring-Meeting
Nicht "72/100." Sondern: "72, stark Correctness 28/30, schwächer Arch 18/25. Walk-Through: solider Lifecycle. Gap: Testability. Für Mid-Level akzeptabel."