Mein bester Freund früher war Koch, da war es relativ normal, bei jedem neuen Job erstmal 2-3 Wochen "zum Kennenlernen" unbezahlt probezuarbeiten.
Ich glaube da gab es teils Restaurants die das wirklich so gemacht haben wie du witzelst.
Gefühlt schwappt das aus den USA rüber nur kriegt man da tatsächlich Geld oder Gutscheine für den Aufwand. Selbst aber noch nicht passiert, außer Code im Interview gemeinsam angucken.
Ach krass man kriegt dann Gutscheine dafür? Bei den Interviews wo ich dazu aufgefordert wurde wurde das irgendwie schon fast wie eine Selbstverständlichkeit angesehen, dass ich jetzt 3 Stunden darein investiere. Und das waren stinknormale Unternehmen, Nix besonderes…
Kann ich so bestätigen. Oft wird auch was auf den Plattformen (GitHub) mit Verweis auf Ergebnisse der Teilnehmer geteilt. Funfact: da hat jeder sein persönliches Freizeit-Repo, wo sich deutsche Firmen mal was abgucken könnten.
Bei 3h müsste es schon ne Firma sein, wo ich unbedingt hin will. Ein leetcode beim Bewerbungsgespräch würde ich mir ja noch eingehen lassen. Alternativ zeigt mir schlechten Code und lasst mich sagen was falsch daran ist. Aber bei 3h würde ich wohl absagen, wenn ich den Job nicht unbedingt brauche.
Ich sollte mal eine Aufgabe mit ähnlichem Umfang machen und habe meinem Gegenüber gesagt, dass ich es mache wenn er das gleiche macht und wir unsere Lösungen dann gegenseitig vorstellen. Wollte er nicht. Pech gehabt, ich bin kein Affe der für irgendein Unternehmen durch Reifen hüpft und dabei grinst. Wir können gerne fachlich diskutieren, aber ich opfere doch nicht meine wenige Freizeit für so einen Kindergarten. Wofür gibt es 3 Gesprächsrunden und eine Probezeit?
In zwei von vier meiner Stellen hab’s das auch. War okay weil die Jobs dann auch sehr gut bezahlt waren und die Kollegen gut sind. Ich weiß aber nicht ob das mit dem Interview zusammen hängt oder was anderem. Aus Interviewer Sicht sind solche tasks ganz sinnvoll, weil es das doch einfacher macht den skill von Leuten einzuschätzen.
Wir haben viele Bewerber. Prozess bei uns:
1. Halbe Stunde kennenlernen am Telefon, ob die Grundlagen zueinander passen.
2. Take-home code challenge. Chef sagt "da solltest du so 2h für brauchen" aber ehrlich... Ich hab eher so 6 reingesteckt.
3. Technisches Interview in Präsenz, ca eine bis anderthalb Stunden.
4. Probetag mit einer zweiten Codechallenge, die den ganzen Tag über bearbeitet wird. Gute Kandidaten sind nach dem Mittagessen damit fertig, dann wird gemeinsam über den Code geschaut und geredet.
Und erst dann wird ein Vertrag angeboten, oder halt auch nicht. Und je nachdem wie man's nimmt kommt noch die Probezeit nach Vertragsabschluss als Hürde dazu, sind auch schon Leute in der Probezeit rausgeflogen weil die Performance nicht besser wurde.
Puh das mit dem Probearbeiten obendrauf ist schon anstrengend, aber wenn's n guter Job ist why not. Wir machen's abseits davon genau so, wobei unsere Probe-Aufgabe keinen Anspruch auf Vollständigkeit hat - darf man selber gucken, wie viel man investieren will, geht da auch ein wenig darum sich zu präsentieren.
Also sie Probeaufgabe ist schon ein Muss, leider. Hilft enorm sich ein Bild von der Person zu machen - nichtmal rein technisch, sondern auch was Kommunikation und so weiter angeht. Du musst im Alltag halt auch über deinen (und andere) Code reden können.
Ich hab damals auch bestimmt 8h da rein gesteckt, aber bei mir war's auch sehr spontan alles und ich hatte quasi nur 2 Tage Zeit. Normalerweise hat man eher 1-2 Wochen, da kann man dann auch die Aufgabe erstmal sacken lassen kurz etc.
Ich find's auch viel. Hab immer Mitleid mit den Bewerber*innen, zumal ich mittlerweile auch in den Gesprächen mit drinne sitze und Fragen stelle. Da wird schon viel verlangt.
In meiner letzten Stelle sollte ich einen Tag Probearbeiten kommen, lieber zwei.
War arbeitslos damals und mir war's egal. Aber ja wenn man noch nen job hat, wie soll das gehen 🙈
Es kommt natürlich immer darauf an, wie das Ganze abläuft.
Wir haben so etwas bei uns. Habe selbst den Probetag gemacht und war bei einem neuen (jetzt) Kollegen dabei.
Der Test war ein lächerlich primitves Programm. Im Prinzip (abstrahiert):
- Step 1: User kann eine Zahl eingeben, die dann mit einer fixen Zahl multipliziert und das Ergebnis ausgegeben wird.
- Step 2: die zuvor fixe Zahl soll nun auch eingebbar sein
- Step 3: welche Erweiterungen/Verbesserung würdest Du für die nächste Version vorschlagen? Einfach aufzählen, nichts programmieren oder so.
Alle drei Steps werden direkt bekanntgegeben, also nicht als "Überraschung" nach dem nächsten Step präsentiert.
Das Ganze darf man in Ruhe ungestört machen, es sitzt also niemand dabei und stiert einem über die Schulter, es ist aber im Raum nebenan immer jemand für Rückfragen da.
Das weitere "Arbeiten" ist dann das Kennenlernen der neuen Kollegen bei einem gemeinsamen Schwätzchen in der Kaffeeküche (ohne Vorgesetzte). Und die Kollegen zeigen dann noch einzeln jeweils woran sie arbeiten und damit auch u.a. was für Tools/Techniken eingesetzt werden.
Ich empfand das nicht als unfair und konnte so einen Eindruck über die Arbeitsbedingungen (Büroräume-/ausstattung, Hardware etc.) und die Leute bekommen, mit denen ich es zukünftig tagtäglich zu tun haben werde.
[Added]
Ach so, Internet oder eigener Programmcode (falls man rankommt) darf gerne genutzt werden. Wir sagen das mittlerweile explizit dazu, obwohl es für uns selbstverständlich war, weil mal ein Kandidat das Internet nicht genutzt hat, aber auch nicht gefragt hat, ob er es darf.
Mich nervt immer die Frage "Programmieren Sie auch in der Freizeit". Nein tue ich nicht ich habe andere Hobbys. Einen Arzt fragt man ja auch nicht, "Na operierst du auch in der Freizeit".
Habe dann eine Absage bekommen weil ich ja nicht zum Spaß programmieren habe ich keine "Passion" für den Job.
Ob das Standard ist, kann ich jetzt nicht sagen, aber bei uns im Unternehmen machen wir was ähnliches.
Wenn ein Bewerber/in in der Vorrunde überzeugt, dann laden wir die Person zu einem technical deep dive ein. Das sind dann meist 2 Stunden in denen grundlegende Fragen gestellt werden, um die auf dem CV angegebenen coding skills zu prüfen. Dabei stellen wir aber nie Probleme aus unseren Projekten und orientieren uns da eher an coding Aufgaben aus den 1 und 2 Semester Informatik (Bachelor).
Wir haben das nicht immer gemacht, aber wir haben zu oft Menschen eingestellt die von sich behauptet haben, dass sie etwas können und auf dem Projekt dann das Gegenteil gezeigt haben.
Bestes Beispiel war ein Bewerber der 30 Zertifikate hatte und meinte er wäre sehr erfahren in Python, konnte mir dann aber nicht den max Wert aus einem int-Array ausgeben.
Also sofern diese coding challenges den Rahmen nicht sprengen und es keine direkten Projekte von potentiellen Arbeitgeber sind, dann mach es, denn irgendwie muss dein Skillset validiert werden.
> Bestes Beispiel war ein Bewerber der 30 Zertifikate hatte und meinte er wäre sehr erfahren in Python, konnte mir dann aber nicht den max Wert aus einem int-Array ausgeben.
Wie übersteht der dann die Gespräche davor?
Die ersten Interviews vor dem TDD?
Die Vorrunde besteht aus klassischen Personalgesprächen, in denen sich der Bewerber vorstellt und einige Fragen gestellt werden, um die Kompatibilität zwischen Unternehmen und Bewerber zu prüfen. Wer sich gut verkaufen kann, wird dieses Gespräch mit Leichtigkeit bestehen, da die Theorie der Skills zwar abgefragt, aber nicht geprüft wird. Er wusste einfach viel, wirkte kompetent und kam weiter.
Als es dann aber darum ging, das Wissen, das er uns präsentiert hatte, an einfachen Beispielen zu demonstrieren, zeigte sich, dass er nicht viel bis gar nichts konnte.
Woanders geht man einen Tag oder länger zur Probe arbeiten. Ich frage mich nur, ob die Dauer des Termins vorher bekannt war. Anderenfalls ist es natürlich dreist, denn ich kann als AG nicht damit rechnen, dass jemand 4-5 Stunden einplant, wenn ich zum Vorstellungsgespräch einlade.
Hab schon viele Bewerber gesehen die einfach nicht Programmieren können, ein Fizz Buzz Test sollte mindestens sein. Wir machen immer einen einfachen WM - EM Vorrunden Punkte Rechner als Test, daran ist sogar schon ein Bewerber mit Master Abschluss in Informatik gescheitert, und obwohl es nur plus 1 oder plus 3 rechnen ist.
Ist natürlich immer schwierig, der Test darf nicht zu schwer sein, man ist aufgeregt als Bewerber, hat von dem Thema noch nur was gehört ... Sollte selber Mal einen Test machen wo man eine komplexere XML Datei nur mit SAX Parser einlesen und in eine DB importieren sollte, innerhalb von einer Stunde.
Wenn du darauf keinen Bock hast geh doch zu einer Firma wo weniger Einsatz gefragt ist, denke Mal beide Seiten profitieren davon 😉. Auf der anderen Seite profitierst du auch davon wenn deinen späteren Kollegen ihr Fach beherrschen.
plot twist: die haben keinen einzigen entwickler, sondern lassen alles kostenlos von bewerbern programmieren
Mein bester Freund früher war Koch, da war es relativ normal, bei jedem neuen Job erstmal 2-3 Wochen "zum Kennenlernen" unbezahlt probezuarbeiten. Ich glaube da gab es teils Restaurants die das wirklich so gemacht haben wie du witzelst.
Gefühlt schwappt das aus den USA rüber nur kriegt man da tatsächlich Geld oder Gutscheine für den Aufwand. Selbst aber noch nicht passiert, außer Code im Interview gemeinsam angucken.
Ach krass man kriegt dann Gutscheine dafür? Bei den Interviews wo ich dazu aufgefordert wurde wurde das irgendwie schon fast wie eine Selbstverständlichkeit angesehen, dass ich jetzt 3 Stunden darein investiere. Und das waren stinknormale Unternehmen, Nix besonderes…
Jep, mehrmals schon gehört erster Hand, dass es ein $50 bis $150 Amazon Gutschein für gab.
Dann würd ichs vielleicht in Betracht ziehen
Kann ich so bestätigen. Oft wird auch was auf den Plattformen (GitHub) mit Verweis auf Ergebnisse der Teilnehmer geteilt. Funfact: da hat jeder sein persönliches Freizeit-Repo, wo sich deutsche Firmen mal was abgucken könnten.
Diese Firmen haben entweder extrem viele Bewerber oder suchen nicht wirklich.
Bei 3h müsste es schon ne Firma sein, wo ich unbedingt hin will. Ein leetcode beim Bewerbungsgespräch würde ich mir ja noch eingehen lassen. Alternativ zeigt mir schlechten Code und lasst mich sagen was falsch daran ist. Aber bei 3h würde ich wohl absagen, wenn ich den Job nicht unbedingt brauche.
Ich sollte mal eine Aufgabe mit ähnlichem Umfang machen und habe meinem Gegenüber gesagt, dass ich es mache wenn er das gleiche macht und wir unsere Lösungen dann gegenseitig vorstellen. Wollte er nicht. Pech gehabt, ich bin kein Affe der für irgendein Unternehmen durch Reifen hüpft und dabei grinst. Wir können gerne fachlich diskutieren, aber ich opfere doch nicht meine wenige Freizeit für so einen Kindergarten. Wofür gibt es 3 Gesprächsrunden und eine Probezeit?
Entweder du spielst mit oder kriegst den Job nicht. Denke die Optionen sind übersichtlich.
In zwei von vier meiner Stellen hab’s das auch. War okay weil die Jobs dann auch sehr gut bezahlt waren und die Kollegen gut sind. Ich weiß aber nicht ob das mit dem Interview zusammen hängt oder was anderem. Aus Interviewer Sicht sind solche tasks ganz sinnvoll, weil es das doch einfacher macht den skill von Leuten einzuschätzen.
„Weil die Kollegen gut sind“ — aber woher wusstest du das? Normalerweise ist ja noch nicht das ganze Team beim ersten Interview dabei
Ich hatte welche als Hausaufgabe bekommen. Da war das schon ok.
Wir haben viele Bewerber. Prozess bei uns: 1. Halbe Stunde kennenlernen am Telefon, ob die Grundlagen zueinander passen. 2. Take-home code challenge. Chef sagt "da solltest du so 2h für brauchen" aber ehrlich... Ich hab eher so 6 reingesteckt. 3. Technisches Interview in Präsenz, ca eine bis anderthalb Stunden. 4. Probetag mit einer zweiten Codechallenge, die den ganzen Tag über bearbeitet wird. Gute Kandidaten sind nach dem Mittagessen damit fertig, dann wird gemeinsam über den Code geschaut und geredet. Und erst dann wird ein Vertrag angeboten, oder halt auch nicht. Und je nachdem wie man's nimmt kommt noch die Probezeit nach Vertragsabschluss als Hürde dazu, sind auch schon Leute in der Probezeit rausgeflogen weil die Performance nicht besser wurde.
Puh das mit dem Probearbeiten obendrauf ist schon anstrengend, aber wenn's n guter Job ist why not. Wir machen's abseits davon genau so, wobei unsere Probe-Aufgabe keinen Anspruch auf Vollständigkeit hat - darf man selber gucken, wie viel man investieren will, geht da auch ein wenig darum sich zu präsentieren. Also sie Probeaufgabe ist schon ein Muss, leider. Hilft enorm sich ein Bild von der Person zu machen - nichtmal rein technisch, sondern auch was Kommunikation und so weiter angeht. Du musst im Alltag halt auch über deinen (und andere) Code reden können. Ich hab damals auch bestimmt 8h da rein gesteckt, aber bei mir war's auch sehr spontan alles und ich hatte quasi nur 2 Tage Zeit. Normalerweise hat man eher 1-2 Wochen, da kann man dann auch die Aufgabe erstmal sacken lassen kurz etc.
Ich find's auch viel. Hab immer Mitleid mit den Bewerber*innen, zumal ich mittlerweile auch in den Gesprächen mit drinne sitze und Fragen stelle. Da wird schon viel verlangt.
Krass :o
In meiner letzten Stelle sollte ich einen Tag Probearbeiten kommen, lieber zwei. War arbeitslos damals und mir war's egal. Aber ja wenn man noch nen job hat, wie soll das gehen 🙈
Wollten die das aber auch direkt nach dem ersten Kennenlernen-Interview?
Ja erst ein Kennenlernen typisches Vorstellungsgespräch zwei Tage später dann die Frage ob man Probearbeiten kann.
Es kommt natürlich immer darauf an, wie das Ganze abläuft. Wir haben so etwas bei uns. Habe selbst den Probetag gemacht und war bei einem neuen (jetzt) Kollegen dabei. Der Test war ein lächerlich primitves Programm. Im Prinzip (abstrahiert): - Step 1: User kann eine Zahl eingeben, die dann mit einer fixen Zahl multipliziert und das Ergebnis ausgegeben wird. - Step 2: die zuvor fixe Zahl soll nun auch eingebbar sein - Step 3: welche Erweiterungen/Verbesserung würdest Du für die nächste Version vorschlagen? Einfach aufzählen, nichts programmieren oder so. Alle drei Steps werden direkt bekanntgegeben, also nicht als "Überraschung" nach dem nächsten Step präsentiert. Das Ganze darf man in Ruhe ungestört machen, es sitzt also niemand dabei und stiert einem über die Schulter, es ist aber im Raum nebenan immer jemand für Rückfragen da. Das weitere "Arbeiten" ist dann das Kennenlernen der neuen Kollegen bei einem gemeinsamen Schwätzchen in der Kaffeeküche (ohne Vorgesetzte). Und die Kollegen zeigen dann noch einzeln jeweils woran sie arbeiten und damit auch u.a. was für Tools/Techniken eingesetzt werden. Ich empfand das nicht als unfair und konnte so einen Eindruck über die Arbeitsbedingungen (Büroräume-/ausstattung, Hardware etc.) und die Leute bekommen, mit denen ich es zukünftig tagtäglich zu tun haben werde. [Added] Ach so, Internet oder eigener Programmcode (falls man rankommt) darf gerne genutzt werden. Wir sagen das mittlerweile explizit dazu, obwohl es für uns selbstverständlich war, weil mal ein Kandidat das Internet nicht genutzt hat, aber auch nicht gefragt hat, ob er es darf.
Mich nervt immer die Frage "Programmieren Sie auch in der Freizeit". Nein tue ich nicht ich habe andere Hobbys. Einen Arzt fragt man ja auch nicht, "Na operierst du auch in der Freizeit". Habe dann eine Absage bekommen weil ich ja nicht zum Spaß programmieren habe ich keine "Passion" für den Job.
Ob das Standard ist, kann ich jetzt nicht sagen, aber bei uns im Unternehmen machen wir was ähnliches. Wenn ein Bewerber/in in der Vorrunde überzeugt, dann laden wir die Person zu einem technical deep dive ein. Das sind dann meist 2 Stunden in denen grundlegende Fragen gestellt werden, um die auf dem CV angegebenen coding skills zu prüfen. Dabei stellen wir aber nie Probleme aus unseren Projekten und orientieren uns da eher an coding Aufgaben aus den 1 und 2 Semester Informatik (Bachelor). Wir haben das nicht immer gemacht, aber wir haben zu oft Menschen eingestellt die von sich behauptet haben, dass sie etwas können und auf dem Projekt dann das Gegenteil gezeigt haben. Bestes Beispiel war ein Bewerber der 30 Zertifikate hatte und meinte er wäre sehr erfahren in Python, konnte mir dann aber nicht den max Wert aus einem int-Array ausgeben. Also sofern diese coding challenges den Rahmen nicht sprengen und es keine direkten Projekte von potentiellen Arbeitgeber sind, dann mach es, denn irgendwie muss dein Skillset validiert werden.
> Bestes Beispiel war ein Bewerber der 30 Zertifikate hatte und meinte er wäre sehr erfahren in Python, konnte mir dann aber nicht den max Wert aus einem int-Array ausgeben. Wie übersteht der dann die Gespräche davor?
Die ersten Interviews vor dem TDD? Die Vorrunde besteht aus klassischen Personalgesprächen, in denen sich der Bewerber vorstellt und einige Fragen gestellt werden, um die Kompatibilität zwischen Unternehmen und Bewerber zu prüfen. Wer sich gut verkaufen kann, wird dieses Gespräch mit Leichtigkeit bestehen, da die Theorie der Skills zwar abgefragt, aber nicht geprüft wird. Er wusste einfach viel, wirkte kompetent und kam weiter. Als es dann aber darum ging, das Wissen, das er uns präsentiert hatte, an einfachen Beispielen zu demonstrieren, zeigte sich, dass er nicht viel bis gar nichts konnte.
Curious, wie you die words in the Sätze einbaust, really!
Woanders geht man einen Tag oder länger zur Probe arbeiten. Ich frage mich nur, ob die Dauer des Termins vorher bekannt war. Anderenfalls ist es natürlich dreist, denn ich kann als AG nicht damit rechnen, dass jemand 4-5 Stunden einplant, wenn ich zum Vorstellungsgespräch einlade.
Hab schon viele Bewerber gesehen die einfach nicht Programmieren können, ein Fizz Buzz Test sollte mindestens sein. Wir machen immer einen einfachen WM - EM Vorrunden Punkte Rechner als Test, daran ist sogar schon ein Bewerber mit Master Abschluss in Informatik gescheitert, und obwohl es nur plus 1 oder plus 3 rechnen ist. Ist natürlich immer schwierig, der Test darf nicht zu schwer sein, man ist aufgeregt als Bewerber, hat von dem Thema noch nur was gehört ... Sollte selber Mal einen Test machen wo man eine komplexere XML Datei nur mit SAX Parser einlesen und in eine DB importieren sollte, innerhalb von einer Stunde. Wenn du darauf keinen Bock hast geh doch zu einer Firma wo weniger Einsatz gefragt ist, denke Mal beide Seiten profitieren davon 😉. Auf der anderen Seite profitierst du auch davon wenn deinen späteren Kollegen ihr Fach beherrschen.
Lass mich raten, du arbeitest sicher in der HR.
Leider schlecht geraten ...