PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Bewerbungsunterlagen von Entwicklern


Marscel
2016-11-27, 01:05:30
Vorweg: Ich abonniere keine HR-Zeitschriften und bin auch nicht derjenige, von dem die letzte Entscheidung gerade abhängt. Dennoch landen hin und wieder mal Lebensläufe und Profile auf meinem Tisch und ich soll drei Worte dazu Feeback geben.

Anfänglich dachte ich, dass das so eine Art Handschrift der einzelnen Bewerber wäre - und da hab ich schon viel sonderbares Zeug gesehen - aber mittlerweile scheint es Trend zu sein, und ich bin selbst ein wenig unschlüssig, ginge es vielleicht mal wieder um meine persönlichen Unterlagen: Spezialisierungsangaben.

Ich selbst bin ja ein ziemlicher Fan Executive Summaries. Ich sehe, wer es drauf hat, in wenig Platz und Zeit mir alle interessanten Dinge zu erzählen, ohne dass ich mich noch mit der Präsentation allzu sehr auseinander setzen muss - keine weitverbreitete Fähigkeit.

Das Extremum war nun ein Kandidat, dessen Lebenslauf drei ausgedruckte DIN-A4 Seiten umfasste, bei 4 Unternehmen in den letzten 12 Jahren. Darauf enthalten waren detaillierteste Angaben über Unternehmen, technisches Setup, Entwicklungsflows, persönliches Involvement, jeweils eine Liste von gefühlt jedem einzelnen Tool, das zu der Zeit mal benutzt wurde - einschließlich Versionsangaben. :O

Aus Amusement les ich mir sowas ja gerne durch, und hier mal ein paar sinngemäße Statements, die ich nun in letzter Zeit hatte:


Mit 2x schrieb ich bei X einen JSON-Parser in COBOL [Du bist gerade ... 2y?]
In dieser Zeit lernte ich einen umfassenden Umgang mit Rails v3.2.5 [Genial, genau DAS nutzen wir hier auch irgendwo, hoffentlich updated das dann keiner ...]
Das Projekt wurde mit CVS versioniert, später dann SVN. [Jo!]
Ich entwickelte einen Ranking-Algorithmus und legte die Ergebnisse dann in MongoDB ab. [Lese ich da Stolz?]
Ich kann Tomcat, Apache, Nginx, IIS. [Ham-mer, Platz 39 in der Ich-kann-Liste für dich]

Von jemandem mit Universitäts-Hintergrund, gibt es Vorgesetzte, die sich für solche Fakten wirklich so tief interessieren und dan lieber X als Y nehmen, weil X detaillierter daherkommt? Ich persönlich interessiere mich ja in der Regel für folgendes, bevor es an eingemachtere Dinge geht:


Kannst du hinreichend gut Englisch?
Was hast du die letzten 5 Jahren gemacht?
Hast du einen Uni-Informatik-Abschluss oder Gleichwertiges, dass wir über theoretische Ansätze diskutieren können?
Was tust du, um über den eigenen Tellerrand zu gucken? Newsaggregatoren, Github, ...?
Bist du jemand, den man für irgendwas speziell kennen sollte? Veröffentlichungen, OpenSource-Engagement, Event-Talks, Hacks ...

Von einem Software-Entwickler - edge case: proprietäres, geschlossenes Zeug mit teuren Zertifizierungserwartungen wie z.B. SAP - erwarte ich eigentlich, dass er nicht als Software-Entwickler für X.NET v3.10rc4 mit Faible für TypeScript-React-iOS-Native hausieren geht, sondern neben Erfahrung in für uns gesuchten Bereichen folgenden Anschein von Skills in seiner Präsentation erweckt: Lernbereitschaft, Abstraktionsfähigkeit, Ausdrucksfähigkeit, Transferleistung, Selbstständigkeit - Basics von Uni-Absolventen zu diskreter Mathe, Sicherheit, Statistik, Computer-Architekturen, Datenbanken, Netzwerken erwarte ich eigentlich immer.

Heißt, wenn ich dir ausreichend Zeit gebe, kannst du Software für ARM64 schreiben, mit Vulkan visualisieren, evaulieren, ob ein Problem mit TensorFlow eleganter zu lösen ist, einen skalierbaren Car-Sharing Dienst techn. konzipieren, VHDL benutzen, Forschungsunterlagen durchsuchen. Harte Diversifizierungen für einen Mann, aber das ist ein wenig der Typ, nach dem ich persönlich suche - und ja, es gibt die wirklich und ich kenne solche.

Bloß: Wenn Bewerbungsunterlagen so klein-klein ausgestaltet sind, ist meine Intuition nur Der weiß doch gar nicht, worauf es wirklich ankommt. Ein Engstirn, Fachidiot, Geltungsdrängler. Und um genau nicht so zu erscheinen, habe ich selbst einzelne Stationen immer nur grob zusammengefasst, wie etwa:

20xx - 201x, Software für Laufzeitmanipulation von Physik-Simulationen - POWER7, Valgrind, Fortran. oder ETL-Prozess für Abrechnungsdienst der Plattform - RDBMS, Scala

Man muss im Gegenzug ja auch sagen, dass viele Stellenausschreibungen ähnlich verquert ausformuliert sind, oder eine Firma erwartet für ihr Ökosystem jemanden mit Einarbeitungszeit gegen 0 einen Senior-Grade-Menschen zu finden, wo fähige Leute ganz allgemein nicht hinter jeder Ecke stehen.

Jetzt heißt man nicht John Carmack, Fabrice Bellard oder DJB - was ist der Erwartungswert in 2017 an eine Bewerbungspräsentation als Entwickler um fähig rüberzukommen, oder um solche zu erkennen?

lumines
2016-11-27, 01:56:07
Man muss im Gegenzug ja auch sagen, dass viele Stellenausschreibungen ähnlich verquert ausformuliert sind […]

Ich glaube, dass das eins der Probleme ist. Manche Stellenausschreibungen lesen sich wie eine Checkliste mit exotischen Kombinationen aus Technologien.

Warum man überhaupt auf die Idee kommen sollte, sogar die Versionen zu benennen, verstehe ich aber auch nicht. Vielleicht bei Technologien mit fundamentalen Umbrüchen zwischen irgendwelchen Versionen, bei denen eine Unterscheidung Sinn macht, aber sonst?

„Tools don't make the man, son.“

Exxtreme
2016-11-27, 17:03:23
Man muss im Gegenzug ja auch sagen, dass viele Stellenausschreibungen ähnlich verquert ausformuliert sind, oder eine Firma erwartet für ihr Ökosystem jemanden mit Einarbeitungszeit gegen 0 einen Senior-Grade-Menschen zu finden, wo fähige Leute ganz allgemein nicht hinter jeder Ecke stehen.

Genau das ist das Problem. Wie man in den Wald hineinruft so schallt es heraus. Die HR-Abteilungen fordern Bullshit-Bingo also bekommen sie es mit allen Konsequenzen. Das Beste was man in so einem Fall macht sind Eignungstests.

Monger
2016-11-27, 17:09:18
Ich denke, so wie eine Firma intern ihre Mitarbeiter bewertet, so sollte sie auch nach Bewerbern suchen, sonst spricht man da getrennte Sprachen.

Bei uns ist es ab nächstem Jahr so, dass zu den Mitarbeitergesprächen nicht zur Zielerreichung gehört, sondern auch wie die Ziele erreicht wurden. Hört sich banal an, hat aber tiefgreifende Konsequenzen wie zukünftig Fortbildungen geplant werden etc. ...

Meine Chefin hat mich auch regelmäßig ermahnt: rede weniger über Technik, und mehr über Verantwortung. Mit wem hast du zusammengearbeitet? Welche Rolle hattest du dabei? Inwiefern hast du zum Resultat beigetragen?


Bezogen auf den Fall hier: wenn der Bewerber schreibt "Ich entwickelte einen Ranking-Algorithmus und legte die Ergebnisse dann in MongoDB ab", dann würde ich Fragen stellen wie:
- Wie groß war das Projekt in dem du gearbeitet hast?
- Welche Rolle hattest du im Team?
- Was waren die Schwierigkeiten dabei, diese Aufgabe zu erledigen?
- Wie hast du diese Schwierigkeiten überwunden?

Es macht halt einen riesigen Unterschied, ob man da ganz alleine irgendwas implementiert hat was eventuell nie jemand anderes je zu Gesicht bekommen hat und nur lokal auf Platte lag, oder ob man sich gegen drei andere Teams durchsetzen musste, und mittlerweile DEN Ranking-Algorithmus abteilungsweit durchgesetzt hat, und alle Anforderungen von außen zur Zufriedenheit bedienen konnte...

Kurzum: was man getan hat, verliert mMn ganz allgemein an Bedeutung. Wenn jemand bestimmte Technologien noch nicht beherrscht, muss er sie sich halt aneignen. Die wichtigere Frage ist, ob er in die Teamkultur reinpasst.

samm
2016-11-27, 17:11:27
Mir hat das Posting zu denken gegeben. Werde meinen CV wohl zweiteilen, wenn ich ihn mal wieder überarbeite in "Overview" und "Details" o.ä.

Gerade wegen teilweise sehr spezifischen Anforderungen, und auch um öffentlich einsehbare Anwendungen zu verlinken, hatte ich es bislang unangenehm detailliert gehalten, ohne mir viel Gedanken über die Personaler-/Management-Sicht zu machen. Dafür musste bisher das Anschreiben herhalten.

Deshalb: Danke für den Einblick, OP.

Marscel
2016-11-27, 20:29:44
Meine Chefin hat mich auch regelmäßig ermahnt: rede weniger über Technik, und mehr über Verantwortung. Mit wem hast du zusammengearbeitet? Welche Rolle hattest du dabei? Inwiefern hast du zum Resultat beigetragen?

Unter einem Kostenstellenaspekt, Ok. Aber Verantwortung per sé? Das hört sich für mich so nach gelebtem Peter-Prinzip an.

Es macht halt einen riesigen Unterschied, ob man da ganz alleine irgendwas implementiert hat was eventuell nie jemand anderes je zu Gesicht bekommen hat und nur lokal auf Platte lag, oder ob man sich gegen drei andere Teams durchsetzen musste, und mittlerweile DEN Ranking-Algorithmus abteilungsweit durchgesetzt hat, und alle Anforderungen von außen zur Zufriedenheit bedienen konnte...

Hm, ich habe noch nie in einem Unternehmen gearbeitet, das es sich leisten konnte, ständig konkurrierende Teams zu halten. Dafür war stets zu diversifiziert abzuarbeiten. Eher Kleinkram wie Wir müssen dieses und jenes angehen und jeder baut nächsten Monat mal einen Prototypen, den wir dann evaulieren, und das auch nur um die beste P/L-Lösung herauszufinden, mit der wir ankommen.

Kurzum: was man getan hat, verliert mMn ganz allgemein an Bedeutung. Wenn jemand bestimmte Technologien noch nicht beherrscht, muss er sie sich halt aneignen. Die wichtigere Frage ist, ob er in die Teamkultur reinpasst.

Volle Zustimmung.

Deshalb: Danke für den Einblick, OP.

Was weiß ich denn darüber, wie es aktuell in anderen Unternehmen hierzulande dazu aussieht. ;) Ich freue mich allerdings auch immer wieder mal, wenn ich irgendwo einen Job-Post sehe, der mir zwar mitteilt, was meine Aufgabe wäre, aber auch auf den ersten Blick keine Unfähigkeit unterstellt, wenn ich nicht ganz genau mit X, Y und Z v2.2 aufwarte.

Entsprechend habe ich bei Bedarf selbst Stellenausschreibungen schon formuliert. Der natürliche Feind vom Kennenlernen fähiger Leute ist dann die HR-Abteilung, die darauf besteht, dass alles nach Schema X abläuft, wo man nicht mal eine öffentliche Institution ist.

Godmode
2016-11-27, 21:29:25
Ich habe es auch immer ziemlich lustig gefunden, wenn ein Softwareentwickler alle möglichen Tools aufzählt und sogar "Windows-Explorer, MSOffice" :facepalm: in seinen Lebenslauf schreibt. Wenn man ihn dann nach bestimmten Konzepten der Softwareentwicklung gefragt hat, die ein Softwareentwickler verstehen muss, stand der ziemlich am Schlauch und da merkten wir dann schnell, dass er nicht mehr als ein "Dampfplauderer" ist.

Wir lassen die Leute mittlerweile kleine Aufgaben (natürlich auf Papier) lösen und daran erkennt man recht schnell, ob jemand etwas kann oder nicht. Das ist zwar etwas aufwendig, kann dich ein Bewerber nicht mit gutem Selbstmarketing täuschen, sondern nur mit seinem Fähigkeiten überzeugen.

Wir hatten schon wahre Raketenwissenschaftler beim Bewerbungsgespräch und bei der Aufgabe sind sie kläglich gescheitert.

exxo
2016-11-27, 21:32:01
Meistens werden nicht mal unbedingt die ganzen Dinge erwartet die in diesen Stellenausschreibungen aufgezählt werden. Es ist gang und gäbe das alles zu fordern und dann einen Bewerber beim Gehalt runter zu handeln weil er angeblich das gesuchte Profil nicht ausfüllt.

schokofan
2016-11-27, 21:53:53
Wir lassen die Leute mittlerweile kleine Aufgaben (natürlich auf Papier) lösen und daran erkennt man recht schnell, ob jemand etwas kann oder nicht. Das ist zwar etwas aufwendig, kann dich ein Bewerber nicht mit gutem Selbstmarketing täuschen, sondern nur mit seinem Fähigkeiten überzeugen.



Der Bewerbungsprozess in Deutschland ist zwar sehr anders, aber ich fand diesen Post immer sehr überzeugend; ist nun zwar schon etwas älter, aber grundsätzlich dürfte es immer noch zutreffen:
https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions

xxxgamerxxx
2016-11-27, 22:00:25
Ich finde das eine ziemlich naive Sichtweise. Nur weil man vielleicht selbst hohe Ansprüche hat, heißt das ja nicht, dass jeder so ist. Außerdem sind Abteilungsleiter, die z.B. für die Einstellung verantwortlich sind, nicht alle zwangsweise fachlich qualifiziert genug, um die Kandidaten richtig einschätzen zu können, sondern auch nur Schäfchen Verwalter, die für die Auslastung sorgen müssen.

Persönlich habe ich schon den Eindruck, dass bei vielen Einstellungen sich die Kandidaten eher mit ihren Softskills durchgesetzt haben bzw. andere sehr gut einlullen können.

Ich kann schon sehr gut verstehen, dass ein Entwickler z.B. detailliert ausführen will, was er in welcher Tiefe kann. Sowas funktioniert vielleicht bei kleineren mittelständigen Unternehmen, wo auch noch der Chef über Fachkompetenz verfügt. Bei großen Unternehmen ist das bestimmt sehr unterschiedlich. Ein Microsoft, Google etc. wird vermutlich bestimmt bis auf Team Ebene neue Kandidaten auf Herz und Niere überprüfen und ob diese gut zum Team passen. Aber wenn es um irgend eine interne IT von irgend einen DAX Unternehmen geht, wo man jemand für abc mit Kenntnissen in Standardsoftware xyz sucht, wird man vermutlich auf irgendwelche Checklisten achten.

Es gibt ja auch unterschiedliche Motive, wieso/wofür jemand eingestellt werden soll und wieviel er dann verdient. Wenn irgendwo ein Bedarf nach xyz besteht, wird man auch so jemanden suchen und die Stelle dafür ausschreiben. Und oft können die Leute dann auch nur das und nix anderes.

Dr.Doom
2016-11-28, 14:21:25
Vorweg: Ich abonniere keine HR-Zeitschriften und bin auch nicht derjenige, von dem die letzte Entscheidung gerade abhängt. Dennoch landen hin und wieder mal Lebensläufe und Profile auf meinem Tisch und ich soll drei Worte dazu Feeback geben.
[...]

Kannst du hinreichend gut Englisch?
Was hast du die letzten 5 Jahren gemacht?
Hast du einen Uni-Informatik-Abschluss oder Gleichwertiges, dass wir über theoretische Ansätze diskutieren können?
Was tust du, um über den eigenen Tellerrand zu gucken? Newsaggregatoren, Github, ...?
Bist du jemand, den man für irgendwas speziell kennen sollte? Veröffentlichungen, OpenSource-Engagement, Event-Talks, Hacks ...
Wie sieht dann so eine Stellenausschreibung aus, auf die sich die "Clowns" (deiner Ansicht nach) bewerben?

Ich war damals bei Bewerbungs-Trainings, die vom Arbeitsamt organisiert wurden, und auch bei welchen, die von konkreten Arbeitgebern (z.B. Siemens, Eberspächer,...) veranstaltet wurde -- das ganze hat mich eher verunsichert, als dass es mir geholfen hat. Der eine wollte eher was über Softskills wissen und ob man C/C++ für x oder y Jahre programmiert hat, war Nebensache. Beim anderen war's die Fachkenntnis über irgendwelche Nischenprodukte. Aber in beiden Fällen wurde eine Stelle als "Informatiker/in" ausgeschrieben ohne konkret zu werden, was das Einsatzgebiet sein wird. Immerhin wurde nach Englischkenntnissen gefragt.

Die Bewerbungsunterstützung vom Arbeitsamt ging in die hier kritisierte Detailaufzählung dessen, was der Bewerber meint zu können oder bisher gemacht hat.

Wie soll man sich auf sowas sofort richtig bewerben, wenn da unterschiedliche Personaler sitzen, die auch was völlig unterschiedliches erwarten?

Monger
2016-11-28, 17:21:59
Unter einem Kostenstellenaspekt, Ok. Aber Verantwortung per sé? Das hört sich für mich so nach gelebtem Peter-Prinzip an.

Nenn es "selbstständiges Handeln und Denken". Man muss in der IT Welt schon tief im Keller sitzen, um sich so überhaupt niemals mit anderen Menschen austauschen zu müssen. Die Frage ist halt, in welchem Maßstab.

Aktuelles Beispiel: wir hatten einen Werkstudenten da, der sollte einen Testadapter programmieren. Die Schnittstellen aber sollte er mit den Kollegen aushandeln. Hat er prima gemacht. War am Anfang n bissl ungläubig dass er auch Anforderungen stellen darf, aber so ist das halt im Alltag.
Macht halt einen Unterschied ob man das Design schon vorgekaut kriegt, oder ob man sich einig werden muss.


Hm, ich habe noch nie in einem Unternehmen gearbeitet, das es sich leisten konnte, ständig konkurrierende Teams zu halten.

Was ich meinte: sobald du irgendeine technische Entscheidung anstrebst, wirst du automatisch kollidierende Interessen haben. Führen wir jetzt TFS Source Control oder Git ein? Nehmen wir MS Office oder Open Office? Brauchen wir fürs Whiteboard mehr blaue oder schwarze Stifte?

Wenn du eine Ein-Mann Armee bist, fällt die Entscheidung immer leicht. Ich kenn da so ein paar Entwickler die super technisch anspruchsvolle Lösungen hinstellen, die aber halt total am Kontext des gesamten Projekts vorbei gehen.
Aber einen breiten Konsens herzustellen, erfordert ganz eigene Talente.
Sieht man auch an Open Source Projekten sehr gut: solange es da nur ein, zwei Entwickler gibt, ist alles gut. Sobald das Projekt anfängt zu fliegen, muss man plötzlich seine Community pflegen.

Monger
2016-11-28, 17:24:33
Wie soll man sich auf sowas sofort richtig bewerben, wenn da unterschiedliche Personaler sitzen, die auch was völlig unterschiedliches erwarten?
Wo wir wieder beim Punkt wären: es ist ziemlich unwichtig was konkret du kannst. Wichtig ist, dass du in die Teamkultur passt.

Das kriegt man allein aus der Stellenanzeige auch als Bewerber meistens nicht raus. Dann muss man halt mal zum Telefonhörer greifen.

Marscel
2016-11-28, 19:51:52
Nenn es "selbstständiges Handeln und Denken". Man muss in der IT Welt schon tief im Keller sitzen, um sich so überhaupt niemals mit anderen Menschen austauschen zu müssen. Die Frage ist halt, in welchem Maßstab.

Aktuelles Beispiel: wir hatten einen Werkstudenten da, der sollte einen Testadapter programmieren. Die Schnittstellen aber sollte er mit den Kollegen aushandeln. Hat er prima gemacht. War am Anfang n bissl ungläubig dass er auch Anforderungen stellen darf, aber so ist das halt im Alltag.
Macht halt einen Unterschied ob man das Design schon vorgekaut kriegt, oder ob man sich einig werden muss.

Was ich meinte: sobald du irgendeine technische Entscheidung anstrebst, wirst du automatisch kollidierende Interessen haben. Führen wir jetzt TFS Source Control oder Git ein? Nehmen wir MS Office oder Open Office? Brauchen wir fürs Whiteboard mehr blaue oder schwarze Stifte?

Wenn du eine Ein-Mann Armee bist, fällt die Entscheidung immer leicht. Ich kenn da so ein paar Entwickler die super technisch anspruchsvolle Lösungen hinstellen, die aber halt total am Kontext des gesamten Projekts vorbei gehen.
Aber einen breiten Konsens herzustellen, erfordert ganz eigene Talente.
Sieht man auch an Open Source Projekten sehr gut: solange es da nur ein, zwei Entwickler gibt, ist alles gut. Sobald das Projekt anfängt zu fliegen, muss man plötzlich seine Community pflegen.

Darüber reden zu müssen, stelle ich mir ziemlich anstrengend vor. Bisher - kann auch an der Auswahl der Leute liegen - hat sich das immer ziemlich gut selbst arrangiert, dass irgendwer, der am meisten Lust auf X hat oder sich damit am besten auskennt, sich noch andere aussucht oder zugeteilt kriegt, und es sich darum ganz gut zusammenfügt. Und wenn man sich nicht einig war, legt man Alternativen flott dem Vorgesetzten vor, und der entscheidet dann.

Wie sieht dann so eine Stellenausschreibung aus, auf die sich die "Clowns" (deiner Ansicht nach) bewerben?

Bewerben tun sich doch bestimmt die meisten auf dieses und jenes. Zumindest urteile ich das nach dem Spektrum, dass dann bei uns zu Besuch kommt.

Ich war damals bei Bewerbungs-Trainings, ...

Meine ganz persönliche Idealanzeige - und die gibt es - sieht etwa so aus:


Software-Entwickler/in [für $HAUPTAUFGABEN_BEREICH]

* Ihre Haupttätigkeit liegt dabei in der Planung/Beratung/(Weiter-)entwicklung/Pflege/... unserer $SOFTWARE.
* Sie verfügen über Kenntnisse/Erfahrung im Bereich der $KUNDEN.
* Sie verfügen über (tiefe) Kenntnisse in $UMGEBUNG/KONZEPT/TÄTIGKEIT.
* Sie sind idealerweise vertraut mit $SOFTWARE/SPRACHE/ÖKOSYSTEM.


Wenn ich lese, dass ich Englisch und Office können soll: Nach hinten sortiert. Wenn ich lese, dass ich mind. N Jahre $X gemacht haben soll: Anforderung ignorieren. Erstens kenne ich selbst genug, die es schaffen in kürzester Zeit richtig gut zu lernen, während andere in Jahren gefühlt irgendwie auf der Stelle ackern. Zweitens: Selbst gestandene Software entwickelt sich weiter, siehe SQL/C++ - ich will nur selten an $NOW-$N zurückdenken, genau wie Anforderungen durch Hardware oder das OS.

Wie soll man sich auf sowas sofort richtig bewerben, wenn da unterschiedliche Personaler sitzen, die auch was völlig unterschiedliches erwarten?

Personaler i.S.v. HR haben in den allermeisten Fällen eh keine Fachahnung und sortieren nur die eingehende Post der Bewerbungen/Head-Hunter. Im Gespräch/AC wird dann ein bisschen pseudo-psychlogisches Blafasel mitgemacht, und der Abteilungsverantwortliche freut sich darauf, endlich allein gelassen werden zu dürfen, um abzuklopfen.

Wo wir wieder beim Punkt wären: es ist ziemlich unwichtig was konkret du kannst. Wichtig ist, dass du in die Teamkultur passt.

Das kriegt man allein aus der Stellenanzeige auch als Bewerber meistens nicht raus. Dann muss man halt mal zum Telefonhörer greifen.

Rule of thumb: Staubige Anzeige, staubige Website: staubige Kollegen.

exxo
2016-11-28, 20:28:12
Es gefällt mir an dem blog den Schokofan gepostet hat uberhaupt nicht das dort ein Ausschlusskriterium ist ob jemand, der C++ programmieren soll, imstande ist eine Telefonnummer in 50000 Textdokumenten zu finden und auszutauschen ohne dafür ein Programm zu schreiben.

Wofür wird die Person eingestellt? Für ihre C Kenntnisse oder für sekundäres Wissen, wie man mit grep oder sed sowas bewerkstelligt.

C ist eine Programmiersprache und Unix Kommandos sind Admin Tools.

Die Aufgaben eines Entwicklers unterscheiden sich diametral von denen eines Admin und vice versa.

Warum soll der Entwickler Unix Tools beherrschen wenn man ihn als C Programmierer einstellen will?

Die Aufgabenstellung erinnert mich an die Fragestellung wie viele Smarties in einer 747 transportiert werden können.

Marscel
2016-11-28, 20:47:22
Wofür wird die Person eingestellt? Für ihre C Kenntnisse oder für sekundäres Wissen, wie man mit grep oder sed sowas bewerkstelligt.

Auf jeden Fall wäre er mir eine Menge wert. ;)

Finde das Beispiel leider nicht zu irgendeinem Uralt-Contest, in welchem ein Beispiel eine Pipe aus sieben kurzen Shell-Commands (à la sed-awk-uniq-cut-... Kette) gegen eine mehrseitige C-Lösung antritt. Und es existieren Cases (http://aadrake.com/command-line-tools-can-be-235x-faster-than-your-hadoop-cluster.html), da staune ich dann doch, wenn man mir das auf den Tisch legen würde.

xxxgamerxxx
2016-11-28, 21:27:13
Der Unterschied ist nur der, dass irgend ein Shell Kommando auch nur Code abstrahiert und nicht von selbst existiert. Ein kompetenter IT Spezialist kann eben nicht nur programmieren, sondern auch bis zu einem gewissen Grad administrieren. Ohne jetzt einen Krieg vom Zaun zu brechen, aber ich habe noch keinen Admin gesehen, der z.B. Exceptions samt Stacktrace aus irgendwelchen Protokollen lesen und verstehen kann. Oft kann kann man schon daraus erkennen, was krumm ist.

Monger
2016-11-28, 21:52:11
Darüber reden zu müssen, stelle ich mir ziemlich anstrengend vor. Bisher - kann auch an der Auswahl der Leute liegen - hat sich das immer ziemlich gut selbst arrangiert, dass irgendwer, der am meisten Lust auf X hat oder sich damit am besten auskennt, sich noch andere aussucht oder zugeteilt kriegt, und es sich darum ganz gut zusammenfügt. Und wenn man sich nicht einig war, legt man Alternativen flott dem Vorgesetzten vor, und der entscheidet dann.

Ein Arbeitsplatz ohne Konflikte? Noch nie Lobbyarbeit für das eigene Lieblingsprojekt gemacht? Noch nie andere Entwickler abgeklappert um gemeinsam eine blöde Entscheidung vom Chef zu kippen? Noch nie ein U-Boot gegen das idiotische und völlig unwirtschaftliche Projekt vom Kollegen gestartet, was der nur durchbringen konnte weil er der Liebling vom Chef ist? Noch nie mit dem Architekten gestritten, weil seine Fehlentscheidungen den eigenen Job zur Hölle machen?

Klingt für mich zu schön um wahr zu sein ;-)

Marscel
2016-11-28, 22:09:26
Ein Arbeitsplatz ohne Konflikte? Noch nie Lobbyarbeit für das eigene Lieblingsprojekt gemacht? Noch nie andere Entwickler abgeklappert um gemeinsam eine blöde Entscheidung vom Chef zu kippen? Noch nie ein U-Boot gegen das idiotische und völlig unwirtschaftliche Projekt vom Kollegen gestartet, was der nur durchbringen konnte weil er der Liebling vom Chef ist? Noch nie mit dem Architekten gestritten, weil seine Fehlentscheidungen den eigenen Job zur Hölle machen?

Klar, natürlich. Aber Hierarchie ist für mich Hierarchie bzw. Demokratie/Demokratie, mal klappt es, mal nicht. Vor einigen Jahren: Chefentwickler hat gehört, dass man mit Scheiß-die-Wand-an-JS wunderbar coole Clients in kurzer Zeit bauen können soll. Nimmt sich Kollegen, eiert Wochen herum, verliert die Lust, setzt mich ran. Ignoriert alle meine Bedenken und besteht auf Weitermachen damit. Finale Auslieferung verzögert sich um 4 Monate, die zugezogenen "Consultants" kochen am Ende noch halbgarer als ich. Sowas ist frustrierend, aber hey: Ich wurd dabei nicht fürs Kopfhinhalten bezahlt. ;)

Die ganzen letzten Tage waren von TIFUs begleitet, allerdings nicht meinen. Wäre mit mir nicht passiert, hätte man mich dazu gefragt, aber: ¯\_(ツ)_/¯

Achill
2016-11-29, 01:00:00
Klar, natürlich. Aber Hierarchie ist für mich Hierarchie bzw. Demokratie/Demokratie, mal klappt es, mal nicht. Vor einigen Jahren: Chefentwickler hat gehört, dass man mit Scheiß-die-Wand-an-JS wunderbar coole Clients in kurzer Zeit bauen können soll. Nimmt sich Kollegen, eiert Wochen herum, verliert die Lust, setzt mich ran. Ignoriert alle meine Bedenken und besteht auf Weitermachen damit. Finale Auslieferung verzögert sich um 4 Monate, die zugezogenen "Consultants" kochen am Ende noch halbgarer als ich. Sowas ist frustrierend, aber hey: Ich wurd dabei nicht fürs Kopfhinhalten bezahlt. ;)

Die ganzen letzten Tage waren von TIFUs begleitet, allerdings nicht meinen. Wäre mit mir nicht passiert, hätte man mich dazu gefragt, aber: ¯\_(ツ)_/¯

Der erste Fehler war, dass einer allein entschieden hat, obwohl ein Team dafür nötig war. Der zweite Fehler (in diesen Hierarchie) ist dann oft, dass diese Leute zu "wichtig" sind und nicht das Tal-der-Tränen durchlaufen / das Projekt zum Abschluss bringen / die Suppe auslöffeln müssen und meist in ein neues Projekt wechseln oder für ein Consulting heran gezogen werden.

Ich mache i.d.R. auch nie ein Vorwurf, es fehlt halt die Feedback-Schleife bzw. es wird sich dieser gekonnt entzogen und meist hat irgend ein Management seine Finger im Spiel.