|
|
|
|
Hat hier jemand schon mal das DllPlugin von webpack genutzt?
Die Anwendungen die ich beim Suchen gefunden habe sind schon aussagekräftiger als die webpack Doku, aber so richtig hat's mit keiner Lösung geklappt.
Anwendungsfall wäre keine Importe in den bestehenden Source Files ändern zu müssen (meinetwegen mit alias, für 20 - 30 packages geht das schon klar). Aber es will nicht hinhauen. Wenn ich die Importe manuell einfüge bekomme ich es zwar compiled, aber die Anwendung im Browser kann danach trotzdem nichts richtig auflösen.
|
|
|
|
|
|
|
In einem meiner ersten Bewerbungsgespräche überhaupt musste ich mal LiveCoding mitmachen, direkt beim ersten Vorstellungsgespräch. Gab nen PC mit IDE, kein Internet, und ein Mitarbeitet saß mit im Raum, damit ich nicht das Handy benutze. Lölchen. Beim Fraunhofer no less. Die Aufgabe war aber eigentlich easy und es ging wohl eher darum ob ich lösungsorientiert rangehen kann. Funktionierender Code wäre sicher nen fetter Bonus gewesen, leider konnte ich die File to String Anweisungen nicht mal eben aus dem Kopf abrufen.
Bei einem anderen Bewerbungsgespräch damals war LiveCoding für die zweite Interviewrunde angesagt. O-Ton: "dann stellen wir uns einen Fernseher und paar Bier hin und gucken dir zu" - also mit Kollegen über den Studi abrofln. Glücklicherweise wurde ich gar nicht erst zur zweiten Runde eingeladen - hätte ich eher von mir aus abgesagt als mich da zum Clown zu machen.
Das war beides 2014. Bin ich dann eben kein Programmierer geworden.
|
|
|
|
|
|
|
Geil, ohne Internet coden. Schonmal für den Krieg üben.
|
|
|
|
|
|
|
Von Stackoverflow kopieren - 0¤
Das Richtige von Stackoverflow kopieren - 80k/Jahr
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von statixx am 04.03.2022 9:18]
|
|
|
|
|
|
|
|
|
|
Ich sollte mal eine SQL-Abfrage per Microsoft-Teams-Bildschirmübernahme basteln. Leider hatte ich Linux und konnte den Bildschirm nicht übernehmen. Dann habe ich einfach was aus dem Kopf runtergeschrieben und sollte den Code rüberschicken. Hat natürlich auch nicht auf Anhieb funktioniert.
|
|
|
|
|
|
|
Wir haben das in der letzten Runde auch mal gemacht, aber für ein sehr übersichtliches Devops-Problem. Alle Hilfen/Internet frei verfügbar, laut Denken erwünscht. Ging eher darum herauszufinden, wie jemand an ein Problem rangeht und ob er Doku lesen kann. Im Endeffekt eine Zeile in der Pipeline korrigieren und 3 Terraform-Resourcen in einem bestehenden Projekt anlegen.
Im 2. Teil (eher Kür) dann eine Hello-World Flask-Anwendung so erweitern, dass statt staischem dynamischer Content aus einem Bucket angezeigt wird.
Selbst das war ein erstaunlich harter Filter für Kandidaten, die nach eigener Angabe seit über 5 Jahren Kubernetes und Terraform benutzen und ausgefeilte Module entwickelt haben.
|
|
|
|
|
|
|
| Zitat von poppxapank
ohne Internet coden
| |
Hab ich nie gelernt, geht das?
|
|
|
|
|
|
|
Bei uns gehört eine Coding-Aufgabe zum Einstellungsprozess dazu. Allerdings lassen wir dem Kandidaten die freie Wahl der Sprache und des Toolings (gerne auf der eigenen Dev-Maschine die er mitbringen darf). Es gibt auch keine Einschränkungen was Libs, Package-Manager, StackOverflow oder $Whatever angeht. Schließlich hocke ich auch nicht in einem airgaped bunker und schreibe Assembler Code für Waschmaschinen.
Und wir wollen schon auch sehen, wie der Kandidat scheitert. Wie er nochmal seinen Code durchiteriert. Verbessert. Abändert. Gerne auch von Anfang an ein paar Unit-Tests dazu packen, wenn man fit ist im Ökosystem, etc. pp.
Aber für all das nehmen sich bei uns aber auch ich und ein weiterer GeFü i.d.R. einen ganzen Tag Zeit um dem Bewerber auf den Zahn zu fühlen. Aber auch um ihm zu zeigen, wie wir hier arbeiten und was wir erwarten bzw. was er dafür von uns bekommt.
Bonuspunkte gibts direkt wenn das erste Komando git init ist.
Meine Lieblings Aufgabe ist übrigens von Codwars geklaut: The Supermarket Queue.
Was wir definitiv nicht wollen: Unter druck irgendwas abliefern. Der Kandidat soll zeigen das er kann, wofür er sich bewirbt. Und das er möglichst den kompletten Werkzeugkasten nutzt. Dazu gehören eben auch Fehlermeldung des compilers/interpreters zu verstehen und schnell in korrekturen umzusetzen. Niemand erwartet das man keine Fehler macht. (Außer komische business kasper aus der HR-Abteilung die Bewerber als Excel-Zeilen abbilden. Aber sowas haben wir in unserer 20Mann klitsche aus gutem Grund nicht )
|
|
|
|
|
|
|
Mir würde es schon ausreichen das unsere Bewerber (selbst) produzierten code mitschicken würden.
Ein Link zu einem gitHub account ist da schon die Seltenheit, in der Regel eine Bulletlist mit Programmiersprachen und Frameworks die man mal durchgecrollt ist...
|
|
|
|
|
|
|
| Zitat von statixx
Von Stackoverflow kopieren - 0¤
Das Richtige von Stackoverflow kopieren - 80k/Jahr
| |
|
|
|
|
|
|
|
| Zitat von X-Tender
Mir würde es schon ausreichen das unsere Bewerber (selbst) produzierten code mitschicken würden.
Ein Link zu einem gitHub account ist da schon die Seltenheit, in der Regel eine Bulletlist mit Programmiersprachen und Frameworks die man mal durchgecrollt ist...
| |
Wir fragen eigene öffentliche Projekt und OpenSource contributions ganz konkret an. Man darf sich aber auch gerne etwas abseits von Coding mit OpenSource/OpenKnowledge beschäftigen (OpenStreetMap, Wikipedia, und was es da alles gibt an $CroudSourcingInitiativen).
Das einzige was wir definitv nicht wollen: Leute die nur stumpfe Befehlsempfänger sind und ihren 9-to-5 Job absitzen möchten. Als Softwareentwickler muss man unserer Meinung nach hungrig sein, neugierig, der Wille zur ständigen Weiterentwicklung muss da sein.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von GH@NDI am 04.03.2022 11:47]
|
|
|
|
|
|
| Zitat von GH@NDI
Bei uns gehört eine Coding-Aufgabe zum Einstellungsprozess dazu. Allerdings lassen wir dem Kandidaten die freie Wahl der Sprache und des Toolings (gerne auf der eigenen Dev-Maschine die er mitbringen darf). Es gibt auch keine Einschränkungen was Libs, Package-Manager, StackOverflow oder $Whatever angeht. Schließlich hocke ich auch nicht in einem airgaped bunker und schreibe Assembler Code für Waschmaschinen.
Und wir wollen schon auch sehen, wie der Kandidat scheitert. Wie er nochmal seinen Code durchiteriert. Verbessert. Abändert. Gerne auch von Anfang an ein paar Unit-Tests dazu packen, wenn man fit ist im Ökosystem, etc. pp.
Aber für all das nehmen sich bei uns aber auch ich und ein weiterer GeFü i.d.R. einen ganzen Tag Zeit um dem Bewerber auf den Zahn zu fühlen. Aber auch um ihm zu zeigen, wie wir hier arbeiten und was wir erwarten bzw. was er dafür von uns bekommt.
Bonuspunkte gibts direkt wenn das erste Komando git init ist.
Meine Lieblings Aufgabe ist übrigens von Codwars geklaut: The Supermarket Queue.
Was wir definitiv nicht wollen: Unter druck irgendwas abliefern. Der Kandidat soll zeigen das er kann, wofür er sich bewirbt. Und das er möglichst den kompletten Werkzeugkasten nutzt. Dazu gehören eben auch Fehlermeldung des compilers/interpreters zu verstehen und schnell in korrekturen umzusetzen. Niemand erwartet das man keine Fehler macht. (Außer komische business kasper aus der HR-Abteilung die Bewerber als Excel-Zeilen abbilden. Aber sowas haben wir in unserer 20Mann klitsche aus gutem Grund nicht )
| |
Und wann macht ihr das alles? Beim "Probearbeiten"?
|
|
|
|
|
|
|
In was für seltsamen Unternehmen arbeitet ihr bitte.
|
|
|
|
|
|
|
| Zitat von Ameisenfutter
Und wann macht ihr das alles? Beim "Probearbeiten"?
| |
Im wesentlichen nennen wir das Kennenlern-Tag. Da stellen wir unser Büro vor, einige von den anderen Leuten die da rumschlürfen, promoten die kostenlosen Drinks und dann setzen wir uns den rest des Tages im Konferenzraum zusammen.
Wer auf uns einen guten Eindruck gemacht hat (menschlich wie fachlich) bekommt danach den Vertrag.
Jetzt muss man aber auch sagen: Bei uns kommt das 2-3 mal im Jahr vor. Wir haben natürlich keine Recruiting-Abteilung die irgendwie 100 Stellen im Jahr besetzen muss und sich durch tausende Bewerbungen filtert.
Aber eben genau weil wir so klein sind, können wir uns diese "bad apples" einfach nicht leisten. Leider eine Erfahrung aus den 10 Jahren in denen wir existieren.
|
|
|
|
|
|
|
| Zitat von SkunkyVillage
In was für seltsamen Unternehmen arbeitet ihr bitte.
| |
Wundere ich mich manchmal auch, wenn man hier so liest wie scheinbar bei vollkommenem Unwissen die Kariereleiter nach oben gefallen wird
Berufsehre anyone?
|
|
|
|
|
|
|
Ich hab nächsten Freitag zum ersten Mal seit 12 Jahren ein Telefongespräch mit einer neuen Firma...
Erstmal nur kennen lernen. Wurde durch einen Recruiter angeleiert.
Ich hätte nichts dagegen, mal etwas neues zu machen. Aber es fühlt sich auch komisch an.
|
|
|
|
|
|
|
Ich arbeite in einer deutschen Außenstelle eines Silicon-Valley-Konzerns und die Interviews sind bei uns sehr amerikanisch. Also 5-6 verschiedene Sitzungen (heutzutage natürlich alles Remote, früher vor Ort bis auf das allererste Gespräch) bei denen üblicherweise eine mit dem Engineering Manager, eine mit dem Recruiter und dann 3-4 Sitzungen die wir als Engineering Team mit den Kandidaten durchführen.
Dafür haben wir eine interne Sammlung von Aufgaben die auch regelmäßig rotieren weil sie nach einer Weile bekannt werden. Je nach Level auf dem eingestellt wird gibt es häufig 1-2 Designinterviews in denen man z.B. ein skalierbares eventbasierendes System entwickeln muss und dann 1-2 Coding-Interviews in denen halt - ja - "vorgecodet" werden muss
Ich bin auch kein riesiger Fan davon. Aber wie auch bei GH@NDI darf man bei uns alle Hilfsmittel verwenden die einem zur Verfügung stellen. Für uns ist es wichtig zu sehen wie man Probleme löst, und klar, da gehört halt manchmal auch Stackoverflow dazu. Das ist bei manchen Firmen aber auch nicht so und man muss alles aus dem Stehgreif können.
Das ganze ist halt so lang weil es bei uns sowas wie Probearbeiten nicht gibt. Entweder man wird eingestellt, oder auch nicht. Da wird dann halt recht viel Aufwand betrieben um im Interviewprozess schon festzustellen ob man wirklich den richtigen hat oder nur jemanden der sich gut verkaufen kann. Geht aber manchmal trotzdem schief.
|
|
|
|
|
|
|
Wenn der Bewerber aktuell schon einen Job hat, muss der sich dann Urlaub nehmen, um dieses Programm zur Aufnahme in die heiligen Hallen absolvieren zu können?
|
|
|
|
|
|
|
Kündigen um Commitment zu zeigen ist der erste Test!
|
|
|
|
|
|
|
| Zitat von Ameisenfutter
Wenn der Bewerber aktuell schon einen Job hat, muss der sich dann Urlaub nehmen, um dieses Programm zur Aufnahme in die heiligen Hallen absolvieren zu können?
| |
Haha, isso.
Durch homeoffice ist das flirten mit anderen Firmen allerdings leichter geworden.
|
|
|
|
|
|
|
Das hatte ich allerdings auch schon bei meinen Bewerbungen letzten Oktober... Nach x Gesprächen wurden wir sie dann gerne zwei! Tage probearbeiten sehen, dann gibt es Feedback vom gesamten Team, und dann sehen wir weiter.
Bei allem Respekt vor einem sinnvollen Teamfit-Test, das ist etwas schwierig in einen normalen Alltag zu integrieren.
|
|
|
|
|
|
|
Einige Unternehmen sollen mal lieber nicht so tun als seien sie was besonderes.
Fuck off, für sowas will ich gar nicht arbeiten. Und dann drüber wundern, dass man keine Entwickler findet, eh.
|
|
|
|
|
|
|
|
|
|
|
Bisher wollte eine Firma bei der Bewerbung nach dem Erstgespräch einen ganzen Probetag abhalten, hab ich dann abgesagt, sry aber is nich...
Kann man ja evtl noch bei Studenten machen, aber danach? Nope.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Swift am 06.03.2022 9:50]
|
|
|
|
|
|
| Zitat von [smith]
Das hatte ich allerdings auch schon bei meinen Bewerbungen letzten Oktober... Nach x Gesprächen wurden wir sie dann gerne zwei! Tage probearbeiten sehen, dann gibt es Feedback vom gesamten Team, und dann sehen wir weiter.
Bei allem Respekt vor einem sinnvollen Teamfit-Test, das ist etwas schwierig in einen normalen Alltag zu integrieren.
| | Und dann natürlich 6 Monate Probezeit!
|
|
|
|
|
|
|
https://hackingcpp.com/cpp/cheat_sheets.html
Nette Ergänzung zu cppreference.com (bzw. Zeal, DevHelp, kleines Buch, dickes Buch, sehr dickes Buch und den Notizen).
Wenn ich eure Bewerbungsgeschichten so lese habe ich direkt keine Lust mehr mich zu bewerben. Teile der Geschichten kommen mir so vor, als ob es als Notwendig erarchtet wir den Programmier in die Donnerkuppel zu stecken. Zwei gehen rein, einer geht wieder raus? Und nur wenn man besser ist als der Einstellende, darf man bleiben?
| Schnell ein Sortierungsalgorithmus! Sie haben 30 Sekunden. | |
Bei mir es noch ein Logiktest auf Papier, etwa ein oder zwei Stunden lang. Die Idee fande ich im Nachhinein gut und hätte den Test gerne behalten. Ich kenne das aus anderen Berufsfeldern auch so nicht.
|
|
|
|
|
|
|
Geht nicht darum, ob du es schaffst, sondern darum, ob du unter pressure noch krass worken kannst!
|
|
|
|
|
|
|
Irgendwie scheint das hier total missverstanden zu werden.
Wir machen unseren Bewerbern keinen Druck. Die müssen nicht unter Zeit was liefern (also nicht mehr als am Ende des Tages jeder der Arbeitet unter Zeit was liefern muss). Sondern wir sitzen in entspannter Atmosphäre im Konferenzraum und machen im wesentlichen eine pair-programming session. Dabei muss das Programm am Ende nicht mal wirklich funktionieren, dass ist für uns nicht das Abnahmekriterium. Sondern der Weg den der Bewerber geht ist für uns das Interessante.
Der Grund warum ich das oben genannte Supermarket-Queue-Kata gerne mag ist der, dass die ersten Testcases noch ziemlich naiv bestanden werden. Allerdings kommen dann ein paar "hickups" wie z.B. das es mehr Kassen als anstehende Kunden gibt. Das führte in der Vergangenheit häufig dazu, dass die erste naive Implementierung ins leere läuft. Und dann ist es einfach spannend zu sehen, wie der Bewerber mit dieser Situation umgeht. Ob er bereit ist alles nochmal zu durchdenken und einen ganz neuen Ansatz findet oder sich einfach an seinen erreichten Status klammert und solange if-else-Blöcke ergänzt bis auch die edge-cases laufen.
Den selben Effekt erreicht man übrigens i.d.R. auch mit FizzBuzz bei Leuten, die das noch nicht gemacht haben/wenig Erfahrung in Programmierung haben und sich nciht vorher Gedanken machen, welche Prüfung zuerst gemacht werden sollte.
Ich sehe das tatäslich gar nicht als "das Unternehmen will dich schikanieren" sondern als Chance für den Bewerber tatsächlich zu zeigen, was er kann.
Wir sehen das ja viel bei den Unternehmen die wir Unterstützen/Beraten was dabei raus kommt, wenn man alle recrutiert was man bekommen kann. Bananensoftware vom meisten. Master-Commits die noch nichtmal bauen. Die ganze git-history voll mit auto-merges bei denen keiner weiß, ob dass das richtige ist.
Ich war mal in einer Firma, da lautete die git-resolve-merge-strategy einfach "meins". Der Mitarbeiter hat bei jedem Konflikt einfach auf "meine Änderung" geklickt und ständig Features aus dem Master-Branch rausgemerged.
Mit so jemandem im Team entwickelst du keine gute Software. Außer natürlich jemand anderes macht sich die Mühe seinen Spagehtti-Code zu mergen. Aber dann beschäftige ich zwei Leute für eine Aufgabe die jemand ordentliches in der halben Zeit machen würde.
|
|
|
|
|
|
|
Das klingt sinnvoll. Hinfallen und den Fehler - oder den strukturellen Irrtum - erkennen (und akzeptieren) ist unsere berufliche Aufgabe.
Das mit dem Hinfallen bekomme ich mittler Weile gut hin. Den Teil danach
|
|
|
|
|
|
Thema: Software-Entwicklung 1 ( Nach log4j ist nichts mehr wie es war ) |