Erfahrungen als C# Softwareentwickler

Softwareentwicklung vs "Softwareentwicklung"

Ich habe nun schon einige Jahre Erfahrungen in der Softwareentwicklung gesammelt, 2 Jahre davon unter Java und 7 Jahre unter C#. Ich mag beide Programmiersprachen und arbeite mit beiden gerne. Ich kenne auch die Insiderwitze und weiß auch diese zu schätzen. Ich weiß, dass es viele Softwareentwickler gibt, die Java mögen, aber dafür bei C# einen schlimmen Hautausschlag kriegen oder andersrum. Das sind alles Punkte, über die man lachen kann.

In meinen Jahren in der C# Softwareentwicklung hatte ich in mal in guten und mal in weniger guten Softwareentwicklungsunternehmen gearbeitet und musste dabei auch einmal die leidvolle Erfahrung machen, dass Unternehmen, welche das Wort "Softwareentwicklung" im Unternehmensnamen tragen, nicht unbedingt auch Softwareentwicklung machen. So gehört es eigentlich für mich als selbstverständlich dazu, dass Unternehmen bei der Softwareentwicklung nicht an den falschen Stellen sparen sollten, weil sie dann mitunter sehr unwirtschaftlich sind. Unwirtschaftlichkeit ist gegeben, wenn Softwareentwicklungsunternehmen (also die Unternehmen, die sich so bezeichnen) nicht in die notwendigen Entwicklungswerkzeuge investieren und keinen vorhandenen professionellen Third-Party-Code nutzen und stattdessen seine Softwareentwickler jedes Rad neu erfinden d.h. von Grund auf entwickeln lassen. Dafür sind heute Softwareprodukte einfach zu kurzlebig und werden innerhalb weniger Jahre wieder runderneuert oder fallen ganz weg und werden durch andere Software ersetzt. Third-Party-Code lässt sich heute in der Regel schnell austauschen, eigener Code dagegen nicht. Bei eigenem Code bindet man sich dann dessen Wartung jahrelang als zusätzliche Last mit an das eigene Bein. Natürlich muss man in einige gute Third-Party-Tools Geld investieren, aber das rentiert sich ja später auch wieder, indem man da nicht selbst Zeit reininvestieren muss.

Ausnahmen würde ich nur dort sehen, wo es tatsächlich um die Sicherheit geht, also in der Steuerungssoftware von Flugzeugen, Zügen, Atomkraftwerken, Medizinischen Geräten, selbstfahrenden Transportmitteln oder bei Weltraumflügen. Wenn Third-Party-Code von vielen Leuten eingesetzt wird, kann man sich auch in der Regel darauf verlassen, dass er gewartet wird (und das nicht nur von einem Entwickler, wo die Gefahr besteht, dass dieser irgendwann mal das Unternehmen verlassen wird). Es gibt OWASP-Codeanalyse-Tools, welche automatisiert Sicherheitslücken in bekannten Third-Party-Tools ausfindig machen und dann automatisiert entsprechende Updates empfehlen (danke smarthouse ;-)). Als ein bereits unverzichtbares Entwicklungstool unter C# sehe ich heute unter anderem ReSharper an. Und auch LINQPad, Notepad++, Postman, Fiddler und weitere nützliche Tools. Wer schonmal mit ReSharper gearbeitet hat, wird wissen, warum man danach nicht mehr darauf verzichten sollte, da es die Wirtschaftlichkeit / Produktivität / Softwarequalität enorm verbessert. Und wenn ich von enorm spreche, dann meine ich das auch. Ich wurde vor kurzem gefragt, ob das ein Ablehnungsgrund für mich wäre, in einer Firma zu arbeiten, wenn dort ReSharper nicht eingesetzt wird. Gegenfrage: Was würde wohl ein Bauarbeiter nach einiger Berufserfahrung bei Neuanstellung in einer Baufirma antworten, dass er ab sofort mit billigem Schraubendreher anstelle eines Akkuschraubers massenweise Schrauben irgendwo reindrehen darf, obwohl er weiß, dass es mit einem Akkuschrauber sehr viel schneller und einfacher geht? Ich setze ReSharper auch privat ein, ich habe kein Problem selbst für die Lizenz aufzukommen.

Bewerbungsgespräche und Coding Tests

Je länger ich Erfahrungen als Softwareentwicklerin gesammelt habe, desto weniger mag ich Coding Tests in Bewerbungsgesprächen. Je wahrscheinlicher ein Coding Test im Bewerbungsgespräch, desto wahrscheinlicher auch eine Absage meinerseits. Warum? Bin ich etwa unfähig, zu programmieren? Sowas ließe sich sehr schnell auch mit gut gewählten Programmierfragen und auch in den ersten Tagen der Probezeit herausfinden, dazu gibt es die Probezeit. Die qualifizierten Arbeitszeugnisse meiner vorherigen Arbeitgeber wurden ja nicht als Scherz erstellt, man kann dort nachfragen, ich kann Codebeispiele zeigen, wenn erforderlich. Ich wurde bei den ersten Unternehmen auch nur mit Programmiertest eingestellt. Warum sollte ich also sowas ablehnen wollen, als erfahrere Softwareentwicklerin? Und die Gegenfrage: Reicht meine Berufserfahrung mit Codebeispielen / Referenzen nicht aus? Wenn ich keine Programmierzeile C# beherrschen würde, wie hatte ich es dann zuvor 7 Jahre lang als Softwareentwicklerin in anderen Softwareentwicklungsunternehmen überstanden?

Der Grund, warum solche Coding Tests zunehmend abgelehnt werden, ist vielmehr der, dass erfahrene Softwareentwickler sich mit zunehmenden Programmierkentnissen auch zunehmend unsicherer fühlen, weil man weiß, was alles beim Coding Test schief gehen kann, möglicherweise, weil man bereits in vorigen Coding Tests schlechte Erfahrungen gesammelt hatte. Zudem wird es als Zeitverschwendung angesehen, da nicht alle Softwareentwicklungsunternehmen Coding Tests machen. Ein Coding Test spiegelt nicht die ganze Erfahrung eines Softwareentwicklers wider, sondern ist nur eine Momentaufnahme vom hier und jetzt. Man hat gegebenenfalls wegen der Aufregung einen Blackout, wählt vielleicht versehentlich die falschen Worte, kennt bestimmte Begriffe unter einem anderen Namen, kennt sich mit der fremden Programmierumgebung nicht aus, man fühlt sich ohne IntelliSense-Unterstützung unsicher.

Bei Online Coding Tests gibt es mindestens zwei Kategorien:

Kategorie 1: Coding Tests, wo es um Mensch versus Maschine geht. Man hat hier keine Diskussionsgrundlage, es gibt nur ein Richtig oder Falsch. Die Maschine arbeitet hier i.d.R. einen vordefinierten Fragenkatalog ab. Und wenn die Bewerber-Antwort nicht exakt der von der Maschine erwarteten Antwort entspricht, dann wird das Ergebnis sofort als falsch eingestuft. Das endet sehr oft in einer Absage, egal, was man für Qualifikationen vorweisen kann. Die Maschine berücksichtigt nicht: Code kann man auf vielfältige Art und Weise schreiben, und jede dieser Möglichkeiten kann richtig sein. Ob die vom Bewerber eingegebene Lösung laut Maschine richtig oder falsch ist, wird der Bewerber i.d.R. nicht erfahren, da die Auswertung sofort nach dem Online Test erscheint, wo aber auf die einzelnen Fragen nicht eingegangen wird, sondern nur das Gesamtergebnis erscheint. Was passiert aber, wenn die Maschine nicht alle Möglichkeiten kennt und voreilig eine eigentlich richtige Lösung als falsch einstuft?
Hier hilft nur stures Auswendiglernen auf Internetseiten und aus Büchern wo diese Top 100 Interviewfragen samt Lösungen gelistet sind, was aber dem Unternehmen keinen Aufschluss über die Qualifikation des Bewerbers gibt, sondern vielmehr darüber, wie gut das Gedächtnis vom Bewerber ist. Auch gibt es keinen Aufschluss darüber, ob der Bewerber überhaupt ins Team passt. Solche Tests lassen auch die Vermutung auf Bewerberseite aufkommen, dass der Interviewer selbst keine Ahnung von der Materie hat. Nicht selten stellen solche Tests ein Red Flag dar, denn für den Bewerber kann dies bedeuten, dass er in einen Unternehmen landet, wo Softwareentwicklung nur in der Stellenanzeige vorkommt und vom Unternehmen sonst selbst so nicht gelebt wird. Die wertvolle Zeit kann man sich sparen. Dem Bewerber stellt sich dann die Frage, ob dann auch weitere Fragen zum Lebenslauf über solch einen Online Test beantwortet werden sollen, denn auch hier kann man einen solchen vorgefertigten Fragenkatalog anwenden: „Warum bewerben Sie sich bei uns?“ und „Wo sehen Sie sich in 5 Jahren?“ und „Was sind Ihre Stärken/Schwächen?“. Der Arbeitsvertrag wird dann möglicherweise mit den Worten "Dieses Schreiben wurde maschinell erstellt und ist ohne Unterschrift gültig." unterzeichnet, um es übertrieben darzustellen.

Nehmen wir folgendes Beispiel aus einem realen Online Test: Der folgende Code soll execution-safe umgeschrieben werden:
StreamWriter sw = File.CreateText(@"C:\blabla.txt");
...
sw.Dispose();
Wie mag wohl die richtige Lösung aussehen?
- Variante 1 (hier kann das Dispose() nicht aus Versehen vergessen werden, um das Dispose kümmert sich das using-Statement selber):
using (StreamWriter sw = File.CreateText(@"C:\blabla.txt"))
{
    ...
}
- Variante 2 (man könnte noch ein try-catch drum herum bauen, dann ist es auf jedem Fall execution-safe):
try
{
    using (StreamWriter sw = File.CreateText(@"C:\blabla.txt"))
    {
        ...
    }
}
catch (Exception ex)
{
    ...
}
Wobei hier alle Exceptions abgefangen werden, was eine schlechte Idee ist, aber es tut seinen Zweck. Sicherlich gibt es noch weitere Varianten. Was wird davon aber von der Maschine hinter dem Online Coding Test als richtig gewertet? Richtig wären all diese Varianten. Weiß das die Maschine? Wie gesagt, diskutieren kann man mit ihr nicht. Was ist dort die "richtige" Lösung? Kann diese überhaupt mit dem Freitext und dem "..." richtig umgehen?
Tipp: Nicht von solchen Online Tests unterkriegen lassen. Stattdessen eher die Vorgehensweise des Unternehmens hinterfragen.

Kategorie 2: Dem gegenüber stehen Coding Tests, wo sich ein Interviewer Zeit nimmt und den Coding Test begleitet und wo eine Diskussionsgrundlage geschaffen wird, wo ein Softwareentwickler mit einem Softwareentwickler spricht. Solchen Coding Tests ist nichts entgegen zu setzen und werden eher vom Bewerber akzeptiert. Hier kann der Interviewer, sofern der Bewerber seine Gedankengänge offenlegt, wesentlich besser einschätzen, ob der Bewerber geeignet ist. Daraus entstehen dann Fragen wie: Warum hast Du es so gelöst? Warum denkst Du, dass Deine Lösung die beste ist? Gibt es bessere Alternativen? Möglicherweise ergibt sich ein Lerneffekt auf beiden Seiten. Hier kriegt man auch als Bewerber besser ein Gefühl dafür, mit wem man später zusammenarbeiten wird. Eine Maschine stellt solche weiterführenden Fragen nicht.

Der Hammer war mal ein Coding Test mit Visual Studio Live Share, wo dann Visual Studio 2019 (wir reden von einer aktuellen Visual Studio Version!) nicht mal fähig war, Syntaxfehler wie fehlende Klammer oder fehlendes Semikolon anzuzeigen.

Oder beispielsweise Coding Tests, wo man eine komplette Software (wie z.B. eine Webanwendung mit SQL-Anbindung und Google Maps womit GPS-fähige Geräte getrackt werden können) in einer Woche erstellen sollte und als "Coding Test" kostenlos abliefern sollte. Hier besteht die Gefahr, dass man ausgenutzt wird. Bei der Nachfrage, ob ein kleiner Coding-Test vor Ort bei dem Unternehmen nicht reicht oder ob ich dann wenigstens für eine solch umfangreiche Software entlohnt werde, hatte sich das Unternehmen nicht mehr bei mir gemeldet. Ja, ich wünsche mir auch manchmal Dienstleistungen zum Nulltarif, aber leider wird einem zu heutigen Zeiten nichts geschenkt.

Beliebt war in einem Online Test auch das "Wheat and chessboard problem". Die Fragestellung sah de facto so aus: wie hier dargestellt. Der Softwareentwickler sollte das im Online Coding Test mal kurz in 75 Minuten verstanden und runterprogrammiert haben. Wer das Problem nicht kannte, wird die 75 Minuten brauchen, um die Fragestellung erstmal zu verstehen. Es gab noch ein zweites ähnlich komplexes Problem, welches ebenfalls in 75 Minuten gelöst werden sollte. Insgesamt standen 2,5 Stunden zur Verfügung. Ich frage dann auch mal Google, ob sie das Problem schon kennen und eine Lösung schon fertig haben, die Wahrscheinlichkeit dafür ist recht hoch. Die beiden Probleme wurden dank Google zu 100% korrekt beantwortet, zumindest sagte die Webseite 2x Bestanden an, was bei solchen Fragestellungen doch sehr unreralistisch schien. Ironischerweise wurde nach dem Coding Test die Frage gestellt, wie man die Online Entwicklungsumgebung fand und ob man da Verbesserungspotential sieht. Da fragt man sich, ob es sich tatsächlich um einen Coding Test handelte, oder ob der Bewerber nur ein Testkandidat für die Beta-Release einer Online Entwicklungsumgebung war, denn das Unternehmen hatte sich danach auch nicht mehr gemeldet.
Liebe Unternehmen, das was ihr hier sucht, ist dieser Mann:

Unter dem Video gibt es einen Kommentar: "This inspired me to give up on coding" - geliked von 30+k Leuten.

Es gibt viele Gründe für die Ablehnung eines Coding Tests, die auch im nachfolgenden Artikel in Englisch genannt sind, ich stimme diesem Artikel 100% zu:
- Why You Should Never Consent to a Coding Test in an Interview
Quote: "Being interviewed by someone with a list of precise technical questions is pretty much always red flag, particularly when they don’t wish to prolong discussion on any one point. It often shows that the interviewer may not fully understand what they’re asking and any answer that doesn’t precisely match up with what’s written on their script will be classified as incorrect."

Weitere Links zu dem Thema:
- Why Coding Tests Are A Bad Interview Technique
- Why Some Developers Hate Coding Skills Tests (And What Hiring Managers Can Do To Change That)
- The Tyranny of the Timed Coding Test
- Why I hate code challenges
- Software developers: Coding interviews are a disaster, and here's why
- Why engineers won’t do your coding test
- Why I Don’t Have Time For Your Coding Challenge
- Why Developers Hate Coding Tests?
- Why Code Challenges are Bad Practice for Hiring Senior Developers
- Why Engineers Won't Do Your Coding Test (Englisch/Deutsch)