Zadania na rozmowach kwalifikacyjnych...

Byłem jakiś czas temu na rozmowie o pracę jako programista w pewnym szacownym banku. Najpierw standardowa rozmowa z dwoma tambylcami, przepytali mnie o różne rzeczy dotyczące ASP.NET, w zasadzie nic niespodziewanego. No może poza tym, że odpowiedź na jedno pytanie trochę skopałem, bo dotyczyło pewnych podstaw języka, które są dla mnie tak naturalne, że nie bardzo potrafię je wyjaśnić. Na jedno pytanie nie odpowiedziałem w ogóle, bo niby jaka może być odpowiedź na pytanie: "Jak zoptymalizowałby pan prędkość ładowania strony korzystającej z 30 web serwisów?". Miałem powiedzieć, że zrobiłbym to bardzo dobrze, a nawet zajebiście, czy spytać skąd wzięli taką stronę, bo mi to wygląda na błąd w architekturze?
No, ale dobra, po rozmowie miałem dostać zadanie praktyczne...
W tym celu z pokoju zostałem zaprowadzony do open space, w którym ciągle pracowali, rozmawiali i wygłupiali się ludzie, i posadzony przed jednym z komputerów. Może ja się nie znam, ale w poprzedniej robocie prowadzono rekrutację, to kandydat siedział sam w cichej sali i dostawał laptopa do wykonania zadania. WTF #1.
Zadanie było banalne, napisać kontrolkę serwerową ASP.NET, która będzie się składała z jakichś tam innych standardowych kontrolek frameworka i ma coś tam robić. Niby nic trudnego, z tymże, ja takie coś robiłem dwa razy w życiu, ostatnio 1,5 roku temu. No i te moje kontrolki były nieco bardziej zaawansowane, tzn. po pierwsze nie były składane z istniejących kontrolek tylko "ręcznie" renderowałem kod HTML i JS, a po drugie były bardziej skomplikowane - coś w rodzaju input+button, który po wciśnięciu dynamicznie generuje dialog z zestawem pól (zdefiniowanym w BD) do pobierania od użytkownika jakichś danych, po czym przekazujący je do obliczenia do odpowiedniej procedury składowanej (jej nazwa też zdefiniowana w BD), itp.
Jak już wspomniałem, dawno tego nie robiłem, więc pamiętałem jedynie, z której klasy muszę dziedziczyć, ale nie pamiętałem dokładnie kolejności innych działań, tj. którą metodę muszę przeciążyć, żeby wyrenderować swoją kontrolkę, jak się obsługuje eventy, itp. Skutkiem czego, nie wykonałem tego prostego zadania. Nie miałem dostępu do dokumentacji, ani internetu, dali mi go łaskawie dopiero 15 minut przed końcem czasu, a więc nieco za późno, abym mógł doczytać i przypomnieć sobie, jak to się robi. WTF #2
A tak w ogóle, to wg nomenklatury ASP.NET, kontrolka złożona z gotowych kontrolek, to composite control. Server control, to tak jak opisałem powyżej, ręcznie renderowany HTML. WTF #3

Wnioski:

1. Panowie z banku nie mają chyba doświadczenia w rekrutacji.
2. Bogatego banku nie stać na jednego laptopa, którego by mogli zanieść kandydatowi do pokoju, a jedynie na kijowe desktopy z zacinającymi się klawiaturami i kwadratowymi monitorami.
3. Odpowiednio dobierając pytania i nie dając dostępu do dokumentacji, łatwo jest udowodnić, że ktoś z 1,5 rocznym doświadczeniem w technologii, absolutnie nic nie potrafi.
4. Nie zawsze jest tak, że rozmowy z osobami technicznymi są lepsze niż z HR. HR zazwyczaj ma przynajmniej cycki.
5. Nawet gdybym przeszedł kwalifikację, nie chciałbym tam pracować.

I tak się zastanawiam - może ja faktycznie powinienem znać na pamięć dokumentację, a to, co opisuję jest normalne, tylko ja jak zwykle marudzę?

Korzystanie w systemach bankowych z takiej ilości webserviców to żaden błąd w architekturze, tylko raczej dość powszechna praktyka. Tym bardziej że nie to muszą być "ich" webservice'y, tylko takie z których system korzysta do pobierania danych...
ad.1. nie wiem skąd ten wniosek, bo z twojego posta nijak to nie wynika
ad.2. a może bogaty bank chciał sprawdzić jak będziesz w stanie pracować w warunkach zbliżonych do tych, w których potencjalnie będziesz pracował? Co z tego że poradzisz sobie z zadaniem siedząc godzinę w cichym pokoju, skoro w pracy będziesz musiał takie zadania rozwiązywać w kilka minut w gwarnym open-space? (inną kwestią jest efektywność pracy w takim środowisku, ale to rozkmina nie na temat)
ad.3. Masz rację, jak ktoś chce to zawsze udowodni ci że czegoś nie umiesz. Przedstawiłeś tutaj tylko dwa pytania z tej rozmowy i:
a) pierwsze jest zupełnie normalnym pytaniem, co więcej bardzo praktycznym pytaniem dotyczącym realnych problemów w systemach bankowych
b) drugie pytanie, sam napisałes że "zadanie było banalne" a jednak sobie z nim nie poradziłeś. Wątpie żeby chodziło o znajomośc dokumentacji na blachę, ale jednak jeśli nie umiesz "banalnego" zadania rozwiązać bez zaglądania do dokumetancji to jednak może coś jest nie tak? Nie znam się na ASP.NET więc nie wiem jak skomplikowane jest to zadanie. Ale gdybym prowadził rozmowę rekrutacyjną i ktoś nie poradziłby sobie z napisaniem konfiguracji jakichś prostych beanów springowych, albo nie umiałby dopisać adnotacji hibernate do jakiejś prostej klasy, albo nie umiał napisac prostego beana ejb (w zależności od tego jaka technologia byłaby potrzebna), twierdząc że potrzebuje do tego dokumentacji, to bardzo mi przykro, ale bym mu podziękował. Nie trzeba umieć wszystkiego na blachę, ale pewne podstawy trzeba umieć.
ad.4. Nie rozumiem co chcesz powiedzieć przez "lepsze". To są zwykle zupelnie inne rozmowy, testujące inne aspekty kandydata. Techniczna rozmowa ma sprawdzić czy coś umiesz. Rozmowa z HR ma zwykle sprawdzić jaki masz charakter i czy pasujesz do zespołu.
ad.5. A ja myśle że przemawia przez ciebie zwykła złość że poszło ci słabo.

Ad 2. Być może, ale gdyby chodziło o test wytrzymałości, to czemu nie przeprowadzać rozmowy na bazarze, a kandydat mógłby być obrzucany bananami przez stado małp? To by był lepszy test niż w miarę spokojny open space.
Po prostu pierwszy raz spotkałem się z rozmową kwalifikacyjną prowadzoną w open space, popytałem też swoich kolegów, żaden nie miał takiej przygody, i wszyscy byli bardzo zdziwieni. Może to normalne w bankach, a może tylko w tym jednym, ja chyba jednak wolę firmy, które prowadzą rekrutację w mniej żenujący sposób.
Ad 3. Nie no, jasne. Uznajmy po prostu, że 1,5 roku mojego życia w ogóle nie miało miejsca, a tak naprawdę jestem murarzem. ;)
Zadanie nie jest skomplikowane, ale jak napisałem, w poprzedniej pracy przez 1,5 roku robiłem to 2 razy, czyli bardzo rzadko. Wydaje mi się, że mogłem nie pamiętać jak zrobić coś, czego nie robi się na co dzień.
Ad 4. Taka opinia panuje, także i na tym forum, że z głupkami z HRu nie ma co gadać, sens jest tylko z ludźmi technicznymi. :)
Ad 5. O złość można by mnie posądzać, gdyby zależało mi na pracy tam. :) Tymczasem tak nie jest - open space, niewygodny sprzęt, i w moim odczuciu niekompetencja, nie są ani trochę zachęcające.

ad.2. Ale w pracy nie będziesz takich zadań wykonywał na targu i nikt bananami rzucać nie będzie ;)
ad.4. Taka opinia panuje bo koderzy zwykle lepiej radzą sobie na tych technicznych rozmowach ;) Bo z HR muszą rozmawiać z kobietami, często w obcym języku, często o jakimś nie-nerdowskim hobby i jeszcze muszą wypaść na team-playerów a nie introwertycznych geeków ;]
ad.5. Zobaczymy jak zadzwonią i powiedzą że byłeś najlepszym kandydatem jakiego mieli :P

Po pierwsze na rozmowie kwalifikacyjnej pracodawca powinien sprawić aby pracownik czuł się komfortowo. Jeżeli to o czym mówisz to był specjalny test na odporność na stres to ja bym nie chciał w takiej firmie pracować. Przeprowadzenie takiego testu oznacza, że praca tam będzie stresująca, a ja nie chce chodzić zestresowany :].
Po drugie nie wiem co to za głupia praktyka dawania zadań do rozwiązania od razu w firmie w stresujących warunkach. Jaki problem dać zadanie do domu? Można wtedy wymyśleć bardziej ambitny problem do rozwiązania a kandydat ma szansę się wykazać. No chyba, że chcieli sprawdzić odporność na stres to wtedy patrz punkt pierwszy.

Shalom napisał(a):

Ale gdybym prowadził rozmowę rekrutacyjną i ktoś nie poradziłby sobie z napisaniem konfiguracji jakichś prostych beanów springowych, albo nie umiałby dopisać adnotacji hibernate do jakiejś prostej klasy, albo nie umiał napisac prostego beana ejb (w zależności od tego jaka technologia byłaby potrzebna), twierdząc że potrzebuje do tego dokumentacji, to bardzo mi przykro, ale bym mu podziękował.

Jeżeli to są rzeczy, które programista Javy EE robi codziennie to ok, ale jeżeli raz na rok to to jest bez sensu. Czy to są rzeczy, które wymagają lat doświadczeń i studiów informatycznych? Czy może przysłowiowych pięciu minut z dokumentacją. Widzę, że rynek programistów Javy jest naprawdę przesycony jeżeli można ich odrzucać z tak błahych powodów. Szukacie klepaczy konfiguracji, czy programistów?

@Mr Obvious ale idąc tym tokiem rozumowania to właściwie wszystko można wrzucić do kategorii "5 minut z dokumentacją". W efekcie rozumiem że proponujesz zatrudniać ludzi którzy nie umieją programować, ale umieją czytać? Lata doświadczenia i studia pomagają projektować porządne rozwiązania na wyższym poziomie, tzn na poziomie architektury aplikacji czy na poziomie modułów/komponentów. Ale mimo wszystko jak ktoś jest koderem, to musi umieć pewne rzeczy napisać. Cóż mi po gościu który potrafi mi słowno-muzycznie opowiedzieć o jakimś rozwiązaniu, ale będzie siedział nad nim 3 dni z książka / dokumentacją, kiedy to jest robota na 30 minut dla gościa który umie programować? To jest zwyczajnie nieefektywne i przesycenie rynku nic do tego nie ma. To jest prosty rachunek ekonomiczny - programista musi swoją pracą zarobić dla pracodawcy więcej niż sam kosztuje.
Zresztą inną rzeczą jest rekrutacja na Junior Developera (co miało przypuszczalnie miejsce w tym przypadku) a czym innym rekrutacja na Senior Developera albo Architekta. Od tego pierwszego nie wymaga się lat doświadczenia i skończonych studiów, tylko umiejętności programowania :P

Po prostu sobie nie poradziłeś i wylewasz żale na forum bo to "pracodawca jest winien" że ma wymagania i nie zatrudni pierwszego lepszego z ulicy.

Nawet gdybym przeszedł kwalifikację, nie chciałbym tam pracować.

Jak w piaskownicy "ja tak sie nie bawie!"

1. Nie wiem czy się nie znają, ciężko powiedzieć na podstawie tej relacji.

2. Miałem kiedyś rekrutację w takich warunkach, ale szczęśliwie sobie poradziłem. Moja praca została wtedy oceniona pozytywnie na 7/10. Przyznaję, że było to bardzo stresujące, ponieważ sam fakt rozmowy jest stresujący, a co dopiero rozwiązywanie zadania wśród rozgadanych pracowników na open space. Możliwe, że zadanie miało właśnie sprawdzać odporność na stres?!

3. To akurat czasem się zdarza i nic na to nie można poradzić. Kiedyś zostałem zapytany o pewną konstrukcję składniową języka za pomocą polskiego określenia, którego nie znałem. Po rozmowie okazało się, że świetnie znałem tę konstrukcję, ale pod oryginalną angielską nazwą, która nie miała nic wspólnego z polskim odpowiednikiem. Tak się składa, że było to jedyne pytanie dotyczące języka, które mi zadano.

Wyszedłem na oszusta, który podaje bardzo dobrą znajomość języka, a nie potrafi odpowiedzieć na postawione pytanie. Na to wszystko machnąłem ręką i stwierdziłem "wasza strata". Naprawdę czułem się na siłach, byłem pewny swojej znajomości języka, ale rekrutacja została przeprowadzona w taki sposób, który jak się okazało był niedoskonały. Z tego też powodu, pytanie tylko o jedno zagadnienie czy to w trakcie rozmowy, czy w zadaniu do rozwiązania jest ogromną pomyłką. Ktoś może dobrze znać język i technologię, ale z jakiegoś powodu tego jednego zagadnienia nie zna, zna pod inną nazwą albo od dawna nie używał.

1. Czasem rozmowa z HR przebiega bardzo przyjemnie, innym razem spotykasz się z gradem głupich pytań. Podobnie bywa na rozmowie "technicznej".

2. Z tego co napisałem, ja również nie chciałbym tam pracować. Po pierwsze nie przepadam za pracą na open space, po drugie sposób przeprowadzenia rekrutacji sugeruje, że praca jest stresująca. Po co się denerwować, jeżeli gdzieś indziej mogę dostać podobną pensję, ale za to w bardziej sprzyjającym kreatywności środowisku?!

Bardzo często spotykałem się z czymś takim zwanym "marnowanie mojego czasu". Bo ktoś nie doczyta CV, zobaczy ASP.NET, ktoś tego nie zweryfikuje itd itd..

Dodatkowo, nie wiem czemu, ale byłem na jednej mega nieprzyjemnej rozmowie, w firmie gdzie Pani z HRu po podaniu mi do wypełnienia testu z WebFormsów, których praktycznie nie znam (kto by tam czytał CV, bo i po co?). Zaczęła mnie wypytywać o to co mogłoby mnie skusić do przejścia do nich, do pozostania do nich itp (Pojawiły się mega nieprzyjemne pytania typu "A jaką ja mam pewność, że za jakiś czas Pan od nas nie odejdzie?", to chyba proste, że "ŻADNĄ !" i wszystko zależy tylko i wyłącznie od Was i od warunków tu panujących). Aż miałem ochotę w pewnym momencie stamtąd wyjść. Dość często zdarzają mi się sytuacje, że po rozmowie w danej firmie już wiem, że nie chce tam pracować z jakiegoś powodu.

Więc to raczej coś normalnego ;) A pisanie tutaj o tym, że ktoś kto nie umie zrobić kontrolki bo nie zna ASP.NET (chyba raz w życiu robiłem takie cudo w WebFormsach) zbyt sensownym podejściem raczej nie jest.

Shalom napisał(a):

ale idąc tym tokiem rozumowania to właściwie wszystko można wrzucić do kategorii "5 minut z dokumentacją

Nie można, byłeś na studiach to wiesz, że było pełno egzaminów/kolosów z dostępem do notatek, które nie tak łatwo było zdać ;) Żeby czegoś poszukać, musisz najpierw wiedzieć, że coś takiego istnieje.

Shalom napisał(a):

ale będzie siedział nad nim 3 dni z książka / dokumentacją, kiedy to jest robota na 30 minut dla gościa który umie programować?

To bardzo interesująca historia, ale można ją odwrócić o 180 stopni, gdzie ten pierwszy gościu zna rodzaj problemu i rozwiąże go w godzinkę, a ten drugi nawet nie wie od czego zacząć. Pytanie czego jest trudniej się nauczyć. W 3 dni to można przeczytać książkę z podstawą konfiguracją JEE, czy popularnymi snippetami ze Springa. I jeżeli to głównie robicie w pracy, to te "3 dni" starczą na lata, czyli koszt dla pracodawcy jest znikomy, nie wspominając już, że te "3 dni" to pewnie będzie weekend poza czasem pracy ;)

Shalom napisał(a):

Zresztą inną rzeczą jest rekrutacja na Junior Developera (co miało przypuszczalnie miejsce w tym przypadku) a czym innym rekrutacja na Senior Developera albo Architekta.

Oczywiście, junior nawet nie musi wiedzieć co to Spring, EJB, czy Hibernate. Chociaż to mało prawdopodobne, żeby o nich nie słyszał, jeżeli chce pracować w tych technologiach. Bez sensu jest odsiewać dobrych kandydatów na juniora bo nie używają wszystkich naszych "ulubionych" technologii.

Shalom napisał(a):

Od tego pierwszego nie wymaga się lat doświadczenia i skończonych studiów, tylko umiejętności programowania :P

I sprawdzasz to poprzez umiejętność konfiguracji Springa? Poprzez takie pytania, sprawdzasz tylko jak dobrą pamięć ma kandydat.

Ja w chwili obecnej nie potrafilbym napisac XMLowej konfiguracji Springa z pamieci - przerazaja mnie te ich namespacy, ktorych po prostu nie pamietam. Jedyne co pomaga to albo net, albo wiedza ze taki spring-beans.jar ma wszystkie schemy zawarte w sobie, czego pewnie i Shalom nie wie (ale moze sie myle), i mozna podpatrzec. Mozliwe ze bym umial uzyc JavaConfig i adnotacje, ale teraz z glowy nie wiem jakiego jara mam uzyc... Taka konfiguracje robi sie raz na projekt, pozniej tylko dorzuca nowe <bean /> lub @Bean za pomoca copy and paste i podpowiadania skladni przez edytory (ja uzywam IDEA i jest mega). Jesli pizgacie takie pliki z pamieci w notatniku to pelen szacun, ale ja nie mam miejsca na takie smieci. Czy to znaczy ze nie umiem programowac?
W kilku sprawach somekind ma IMHO racje (ja tez chce laptopa i jak najmniej stresu) ale w innych sie myli - nie umie w VS 20xx wyklepac kontrolki / komponentu? Przeciez tam jest dokumentacja, code completion itp. No chyba, ze kazali to robic w notepadzie, wtedy patrz wyzej.
Co nie znaczy, ze calkowicie popieram somekinda - wielokrotnie na forum sie wymadrzal i cwaniaczyl, a sie okazalo ze zwykly z niego code-monkey (moze nawet rzucaja w niego banami na rynku, skads ten pomysl musial mu przyjsc do glowy) ktory wylewa teraz swoje zale. Doswiadczenie 1.5 roku i juz pewnie senior czy inny architekt, wielkie mniemanie o sibie, a prawda taka ze nic jeszcze nie widzial. Troche pokory i nauki.

ad 1. być może tak być może nie. Może kwestia sezonu urlopowego.
ad 2. patrz 1. Zorganizowanie rekrutacji (w sensie spotkania) przez osobę, która tego nie robi na co dzień (HR) to już wyzwanie i pewne szczególy umykają.
ad 3. można i z 20 letnim stażem. Kwestia pytań.
ad 4. techniczni też mogą mieć cycki, a HR ich nie mieć.
ad 5. bo rekrutacja to proces obopólny. Ty też oceniasz firmę, a twój przypadek jest super przykładem takiej relacji.

Ucilala ma sporo racji. Mówię z perspektywy osoby, która dopiero zaczyna przygodę z komercyjnym programowaniem, za to mam już doświadczenie w innej branży. Ludzki mózg ma ograniczoną pojemność. Z latami wypełniasz sobie głowę wiedzą zawodową, hobbystyczną, doświadczeniami życiowymi, śmieciowymi informacjami z onet.pl i telewizji etc. W pewnym wieku zaczynasz zdawać sobie sprawę, że twoje szare komórki są tak bardzo wypchane różnymi faktami, że coraz trudniej jest nauczyć się na pamięć czegoś nowego. W moim poprzednim zawodzie musiałem znać na pamięć kilka ustaw i umieć w mig zrobić ich syntezę dla rozwiązania podanego przez klienta problemu prawnego. Między innymi dlatego zdecydowałem się zostać programistą, gdyż wolę myśleć niż pamiętać. Niedawno będąc na szkoleniach z Javy rozmawiałem na ten temat z prowadzącym. Przyznał, że zwykle jest tak, że jak nauczysz się dobrze jednej technologii, to jednocześnie zapominasz trochę z poprzedniej. Programista powinien mieć przede wszystkim kreatywny umysł i mentalność "da się zrobić". Dokumentacja i internet to są cegłówki, z których buduje projekt. Bez tych cegieł ciężko jest mu cokolwiek zbudować. Ja osobiście potrafię "z głowy" wyklepać nawet bardzo złożone interfejsy graficzne w Swingu, bo to pisałem już w wielu projektach. Ale miałbym problem ze wspomnianymi przez Shaloma adnotacjami w Hibernate, abstrahując nawet od faktu, że z przyzwyczajenia używam plików mapujących XML. Same pliki mapujące można zresztą wygenerować na podstawie istniejącej bazy danych, więc też tym bardziej ciężko napisać je z głowy. Ważne, by rozumieć, do czego służy poszczególny fragment i umieć go zaktualizować w celu zachowania zgodności z klasą domenową, której mapowaniu jest on poświęcony.

@ucilala & @Mr Obvious ale gdzie ja mówiłem że sadzasz gościa przed kartką papieru / notatnikiem? Przecież somekind siedział przed komputerem z IDE i podpowiadaniem składni. Jeśli ktoś w takiej sytuacji nie umie dopisać konfiguracji nowego beana (czyli stuknąć 5 razy ctrl+spacja, albo zerknąć do jara gdzie takie konfigi leżą) to bardzo mi przykro. Z EJB i Hibernatem jest to samo, chyba że ktoś programuje lodówką albo w notatniku.

Po pierwsze, informacja dla niektórych, m.in. ucilala i Shalom - napisałem już wyraźnie, że dokumentacji nie było. Nie było ani zainstalowanej lokalnie, a z online nie mogłem skorzystać, bo nie znałem hasła pozwalającego na dostęp do internetu. Samo IntelliSense podpowiada nazwy metod i klas, a nie kolejne kroki działania. Jak jesteście tacy super, to odpalcie VS, i napiszcie system operacyjny. Przecież jest podpowiadanie!

Piszecie niektórzy, że sadzając mnie w open space chcieli sprawdzić jak sobie radzę w realnych, stresujących warunkach. Może i tak, ale to przecież nie były realne warunki, bo nie miałem dostępu do dokumentacji! No chyba, że u nich w firmie pracownicy też nie mają dostępu do internetu. :|

Shalom napisał(a):

@Mr Obvious ale idąc tym tokiem rozumowania to właściwie wszystko można wrzucić do kategorii "5 minut z dokumentacją". W efekcie rozumiem że proponujesz zatrudniać ludzi którzy nie umieją programować, ale umieją czytać?

Umiejętność czytania i szukania informacji jest tym bardziej wartościowa, im bardziej skomplikowane jest zadanie. Dobry programista znajdzie rozwiązanie w godzinę, natomiast ten, który potrafi programować tylko z pamięci, będzie siedział trzy dni i nic nie zrobi.

Cóż mi po gościu który potrafi mi słowno-muzycznie opowiedzieć o jakimś rozwiązaniu, ale będzie siedział nad nim 3 dni z książka / dokumentacją, kiedy to jest robota na 30 minut dla gościa który umie programować?

Gość, który umie programować, nauczy się szczegółów implementacji w jeden dzień i później będzie pełnowartościowym pracownikiem. Słaby koder, który akurat potrafi zrobić to, czego kiedyś wyuczył się na pamięć i akurat trafiło mu się na rozmowie, pełnowartościowym programistą może nigdy nie zostać.

To jest prosty rachunek ekonomiczny - programista musi swoją pracą zarobić dla pracodawcy więcej niż sam kosztuje.

A to akurat sprawdzić można tylko podczas okresu próbnego, dając realne zadania. (I dostęp do dokumentacji/internetu.)

Zresztą inną rzeczą jest rekrutacja na Junior Developera (co miało przypuszczalnie miejsce w tym przypadku) a czym innym rekrutacja na Senior Developera albo Architekta. Od tego pierwszego nie wymaga się lat doświadczenia i skończonych studiów, tylko umiejętności programowania

To nie była rekrutacja na juniora. Myślę też, że od juniora nie wymaga się umiejętności programowania, tylko znajomości składni języka, jakiejś części biblioteki standardowej oraz zrobienia GUI ze standardowych komponentów (a nie tworzenia własnych).

ucilala napisał(a):

W kilku sprawach somekind ma IMHO racje (ja tez chce laptopa i jak najmniej stresu) ale w innych sie myli - nie umie w VS 20xx wyklepac kontrolki / komponentu?

Pisałem przecież, że potrafię napisać kontrolkę. Na rozmowie po prostu nie pamiętałem szczegółowo sekwencji niezbędnych czynności.

Co nie znaczy, ze calkowicie popieram somekinda - wielokrotnie na forum sie wymadrzal i cwaniaczyl,

Dziwne tylko, że to moje wymądrzanie i cwaniaczenie było wielokrotnie pomocne dla użytkowników, stojąc w zgodzie zarówno z dobrymi praktykami danego języka/technologii, jak i dobrymi praktykami programistycznymi.

a sie okazalo ze zwykly z niego code-monkey

A skąd wyciągasz taki wniosek? Napisałem na tym forum kilka tysięcy postów z zakresu C#/.NET oraz kilkaset odnośnie analizy i projektowania obiektowego oraz modelowania baz danych. Konkretnie które świadczyły o tym, że nie umiem projektować?

ktory wylewa teraz swoje zale.

Czemu tak bardzo chcesz dobić do poziomu tego małego kryptogeja?
Opisałem, co mi się przydarzyło, jak widać kilka osób tutaj również jest zdziwiona takim podejściem do kandydata, oni też wylewają swoje żale?

Doswiadczenie 1.5 roku i juz pewnie senior czy inny architekt, wielkie mniemanie o sibie, a prawda taka ze nic jeszcze nie widzial. Troche pokory i nauki.

Senior? Architekt? O czym Ty koleś bredzisz?
Skąd wiesz, czego ja nie widziałem? Masz jakieś uwagi co do usług, które rozwijałem, a z których codziennie korzystasz? (Nie piszę jakich, bo skoro tak dobrze mnie znasz, to wiesz o co chodzi.)

Ja chyba jestem idealistą, bo dla mnie programista to ktoś, kto potrafi rozwiązywać problemy i dostarczać funkcjonalność robiąc to zgodnie z dobrymi praktykami i pisząc czysty kod, a nie znać na pamięć jakiś framework GUI, którego opanowanie zajmuje miesiąc. Ktoś, kto analizując problem od razu widzi miejsce do zastosowania np. strategii albo adaptera, i to je będzie potrafił napisać z pamięci, a nie jakąś durną kontrolkę. Ktoś, kto wie, jak zrealizować dziedziczenie w bazie danych, a nie pisze xmlowe mappingi z pamięci. Ktoś, kto zna różnice między MVP, a DDD (tak, nie wszyscy znają!). Ktoś, kto potrafi dobrać odpowiednią strukturę danych w danej sytuacji i wie, że do częstej konkatenacji używa się specjalnych klas, a nie zwykłego stringa. Itd., itp.

somekind napisał(a):

Pisałem przecież, że potrafię napisać kontrolkę. Na rozmowie po prostu nie pamiętałem szczegółowo sekwencji niezbędnych czynności.

Nie widzisz bezsensu tej wypowiedzi? Umiesz, ale nie pamietasz jak?

ucilala napisał(a):

Nie widzisz bezsensu tej wypowiedzi? Umiesz, ale nie pamietasz jak?

Umiem - potrafię wykonać kontrolkę, która spełnia założoną specyfikację funkcjonalną i ma praktyczne zastosowanie w działającym systemie.
Czekam na odpowiedź w kwestii "code monkey".

Programiści lubią sobie dogryzać, jak nie robimy czegoś na co dzień to bez dostępu do dokumentacji z głowy tego nie wygrzebiemy, co nie znaczy, że tego nie potrafimy. Myślę, że ci ludzi, którzy krytykują somekind nie mają jeszcze doświadczenia w pracy programisty - gdzie powszechne jest wspomaganie się Internetem.

ucilala napisał(a)

wielokrotnie na forum sie wymadrzal i cwaniaczyl

Ja myślę, że @ucilala miał na myśli Twój ton wypowiedzi, nie zaś jej zawartość merytoryczną. Czytam różne tematy na forach i widzę różnicę w odpowiedziach Twoich od odpowiedzi innych użytkowników. Większość osób odpisze życzliwie lub przynajmniej neutralnie. Ty natomiast często odpisujesz tak, jakbyś chciał pytającego zmieszać z błotem na zasadzie: "jak śmiesz w ogóle o to pytać?!", "co Ty gadasz za głupoty?!". Poza tym ostatnie fragmenty Twojej wypowiedzi:

Czemu tak bardzo chcesz dobić do poziomu tego małego kryptogeja?

O czym Ty koleś bredzisz?

Dowodzą, że coś jest nie tak. Tak się nie zachowują profesjonaliści. A zgaduję, że chciałbyś być takim postrzegany.

Goodrock napisał(a):

Większość osób odpisze życzliwie lub przynajmniej neutralnie. Ty natomiast często odpisujesz tak, jakbyś chciał pytającego zmieszać z błotem na zasadzie: "jak śmiesz w ogóle o to pytać?!", "co Ty gadasz za głupoty?!".

Cenię Twoją uwagę i się z nią zgadzam, chciałbym jednak zobaczyć jakieś konkretne przypadki.
Ja w ten sposób odpisuję zazwyczaj leniom, którzy nie przeczytali dokumentacji, nie spróbowali użyć Google czy wyszukiwarki na forum, ani nie chcą się wysilić na zadanie precyzyjnego pytania i zapisania go w czytelny sposób. (Czasami też tym, którzy zakładają, że każdy programista C# musi znać C++, bo tak ma być i już.)

Jeśli czujesz się urażony tym, że w Twoim wątku nazwałem C++ durnym językiem, to Cię bardzo przepraszam. I w sumie przyznaję, że się zagalopowałem, bo C++ nie jest durny, a "jedynie" okropny.

Poza tym ostatnie fragmenty Twojej wypowiedzi:

Czemu tak bardzo chcesz dobić do poziomu tego małego kryptogeja?

O czym Ty koleś bredzisz?

Dowodzą, że coś jest nie tak.

Tak, dowodzą, że ktoś imputuje i dopowiada sobie historię mojego życia, odczuć, itd. - jednym słowem, bredzi.

Tak się nie zachowują profesjonaliści. A zgaduję, że chciałbyś być takim postrzegany.

Nie mam zamiaru o to zabiegać, wszakże niektórzy tutejsi profesjonaliści nie widząc ani jednego mojego projektu, już mnie okrzyknęli kodującą małpą. Tego typu podejścia nie zmienią ani moje słowa, ani obiektywne fakty.

Tak czy siak:

1. Zażalenia odnośnie mojego tonu wypowiedzi należy składać w miejscu ich wystąpienia. (Bo może ja po prostu pisząc coś nie zdaję sobie sprawy, że nie jest to neutralne, więc nie mogę się poprawić.)
2. Na debaty o tym, że somekind to stary wredny uj i kodująca małpa, jest łysy, gruby, brzydki, ma drewniane oko i trzy szklane nogi, sugeruję założyć oddzielny wątek w dziale "Społeczność".

Jeśli czujesz się urażony tym, że w Twoim wątku nazwałem C++ durnym językiem, to Cię bardzo przepraszam. I w sumie przyznaję, że się zagalopowałem, bo C++ nie jest durny, a "jedynie" okropny.
To już nie chodzi nawet o to. Tym bardziej, że napisałeś o języku, a nie o mnie. Miałem na myśli również wypowiedzi pojawiające się w tematach nie założonych przeze mnie.

Tak, dowodzą, że ktoś imputuje i dopowiada sobie historię mojego życia, odczuć, itd. - jednym słowem, bredzi.

Ale dlaczego w takim razie nie spróbujesz odeprzeć jego argumentów w bardziej hm dorosły sposób? Niepotrzebne były słowa "koleś" i "kryptogej".

Bo może ja po prostu pisząc coś nie zdaję sobie sprawy, że nie jest to neutralne, więc nie mogę się poprawić.

Może warto kilka razy przeczytać swoją wypowiedź i zastanowić się, czy jest neutralna, a jeśli nie, to poprawić kilka zdań by została lepiej odebrana? Może zechcesz teraz napisać "nie chce mi się, nie mój problem". Ale przecież to dużo nie kosztuje.