el_pollo_diablo

Da ich einigen Kommilitonen Nachhilfe gebe (die zum Teil gar nichts mti IT studieren, sondern einfach das Modul irgendwie bestehen müssen), habe ich inzwischen einiges an Erfahrung, woran es hackt:
1. Grundlagen (1) 
Ganz häufig ist das Problem, dass sie zwar "irgendwie wissen", was Variablen, Klassen, Methoden usw. sind, aber nicht, wofür man die anwendet. Das muss einfach sitzen. Zum Beispiel kommen viele überhaupt nicht auf die Idee, hier und da einfach eine Variable zu deklarieren, in der irgendwas zwischen gespeichert wird. Dieses Denken muss sich auch erst entwickeln und darum ist es wichtig, damit rumzuspielen. Zum Beispiel, alle möglichen Operationen auf Integer anwenden, auf Floats, auf Strings, diese zu kombinieren, in ne neue Variable reinzuschmeißen usw. Damit man einfach ein Gefühl dafür kriegt, was überhaupt möglich ist. Und dann kommt irgendwann das Denken "oh, da mach ich mir ne neue Methode, schmeiß den Rückgabewert in ne Variable und arbeite damit weiter". Aber dafür muss man nicht "lesen, lesen, lesen" sondern einfach "machen, machen, machen".
2. Grundlagen (2)
Was auf jeden Fall sitzen muss sind Datentypen (primitive Datentypen, Arrays), Verzweigungen (IF, If-Else, If-Else if-Else, Switch-Case), Schleifen (while, do-while, for, foreach). Ich merke immer wieder, dass viele selbst nach einem halben Jahr Softwareentwicklung einfach nicht auf die Idee kommen, zwei Bedingungen in ein If zu stecken oder eine Schleife rückwärts laufen zu lassen. Wieso nicht? Der PC macht, was der Programmierer will (wenn der das richtig angibt)
3. Aufgaben verstehen
Mit Grundlagen 1 und 2 kann man schon sehr sehr viel machen. Zum Beispiel diese ganzen typischen Aufgaben wie z.B. "finde die größte Zahl in einem Array", "ermittle den Durchschnitt in einem Array", "gebe einen Text rückwärts aus", "implementiere ein Zahlenraten" usw., also die typischen Aufgaben für einen Anfänger. Diese Aufgaben muss man irgendwie vom Text in Code umwandeln. Ganz oft, gibt der Text aber auch Hinweise darüber, was man machen muss. Zum Beispiel: "der User soll eine Zufällige Zahl raten. Solange die Zahl nicht erraten wurde, soll 'Leider falsch... Nochmal raten' ausgegeben werden. Ansonsten, soll 'Super, du hast die Zahl erraten" ausgegeben werden. Gebe zusätzlich aus, wie viele Versuche der User benötigt hat". Darin steckt schon sehr viel, was man machen muss:
Der User soll eine Zufällige Zahl raten: Super, dann steck ich eine Zahl in einen Integer! Solange blablablabla...: Super! Solange irgendwas gemacht wird, ist immer eine Schleife (genauso wie "für alle..."). Wenn dies.... ansonsten...: Ahhhh, eine If-Verzwiegung! Wie viele Versuche: Ah, ich muss die Versuche irgendwo speichern. Ah, wie wärs mit nem Integer, den man hoch zählt, wenn die Zahl nicht getroffen wurde! Mit der Zeit entwickelt sich dann das "Denken in Code" und sobald das passiert ist, ist es egal, ob ich in einer Schleife jeden Zweiten Wert aus einem Array auslese, oder der Holzfäller jeden zweiten Baum fällt. Irgendwann entwickelt sich das schon.
4. Nicht das große Ganze sehen
In Punkt 3 habe ich eine Aufgabe, die vielleicht am Anfang komplex erscheinen kann, in viele kleinere Schritte zerlegt. Aber genau darum geht es: nicht das große Ganze sehen und nicht wissen, was zu tun ist, sondern Schritt für Schritt das Problem lösen. Zum Beispiel, erst einmal eine Zufallszahl erzeugen und ausgeben. Funktioniert? Wunderbar, dann kanns ja weiter gehen. Dann eine Zahl einlesen. Cool, klappt ja auch! Dann die Zahl mit der Zufallszahl vergleichen. Geil, gar kein Problem. Dann eine Schleife drumrum basteln. Oh, jetzt will er immer eine Eingabe. Wie unterbreche ich jetzt die Schleife, wenn die Eingabe stimmt? Was gabs da nochmal? Ah, genau, break. Perfekt, funktioniert. Nun noch ne Variable die die Fehlschläge zählt, die am Ende mit ausgeben und fertig. Cool, läuft. Und dann macht es auch Spaß
5. Dann erst komplexere Dinge machen
Sobald man Punkt 3 beherrscht, kann man sich komplexeren Dingen zuwenden, wie zB Klassen, Designpattern usw. 
6. Üben, üben, üben
Egal wie gut ein Programmierer ist, er kann immer noch was lernen. Aber die, die das Jahrelang machen, haben jeden Fehler zehn, zwanzig, hundert mal gemacht, bevor sie sich weiter entwickelt haben. Programmieren lernen hat (leider) nicht immer eine steile Lernkurve, sondern ist manchmal auch einfach ätzend. Aber wenn man dann nach drei Stunden endlich ein Problem gelöst hat, darf man auch mal stolz auf sich sein  

Ich empfehle dir Gerhard Wohlands "Denkwerkzeuge der Höchstleister". Alternativ den etwas in die Jahre gekommenen, aber für Entwicklerjobs immer noch aktuellen Blogpost von Joel Spolsky zum Thema "Guerilla Interviewing". Grade in einer schnelllebigen Branche, in der Wissen redundant verfügbar und in der Regel von überall abrufbar ist, kommt es bei den meisten Jobs nicht auf "Wissen" an, sondern auf "Können", "Intuition" und "Talent". Wohlands und auch meiner Einschätzung nach kann eine zentrale Steuerung wie eine "Personalabteilung" oder gar die "Geschäftsführung" die Komplexität am Markt gar nicht erfassen, geschweige denn sie mit Prozessen und Schablonendenke erschlagen.
Das führt zum einen dazu, dass 
die Kollegen, die direkt wertschöpfende Arbeit leisten sowieso am besten wissen, was sie benötigen und das(jetzt wird es spannend) auch am ehesten erkennen, wenn ein Kandidat diese Skills mitbringt. Der Großteil der Fragen ist viel zu generisch, um überhaupt einen guten Bewerber für eine spezifische Stelle anhand dieser ausmachen zu können. Grade, weil die meisten Kandidaten gebetsmühlenartig die schon vorbereiteten Antworten runterrattern. 
Ein ehrliches Gespräch unter evtl. zukünftigen Kollegen auf Augenhöhe in einem geeigneten Rahmen, im dem konkrete zukünftige Einsatzfelder abgeklopft werden(man stellt ja niemanden auf Verdacht ein, wenn man bei Verstand ist) ist meiner Meinung nach unendlich viel wertvoller als jedes noch so minutiös geplante Assessment Center oder vorbereitete Gesprächsleitfäden. Wer für eine große Menge an Bewerbern mit individuellen Hintergründen allgemeine Methoden verwendet, um ggfs. den Kandidaten mit dem besten Durchschnitt anzustellen, wird im schlimmsten Fall auch genau das erhalten. Durchschnitt.
Der Aufwand für passgenaue Gespräche und Vorgänge mag ggfs. höher sein, aber Spolsky bringt es mit einem Teil finde ich ziemlich genau auf den Punkt:
Gruß, Goulasz