C++ Test bei Vorstellungsgespräch
-
http://stackoverflow.com/questions/tagged/interview-questions
Btw. meine Lieblingsfragen: Was passiert beim Aufruf virtueller Methoden im Konstruktor? Und: Koennen pure virtual Memberfunktionen eine Implementation besitzen?
Bei einem richtigen Bewerber halte ich sowas für geschmackslos
Bullshit. In einer Bewerbung kann ich diesbezueglich alles hineinschreiben ohne zu luegen. Also ist ein rudimentaerer Test im Bewerbungsgespraech nur sinnvoll.
-
knivil schrieb:
Bei einem richtigen Bewerber halte ich sowas für geschmackslos
Bullshit. In einer Bewerbung kann ich diesbezueglich alles hineinschreiben ohne zu luegen. Also ist ein rudimentaerer Test im Bewerbungsgespraech nur sinnvoll.
Hineinschreiben ja. Aber bei einem normalen Gespräch kann man auch schnell erkennen, ob der Mann weiß, wovon er redet, da braucht man keinen "Test".
-
knivil schrieb:
Btw. meine Lieblingsfragen: Was passiert beim Aufruf virtueller Methoden im Konstruktor? Und: Koennen pure virtual Memberfunktionen eine Implementation besitzen?
löl, too easy.
Aber netter Link.
-
knivil schrieb:
Btw. meine Lieblingsfragen: Was passiert beim Aufruf virtueller Methoden im Konstruktor?
-
Bashar schrieb:
knivil schrieb:
Btw. meine Lieblingsfragen: Was passiert beim Aufruf virtueller Methoden im Konstruktor?
Edit: Solche Fragen haben in einem Vorstellungsgespräch imho wenig zu suchen. Ein Gespräch ist nützlicher als Faktenwissen abzufragen. Insbesondere, da ein guter Entwickler vielleicht gerade auf dem Schlauch steht und umgekehrt den Interviewer ganz leicht mit Gegenfragen in Verlegenheit bringen könnte.
-
µ schrieb:
Solche Fragen haben in einem Vorstellungsgespräch imho wenig zu suchen. Ein Gespräch ist nützlicher als Faktenwissen abzufragen.
So kenne ich das auch.
Einmal habe ich aber einen unangekündigten Test erlebt: Da kam dann der CTO of the Company mit wichtigem Geschau an und hat mich mit Detailfragen zur irgendwelcher Software gelöchert und wollte von mir wissen, wie irgendwelche Experimentalaufbauten in den 60er Jahren GENAU ausgesehen haben. Außerdem wolle er mir nicht glauben, wie die Rollreibung aussieht.
Also haben wir uns ein wenig rumgestritten, bis ich schließlich nachgegeben hab (es war immerhin ein Bewerbungsgespräch); ich war einigermaßen gefrustet.
Als sich direkt an diesen Test die Gehaltsverhandlungen angeschlossen haben, habe ich allerdings verstanden, was diese (IMHO: unprofessionelle) Aktion sollte ...
-
Ich würde dir auf jeden Fall raten, dir mal folgende Präsentation zu Gemüte zu führen:
http://www.slideshare.net/olvemaudal/deep-cHab da auch noch einiges lernen können, als ich die vor ner Weile gelesen habe
1A Slideshow : wie viele Sachen ich nicht wusste.
Kommt wohl davon dass ich im Beruf auf Java herabgestiegen bin...in den ersten 100 Folien habe ich mir trotzdem ein funny End gewünscht, wie,... der Typ wird eingestellt einfach weil er ein Mann ist
-
Aber bei einem normalen Gespräch kann man auch schnell erkennen, ob der Mann weiß, wovon er redet, da braucht man keinen "Test".
Er muss nicht schriftlich sein, es muss nicht gross Test draufstehen. Normalerweise sind Tests in einem Gespraech verpackt. Und diese Tests bestehen nicht aus wahllosen Fragen sondern aus solchen Sachen, was die Firma macht. Fragen a la "How Would You Move Mount Fuji" finde ich auch beknackt. FizzBuzz ist da schon besser, wobei fuer OO eher ungeeignet.
Und wenn man den Job haben moechte, ist eine gute Vorbereitung notwendig. Fuer meinen aktuellen Job hat das Bewerbungsgespraech 3 h gedauert mit jeweisl 2 Pausen a 10 min.
Virtuelle Funktionen: Ja, ich habs nachgeschlagen. Mein Fehler. Fehler sind erlaubt, einer sollte auch nicht ueber den Ausgang entscheiden. Perfejkt ist natuerlich besser, aber wer ist das schon. Natuerlich fuehre ich keine Personalgespraeche, will ich auch gar nicht.
-
---
-
Ein Gespräch ist nützlicher als Faktenwissen abzufragen.
Aber bei einem normalen Gespräch kann man auch schnell erkennen, ob der Mann weiß, wovon er redet, da braucht man keinen "Test".
Ne serioese Firma wird auch eher Gespräche führen .... wenn sie denn die Zeit für haben.
"Tests" macht man doch eher für nen Vorausscheid, wenn man aus zigtausend schon mal ne vorauswahl treffen will ...Wobei ich mir dann die Frage stelle, welche Firma hat heutzutage den Luxus, sich aus zig Kandidaten den richtigen auszuwehlen
Also im Programmierumfeld ...Ciao ...
-
C++ Einstieg schrieb:
Hat von euch jemand schon mal so einen Test gehabt?
Ja.
Aber war allergruseligstes C. Von der Schwierigkeit her nicht schlimmer, als festzustellen, ob ein nullterminierter String ein Palindrom ist.
-
Soll ja nur dafür sorgen, die besonders guten Schaumschläger und Hochstapler rauszukicken.
-
Ich sehe in solchen Tests durchaus einen Sinn. Das perfekte Wissen ist eher uninteressant. Bei einem gut vorbereiteten Test soll und darf der Bewerber mehr als nur schon vorhandenes Wissen zeigen: verstehe ich worum es geht, bin ich lernbereit, passe ich in die Firma.
-
Grundsätzlich werden in unserer Firma tatsächlich (einfache) Programmieraufgaben gestellt (Wobei die Sprache selbst eher nebensächlich ist, es geht mehr um ein paar theoretische Fragen). Ich selbst habe mich über die Aufgaben eher gewundert, kamen sie doch recht simpel daher, sie führten aber wohl in der Vergangenheit schon zu einer Aussortierung.
Anschließend habe ich meinen jetzigen Chef mit einer kurz zusammengestellten Minianwendung, die ich auf der Zugfahrt geschrieben hatte "überfahren". Wobei es schon vorher klar war, ich hatte im Telefonat einige neuere C++ Themen abgefragt, und die ihm unbekannten verwendet, um sie vorzustellen. Dies hat mir auch eine gewisse Narrenfreiheit (z.B. das Einbringen von STL und Boost) gegeben...
Ich halte so etwas in einem Vorstellungsgespräch auch nicht für verkehrt, zumindest wenn man wirklich die groben logischen Fähigkeiten eines Bewerbers für den Bereich der Programmierung abschätzen will. Nützt gerade in kleinen Firmen weitaus mehr als (wie in der vorherigen Firma) die Frage nach ein paar Begriffen und Techniken, die aber tatsächlich in der Firma keine Relevanz hatten (Wie so ziemlich alle anderen im Stellenangebot erwähnten Punkte).
-
Also, der Test war nicht schwierig, typisches C++ Zeugs halt, Referenzen, Polymorphismus, STL, einfache Mathematik, paar Fragen zum Aufbau der STL Container mitsamt Zugriffszeiten - allerdings auch hier nur simple Dinge (z.B. Einfügen am Ende einer Liste, Zugriff auf Element x einer Liste,... ), und so weiter...
Diente wohl nur um zu sehen ob man zumindest die Grundlagen der Programmierung (nicht nur auf C++ bezogen) geschnallt hat.
Diese Art von Tests kann ich durchaus befürworten, sie tut dem Bewerber nicht weh, ganz im Gegenteil, man kann zeigen was man kann.
-
Ich hab son Test auch mal bekommen - der Codeausschnitt war gruselig. Als ich gefragt worden bin was ich aus dem Code erkenne hab ich mich unbeliebt gemacht á la "da hat jemand vor Jahren versucht..." Ein Header mit 120 Zeilen C mit Klassen. In dem Fall hab ich im Vorstellungsgespräch schon einige Designprobleme, Speicherlecks, veraltete #includes und 118 Zeilen Code sparen können:
#include <list> typedef std::list<int> IntegerList;Später hat sich rausgestellt, dass der Code noch für doubles und short kopiert worden war...
In einem anderen Vorstellungsgespräch sollte ich einen Code auf einen Zettel schreiben, der für eine vorgegebene Zahl N rausfindet, obs eine Primzahl ist. Dass ich außer 2 nur ungerade Zahlen als mögliche Teiler überprüft hab und auch noch bei sqrt(N) die Schleife abgebrochen hab war dem schon zu viel Feintuning.
Mein Eindruck (aus einem zugegebenermaßen sehr kleinen Erfahrungsschatz) ist, dass man solche "Tests" nicht zu fürchten braucht, wenn man ein paar Grundlagen beherrscht. Sowas kann andersrum auch für den Bewerber gut sein, um zu sehen mit was für einer Codebase er zu tun bekommt, wenn er den Job nimmt.
-
pumuckl schrieb:
Als ich gefragt worden bin was ich aus dem Code erkenne hab ich mich unbeliebt gemacht á la "da hat jemand vor Jahren versucht..." Ein Header mit 120 Zeilen C mit Klassen. In dem Fall hab ich im Vorstellungsgespräch schon einige Designprobleme, Speicherlecks, veraltete #includes und 118 Zeilen Code sparen können:
#include <list> typedef std::list<int> IntegerList;Später hat sich rausgestellt, dass der Code noch für doubles und short kopiert worden war...
Und wie gings dann weiter? Haben sie dich wegen Unbeliebt-machens nicht genommen, oder hast du wegen offenbar steinzeitlicher Standards abgelehnt?
-
Bashar schrieb:
Und wie gings dann weiter? Haben sie dich wegen Unbeliebt-machens nicht genommen, oder hast du wegen offenbar steinzeitlicher Standards abgelehnt?
Ich hab anderswo ein besseres Angebot bekommen und angenommen. Steinzeit-Standards hätten mich zu der Zeit nicht abgeschreckt, dazu war ich zu sehr Idealist - ich hätte schon einen Weg gefunden, um den Code zu verbessern, an dem ich vorbei komme
Zumindest versuche ich das auch heute noch...
-
pumuckl schrieb:
Steinzeit-Standards hätten mich zu der Zeit nicht abgeschreckt, dazu war ich zu sehr Idealist - ich hätte schon einen Weg gefunden, um den Code zu verbessern, an dem ich vorbei komme
Hm. Da hör ich hier jedesmal tausend Ausreden, warum ich das nicht darf
Naja Thema für einen anderen Thread.
-
Ist der TE mittlerweile eigentlich durchgefallen?
