Das ist absoluter humbug, bei derartigen Fragen habe ich schon damals in der Schule schnell das interesse verloren und den Test vergeigt.

Ich (und viele andere Autodidakten) wuerde hier durchfallen...also kann mit dem Test was nicht stimmen.

Ausserdem wird hier getestet was der Pruefling auswendig gelernt hat, nicht aber das wesentliche, seine Arbeitsweise.

Ich verstehe zwar das jemand der kein Programmierer ist Kennzahlen ueber seine Leute haben moechte, diese ueber derartige Tests zu erstellen ist aber schlichtweg schwachsinn.
Ich empfehle immernoch den Alpha geek! :)

Ausserdem sind meist die CPAN Module eines Perl Programmierers (bzw. Beitraege zu CPAN Modulen Dritter) ein guter Anhaltspunkt.
Das sagt viel uber die Faehigkeit im Team zu arbeiten, sich an Standards zu halten, und vor allem Qualitaet aus!

Das ist alles Ansichtssache. Jeder lernt anderst...

ey stimmt das ist gut, vorallem relativ einfach zu realisieren!
Ist zwar ne einseitige Sache aber immer hin eine Möglichkeit die am einfachsten umgesetzt werden kann.

is ja klar dass das nicht das einzigeste bleiben darf. Aber es wäre ein Anfang oder?

Ganz genau, jeder lernt anders, und genau deshalb ist die einzige Moeglichkeit einen Programmierer zu testen ihm Probleme zu geben die er loesen soll.
Ohne weitere Vorgaben...

Es ist zwar nicht leicht auszuwerten, wird aber schnell die Spreu vom Weizen trennen. ;)

Bei Multiple Choice werden klar die schlechteren Programmierer bevorzugt!!!

ich möchte hier noch mal auf "KUMON" zurückkommen. mein dringender vorschlag währe abstand von allen japanischen lehr-/lernmethoden zu nehmen. das japanische schuhlsystem produziert laufend psychopathen. es ist dort ein weit verbreitetes problem, dass schüler mit dem leistungsdruck, den sie in der schule erfahren, nicht klar kommen und sich teilweise jahrelang in ihrem zimmer einschliessen. wie schon gesagt sind das auch keine einzelfälle sondern ein tatsächlich verbreitetes und bekanntes problem.
ein weiteres gegenargument bietet die pisa-studie. hier schneidet japan auf den ersten blick sehr gut ab, allerdings hat japan hier auch die meisten nicht beantworteten fragen. wenn schüler mit einer frage gefordert sind, kreativ zu denken, dann geben sie einfach auf. das ist sicher keine qualität die man von einem programmierer erwartet.
imho sind diese probleme direkt auf die leistungsorientierten und entmenschlichten methoden zurückzuführen, mit denen in japan schüler und arbeiter zu höchstleistungen angespornt werden sollen.

es kann nicht sein, dass man ein zertifikat als programmierer aufgrund eines multiple-choice testes bekommt. solche tests können einfach qualitäten wie kreativität nur eingeschränkt messen. und m.E. ist kreativität eine der wichtigsten eigenschaften, die einen mässigen von einem wirklich guten programmierer unterscheidet.

Taulmarill++

@sri: beim letzten Punkt kommt es immer darauf an, wie die Multiple-Choice-Fragen (MCF) aufgebaut sind... Sie dürfen ganz klar nicht das einzige Mittel im Test sein. Aber ein paar solcher Aufgaben sind zum "Auflockern" nicht schlecht. Hier kommt es ein wenig auf gutes Gespür an, ob man zu einem Thema eine gute MCF machen kann oder nicht.
Es ist klar, dass der Unterschied zwischen "richtigen" Programmierern und "guten" Rätsellösern bei MCF nicht so groß sind, aber an ein paar Stellen eingestreut kann man gewisse Bereiche abfragen, die mit einer "offenen" Frage nicht ganz so leicht abzuhandeln wäre!

Ganz ohne Vorgaben würde ich dem Programmierer aber kein Problem lösen lassen. Wie oft kommt es bei Dir vor, dass Dein Chef einfach nur sagt "Schreib mal ein Programm!". Es ist ja wohl eher der Fall, dass Du Vorgaben darüber bekommst, was am Anfang steht und was am Ende rauskommen soll! So etwas nach dem Motto "Wir haben hier ne Webseite und am Ende soll eine Liste rauskommen, in der alle Linktexte und URLs stehen. Mit Tab getrennt damit wir das in das Programm XY einlesen können".
Also ganz ohne Vorgaben geht es nicht. Dann ist es auch nicht wirklich kontrollierbar! Die Vorgaben dürfen aber auch nicht zu eng sein, weil sonst der "Erfindergeist" nicht in Schwung kommt.
Ich liebe es bei meiner jetzigen Projektleiterin, dass sie mir immer nur sagt was wir haben und was am Ende rauskommen soll, aber der Weg ist mir absolut freigestellt.

[quote=kalyxo,11.07.2005, 12:30]Meines Erachtens gibt es übrigens nur sinnlose Aufgaben. Eine "Kontrolle" kann überflüssig aber nicht "schlecht" sein.[/quote]
Oh doch, das kann sie, je nachdem wie sie ausgeübt wird. Wobei mir sowohl positive wie auch negative Beispiele einfallen. Meist hängt das von der Person des Controllers ab und wie dieser seine Tätigkeit versteht. Ich kannte welche die über jede Arbeitsminute einzeln Aufschluß wollten was sehr lästig war (solange die Produktivität stimmt, hätte er sich auch um wichtigeres kümmern können - vor allem weil der Zeit-Aufwand für den Nachweis höher war als das mögliche Optimierungsresultat) und welche die sich darum bemüht haben, das die Leute vernünftige Arbeitsbedingungen und das benötigte Material zur Verfügung hatten, was mir sehr positiv aufgefallen ist.

Darüber hinaus kann das Controlling (den hierzu werden die Kennzahlen ja benötigt) nur sinnvoll sein, wenn ein Maßnahmen-Paket bereitsteht um angemessen zu reagieren. "Das muss besser werden ..." - alle paar Monate hilft nicht, es müssen entsprechende Maßnahmen damit verknüpft sein, die es ermöglichen die Schwachpunkte in den Griff zu bekommen.

Generell geht es beim Controlling ja um die Beurteilung von Prozessen bzw. Leistungen die man wie eine Regelstrecke zu betrachten hat: Also die Einfluß- bzw. Störgrößen (insofern signifikant), die Leistungserstellung und die Leistungsabnahme. Meist wird sich auf die Leistungserstellung konzentriert, ohne die beiden anderen Größen zu berücksichtigen was keine qualifizierte Aussage über den Gesamtprozeß erlaubt. Gerade die Leistungsabnahme durch den Kunden wird oft eher stiefmütterlich behandelt ("Oh Gott, sollen wir jetzt auch noch mit denen reden?"), was sehr negativ ist, weil diese ja am ehesten wissen, welche Verbesserungen sie von Leistungen/Produkten erwarten. Die Eingangsgrößen nicht zu berücksichtigen und sich z.B. über die Ausschußquote zu beschweren, wenn das Quellmaterial nicht geeignet ist (aber billig eingekauft) könnte man dann sogar als dummdreist bezeichnen.

Ich könnte gerne noch mehr zum Thema Controlling erzählen, wobei ich wahrscheinlich leicht OffTopic bin, wenn es jemanden interessiert.\n\n

<!--EDIT|Ronnie|1121084535-->

Noch etwas, das ich immer ganz gut fand, war für Einsteiger so etwas wie die Fehlersuche bei C für Linux in 21 Tagen am Ende eines Kapitels. Da hat man dann ein ganz kleines Programm, wo man dann die Fehler suchen muss.
Ein Beispiel:

klar, hier schlägt das strict Pragma zu. Sowas übersieht man aber doch recht einfach als newbie. Wenn man dann mal einige Minuten damit verbracht hat, diesen Fehler zu finden, denkt man sicherlich eher daran, wenn man mal wieder vor so einem Problem steht.

Noch eine kleine Idee wäre vielleicht daraus ein OpenSource Projekt oder sowas für Freiwillige Entwickler auf die Beine zu stellen. Um so mehr Leute daran arbeiten, um so mehrere Möglichkeiten hat man, sich die Lernmethoden anderer anzuschauen.
Es ist beispielsweise untergliedert in die verschiedenen Methoden ( Fehlersuche, Programmierlösungen, Multiple Choice, ...) und einige Leute, die das Projekt Maintainen, portieren dann die von den verschiedenen Leuten gestellte Aufgaben auf die verschiedenen Bereiche.

Ich muss zugeben: Sowas hät mir den Einstieg aus extrem erleichtert. Ich bin von allein auf die Programmierung gekommen und hab "offline" gelernt, mit Büchern. Mittlerweile schau ich mir beispielweise ganz gerne scriptbeispiele auf http://www.koders.de an und leite dann meine "Fragen" auf die Lösungen, die ich finde ab. So etwas wäre sicherlich hilfreich. Aber ich denke auch nur wirkich brauchbar, wenn es in einem gewissen Umfang vorhanden sein wird. Und das kann denk ich mal einer allein kaum auf die Beine stellen...