Vorstellungsgespräch -> C# Test, was würdet ihr fragen?

Hallo,

da sich mein Studium dem Ende zuneigt, kommen jetzt die ersten Vorstellungsgespräche auf mich zu, u.a. wurde ich auch schon darauf vorbereitet, dass ich zu einem Vorstellungsgespräch einen kleinen C#-Test absolvieren werde, mit 15 Fragen (sonst keine genauere Infos), das würde man bei Berufseinsteigern dort halt einfach so machen.

Ich fühl mich ja eigentlich ganz fit mit C#, aber da es meine ersten Vorstellungsgespräche überhaupt sind, will ich natürlich bestmöglich vorbereitet sein (ich weiß ja schließlich noch nicht was mich erwartet).

Ich würde euch deshalb einfach mal gerne Fragen, mit was man denn bei so einem Test rechnen könnte? Was würdet ihr selber einem Berufseinsteiger fragen bzw. was sollte er bezüglich C#/.NET wissen? Manchmal ertippe ich mich noch bei zT grundlegenden Sachen die ich nicht weiß, weil ich sie bei Bedarf einfach googlen würde oder vielleicht auch noch nicht gebraucht habe.
Also einfach mal raus mit paar Sachen, die man eurer Meinung nach auf dem Kasten haben sollte.

Danke schon mal für jegliche Anregung 🙂

Hallo Thoxx,

das ist sehr schwer zu sagen weil das sicherlich stark von Firma zu Firma variiert.

Ich habe von einem Kollegen gehört dass ihm auch ein paar Fragen gestellt wurden als er sich für das Praktikum beworben hat.
Dabei ging es aber um triviale Dinge (also nix spezielles von .NET)

z.B. wurde er gefragt wie der Fibonacci Algorithmus funktioniert, was genau Rekursion ist.. und halt alles solche "einfache" Fragen

Aber wenn du in C# eigentlich ganz fit bist dann wird das schon passen.
Normalerweise bringt es auch nicht wenn die einen Praktikanten um alle möglichen Details fragen, wichtig ist dass die Grundkonzepte sitzen, den Rest kann man dann schon erlernen 😃

Gruss
Michael

EDIT: Das heisst aber nicht dass du auch sicher so einfache Fragen bekommst 😃

Hi Thoxx,

also ich würde z.B. nichts fragen, was Programmiersprachen spezifisch ist, sondern eher das objektorientierte Verständnis hinterfragen. In dem Zusammenhang vielleicht Schlüsselwörter erklären können, wie z.B. "abstract", "static", "sealed" oder was weiß ich noch alles.

Was ich eigentlich sagen wollte ist, dass es für mich viel wichtiger ist das jemand grundlegendes Verständniss mitbringt, als perfekt spezialisiert zu sein.

MfG
wax

Hallo Thoxx,

hmm da würde mir noch vieles einfallen. (natürlich nur ergänzend mit den Fragen meines Vorgängers)

Aber da es ein C# Test ist

Thema WPF:
Unterschiede zwischen Visual Tree und Logical Tree
Was ist ein Dependency Property

Allgemein:
Unterschied zwischen einem Property und einem Field
Unterschiede zwischen dem Thread und dem Backgroudworker

Typische Exceptions vorgeben und der Potentielle Bewerber, soll etwas dazu sagen, ZB. wie sie entstehen und möglicherweise behoben werden können

und noch viele weitere

Viele Grüße
Lars

Hallo,

ergänzend zu den Vorpostern:

Fragen ob bestimmte Begriffe bekannt sind wie (ohne bestimmte Reihenfolge) O/R-Mapper, MVP, myCSharp, MVVM, Strategy, DAL, Repository, Unit of Work, DI, IoC, usw.

Wenns um kleine Testaufgaben geht dann liefert Programmier-Spiel eine große Auswahl von Aufgaben. Davon würde fast jede passen.

mfG Gü

Wenn du sagst du weisst Bescheid dann viel Glück.
Typische Fragen gibt es nicht.
Es kann sein das du eine Frage gestellt bekommst worauf die Antwort nicht kennen kannst. Manche Leute tun das um zu testen wie du reagierst. Wäge da klar ab ob du das wissen musst oder kannst und gestehe fallweise ein das du da nicht so im Thema bist.

Hallo,

gestehe fallweise ein das du da nicht so im Thema bist.

und in diesem Fall ist dann wichtig dass du zeigen kannst wie du zum nötigen Wissen kommst bzw. wie es mit dir bekanntne Alternativen umsetzbar ist usw.

mfG Gü

Hi,

also wir bei uns erwarten, dass ein halbwegs guter Programmierer sich in Themenbereiche (u. U. auch eine neue Programmiersprache) selbständig einarbeiten kann. Es ist uns also völlig egal, ob er nun den Namensraum X.Y.Z auswendig kann oder nicht.... Wozu gibt es heute Google und Code-Completetion im Editor....

Wir fragen/checken eher, ob der Bewerber beispielsweise mit den grundlegenden Pattern umgehen kann (Visitor, Decorator, Strategy, usw.)... Ggf. auch mal eine Aufgabenstellung, und wie er diese realisieren/umsetzen würde - und dabei auch hinterfragen warum/wieso (um zu sehen, ob der Kanditat ein bisserl über den Tellerrand guckt - so Richtung Erweiterbarkeit seiner erdachten Lösung).

Wenn der Kanditat im GUI Bereich arbeiten soll, dann wäre sicherlich auch da ein wenig Nachfragen nötig, wie er denn an ein Oberflächendesign ran geht, was ihm wichtig ist, wrum er jenes "so" und nicht "anders" macht.

Wenn der Kandidat bereits eine Software entwickelt hat, dann darf er diese auch gerne auf seinem Notebook zeigen - wobei wir dann auch gerne "ganz spontan" mal in den Source gucken wollen - dann sehen wir gleich, wie der Code so formatiert ist und ob es auch seiner ist (und nicht der eines Freundes) - da wir auch den Kandidaten im Source Navigieren lassen.... Wenn die Software im Internet präsent ist (z. B. ein OpenSoure Produkt) - noch besser...

Bye,
Michael

Danke für die Antworten und die Anregungen. Dass das von Firma zu Firma unterschiedlich ist, ist mir natürlich klar 😉 Deshalb wollte ich auch einfach mal in die Runde fragen, was ihr erwarten würdet.

Ich würde es natürlich auch für sinnvoller halten eher nach Konzepten zu fragen oder Sachen zur OO, weil ich halte es für wichtiger dass sich jemand bei Unwissen eher schnell Infos beschaffen kann, als massig Sprachfeatures auswendig zu können, aber im Zweifelsfall dann blöd da sitzt, wenn sein Wissen zu Ende ist 😁

Ich geh noch mal die genannten Sachen im Thema hier durch (gerade zu diversen Pattern könnte ich mich noch mal kurz einlesen) und schauen, was ihr beim Programmierspiel so getrieben habt 😉

Eventuell kann ich euch ja dann einfach mal berichten, was gefragt wurde.

Ich würde mir irgendein Konzept im Detail erklären lassen - zum Beispiel die Garbage Collection: Was sind Generationen? Wann wird collected? Was ist ein Finalizer? Warum sollte man Finalizer - wenn möglich - vermeiden? Was ist die FReachable-Queue? Wie findet der GC die zu entfernenden Elemente?

Also einfach Dinge, von denen ich davon ausgehe, dass sie ein 08/15-Programmierer nicht kennt, aber die ich von einem wirklich guten Entwickler erwarten würde.

Außerdem würde ich ihm eine Aufgabe stellen, die ihn herausfordert, um zu sehen, wie er arbeitet. Das sagt IMHO mehr aus als das reine Wissen.

ZB: Schreibe eine Methode, die einen String umkehrt - ohne Schleifen zu verwenden, und ohne die String.Reverse-Methode zu verwenden. Und dann: Performance messen und optimieren. Kommt derjenige zB auf die Verwendung von Tail Recursion? Wie geht er mit der Aufgabe überhaupt um? Legt er direkt los? Plant er? Googlet er? ...?

ZB: Schreibe eine Methode, die einen String umkehrt - ohne Schleifen zu verwenden, und ohne die String.Reverse-Methode zu verwenden. Und dann: Performance messen und optimieren. Kommt derjenige zB auf die Verwendung von Tail Recursion? Wie geht er mit der Aufgabe überhaupt um? Legt er direkt los? Plant er? Googlet er? ...?

Ich halte das für sinn frei und kontraproduktiv. das sagt nur aus, das der Entwickler durchaus in der Lage ist, super smarten ultra komplexen und hoch hochperformanten Code zu programmieren, den im ersten Monat nur er und Gott lesen und verstehen kann und nach einem Monat nur noch Gott....

Bei meiner Anstellung wurde ich über folgende dinge ausgequetscht (ohne besondere Reihenfolge):
Optimistische/pessimistisches locking, Mocks, Unittesting, diverse patterns, diverse schichtenarchitekturen (konzept und trennung...), oberflächlich uml, usw..

Im wesentlichen waren es eher Fragestellungen ohne diese Stichwörter und das oben sind die korrekten antworten gewesen. (z.B. wie vermeidet man, das ein einmal gefundener Bug in zukünftigen Code nicht mehr auftritt --> Unittest für diesen Bug schreiben.)

Ich hatte im letzten Monat ein paar Vorstellungsgespräche. In einem bekam ich einen Fragenkatalog den ich mit dem Techniker gemeinsam durchging.

• Fragen zum Aufgabengebiet des Unternehmens. (In dem Fall waren es Börsenfrage - bin böse gescheitert 😄)

• Allgemeine Fragen zur Informatik
  -- Erkläre Binäre Suche
  -- Programmiere in Pseudo-Code die Binäre-Suche aus (Knackpunkt: Rekursion u. Abbruchbedingung)
  -- Zeug das ich vergessen habe, sorry

• OOP
  -- Was ist ein Design Pattern?
  -- Nenne u. erkläre ein paar.
  -- Wofür braucht man z.B. das Observer Pattern? Wie löst man das in .Net? (Knackpunkt: Zu verstehen, dass Events eine in C# integrierte Variante des Observer Patterns ist.)

• Unit Tests
  -- Was ist das und warum braucht man das?
  -- Was ist ein Mock?
  -- Erfahrungen?
  (Ich habe dem Fragesteller damals von EBC erzählt da ich mich zu der Zeit gerade damit beschäftigt habe. So ganz hat ihn das nicht überzeugt aber es kam gut an, dass ich mich mit sowas beschäftige.)

• Bisherige prof. Erfahrung
  -- Was war dein Aufgabengebiet in der alten Firma?
  -- Wieso habt ihr das so u. so gelöst? (Dabei ging es nicht um Implementationsdetails (Betriebsspionage wäre da nicht mehr fern.) sondern da ging es mehr darum zu erklären welchen allgemeinen praktischen Sinn die jeweilige Technologie hatte.)

• .Net-Wissen
  -- String a, b; a = "asdf"; b = a; a = "asd"; // Was steht in b?
  -- Was ist WCF? Wo ist der Unterschied zu Remoting?
  -- Was ist ein BasicHTTP-Binding in WCF?

• Welches technische Sachbuch Buch hast du als letztes gelesen? Wie fandest du es u. warum?

Im Endeffekt kam ich gut an obwohl ich beim ersten Teil ziemlich böse gescheitert bin. (0 von 5 Fragen gewusst.) Es fehlen einige Frage, da das nur aus der Erinnerung ist. Das Gespräch war sehr intensiv u. hat 1,5h gedauert.

Ich erinnere mich an meine Einstellunsprozedur.

Zuerst wurde ich mit einem Entwickler zusammen gesetzt, der hatte ein paar Code ausdrucke wo ich ein Fehler finden sollte, da hatte ich 1 von 5 ^^. (Nur C++)

Danach hieß es, den Rest des Tages eine kleine Programmieraufgabe zu lösen, eine Konsolen Applikation die ein Irrgarten aus einer Text Datei aus liest, und dann selbständig den Weg findet. Angesetzte Zeit waren 4h wenn ich mich recht erinnere.

Am ende wurde zusammen (zu dritt) der Code durch gesehen um zu schauen was ich wie gelöst habe.

So kam ich dann in die "nächste Runde" und zwar eine größere Aufgabe in einer normalen Arbeitswoche zu lösen, essen und Unterkunft wurde von der Firma gestellt.

Joa, das ist nun fast 4,5 Jahre her.

Ich hatte gleich nach der Uni mal ein solches Gespräch und es blieb doch sehr theoretisch. Also was sind Klassen, Objekte und Typen und soweiter, paar Fragen zu Datenbanken & allgemeines IT Wissen (TCP/IP, RS232, XML).

Das Witzige damals war, das der IT-Chef dabei war und der Personalchef.
Der IT-Chef war sehr angetan von meiner Art mit "Armen und Beinen" dem Personalchef
ein paar Grundlagen der Programmierung zu erklären.

Viel Erfolg, schön locker bleiben, und dran denken, es gibt sowieso immer einen Besseren!

Bei meinem letzten Vorstellungsgespräch bekam ich code auf einer A4 Seite vorgelegt, ein bisschen Zeit diesen durchzulesen und danach wurden mir dazu fragen gestellt.
Was ist ein ctor, wo ist er, wann wird er aufgerufen

welche methode ist als überschreibbar definiert, wo ist die Eventhandler Methode.
Woran erkenne ich das diese klasse von einer anderen ableitet.
Was bedeuted dieses schlüsselwort. und kompiliert der Code?

Also eher triviale Fragen hatte auch alle richtig bis auf "kompiliert der Code" da ich das schlüsselwort new nicht kannte (ich war vb programmierer)

Und dann wurde ich noch relative viel im Bereich datenbanken ausgequetscht. wie erstellt man eine Tabelle, ein Feld, wie löscht man eine Tabelle.
Wie ist die Syntax von einem Insert oder Update. Was ist ein JOIN und was ist der unterschied von LEFT JOIN zu INNER JOIN.

Da ich damals recht viele Interviews hatte, kann ich noch sagen, es ist nicht so wichtig dass man 100% der Fragen richtig hat, sondern eher wie geht man mit Fragen um die man nicht beantworten kann. Beschreibt indirekt Dein Verhalten in Stresssituationen.

Also 80% richtig beantworten, vielleicht mit privaten Arbeiten punkten, das mögen unternehmen sehr wenn man sich auch privat weiterbildet. und bei den 20% die man nicht weis einfach locker bleiben
Der der mit Dir das Vorstellungsgespräch führt kocht auch nur mit Wasser.

good luck.

//EDIT: und ganz wichtig, nicht zu weit aus dem Fenster lehnen. Manchmal wird einem da eine Falle gestellt und dann muss man felsenfest wissen von was man redet.

Programmierfragen beim Einstellungstest - Kindergarten. Garbage Collection erklären - so ein Schwachsinn.

1. Sagt das fast nichts aus. Wenn ich zwei Jahre nicht mehr C# programmiert habe, mag ich vielleicht den ein oder anderen Befehl vergessen haben, kann jedoch immernoch ein sehr guter Entwickler sein. Wer horizonttechnisch "Informatik" mit ".NET" gleichsetzt, der mag sich irgendeinen .NET-Blödsinn erklären lassen, ja.

2. Ist die praktische Informatik die Teilmenge der Informatik mit den meisten unscharfen Begriffen. Was bringt es, wenn ich auf dem Begriff "Dependency Injection" rumhacke? Vielleicht kennt der Entwickler die Sache unter einem anderen Begriff.

3. Wozu hat man (Hochschul)zeugnisse? Wenn da ne 1 in Software Engineering steht, dann braucht man Kindergeburtstagfragen von wegen OOP / Vererbung / Konstruktor nicht stellen.

4. Inwiefern sichert das einen ab? Ein Informatiker mag wissen, welche Design Patterns es gibt und wie man mit Scrum-Buzzwords um sich wirft, ist aber von der mathematischen / algorithmischen Seite eine Pfeife, weil er das Studium abgebrochen hat und in Analysis eine Niete war.

Tja, ein Hochschulstudium macht noch keinen guten Entwickler. Und dementsprechend checken dass die Techniker im Vorstellungsgespräch auch ab. (Wenn man dann bei diesen "Lulu-Themen" nichts zu sagen hat, tja - man kann ja noch in die Forschung gehen.)

Man muss damit leben, dass es Leute gibt, die das Studium absolvieren möglicherweise sogar in den Mathedingen top waren aber sich in Entwicklungssachen mitziehen haben lassen.

@marco.b
Die Alternative wäre nichts zu fragen ... jetzt auch nicht die beste Lösung.

eben meiner Erfahrung nach gehts ja auch nicht primär darum das man ein .Net guru ist sondern wie tut der Bewerber. wie redet er, wie sicher ist er und man erkennt auch bei Kindergarten fragen ob er was verstanden hat.
Und wie geht er mit den Dingen um wo er sich nicht auskennt.

Bei neuen Leuten schau ich auf folgende Merkmale

1. Eine gesunde Basis in der Ausbildung (deckt der Bewerber die notwendigen Skills ab oder sehe ich das Potential das er es bald können wird)
2. Passt er ins Team, wenn ich das Gefühl habe das er menschlich nicht dazu passt, kann er 7 Doktor Titel haben, zeig ich ihm sofort die Tür.
3. Hat der Bewerber spezielle Kenntnisse die für uns interessant sein könnte.

Programmiertests oder spezifische Fragen zu einem Framework sind meiner Meinung Kindergarten. Die kram ich nur hervor wenn ich glaube der Bewerber schönt seine Skills. Ein paar gezielte Fragen zieht dann den meisten e die Hosen aus.

[...]
2. Passt er ins Team, wenn ich das Gefühl habe das er menschlich nicht dazu passt, kann er 7 Doktor Titel haben, zeig ich ihm sofort die Tür. [...]

Punkt 2 ist insofern auch sehr wichtig, da sich sonst der Neue auch schnell aus der Firma verabschiedet wenn er nach einer Einarbeitungsphase plötzlich merkt seine Kollegen oder die Unternehmenskultur sind ihm nicht ganz recht. (Ist uns einmal passiert, nicht so schön für alle Beteiligten.)