Follow Up: Tipps zur Beurteilung der Qualität eines Developers

Wir haben den Vorteil, mit einem Pool von mehr als 750 Fachkräften im Bereich Software-Entwicklung zusammen zu arbeiten und können im Einstellungsverfahren jederzeit auf die Expertise unserer Freelancer zurückgreifen. Da dies aber natürlich nicht immer der Fall ist, gibt Emile jetzt noch ein paar nützliche Tipps dazu, wie man die Qualität eines Developers, auch als Nicht-Developer, am besten beurteilen kann.

Gerade für Personen, die sich nicht so gut in dem Bereich auskennen, ist es wichtig zu lernen die Warnzeichen zu erkennen. Wir wollten also von Emile wissen, was die sogenannten “Red Flags” und “Green Flags” sind.

Ich habe selbst nicht wirklich viel Ahnung von Coding und Software-Entwicklung, auf was muss ich im Interview mit einem Developer achten?

Das ist wirklich schwierig, weil du ja dann überhaupt nicht einschätzen kannst, auf welchem Level sich der Developer befindet und ob der Code fehlerfrei ist. Wenn es irgendwie möglich ist, würde ich dazu raten, einen erfahrenen Developer mit ins Interview zu holen, der die Coding Kenntnisse des Kandidaten testen soll. Freunde, Bekannte oder ehemalige Kollegen können dir dabei vielleicht weiterhelfen. Wenn du wirklich komplett auf dich alleine gestellt bist, würde ich dazu raten zwischen den Zeilen zu lesen, und mich sehr auf das Verhalten und die Ausdrucksweise konzentrieren. Eine gute Frage ist zum Beispiel: „Mit welchen Bereichen bist du deiner Meinung nach noch nicht zu 100% vertraut?“ Diese Art von Selbsteinschätzung hilft dir dabei gewisse Qualitäten zu erkennen. Auch gut ist die Frage: „Wie möchtest du dich weiterentwickeln und noch verbessern?“ Wenn der Kandidat zum Beispiel antwortet, dass er alles weiß und es keine Lücken gibt, ist das ein sehr schlechtes Zeichen. Auch wenn die Person um die Frage herum redet und keine wirkliche Antwort gibt, ist das überhaupt nicht gut. Es zeigt, dass sie zum einen zu arrogant ist und sich zum anderen auch nicht präzise ausdrücken kann. Gute Kommunikation, nicht nur über Coding und Software, sondern auch bei allgemeinen Themen, ist unglaublich wichtig.

Und wie kann ich gute Zeichen erkennen?

Jemand, der ein gutes Verständnis von Software-Entwicklung hat, würde auf die Frage, mit was er noch nicht so vertraut ist, eher etwas sagen wie: „Es ist gerade etwas Neues auf den Markt gekommen, das ich mir genauer ansehen wollte“ oder „Ich bin gerade noch dabei dies und das neu zu lernen“. Es gibt Millionen von neuen Features, Tools und Lernmöglichkeiten in Software-Entwicklung und ein gewisses Interesse daran, was neu herauskommt sowie dann die Neugier, sich das genauer anzusehen, ist ein sehr gutes Zeichen.

Eine weitere gute Frage ist „Arbeitest du gerade an einem Nebenprojekt?“ Wir sind der Meinung, dass ein Developer, der mit voller Leidenschaft Developer ist, den Job nicht aus finanziellen Gründen macht. Ein richtig guter Developer versucht sich stets weiterzuentwickeln, geht auf Konferenzen und zu Meet-ups oder hat Projekte mit Freunden nebenbei laufen. Diese Leidenschaft und Freude an der Arbeit selbst ist ebenfalls ein sehr gutes Zeichen für gute Qualität.

Ansonsten kann ich auch nur empfehlen, einen Blick in GitHub zu werfen. Die meisten Developer mit genug Erfahrung sind auf GitHub registriert, wo all ihre Projekte in sogenannten Repositories - eine Art Verzeichnis - zu finden sind. Bei GitHub kann ein Developer Sterne und Follower sammeln und bei beidem lautet die Devise, je mehr desto besser! Denn man kann keine Sterne kaufen oder die Anzahl der Follower beeinflussen. Beides bekommt man nur durch außerordentlich gute Arbeit an Software-Projekten. Auch jemand, der selbst keine Coding Kenntnisse hat, kann an den GitHub Repositories sehen, auf welchem Level sich ein Developer in etwa befindet.

Zusammenfassend kann man also sagen:

Red Flags

• Arroganz
• Scheinbare Perfektion
• Kein Interesse / Kenntnis an aktuellen Geschehnissen in der eigenen Branche

Green Flags

• Mehrere Jahre Erfahrung (je mehr Erfahrung, desto besser)
• Neugier
• Ehrlichkeit, wenn es um Wissenslücken geht
• Lernerfolge aus vergangenen Projekten

Es passiert den Besten: Man stellt einen Developer ein und nach ein paar Wochen muss man feststellen, dass die Zusammenarbeit leider nicht funktioniert. Ein Interview ist schließlich nur eine Momentaufnahme einer Person und manchmal kann es sein, dass es sich trotz intensiver Screenings und einem aufwendigen Einstellungsverfahren im Laufe der Zeit herauskristallisiert, es passt einfach nicht.

Einer der Vorteile davon mit Freelancern zusammen zu arbeiten, ist, dass man die Zusammenarbeit ebenso schnell beenden kann, wie man sie begonnen hat. Das klingt vielleicht erst einmal etwas hart, doch wie Emile in seinem Interview zum Einstellungsverfahren eines Developers erklärt hat, muss das Gesamtpaket stimmen. Wenn du herausfinden möchtest, wie CodeControl mit Problemen zwischen Klienten und Freelancern umgeht, dann lies dir unseren Insights Artikel zu dem Thema durch.

Am besten ist aber natürlich, es gar nicht erst soweit kommen zu lassen. Wie lässt sich das vermeiden? Laut Emile hilft es die Erwartungen, den Umfang und das Anspruch Level des Projektes klar zu definieren:

Emile, was würdest du sagen, ist der häufigste Grund, dass die Zusammenarbeit zwischen Klient und Developer scheitert?

Ich würde sagen, meistens liegt es an falschen Erwartungen. Wenn Klienten mit einem bestimmten Produkt zu uns kommen, wie einer App oder Website, dann suchen wir den passenden Developer für dieses Projekt. Doch manchmal ändern Klienten nach ein paar Wochen ihre Meinung, möchten mehr, weniger oder etwas ganz anderes, was am Anfang nicht besprochen wurde. Wenn das mehrmals vorkommt, kann es sein, dass ein Developer nicht mehr an dem Projekt arbeiten möchte. Als Developer braucht man eine gewisse Struktur und der Workflow kann sich nicht ständig ändern.

Ein weiterer Grund ist die Herausforderung. Ein Developer entscheidet sich meistens dazu, freelance zu arbeiten, weil er eine Herausforderung möchte und sich nicht um die konstante Pflege eines einzigen Produktes kümmern will. Wenn sich nach einer gewissen Zeit an einem Projekt herausstellt, dass der Lernprozess und die Herausforderung nicht groß genug sind, kann es sein, dass der Developer vom Projekt abspringt.

Selbst wenn man die Erwartungen und Ansprüche des Projektes im Voraus gut definiert, kann es manchmal zu Problemen kommen. Um diese so gering wie möglich zu halten, könnte man zunächst mit einem kleinen Testprojekt starten. Wenn man die Qualität des Developers im Interview nicht richtig einschätzen konnte, oder aus irgendeinem anderen Grund unsicher ist, ob die Zusammenarbeit funktionieren wird, bieten sich kleinere Testprojekte hervorragend an genau das herauszufinden. Die Testphase kann ein paar Tage oder ein paar Wochen laufen, je nachdem welches Mini-Projekt gerade zur Verfügung steht. In dieser Phase kann man Feedback von Mitarbeitern sammeln, die mit dem neuen Developer zusammenarbeiten und auch einen bereits bestehenden Developer des Unternehmens bitten, mal ein Auge auf den Neuankömmling zu werfen. Wenn die Zusammenarbeitet scheitert, habt ihr nicht allzu viel Zeit verschwendet und sollte es gut laufen, könnt ihr den Developer für größere Projekte anheuern.

Wenn du dir die ganze Mühe eines Einstellungsverfahrens sparen möchtest und das Risiko verringern willst, die falsche Person einzustellen, dann komm einfach zu CodeControl. Der Vorteil ist unser großer Pool an den besten und unterschiedlichsten Talenten. Für uns ist es kein Kriterium jemanden einzustellen, nur weil er vor Ort ist. Wir suchen die besten Talente weltweit, denn die heutigen Technologien machen es sehr leicht, remote zu arbeiten. Nach jedem Projekt, bekommen wir Feedback von beiden Seiten und dank diesem fortlaufenden Feedback-Prozess und der Reichweite unseres Pools können wir immer den perfekten Match finden. Außerdem bieten wir auch allgemeine HR Assessments an, um dich bei deiner Herangehensweise von Anfang an zu unterstützen. Mehr dazu findest du im Insights Artikel mit Emile.