Um einen guten LLM-Engineer einzustellen, testen Sie auf Produktionsurteilsvermögen, Evaluation, Retrieval-Qualität, Kosten und Zuverlässigkeit, nicht auf Prompt-Tricks oder Framework-Namedropping. Der beste Prädiktor ist eine kurze Arbeitsprobe an einem fehlschlagenden LLM-Feature: Echte LLM-Engineers greifen zuerst zu Evals und Daten, Hobbyisten zu einem größeren Modell.
Die Skills, die wirklich zählen
- Evaluation Engineering: Eval-Sets und Metriken entwerfen, die Regressionen fangen, bevor Nutzer es tun.
- Retrieval und Kontext: Chunking, Indexierung und das Wissen, warum RAG-Antworten schiefgehen.
- Kosten- und Latenzkompetenz: Modellauswahl, Caching und Routing als Engineering-Entscheidungen, nicht als Nachgedanken.
- Failure-Mode-Design: Guardrails, Fallbacks und Graceful Degradation für eine probabilistische Komponente.
- Solides Software-Engineering: LLM-Features leben in echten Systemen; starke Engineers liefern das ganze Feature.
Interviewfragen, die sie offenlegen
- 1„Unser RAG-Feature antwortet selbstbewusst, aber in etwa 10% der Fälle falsch. Führen Sie mich durch Ihre erste Woche.“ Achten Sie auf: erst messen, Retrieval inspizieren, ein Eval-Set bauen, bevor Modelle angefasst werden.
- 2„Woran würden Sie erkennen, dass dieses Feature nach einem Modell-Upgrade schlechter geworden ist?“ Achten Sie auf: Regressions-Evals in der CI, überwachte Qualitätsmetriken, nicht „das würden wir merken“.
- 3„Die Inference-Kosten haben sich mit der Nutzung gerade verdreifacht. Was tun Sie?“ Achten Sie auf: Routing, Caching, kleinere Modelle für einfache Fälle, Messung der Qualitätswirkung jeder Maßnahme.
- 4„Erzählen Sie mir von einem LLM-Feature, das Sie ausgeliefert haben und das gescheitert ist. Was haben Sie geändert?“ Achten Sie auf: Konkretes, Daten und Ehrlichkeit, jeder, der geliefert hat, ist auch schon gescheitert.
Red Flags zum Aussieben
- Portfolio aus Demos und Notebooks, nichts mit echten Nutzern in Produktion betrieben.
- Keine Zahlen: kann nicht sagen, welche Genauigkeit, Kosten oder Latenz frühere Systeme erreicht haben.
- Modell-Maximalismus: Jedes Problem wird mit „nimm das neueste Modell“ beantwortet statt mit Daten und Evals.
- Tut Evaluation als Bremse ab, dieser Engineer liefert Regressionen aus.
- Framework-Namedropping statt einer Erklärung, was das Framework darunter tut.
