Ich bin bei diesen Artikel bei Heise mal wieder auf das Werben der Arbeitgeber mit Team-Events gestoßen. Dieser Kommentare zeigt aber auch, dass nicht nur ich diese Events auch skeptisch sehe.
Wahrscheinlich will die Masse der Arbeitnehmer einfach irgendwann nach Hause gehen um Zeit mit Freunden und Familie verbringen bzw. Hobbies nachgehen.
https://www.heise.de/forum/heise-Developer/News-Kommentare/StackOverflow-Was-deutsche-Entwickler-wirklich-wollen/Team-Events/thread-5449366/
Wenn ich ein Job-Angebot mit "regelmäßigen Team-Events" sehe, bin ich eher geneigt, dieses Angebot erst gar nicht in Betracht zu ziehen. Nicht dass ich was gegen die anderen Team-Mitglieder hätte, werden schon nette Leute sein. Nur das Wort "regelmäßig" impliziert für mich, dass auch ein "regelmäßiges" Erscheinen vom Arbeitgeber erwünscht wird.
Wenn man Frau, Haus, Freunde, Familie, Privatleben, etc hat, ist es aber schon so schwer, alles in der Woche unterzubringen, was man erledigen muss. Einkaufen, Putzen, etc und am Ende soll man sich ja auch noch entspannen und für spontane Nachfragen oder Kontrollen von Änderungen von zu Hause soll man ja auch noch zur Verfügung stehen.
Wenn man Single ist und seine Wohnung nur als Ort sieht, den man zum Schlafen aufsucht und sonst seinen Lebensmittelpunkt bei der Arbeit sieht, mögen diese Events schön und toll sein. Für die meisten werden sie aber eher Zeit belegen, die man für andere Dinge gebraucht hätte.
Auf den jährlichen Weihnachtsmarktbesuch mit dem Team würde ich nicht verzichten wollen. So etwas im monatlichen Rhythmus würde ich auch ok finden, wobei ich aber eine Anwesenheitsrate von 50% schätzen würde, die ich realistisch einhalten könnte.
"Du kannst fast immer pünktlich gehen" wäre also für mich viel mehr ein Anreiz als Team-Events. Weil was bringt es mir pünktlich Feierabend zu machen und dann 4h bei einem Team-Event zu verbringen.
Das bei Webentwicklern PHP meistens hinter Java kommt ist bei dieser Statistik wieder eine andere Geschichte...
Vor doch schon einiger Zeit bin ich über diesen Artikel http://www.heise.de/developer/artikel/Hinterfragt-Woran-erkennt-man-einen-guten-JavaScript-Entwickler-2652128.html bei Heise gestolpert. Die Fragen die dort verwendet werden, um zu beurteilen, ob jemand ein guter JavaScript-Entwickler ist, halte ich persönlich für zum Teil voll kommen nichts sagend.
Gut man prüft das Wissen über die Interna von JavaScript, aber man will ja erstmal jemanden der mit JavaScript eine Anwendung schreiben kann und nicht jemand der mir eine JavaScript-Engine schreiben. Ich kann aus meiner Erfahrung heraus sagen, so wie ich JavaScript gelernt habe, dass nur eine relevante Frage dabei ist und zwar die nach den Closures. Wenn man das erstmal verstanden hat und kann sind auch die technischen Gegebenheiten hinter den Fragen davor leicht verständlich.
Die letzte Frage ist auch kaum brauchbar. Wenn ich mit einem Canvas arbeite gibt es natürlich ganz andere Probleme und Lösungen, als wenn ich viel Berechne und in Script-Timeouts laufe. Wenn ich schlecht programmiere und unnötig Methoden immer und immer wieder in einer Schleife aufrufe, sagt es auch eher allgemein was über mich als Entwickler aus und weniger über meine Fähigkeiten mit JavaScript.
Also ich würde bei JavaScript mehr auf Closures achten und wenn mir jemand erzählt sowas bräuchte man nicht. Aber mir gleichzeitig von seiner langjährigen Erfahrungen mit JavaScript erzählt und dann aber auch beim Zuweisen einer Function zu einem Object scheitert..
object.onSomething=func();
weil es wird nur einmal bei der Zuweisung die Function aufgerufen, aber onSomething bleibt null.. dann sollte man nochmal gut überlegen, ob die Person geeignet ist. (Das war jetzt ein Beispiel das sich genau so zugetragen hat.. und er hat einige Jahre mit JavaScript gearbeitet... nur eben trotzdem keine Ahnung davon)
bezahlt von 
Blog: Blog-entries by search-pattern/Tags: