Programmieraufgaben für Bewerber

Hallo zusammen,

ich bin gerade dabei eine kleine Anforderung zu schreiben, welche Bewerber vor einem Bewerbungsgespräch lösen sollen. Diese Aufgabe würde ich ca. 10 Tage vor dem Gespräch an die Bewerber schicken, und mir die Lösung im Gespräch kurz vorführen lassen. Hintergrund ist, dass ich kein Fan davon bin jemanden im Gespräch etwas entwickeln zu lassen. Macht jemand von euch schon so etwas ähnliches?

Hintergrund zu meinem Arbeitgeber: Wir suchen Java Entwickler für Consulting im Bereich Banking und Versicherungen. Kenntnisse in Spring oder JEE sind vorausgesetzt. Ich würde demnach eher eine Konzeptionsaufgabe stellen wollen als den Entwurf eines Algorithmus. Ich will sehen wie sich jemand in fachliche Aufgaben einarbeiten kann, wie er oder sie eine Software konzipiert, und wo im Design die Prioritäten gesetzt werden. Berücksichtigt werden soll dabei natürlich auch, dass unsere Bewerber berufstätig sein könnten, der Umfang sollte also nicht zu groß sein.

Gerade heraus gefragt: Wie würdet ihr sowas finden, wenn ihr euch bewerbt? Fändet ihr das seltsam, oder gerechtfertigt wenn euch jemand so eine Aufgabe stellt? Ich überlege noch, ob ich das Vorgehen nur für Bewerbungen von Junioren einführe, aber andererseits gab es da auch schon Personen mit viel Berufserfahrung, die nicht so wirklich das geliefert haben was sie versprechen…

Die Gefahr ist zu groß, dass sich jemand dabei helfen lässt. Lieber eine kleine Aufgabe geben und eine halbe oder dreiviertel Stunde allein(!) daran arbeiten lassen.

Hmm, ehrlich? Ich glaube “Hausaufgaben” fände ich jetzt nicht so toll. Und wenn der Arbeitgeber nicht wirklich attraktiv ist, würde ich mich erstmal auf andere Arbeitgeber konzentrieren (und davon gibt’s mehr wie genug)

Vielleicht hilft ja der brainstormartige content auch etwas weiter:
Also wir lassen unsere Bewerber hier immer eine Programmieraufgabe inhouse lösen. Da musste ich allerdings nicht durch, als ich hier ins Team gekommen bin, gab es ein neues Projekt und da ich mit JavaFx schon Erfahrung hatte, hab ich bei der Prototypentwicklung geholfen. Ist vermutlich nicht immer möglich, aber den Bewerber helfen lassen ein reales Problem zu lösen fand ich (aus Bewerbersicht) echt gut. vor allem weil ich was von mir zeigen konnte ohne diese Prüfungsatmoshpere.

Auch interessant fand ich das Vorgehen von 1&1 - hier wurden mehrere entweder-oder-Fragen gestellt ohne eindeutige Antwortmöglichkeiten z.b. “xml oder json?”. Also muss der Bewerber doch irgendwie über beides philosophieren wann er denn jetzt was verwenden würde.

@Landei : Da gebe ich dir teilweise recht. Man kann nicht überprüfen wer es umsetzt, auf der anderen Seite muss er ja dann auch erklären können was er wie gemacht hat. Und wenn er sich auch auf intensives Nachfragen nicht aus der Ruhe bringen lässt, ist er Consulting-Material :smiley: Aber im Ernst, ein valider Punkt.
@Tomate_Salat : Keine schlechte Idee. Der verhältnismäßig kurze Zeitraum macht es halt schwierig wirklich konzeptionelle Aufgaben zu stellen. Da ist etwas in der Richtung Multiple Choice kein schlechter Ansatz!

10 Tage vorher schicken bedeutet aber keine tagelange Arbeit, oder?
das wäre dann ja langsam zu bezahlen :wink:

klingt für komplette Aufgaben auch nicht so doll, was ist denn da üblich?


ist es möglich, Quellcode des gewünschten Bereichs vorzubereiten, Fehler + Bottlenecks eingebaut,
im Gespräch darüber zu fachsimpeln, auftretende Fehlermeldungen usw. vorzugeben und nach Handlungsvorschlägen/ Erweiterungen zu fragen, oder was immer das Ziel ist?

Eine (konzeptuell sehr weit darüber stehende) Alternative ist, den Bewerber einfach nach seinem GitHub-Account zu fragen. Da sieht man ja dann, was er so macht (und wie).

Fand das ehrlich gesagt immer doof.
Ist meine Zeit die dafuer draufgeht bevor ich weiss ob die Firma interessant ist.

IMHO gehoert zu einem guten Bewerbungsgespraech dass die potentielle AG Seite Leute hinschickt, die in der Lage sind gute Fragen zu stellen und Antworten darauf richtigen einzuordnen, wenn jemand etwas verspricht dass er nicht halten kann, muss das bei der Bewerbung aufgedeckt werden, sonst haben die Interviewer keine gute Arbeit geleistet.

Persoenlich hat mir pairing beim Gespraech an einem Real World Problem am besten gefallen, am wenigsten die Aufgabe die Firmen mir zugeschickt haben, hab dann oft kaum Lust gehabt oder gleich etwas gebaut das „viel zu modern war“ bez. der Frameworks oder verwendeten Versionen, so eine Hausaufgabe bzw. die Antwort darauf zu analysieren dauert auch laenger als ein Tag wenn man es ernst meint.
AM schlimmsten war es wenn die Hausaufgabe mehrdeutig formuliert war und keiner Zeit hatte das zu korrigieren bzw. zu erklaeren…

Wenn ich jetzt plötzlich irgendwo an einem fremden Rechner, mit einer fremden IDE und ohne Zugriff auf meine Quellcodes programmieren sollte, käme da bestimmt was deutlich schlechteres heraus und es würde wesentlich länger dauern. Aber das Problem, dass sich Leute helfen lassen könnten, besteht natürlich.

Vielleicht könnte man ja beides machen und vor Ort dann wirklich etwas einfaches, rudimentäres, was aber ausreicht um zu erkennen, ob da jemand blendet mit fremdem Code oder wirklich programmieren kann.

Ich denke, das mit dem „sich helfen lassen“ ist nur bedingt ein Problem. Die Einstellungsentscheidung würde ja nicht auf Basis des Codes getroffen. Bei sowas geht es ja nicht um die Lösung, sondern eher um die Rechtfertigung für die Lösung. In diesem Sinne wäre die Lösung ja nur die Grundlage für eine Diskussion während des Live-Gesprächs: Warum ist das public? Warum ist das ein Interface? Wo sind die Unit-Tests? Warum ist die ‚{‘ nicht in einer neuen Zeile? Und ist C++ nicht eigentlich besser als Java? :smiley:

Der AG/Kunde müsste mich schon sehr ansprechen, damit ich diese Arbeit vor einem eigentlichen Gespräch machen würde.

Aktuell sieht der Stellenmarkt so aus, dass sich der potentielle AG Gedanken machen muss, warum ich gerade zu ihm möchte und nicht umgekehrt. Ich bevorzuge daher lieber gute Interviewer. Gerne auch mit Pair an einem echten Problem, sofern dies sofort fachlich auch begreifbar ist.

Für mich wäre eher interessant: Was halten Sie von TDD? Haben Sie damit Erfahrung? Was macht für Sie einen agilen Entwickler aus? Welche aktuellen Frameworks kennen Sie? Kennen Sie SOLID?

Ich glaube, dass man als guter Interviewer mit diesen Fragen den Bewerber schnell einordnen kann. Wenn dann die soziale Kompetenz erkennbar ist würde ich es vermutlich direkt auf eine Probezeit ankommen lassen.

Was ist denn euer Problem?

In der Medizin/Statistik hat man das bekannte Problem von False Positives und False Negatives. https://en.wikipedia.org/wiki/False_positives_and_false_negatives

Geht es darum aus geeigneten Bewerbern die Besten zu finden oder geht es darum ungeeignete auszusortieren?
Wie soll eine Aufgabe aussehen, damit sie nicht einen hervorragenden Bewerber als ungeeignet aussortiert.
Wie muss eine Aufgabe aussehen, damit sie ungeeignete Bewerber nicht durchkommen lässt.
Welches dieser Probleme wiegt schwerer?

Ich persönlich habe mit den False Negatives ein riesiges Problem. Obwohl als Programmierer sehr brauchbar hab ich einen Lebenslauf der bei jeder Personalabteilung nur der Schluss Vollidiot zulässt.

Github ist eine schöne Sache, keine Frage, aber nicht jedem sein Ding. Es gibt private Projekte, die man aus diversen Gründen nicht auf Github sehen möchte. Seien es IP und NonDisclosures oder moralisch fragwürdige Projekte, die technisch dennoch anspruchsvoll wären.

Wieviel Aufwand soll/darf in eine Aufgabe einfliessen? Angenommen jemand liefert nach einer Stunde eine 90% Lösung, während jemand anders sich mehr “Mühe” macht und nach einem Wochenende eine 92% Lösung liefert. Wie will man das vergleichen?

Wieviele geeignete Bewerbungen treffen den ein? Denn statistisch gesehen braucht es genausoviele Bewerbungen die jeder Bewerber schreiben muss um eine realistische Jobaussicht zu haben. Wenn nun die Unternehmen alle anfangen Aufgaben zu verteilen, dann steigt auch der Aufwand für eine Bewerbung, der wenn sich der Bewerber mühe gibt, sich über das Unternehmen informiert und die Bewerbungen entsprechend zuschneidet eh schon gross ist.
10 Bewerbungen, bedeutet, dass sich ein Bewerber auch durchschnittlich 10 mal Bewerben muss. Bei 2 Stunden Aufwand pro Aufgabe macht dies alleine ein Plus von 20 Stunden für den Bewerbungsprozess. Für Programme die letztendlich in den Müll wandern.

Daher meine ich, dass es das mindeste ist, den Aufwand hierfür auch zu vergüten. Schliesslich geht man ja auch nicht ins Restaurant und lässt sich Proben von verschiedenen Gerichten liefern um dann zu entscheiden was man isst. Bei Softwareentwicklern scheint dies allerdings Standard zu sein ;(.

Erst einmal danke für euer Feedback!

Wir sind eine kleine Firma, von daher haben wir keine Illusion die Besten der Besten zu finden. Von den Bewerbungen die nicht sofort wegen absoluter Mindeststandards abgelehnt werden, erreichen uns in guten Monaten zwei Stück. Uns geht es darum, aus unseren Bewerbern diejenigen zu finden die eigenständig Software entwickeln können. Wenn wir von CV her Zweifel haben laden wir den Bewerber eher ein und stellen dann im Gespräch fest dass es nichts ist, als andersherum. Gerade aber im Beratungsgeschäft kann es passieren, dass wir einen Entwickler alleine in ein Projekt schicken. Da haben wir keine Möglichkeit Junioren zu Coachen oder an die Hand zu nehmen, von daher wäre es unfair jemanden einzustellen, bei dem so etwas nötig wäre.

Das Fragen nach Frameworks machen wir schon, da hatten wir aber mal jemanden drinnen der einfach sehr gut im Auswendiglernen war. JSF, EJB, JSP, Spring, JPA, alles gekannt und die Konzepte gewusst, auch schon mit gearbeitet. Anwenden konnte er dann aber davon nichts. Das Risiko hat man natürlich immer.

Ich nehme mal aus der Grundstimmung mit, dass so eine Voraufgabe problematisch ist, da sie einfach viel Zeit voraussetzt. Dass man das vielleicht als unverschämt empfindet, leuchtet mir ein. Aus Bewerbersicht zu sagen “Sie wollen einen Proof of Work, das finde ich vorab oder auch im Termin nicht gut”, verstehe ich ehrlich gesagt nicht so ganz. Klar haben gute Bewerber die Auswahl aus vielen Stellenangeboten, aber gleichzeitig kann ich nicht jemanden auf Vertrauensbasis einstellen.

Wenn ich mir aber euer Feedback so ansehe, werden wir auch in Zukunft auf die “Voraufgaben” verzichten. Eventuell eine Mischlösung aus “Bring deinen Laptop mit und vervollständige diesen Java Code, damit er xyz macht”, aber da werde ich mich noch einmal mit meinen Kollegen absprechen, wie wir das aufziehen können.

von ‚zeig mal ob du überhaupt Java kannst‘ zu ‚ohne weiteres Kümmern dann alleine Projektarbeit beim Kunden‘ ist in der Tat gewagter Schritt,

wie wäre es, neue Mitarbeiter erstmal bei einem anderen Projekt mit erfahrenen Kollegen ein Jahr mitmachen zu lassen, etwa den Code dabei zu übernehmen,
mehr Zeit für den erfahrenen Mitarbeiter für anderes nebenher,
oder auch komplettes Projekt vom Neuen, nur tatsächlich erfolgende Kontrolle im Hintergrund, Mails & Code checken?

wenn dazu ‚keine Möglichkeit‘, dann ist das eben so, dann aber auch etwas besondere Situation,
es könnte helfen, nur Leute mit bereits ähnlicher Arbeit (in Firmen die sich Einarbeitung leisten können) oder sonstwie klar nachgewiesenen Fachwissen anzustellen,
als Supermarktleiter wird ja auch kein Neuling mit 3 Stunden Test Kisten Stapeln + Buchhaltungsexcel genommen :wink:

wenn alles nichts hilft, dann eben die Aufgaben, als betont ungewöhnlichen Aufwand wegen ungewöhnlicher Job-Konstellation,
aber ich würde mir davon nicht viel versprechen…

Mach(t) das doch wie in den USA!

Benötigt wird ein Alkoholmessgerät:
(und N Aufgaben nach deinem Schwierigkeitsgrad)

4-5 Bewerber werden an einen Tisch gesetzt, nacheinander werden N Aufgaben gestellt, welche 5-30 Minuten benötigen,
der erste(*), der fertig ist, muss ein (Doppelten-)Pinnchen trinken. Schließlich gewinnt der, dessen Alkoholgehalt am höchsten ist.

(*): der/die/das erste, der/die/das fertig ist…

Es gibt ja den Joel Test The Joel Test: 12 Steps to Better Code – Joel on Software
Punkt 11 : Do new candidates write code during their interview?
geht ja in diese Richtung, wenn auch eindeutig bezogen auf während des Interviews. Tatsächlich hatte ich für mich persönlich schon fast die Regel abgeleitet: Wenn jemand mich einstellen würde, ohne, dass ich für denjenigen etwas Code geschrieben habe, dann würde ich nicht dort arbeiten - wer weiß, welche (anderen :slight_smile: ) Flaschen die schon eingestellt haben, nach dem gleichen Prinzip, und vielleicht nur weil einer beim Bewerbungsgespräch eine ganz besonders hübsche Krawatte anhatte.

Als Strategie für die Einstellung von Hiwis hatte ich auch schon vorgeschlagen: „http://www.bundeswettbewerb-informatik.de/, erste Aufgabe, eine Woche Zeit - und los“. Aber es ist schwierig.

Unabhängig davon, welche Aufgabe das ist, oder ob sie vor dem Gespräch eingereicht oder während des Gesprächs bearbeitet wird (da gibt’s ja auch noch Abstufungen: Muss der Bewerber am Präsentations-PC tippen? Oder kriegt er eine Stunde Ruhe und Zeit? Oder passert das am Whiteboard?), geht es ja, wie oben schon erwähnt, NICHT um den Code, der da produziert wird. Natürlich, wenn jemand irgendwo try { ... } catch (IndexOutOfBoundsException e) schreibt, kann das ein Killer sein. Aber etwas repräsentatives, wo man sieht, wie jemand auf SOLID, Clean Code, Testbarkeit, Buildprozess usw. achtet, ist nicht verkehrt, und eine gute Diskussionsgrundlage.

Ganz konkret: Ich durfte neulich für eine „„Bewerbung““ ein „Stein-Schere-Papier“ implementieren. Abgegeben hab’ ich was mit Klassen: Player, Game, Symbol, Rules, usw. Aber in der README.md hatte ich auch die Variante, die aus einer main mit 10 Zeilen code bestand, und der Bemerkung: „The pragmatic solution, for the case that the deadline was yesterday“ :smiley:

Interessant, wie unterschiedliche die Erwartungen sind. Ich würde sagen, wenn ich mit programmieren anfangen müsste, hätte ich ich vorherigen Gespräch schon versagt. Es hängt aber wohl sicherlich davon ab, was man für eine Person vor sich hat. Bei einem Architekten würde ich nicht mit programmieren anfangen. Suche ich einen Junior wäre das aber evtl. eine Option - vielleicht - unter Umständen. :slight_smile:

Ich finde schon, dass man jemanden einstellen kann. Ich glaube kaum, dass man mit einer Programmieraufgabe herausfinden kann, ob diese Person geeignet ist. Es kann so viele Gründe geben, warum mit der Code missfällt: die Person möchte möglichst schnell eine Lösung präsentieren oder einfach: die Person ist aufgeregt. Ein gutes Beispiel ist @Marco13 Beispiel mit dem 10 Zeiler. Man muss nicht unbedingt eine große Architektur aufbauen, um ein kleines (temporäres) Problem zu lösen.

Ich denke, ob eine Person generell in ein Unternehmen passt, kann man mit den richtigen Fragen herausfinden. Ob diese Person auch in der Praxis gut ist, menschlich wirklich passt und die richtigen Social Skills mitbringt ergibt sich bei mir meist erst in der Probezeit.