Rozmowa kwalifikacyjna, część techniczna młodszy programista .Net

Witam, mam do Was starych wyjadaczy jeżeli chodzi o rozmowy kwalifikacyjne pytanie. Mianowicie w przyszłym tygodniu umówiłem się na kilka rozmów kwalifikacyjnych na stanowisko młodszego programisty .net, wiem że będzie normalna rozmowa kwalifikacyjna, czyli dlaczego ta firma opowiedz o tym co dotychczas zrobiłeś i takie tam, a druga cześć to część techniczna ze znajomości platformy i języka C#. Czego można się spodziewać w takiej części technicznej?

Z góry dzięki za wszystkie odpowiedzi
Pozdrawiam.

W ogóle korzystając z okazji miło by było jakby ktoś wrzucił jakieś przykładowe testy obojętnie czy to z C/C++, C#, Javy czy Visual Basica.
Kiedyś tu była stronka z takimi testami, ale nie dość, że płatna to jeszcze z błędami. Może ktoś ma coś sensownego to by się mógł podzielić :)

edit: mam na myśli oczywiście testy kwalifikacyjne do pracy. Wiem, że takowe układa się różnie i zależnie od firmy, ale... może coś ktoś ma.

Kiedyś tu był nawet wątek o pytaniach na rozmowę na programistę C#, ale zrobił się flame i został zamknięty.

Pytania, to:

1. Czym się różni interfejs od klasy abstrakcyjnej?
2. Czym się różnią typu wartościowe od referencyjnych, podać przykłady znanych typów obu rodzajów.
3. Jakie znasz kolekcje?
4. Jaką klasą najprościej zapisać dane z obiektu do pliku XML?
5. Jak znasz metody dostępu do baz danych z aplikacji .NET?
6. Napisać kod wyświetlający na konsoli liczbę wierszy z jakiejś tabeli w bazie danych.

jak chcecie jave to java black belt factory, http://knowledgeblackbelt.com/

Jeżeli uderzasz na młodszego programistę (czyli doświadczenie w innych firmach małe lub żadne) możesz dostać jakieś algorytmiczne problemy do rozwiązania.

Ja zawsze dostaję pytanie o fabrykę abstrakcyjną. A odpowiedzią jest zawsze wyśmianie wzorców i Head First ;)

I jak poszło na rozmowach? O co pytali?

Zbiór problemów, jakie napotykamy jest nieograniczony, zbiór wzorców - niewielki. Większości problemów nie da się rozwiązać, stosując wzorce, a szukając analogii do historyjek o ciasteczkach, tortach itp. (takie są w Head-First) to komedia. Dobry programista nie potrzebuje znać żadnego wzorca, sam wymyśli odpowiednie rozwiązanie, które będzie umiał potem zmodyfikować, ulepszyć itd.

Owszem, sam czasami korzystam z wzorców, ale zawsze robię to bezwiednie.

A na dodatek nie znoszę OOP, lecz to zupełnie inna bajka ^^.

co do niepotrzebności wzorców, jak masz w jakimś miejscu wzorzez to wiesz już coś jak dany kawałek kodu działa (bądź powinien działać), wzorce sa z reguły dobrze opisane wiec masz jakąś czesc dokumentacji - i łatwiej rozmawiać z innymi mówiąc tu jest taki/a taki wzorzec niż tu jest taka klasa która dziedziczy po tamtej klasie implementującej tamte dwa interfejsy i posiada taką virtualną metodę która powinna zwracać boola który mówi czy powinno wykonać się tamtą metodę z tej klasy abstrakcyjnej co jest na górze tego dziedziczenia.

ElevenEleven napisał(a)

Zbiór problemów, jakie napotykamy jest nieograniczony, zbiór wzorców - niewielki.

Dotyczy to również zbioru instrukcji języka, ale co z tego?

Większości problemów nie da się rozwiązać, stosując wzorce

Wzorce nie służą do rozwiązywanie większości problemów tylko do rozwiązywania problemów typowych. A większość problemów da się rozłożyć na n problemów typowych, które już można rozwiązać wzorcami.

Dobry programista nie potrzebuje znać żadnego wzorca, sam wymyśli odpowiednie rozwiązanie, które będzie umiał potem zmodyfikować, ulepszyć itd.

Dobry programista nie potrzebuje żadnego języka, napisze w pseudokodzie i chooj!

Jeśli zna się wzorce, to gdy widzi się jakiś typowy problem nie traci się czasu na zastanawianie, bo od razu się wie, co trzeba zrobić. Tak samo, gdy wiemy, że mamy coś wykonać określoną liczbę razy, użyjemy pętli for.
Można oczywiście samemu kombinować z hierarchią klas i interfejsów, ale w ten sposób i tak odkryje się koło na nowo, więc straci się czas. Można zdobywać całość doświadczenia samemu, a można skorzystać z doświadczenia innych, co jest szybsze i tańsze.

Wzorce to po prostu klocki do budowy programów, znajdujące się poziom wyżej od pętli i instrukcji warunkowych. Pewnym ograniczeniem jest ich nieznanie, również z przyczyn, o których napisał Moskitek wyżej.