Die Bezeichnungen Senior Developer, Solution Architect und wie sie alle heißen sollen andeuten, dass es sich um jemanden mit Erfahrung handelt. In dem ein oder anderen Bewerbungsschreiben lese ich dann auch gerne “Experte”. Für mich sind das aber – und ich denke der Leser stimmt mir zu – alles relative Aussagen. Vor allem in Anbetracht der Produkt- und Themenvielfalt in der Programmierung.
Sicherlich kennt (wohlgemerkt: kennt, nicht kann) kein .NET Experte alle Programmiersprachen. Dann brechen wir das weiter runter. Sicherlich kennt kein C# Experte alle .NET Klassen. Ok, dann brechen wir es nochmal weiter runter. Sicherlich kennt kein C# BCL Experte die ganzen Facetten der Klasse String (Anmerkung: Wenn ein Leser dies anzweifelt, dann möge er sich diesen Artikel zu Gemüte führen).
Von daher tue ich mich logischerweise schwer, wenn ich von solchen Jobtiteln lese. Nichtsdestotrotz habe ich eine unsere Stellenausschreibungen genauso tituliert. Damit wollte ich ausdrücken, dass wir nach Kandidaten suchen, die sich schon längere Zeit mit der Materie beschäftigen. Ein wenig präziser schreibe ich: “Mindestens 5-jährige Berufserfahrung”. Erfahrung bedeutet nicht gleich tiefgreifende Kompetenz oder überragendes Know How. Ich hoffe der geneigte Leser stimmt mir zu. Aber für ein ganz grobes Profil und die Vermeidung völlig ungeeigneter Bewerbungen (wenn denn überhaupt so viele da wären…) muss das reichen.
Jetzt stellt sich mir die Frage wie sich ein sagen wir mal ausbaufähiges Fundament feststellen lässt. Krisztina nennt in ihrem Blogbeitrag ‘Are you nerd enough to code with us’ z.B. Clean Code, SOLID, TDD, etc.. Klar ist, dass mit den eigenen Ansprüchen vorsichtig umgegangen werden sollte. 100%ige Profiltreffer oder Kandidaten, die uns stark ähneln, gibt es nicht. Ganz abgesehen davon gingen bei einer homogenen Abteilung die Benefits des Melting Pots verloren. Den Mehrgewinn durch Vielfalt. Was suche ich also? Ich versuche es beispielhaft an der deutschen Sprache festzumachen: Wer unserer Sprache mächtig ist (Grammatik, Rechtschreibung, Umfang), der wäre für mich ein geeigneter Kandidat, wenn es darum ginge unseren schönen badischen Dialekt zu erlernen.
Und dabei setzt nun meine eigentliche Frage an: Woran mache ich es fest, dass jemand besagtes solides Fundament beherrscht. Im übertragenen Sinne die deutsche Sprache. Letzteres ist übrigens genauso schwierig zu prüfen, wie ersteres. Hier ein paar Beispiele, die ich zur Diskussion stelle:
- Ist das Schlüsselwort ‘yield’ bekannt?
- Worauf soll ich achten, wenn ich Programmcode gemäß dem Don’t Repeat Yourself-Prinzip analysiere
- Wozu dient das MVVM Entwurfsmuster im Kontext von WPF
Klar ist, dass die Fragen zum Themenschwerpunkt des Bewerbers passen sollten. Jemand, der bisher nur Backend-Code geschrieben hat, kennt sich verständlicherweise nicht mit WPF und MVVM aus. Nach 5 Jahren Entwicklung sollte aber jeder Entwickler (sogar PHP Developer 
) das DRY-Prinzip kennen.
Was meint ihr? Wie lotet ihr das aus? Habt ihr auch die Situation, bei der ihr denkt: Also die Bewerbung hat überhaupt nicht gepasst? Eione kleine Bitte noch: Fachkräftemangel ist ein Thema für sich. Darum geht es mir in diesem Artikel nicht. Wer sich dafür interessiert, findet dieses Video vielleicht interessant.
Mit Tag(s) versehen: heco, Stellenausschreibung
Uli Armbruster 
Schon eins vorab: ich finde die Anzeige sehr gut, sie vermittelt es ganz klar, dass man keine „Junioren“ sucht. Die Frage ist natürlich, ob die Bewerber das auch lesen wollen, oder ?
Wir hatten früher auch eine Anzeige, wo einfach nur Skills aufgelistet waren. Das hat zu allen möglichen Bewerbungen geführt, die man als eine Checkliste hätte betrachten können.
Zum Beispiel:
– eine lange Liste von Zertifikaten als Beweis für all diese Skills. Im Interview gab es keine unbeantwortete Frage, yield return war kein Problem, aber als es zum Coden kam, wurde FizzBuzz zu einer unlösbaren Aufgabe.
Teamleiter für Jahren, aber das Team bestand meistens aus 1-2 Leuten. yield return war – glaube ich – kein Thema, aber von TDD (bzw. von T) keine Spur.
jemand mit 3 Jahren C#-Erfahrung, der als Azubi Continuous Deployment in seinem Unternehmen eingeführt hat, alles von den neusten C#-Features wusste, aber noch keine echte Erfahrung im Web gesammelt hat. Wir haben ihn eingestellt! Nach eigenen Angaben kam er zu uns wegen dem, was in meinem Blogeintrag steht: weil er ein Macher ist und etwas bewegen will. Ich bin überzeugt, dass bis Januar, wenn er bei uns anfängt, sich längst in die Sache eingelesen hat.
jemand mit 10 Jahren Erfahrung, dessen Bewerbung perfekt war: wie du selbst schreibst, er ist so jemand wie wir! Und dann hat sich beim Coden herausgestellt, dass er nichts von Web wußte, obwohl es in der Bewerbung stand. Wir haben ihn trotzdem ein Angebot gemacht, weil er absolut der richtige ist, der einen Fehler gemacht hat.
Die sind die Leute, die wir wollen aber wie soll man das in eine Anzeige gießen??
Wir haben uns auf ein paar Punkte geeinigt, die nicht verhandelbar sind: das sind Unit Tests, DRY, Dependency Injection, yield return, anonyme Methoden. Letztere sind alle Dinge, die seit Jahren zum Framework gehören und unsere Meinung nach niemand sollte sich Experte nennen, der sie nicht kennt. Der wichtigste Anhaltspunkt ist allerdings das Wissen/die Erfahrung mit Unit Tests geworden: wenn jemand Tests schreibt – egal ob davor oder danach – ist auf jedem Fall jemand, der irgendwann mal mit der Qualität seiner Arbeit unzufrieden war, jemand der sich verbessern will. Und das ist das wichtigste, dass ist das was wir alle auf jedem Fall wollen.
LikeLike
Hey Krisztina, kann ich so genau unterschreiben. Das Problem, dass sich zu viele bewerben und ich mit der Aussortierung zu beschäftigt bin, habe ich nicht einmal. Theoretisch könnte ich das ganz offen lassen, aber naja, frustrierend ein wenig.
Was ich oben gar nicht erwähnt habe, aber eigentlich das Wichtigste ist: Ein IT-ler muss ein Leben lang lernen und sich auch kontinuierlich verbessern wollen. Das sind aber die wenigsten. Und das drückt sich dann eben genau so aus, wie du es auch beschrieben hast. Nach langer Berufserfahrung fehlen gravierende Basics.
Technologien vermeide ich so gut es geht, weil ich denke, dass sich das alles mehr oder weniger schnell lernen lässt. Aber der Persönlichkeitstyp ist wichtig. Der Rest ergibt sich daraus.
LikeLike
http://www.agile-is-limit.de/blog-diskussion-was-ist-denn-bitte-ein-c-experte/
LikeLike
Je mehr unterschiedliche Projekte jemand gemacht hat, desto höher ist die Wahrscheinlichkeit, dass er das geforderte Wissen und die geforderten Fähigkeiten beherrscht. Wer schon lange im Geschäft ist, der hat auch eher mehr Projekte durchgezogen. Technologien werden dann irgendwann nebensächlich. Hier sehe ich den „Senior“ mit Lebenserfahrung und hoher sozialer Kompetenz.
LikeLike
Definitiv. Aber wie auch Krisztina schon geschrieben hat, können Leute schon 10 Jahre entwickeln und einfach nie über den Tellerrand hinaus geschaut haben. Deswegen frage ich aber auch weniger nach Technologien bzw. schreibe diese aus. Mir geht es die Einstellung der Person und die Allgemeinbildung bei der Programmierung.
LikeLike
Komplexes Thema…
Im ersten Ansatz frage ich mich warum manche Unternehmen nicht einfach hinschreiben was Sie möchten. Wenn Sie jemanden suchen der fünf Jahre Erfahrung in unterschiedlichsten Projekten gesammelt hat, dann sollte das da stehen. Fertig.
Wenn Sie jemanden suchen der Aufträge abarbeitet und runterprogrammiert die man ihm in die Hand drückt, dann sollte das ebenfalls dort stehen. Zumindest ist das wohl dass, was unter dem Wörtchen „Macher“ zu verstehen ist, welches ihr diskutiert. Ein Macher tut Dinge statt darüber zu diskutieren, er stellt sie nicht in Frage, er analysiert nicht oder schlägt gar einen anderen Weg vor – er tut was man ihm aufträgt. Klingt nach Klarheit und nach einem Job auf den ich mich bspw. gar nicht mehr bewerben würde.
Wenn jemand gesucht wird, der in seiner Freizeit die Probleme des Tagesgeschäfts lösen soll, dann sollte das dort stehen.
Bei der Stellenausschreibung von Uli und dieser Diskussion geht für mich nicht hervor was für ein Mensch tatsächlich gesucht wird. Ein Entwickler der am Ball bleibt oder über den Tellerrand schaut? Falls ja, warum steht das da nicht? Es gibt Menschen die schauen so weit über den Tellerrand, das sie schon gar nicht mehr über yield und andere technischen Raffinessen nachdenken, weil sie nämlich für den Kundenwert gar nicht wichtig sind…
Krisztina schildert, das sie sich im Team auf bestimmte Basics geeinigt haben: Unit Tests, DRY, Dependency Injection, yield return und anonyme Methoden. Was aber, wenn das laut den Anforderungen gar keinen Sinn macht? Macht Dependency Injection immer und überall Sinn? Sinkt mit anonymen Methoden nicht die Lesbarkeit und Wiederverwendbarkeit des Codes? Ist ab einer bestimmten Anzahl von Vorgaben noch ausreichend Platz für Kreativität? Ist das noch „Keep it simple“? Fragen über Fragen…
Wieso so provokant? Weil es sich um Regeln handelt die Teams zum Status Quo machen und dabei vergessen worauf es bei der Entwicklung von Software ankommt: Kundenwert und die Lösung von Kundenproblemen. Man sucht kreative Problemlöser oder Code Monkeys. Beides geht nicht.
Die Erhöhung der Kompliziertheit die in vielen vielen Teams stattfindet in Kombination mit dem Wunsch nach der eierlegenden Wollmilchsau, also crossfunktionalen Teammitgliedern statt crossfunktionaler Teams, geht für die meisten nicht zufriedenstellend auf. Wie auch, das menschliche Gehirn hat nun mal eine begrenzte Kapazität. Entweder es wird für technische Highlights oder echte Probleme genutzt. Beides geht nur begrenzt.
Zudem wirkt es für mich so, als setzt ihr zum Maßstab, das ein Entwickler x, y und z können muss, weil er/sie sonst kein guter Entwickler zu sein scheint. Ihr startet dort mit einer waghaften These. Mein persönliches Menschenbild: Jeder kann die besagten Aspekte lernen, einsetzen und er wird es tun: wenn er es für die Lösung sinnvoll hält. Sich „besser“ hinzustellen, weil man eine bestimmte technische Raffinesse einsetzt… weiß nicht. Und ja: Ich vermeide ganz bewusst solche Dinge wie anonyme Methoden, weil ich von mir selbst weiß wie schwer es im Tagesgeschäft fällt sie zu verstehen. Geschweigedenn wie es anderen gehen wird, wenn sie nach fünf Jahren auf diesen Code raufblicken.
Bei der Stellenausschreibung von heco fällt mir zudem auf, dass jemand gesucht wird, der für komplexe Geschäftsprozesse Lösungen erarbeiten soll. Er soll entwickeln und zusätzlich die Arbeitsprozesse durch kreative Lösungen und moderne Software Technologien verbessern. Schließlich soll er sich mit der Oberfläche und der Datenzugriffsschicht auskennen und mit der Fachabteilung zusammenarbeiten. Die Qualität der Software soll er ebenfalls garantieren und eine skalierbare Architektur erstellen (Sie stellen sicher, dass unsere Software stabil und effizient arbeitet und zuverlässig skaliert). Die Kombination finde ich spannend.
Aus meiner Sicht sucht ihr einen Oberflächenentwickler, eine Schnittstelle zwischen Fachabteilung und Entwicklung, einen Architekten und jemand der den Überblick über Qualität und den Software-Entwicklungsprozess behält. Diese Person soll sich kontinuierlich über neue Entwicklungen informieren und Verbesserungen vorschlagen.
Vielleicht findet ihr jemanden für den das alles so passt, ja, ich wünsche es euch. Aus meiner Sicht setzt ihr die Messlatte sehr sehr hoch. Die Ausschreibung kann sicher auf zwei bis drei einzelne Ausschreibungen zerlegt werden.
…ganz schön lang geworden :)
Lg
Patrick
LikeLike
Hey Patrick,
kann mich erst in den nächsten Tagen dazu melden. Heute reicht es mir nicht mehr, v.a. da viele Punkte erwähnt wurden.
LikeLike
Hey Patrick, danke für deine Meinung. Ich habe es einfach den Absätzen nach verarbeitet und kommentiert. Meine Meinung geht in großen Teilen in eine andere Richtung:
Macher interpretiere ich ganz anders. Für mich ist das jemand, der nicht nur Ideen hat, sondern diese auch aktiv angeht und umsetzt. Da müsste jetzt Krisztina sagen, was sie darunter versteht.
Dass der von uns gesuchte Entwickler am Ball bleiben und über den Tellerrand schauen soll, steht sehr wohl in der Stellenbeschreibung, jedoch nicht in deinen Worten, sondern eben in unseren. „Wissensdurst und der Wille zur kontinuierlichen Verbesserung“ oder „Sie verfolgen die neuesten technischen Entwicklungen“ sind aus meiner Sicht klar.
Yield und andere technische Raffinessen haben dann einen Kundenwert, wenn sie schneller zu besserem Code führen. Ganz abgesehen davon ist das für mich keine technische Raffinesse oder gar der Tellerrand. Zumindest nicht für einen erfahrenen Entwickler.
Bezüglich Code Monkeys und kreativen Problemlöser, sowie der Vorgabe, dass der Kandidat sich z.B. mit Dependency Injection auskennt, will ich folgendes sagen: Code Monkeys kann man wie ich finde generell nirgends gebrauchen. Weil das würde implizieren, dass überhaupt nicht nachgedacht wird. Das ist jetzt ein Versuch nur in Schwarz und Weiß zu denken. Wenn die Architektur modular aufgebaut ist und das über Dependency Injection realisiert ist, dann macht es natürlich Sinn, dass ein potentieller Kandidat sich damit auskennt. Es steht ja nirgendswo, dass er ausschließlich diesen Ansatz wählen soll. Aber dort, wo es für die Architektur zum Einstecken des Moduls notwendig ist, da muss er das halt. Außerdem auch hier wieder der Verweis, dass es sehr wohl einen Kundenwert hat, wenn sich eine gut skalierbare Architektur daraus ergibt. Welchen Vorteil eine modulare Applikation mitbringt, brauche ich an dieser Stelle denke ich nicht weiter ausführen.
„Entweder es wird für technische Highlights oder echte Probleme genutzt. Beides geht nur begrenzt.“ <- Ähm, ich suche einen Entwickler, der die Probleme der Fachabteilung technisch, nämlich in Form von Code, löst. Wenn er das nicht kann, ist er kein Software-Entwickler.
Ich bin übrigens nicht der Meinung, dass jeder alles erlernen kann. Aber abgesehen davon, ging es in dem Blogbeitrag darum, nachzufragen, was den Maßstäbe sein könnten, um einen guten Entwickler zu beurteilen, eben weil das schwierig ist. Aber es ist nun einmal notwendig, wenn ich davon ausgehe, dass zum einen nicht jeder alles lernen kann, und zum anderen, dass ich nicht erst noch lange Grundlagenforschung mit dem neuen Mitarbeiter durchführen will.
Es steht nicht in der Stelle, dass wir voraussetzen, dass der Entwickler sich mit irgendeiner Technologie (UI, Persistenz) auskennt oder sogar beides können muss. Wenn du genau liest, steht hier „wünschenswert“. Sprich in unserer Stellenausschreibung gibt es keinerlei Beschränkung oder Voraussetzung, was der Kandidat im Detail an Technologien kennen muss. Außer C# versteht sich. Aus Gründen des Platzmangels habe ich nicht geschrieben „in einer oder mehreren der folgenden Auswahl“. Den Kritikpunkt nehme ich mit. Uns ist es egal, ob er sich mit UI oder Backend besonders auskennt, da wir an beiden Stellen jemanden gebrauchen können. Wir werden ihn so einsetzen, wie sein Know How es zulässt. Da wir jedoch mit Scrum arbeiten, wird er – mit entsprechender Unterstützung – ohnehin in alle Bereiche eingearbeitet. Inselwissen ade! Die restlichen Punkte, die du erwähnst, drücken im Prinzip nur 2 Gedanken aus: Wir benötigen jemand, der gleichzeitig betriebswirtschaftliches Denken zur Zusammenarbeit mit der Fachabteilung mitbringt und dabei die technische Expertise, um dieses gewinnbringend umzusetzen. Ein Wirtschaftsinformatiker also.
LikeLike
Ich sehe alles ganz genau so wie du Uli. Für mich ist ein Macher jemand der anpackt.
Was die Team-Vereinbarungen betrifft: es geht um eine Vereinbarung darüber was wir alle von einem Experten erwarten. Niemand muss/soll bei uns anonyme Methoden schreiben, jeder Senior Entwickler soll sie aber kennen. Das selbe gilt für Yield and Co. Es geht nicht um Coding Guidelines, es geht um „Erkennungszeichen“ Es geht einzig und allein darum, dass die Entwickler alleine entscheiden können, ob sie diese Features der Sprache nutzen oder nicht, abhängig von Feature, von Mehrwert.
LikeLike
[…] meinem letzten Blogbeitrag Was ist denn bitte ein C# Experte gab es auf Twitter noch eine Diskussion darüber, ob der Job eines Entwicklers ein 8-17 Uhr Beruf […]
LikeLike
He Uli,
ich mag jetzt nur kurz antworten, weil das insgesamt sicher ein Thema ist, das man mal direkt diskutieren sollte/könnte.
Der wichtigste Punkt:
„Da wir jedoch mit Scrum arbeiten, wird er – mit entsprechender Unterstützung – ohnehin in alle Bereiche eingearbeitet. Inselwissen ade!“
Ganz klar: Scrum trifft hierüber keine Aussage (und das ist gut so). Meine Meinung: Das jeder alles kann ist ein sehr sehr hohes Ziel, vor allem in unserem Bereich in dem noch nicht durchgesickert ist, dass Dinge einfach, verständlich und nachvollziehbar gemacht werden müssen damit jeder es ad hoc verstehen kann kann. So lange die Einarbeitung in eine Tätigkeit vier Stunde dauert und ein Kollege mit mir gemeinsam fünf Minuten braucht, werde ich zu ihm gehen und ihn fragen ob er Zeit hat.
Das jeder alles kann ist ein taffes Ziel und ich finde das auch toll. Bei der Kompliziertheit die wir in der Software-Entwicklung haben oder meist künstlich schaffen, halte ich es inzwischen für ineffizient.
Lg
Patrick
LikeLike
Scrum gibt das imho indirekt vor: Du musst die Issues abarbeiten, die von der Prio her als nächstes dran sind. Wenn das halt ein Issue ist, welches sehr UI lastig ist, dann ist das halt so. Klar wird jeder immer seine Schwerpunkte haben, v.a. weil er sich einfach zu bestimmten Themen mehr weiterbildet, aber sagen wir es mal so: Es wird nicht mehr so sein, dass einer ausfällt oder die Firma verlässt und damit die Entwicklung zum Erliegen bringt.
Ich gebe dir recht, wir müssen das mal bei einem Bierchen in der Runde besprechen. Eine Frage habe ich von dir in jedem Fall mitgenommen: Wie würden Sie die Oberfläche von der Geschäftslogik entkoppeln?
LikeLike
[…] Armbruster hat mich mit seinem Blogartikel “Was ist denn bitte ein C# Experte?” berührt. Vermutlich liegt es daran, dass ich mich schon eine ganze Zeit lang mit dem Thema […]
LikeLike
[…] Was ist denn bitte ein C# Experte? […]
LikeLike