Gutes Vorstellungsgespräch?

[arlegermi]

vor 4 Stunden schrieb monolith:

Nein, das sehe ich anders. [...]

Dann haben wir wohl unterschiedliche Ansprüche an einen Entwickler. Ich erwarte von einem Profi, dass er mir erklären kann, wieso er welches Werkzeug einsetzt. Und wenn mir ein Entwickler nicht sagen kann, welche Gründe es für OO gibt (oder halt FP oder was auch immer für die Stelle relevant ist), dann zeigt mir, dass er kein tieferes Interesse an seinem Beruf hat.

Das muss nicht den Umfang oder die Qualität eines Papers haben, aber eine Vorstellung sollte jeder Entwickler haben - und auch spontan etwas dazu sagen können.

Das ist ja völlig ok - ich möchte nur nicht mit so jemandem arbeiten.

[Gast D-eath]

vor 13 Stunden schrieb arlegermi:

Ich erwarte von einem Profi, dass er mir erklären kann, wieso er welches Werkzeug einsetzt.

Richtig. Vor allem macht einen richtig guten Entwickler auch aus, dass er nicht nur OOP feiert und mit Buzzwords wie in der Java-Welt üblich um sich werfen, sondern auch erklären kann, warum es manchmal nicht angebracht ist. Gerade so etwas zeigt dann, dass man auch verstanden hat, was man da tut.

[monolith]

vor 16 Stunden schrieb Listener:

Als Einstiegsfrage? Man kann erkennen, ob der Bewerber ein Verständnis davon hat, warum etwas eingesetzt wird. Und jetzt mal ehrlich: Das lernt man spätestens in der Berufsschule und eine Antwort darauf zu finden ist relativ banal.

Ist wahrscheinlich eine Typfrage ob man das als angenehme Einstiegsfrage wahrnimmt oder nicht. Mich würde es eher unter Druck setzen, auf Abruf ein so großes Thema in wenigen Worten so zusammenzufassen, dass ein kritischer Nachfrager zufrieden ist.

Zitat

Und jetzt mal ehrlich: Das lernt man spätestens in der Berufsschule und eine Antwort darauf zu finden ist relativ banal.

Irgendeine Antwort... Auch eine überzeugende?  Ich sag's mal so, wir müssen nicht überzeugend darlegen können, warum aus mikrobiologischer Sicht Hände waschen vor dem Essen eine gute Idee ist - wir müssen es einfach nur tun.

[monolith]

vor 14 Stunden schrieb arlegermi:

Dann haben wir wohl unterschiedliche Ansprüche an einen Entwickler. Ich erwarte von einem Profi, dass er mir erklären kann, wieso er welches Werkzeug einsetzt. Und wenn mir ein Entwickler nicht sagen kann, welche Gründe es für OO gibt (oder halt FP oder was auch immer für die Stelle relevant ist), dann zeigt mir, dass er kein tieferes Interesse an seinem Beruf hat.

Sein Beruf ist aber nicht Wissenschaftler, sondern Software-Entwickler. Wenn der JAVA-Entwickler dir nicht gut begründen kann, warum OOP, was macht das für einen Unterschied? In beiden Fällen programmiert er sowieso OOP. 

Zitat

aber eine Vorstellung sollte jeder Entwickler haben - und auch spontan etwas dazu sagen können.

Etwas oder etwas vernünftiges? No offense aber die ganze Zeit über habe ich diese Stimme im Hinterkopf die mir einflüstern will, dass nicht jeder, der hier so überzeugt zu sein scheint genau zu wissen welche Vorteile OOP gegenüber beliebigem anderen Konzept X bietet, dass auch wirklich weiß. Dazu sind hier schon zu viele Warnhinweise zu sehen gewesen, Wörter wie "banal" oder Aussagen wie "muss nicht (...) die Qualität eines Papers haben" fördern jetzt nicht gerade mein Vertrauen in die Qualität der zu erwartenden Antworten. Wird zusätzlich erodiert durch die bereits hier gegebene Beispielantwort "dass man besser die Wirklichkeit darstellen kann".

Bearbeitet 7. Dezember 2018 von monolith

[monolith]

vor 27 Minuten schrieb D-eath:

Richtig. Vor allem macht einen richtig guten Entwickler auch aus, dass er nicht nur OOP feiert und mit Buzzwords wie in der Java-Welt üblich um sich werfen, sondern auch erklären kann, warum es manchmal nicht angebracht ist.

Wann ist es denn für einen Java-Programmierer angebracht, nicht objekt-orientiert zu programmieren?  Es sei denn du willst dich jetzt an so was wie int vs Integer aufhängen.

Bearbeitet 7. Dezember 2018 von monolith

[KeeperOfCoffee]

Ich bin da skeptisch mit dem erläutern usw. Ich kenne Entwickler der sehr verschiedene Ansichten hatten und so lautstark "diskutierten", dass das halbe Haus das mitbekommen hat. Und einen Vortrag zu halten über das theoretisch best anzunehmende Szenario (welches oft mit der Realität nichts zu tun hat) bringt beide Parteien oft auch nicht weiter.

Ein Entwickler der sich bewirbt kennt das Team nicht, kennt interne Prozesse nicht, weiß nicht wie gearbeitet wird (Gibt genügend Fälle von älteren Entwicklern die ihren Stil druchsetzen wollen). Was soll man ohne diese Informationen groß sagen, außer die Standards...

 

Bearbeitet 7. Dezember 2018 von KeeperOfCoffee

[Rienne]

vor 16 Minuten schrieb monolith:

Sein Beruf ist aber nicht Wissenschaftler, sondern Software-Entwickler.

Sorry, aber als FIAE ist man aber nunmal kein Codingäffchen, sondern wird auch ausgebildet eben Entscheidungen treffen zu können, was die Methoden und Werkzeuge angeht. Und dazu gehört nunmal auch, sich mit den verschiedenen Paradigmen auseinandersetzen zu können. Und es ist auch nur nachvollziehbar, dass man dieses Grundwissen nunmal bei einem Bewerbungsgespräch abfragt.
Und ganz davon abgesehen, ist es immernoch die Entscheidung des Arbeitgebers, was der potentielle Arbeitnehmer mitbringen sollte.

vor 16 Minuten schrieb monolith:

Wenn der JAVA-Entwickler dir nicht gut begründen kann, warum OOP, was macht das für einen Unterschied? In beiden Fällen programmiert er sowieso OOP. 

Das mag vielleicht bei Java noch zutreffen, aber wer sagt denn, dass immer nur in Sprache X programmiert wird und in Sprache X auch immer nur das eine Paradigma unterstützt wird?
Mal als Beispiel: Ich bin ABAP-Entwicklerin (SAP). Dort war es lange ganz normal rein funktional zu programmieren, obwohl es schon länger auch dort die Objektorientierung gibt.

Nun wird man mit SAPUI5 und S 4/HANA kaum noch um die Objektorientierung herum kommen. Hinzu kommt, dass man dafür neben ABAP auch noch Java und JavaScript benötigt. Von daher ist es in diesem Bereich zum Beispiel den Arbeitgebern umso wichtiger den Bewerber daraufhin zu prüfen, dass ihm das bewusst ist und er auch bereit (und fähig) ist, sich in diese Thematiken einzuarbeiten.
Das kann mMn bei Java oder .NET oder sonstwo genauso sein.

Bearbeitet 7. Dezember 2018 von Rienne

[monolith]

vor einer Stunde schrieb Rienne:

Sorry, aber als FIAE ist man aber nunmal kein Codingäffchen

Vorab: Mir käme es nicht in den Sinn irgend jemand dazu zu degradieren. Leider bin ich derzeit (noch) genau in so einer Rolle gefangen - kaum Freiheit, nur Code runtertippen nach teils kleinteiligsten Vorgaben. Absolut enervierend.

Aber warum du gerade mit der/dem FIA argumentierst kann ich nicht nachvollziehen. Der/die ist doch davon, OOP mal ernsthaft aus theoretischer Sicht auseinander zu nehmen, wie man das bspw. in einem Studium vielleicht mal macht, eher weit entfernt?! Sondern eben als Ausbildungsberuf eher praktisch orientiert? Ich hätte jetzt eher genau anders herum arumentiert: Gerade von FIA hätte ich dazu jetzt keine tiefergehende Stellungnahme eingefordert. Viel wichtiger wäre mir dass das, was dann als Code im OOP-Stil am Ende produziert wird, den Ansprüchen genügt. Wenn das nach drei Ausbildungsjahren gelingt - super. Wenn Studierende mit Masterabschluss und 5+ Jahren Studium auch noch die Theorie hinter dem Konzept OOP schlüssig erläutern können - umso besser aber eher Bonus, in meinen Augen.

 

vor einer Stunde schrieb Rienne:

JavaScript

Und, programmierst du denn in JS nun seit ES6 mit Klassen? Kannst du mir jetzt aus dem Stehgreif erklären ob nun ES6 bedeutet, dass ich Klassen einzusetzen habe? Und jetzt wird's ja langsam interessant, JS erlaubte mit ES5 objekt-orientierte Programmierung und mit ES6 auch, obwohl es erst seit ES6 Klassen gibt. Könntest du da jetzt aus dem Stehgreif die feinen Unterschiede erklären? Ich würde mich da gerade in einem Bewerbungsgespräch schwer tun.

Ich würde interessehalber sowas vielleicht in einem Bewerbungsgespräch mal ansprechen, aber dann mit einem gewissen Wohlwollen und nicht weil ich da ernsthaft eine geschliffene Antwort vom Bewerber/der Bewerberin erwarte. Weil mich die Ansicht dazu interessiert oder wie damit individuell umgegangen wird. Nicht, weil ich vermeintliches Wissen abprüfen will. 

Bearbeitet 7. Dezember 2018 von monolith

[Griller]

vor 5 Minuten schrieb monolith:

Und, programmierst du denn in JS nun seit ES6 mit Klassen? Kannst du mir jetzt aus dem Stehgreif erklären ob nun ES6 bedeutet, dass ich Klassen einzusetzen habe? Und jetzt wird's ja langsam interessant, JS erlaubte mit ES5 objekt-orientierte Programmierung und mit ES6 auch, obwohl es erst seit ES6 Klassen gibt. Kannst du das jetzt aus dem Stehgreif die feinen Unterschiede erklären? 

Das ist ja wohl komplettes Äpfel mit Birnen vergleichen! Du fragst hier spezifisches zu einer Programmiersprache, wenn in einem Vorstellungsgespräch aber nur mal erörtert werden soll, ob grundlegende Kenntnisse zur OOP vorhanden sind, ist das was ganz anderes. 

Es mag zwar sein, dass du dich auf einer Stelle als Entwickler bewirbst, wenn ich dich aber frage, wie ein Betriebsabrechnungsbogen aufgebaut ist, oder wie man eine Nutzwertanalyse erstellt, erwarte ich das trotzdem von einem ausgebildetem FISI/FIAE, denn das gehört zur Ausbildung. Genau, wie man davon ausgehen sollte, dass "prozedurale und objektorientierte Programmiersprachen unterscheiden" machbar ist, auch das gehört zur Ausbildung*

 

*https://www.frankfurt-main.ihk.de/pdf/berufsbildung/ausbildung/ausbildungsplan/Fachinformatiker_Ausbildungsplan.pdf

[Rienne]

vor 7 Minuten schrieb monolith:

Kannst du mir jetzt aus dem Stehgreif erklären ob nun ES6 bedeutet, dass ich Klassen einzusetzen habe? Und jetzt wird's ja langsam interessant, JS erlaubte mit ES5 objekt-orientierte Programmierung und mit ES6 auch, obwohl es erst seit ES6 Klassen gibt.

Ich denke schon, dass ich das kann. Denn nur weil es Objekte gibt, muss es ja noch lange keine Klassen geben. Und so ist es meines Wissens nach bei ES5 bzw ES6. Ein Objekt in JavaScript war ja erst einmal nichts anderes als eine Variable mit Attributen und Methoden, welche du beliebig ändern und erweitern kannst. Eine Klasse hingegen gibt ja vor, wie so ein Objekt dieser Klasse auszusehen und sich zu verhalten hat.

vor 10 Minuten schrieb monolith:

Der/die ist doch davon, OOP mal ernsthaft aus theoretischer Sicht auseinander zu nehmen, wie man das bspw. in einem Studium vielleicht mal macht, eher weit entfernt?!

Dann hast du keine Ahnung vom FIAE. Das alles gehört mit zu den Inhalten, die ein Anwendungsentwickler lernen muss und die auch immer wieder in den Abschlussprüfungen gefragt werden. Also wir haben das mehr als zu Genüge in der Berufsschule lernen müssen.

[monolith]

Zitat

Das ist ja wohl komplettes Äpfel mit Birnen vergleichen! 

Das habe ich nur als Anknüpfungspunkt genutzt, weil Rienne JS explizit angesprochen hat. Mir ging es jetzt eigentlich nur darum, dass ich bezweifle ob jedem klar ist, dass Objektorientierung nicht zwingend die Nutzung von Klassen voraussetzt. Hier am Beispiel von JS da es angesprochen wurde, aber an sich ja universell gültig.

Zitat

wenn in einem Vorstellungsgespräch aber nur mal erörtert werden soll, ob grundlegende Kenntnisse zur OOP vorhanden sind

Ok, vllt. bin ich jetzt selber von meinem roten Faden abgewichen. Eigentlich ging es mir eher darum, dass mal gefordert wurde, Grundlegende Vorteile von OOP zu erläutern:

Zitat

Dinge wie "warum OO" (...)sind eben Handwerkszeug eines Entwicklers.

Mir ging es eigentlich nur um das "warum", nicht das "wie". Du hast aber recht, davon bin ich jetzt ein stückweit selber abgewichen. Whoopsy...

Zitat

prozedur ale und objektorientierte Programmiersprachen unter scheiden

Das zu unterscheiden ist aber was anderes als grundsätzlich zu begründen, warum OOP eingesetzt werden sollte - was hier auf Seite 1 gefordert wurde. Sorry falls ich dich da jetzt selber in eine andere Richtung gelenkt habe.

Bearbeitet 7. Dezember 2018 von monolith

[monolith]

vor 15 Minuten schrieb Rienne:

Ich denke schon, dass ich das kann

Super! Würdest du jemanden für deinen aktuellen Job nicht einstellen, der/die das in einem Bewerbungsgespräch nicht erwähnt?

vor 15 Minuten schrieb Rienne:

Dann hast du keine Ahnung vom FIAE.

Hab ich auch nicht, habe keine Ausbildung gemacht. Nehme dennoch an, dass das nicht vergleichbar ist, z. B. mit der Vorlesung zu Objektorientierung an der  Uni DuE ( https://www.dawis.wiwi.uni-due.de/studium-lehre/lehrveranstaltungen/wintersemester-1516/kiop-7252/ ). 

Bearbeitet 7. Dezember 2018 von monolith

[KeeperOfCoffee]

Diese ganze Diskussion dreht sich hier langsam darum, was ein FIAE wissen sollte, als was ein FIAE in einem Bewerbungsgespräch, mit den Informationen die er aus der Stellenbeschreibung hat (und evlt. anderer Quellen), mitbringen sollte.

Edit: und ja was man in manchen BS über gewisse Themen lernt ist ein Witz, in jedem Fachbuch bekommt man teilweise mehr Informationen.

Bearbeitet 7. Dezember 2018 von KeeperOfCoffee

[Rienne]

vor 3 Minuten schrieb monolith:

Würdest du jemanden für deinen aktuellen Job nicht einstellen, der/die das in einem Bewerbungsgespräch nicht erwähnt?

Nein, weil ich diese Frage gar nicht erst stellen würde. Wie @Listener schon geschrieben hat, ist das schon eine sehr sehr spezielle Frage und hat erst einmal nichts mit dem grundlegenden Verständnis und Wissen zu tun, das man als Software-Entwickler besitzen sollte.

Ich bin aber zum Beispiel auch kein Fan davon, dass man spezifische Fragen zu Framework X und Y gestellt bekommt, wenn man sich beispielsweise auf eine Juniorstelle als Entwickler bewirbt. Oder eben auch schon x Jahre genau mit dieser Programmiersprache gearbeitet haben. Man sollte eben mMn eher die Fundamentals mitbringen und sich entsprechend schnell in eine neue Thematik einarbeiten können, als vielleicht absoluter Experte in Framework X zu sein, aber dann komplett scheitert, wenn es auf einmal ersetzt werden soll.

vor 4 Minuten schrieb KeeperOfCoffee:

und ja was man in manchen BS über gewisse Themen lernt ist ein Witz, in jedem Fachbuch bekommt man teilweise mehr Informationen.

Ist leider je nach Dozent aber auch an Hochschulen der Fall. Und nur, weil man irgendwie durch ein Modul durchgekommen ist, heißt das auch noch nicht, dass man es auch wirklich verstanden hat.

 

[arlegermi]

vor 1 Stunde schrieb monolith:

Sein Beruf ist aber nicht Wissenschaftler, sondern Software-Entwickler.

Ein Schreiner ist auch kein Statiker. Trotzdem erwarte ich von ihm, dass er mir begründen kann, wieso er die Beine vom Tisch auf diese Weise angebracht hat und nicht auf eine andere. (Jaja, ich weiß - solche Vergleiche sind immer blöd.)

Und so erwarte ich von einem Entwickler auch, dass er mir in Grundzügen erklären kann, welche Vorteile OO gegenüber bspw. prozeduraler Programmierung hat. Dabei möchte ich keine akademische Abhandlung, sondern praktische Erfahrungen und Einschätzungen.

Aber ich glaube, wir schweifen hier zu weit ab. Wir haben eben unterschiedliche Einschätzungen davon, was ein Entwickler heutzutage wissen muss.

[Gast D-eath]

vor 9 Stunden schrieb monolith:

Wann ist es denn für einen Java-Programmierer angebracht, nicht objekt-orientiert zu programmieren?  Es sei denn du willst dich jetzt an so was wie int vs Integer aufhängen.

Gar nicht. Ein Programmierer (!) muss aber wissen, wann es angebracht ist, OOP anzuwenden und wann nicht. Das ist genauso wichtig zu wissen, wie eine Antwort auf die Frage zu haben, ob man nun Vererbung oder Komposition anwendet oder ob gegebenenfalls auch Fallunterscheidungen ausreichend sind und so weiter. Das sind Punkte, die wiederum Kenntnisse über Laufzeitverhalten, Performance, polymorphes Verhalten, Wissen über Code-Design verlangen und hier zeigt sich dann, ob man sein Werkzeug auch beherrscht. Du würdest dich wundern, wie viele Menschen unfassbar viel Geld verdienen und wie wenige davon nicht mal die essentiellen Kenntnisse über Computer besitzen, um zu erklären, wie ihre tagtäglichen Werkzeuge wie eben Polymorphie überhaupt funktionieren. Muss man ja auch nicht haben. Schadet aber auch nicht, vor allem, wenn man sich in leitenden Positionen befindet oder wie einige Bewerbungsgesprächspartner offensichtlich etwas überheblich sind.
Du kannst simple Probleme auch ohne ProblemSolvingStrategyFactory und so einen Quatsch lösen. Genau das meine ich. Das richtige Werkzeug für den richtigen Einsatzzweck. Kleine Anekdote aus meiner Berufslaufbahn: einer meiner "Chefs" hat sich mal so in seinem simplen Crawling-Tool mit Java in verkünstelt, dass um den eigentlichen Code, der nicht von ihm selbst geschrieben wurde, der eben die Hauptaufgabe durchgeführt hatte, Daten aus dem Internet zu laden und zu deserialisieren, um damit weiter zu arbeiten, ein Haufen Boilerplate und Design-Pattern wie Chain of Responsibility und so weiter programmiert wurde. Am Schluss kannte sich niemand mehr aus, fertig wurde es auch nicht und leider musste man damit aber irgendwie Geld verdienen. Die simple Lösung, geschrieben in Go war übrigens ebenfalls concurrency-fähig, innerhalb weniger Tage fertig und erheblich schneller. Wichtig war dem damaligen Chef nur, sich mit seinem tollen "Design" auszutoben, wie halt auf dem Spielplatz. Von jemandem, der sich Chef nennt, erwarte ich halt beispielsweise auch entsprechend, dass er rational mit seinen Ressourcen wirtschaftet und nicht Kindergarten spielt, weil er Generalisierung so toll findet. So was landet dann nur bei anderen Mitarbeitern, die Stress haben und verkaufen kann man solche Lösungen auch eher schlecht, weil niemanden interessiert, ob das Ganze in Java oder Go geschrieben wurde und niemand die Preise dafür bezahlt, nur um die hohen Kosten zu decken, die durch den Spieltrieb von Entwicklern ohne ernsthaften Problemlösungsdrang entstanden sind.
Darum ja: von einem guten Entwickler darf man erwarten, dass er weiß, wann was angebracht ist. Achja, Dependency Injection lief natürlich auch mittels Spring Boot.

[maestro impostor]

vor einer Stunde schrieb D-eath:

Achja, Dependency Injection

Dependency Injection is a 25-dollar term for a 5-cent concept.

Ich musste Dependency Injection erklären. Also das Prinzip dahinter. 

Leider war der Gesprächspartner nicht mit meiner Antwort zufrieden da ich nicht Unity bzw. AutoFac erwähnt habe. Was meiner Meinung nach DI Frameworks sind und nicht „Dependency Injection“. Na ja