Zestawy pytań z rozmów o pracę (kompetencje twarde)

0

Zastanawiam się czy są gdzieś w Internecie zestawy pytań jakie zadają pracodawcy kandydatom do pracy, szczególnie w dużych firmach typu IBM, Motorola, Samsung itp.? Nie pytam o wymysły w stylu "ile piłek wejdzie do autobusu" (temat o tym widziałem ostatnio na wykopie), tylko o pytania o umiejętności czysto programistyczne: składnię języków, fragmenty kodu do uzupełnienia, rozkminy z teorii programowania itp..

Wychodzę z założenia że lepiej przygotować się na to o co można być zapytanym.

Jeśli nie znacie takich stron z takimi zestawami pytań, pochwalicie się może jakie pytania WAM zadano?

0

Jeśli chodzi o Javę, to wygooglaj sobie blog Javarevisited ze słowami kluczowymi "top interview questions".

0
Shalom napisał(a):

Nie no żartujesz sobie?
http://4programmers.net/Forum/Kariera/148793-rozmowa_rekrutacyjna_-_programista_c++
Jak przygotować się do testów z programowania?
Rekrutacja przez telefon.
Zadania na rozmowach kwalifikacyjnych...
Rozmowa kwalifikacyjna
i wiele wiele innych...

Dzięki za linki, choć nie do końca są kompletne i nie ma w nich do końca tego czego poszukuję. Ale co tam, ponoć "żartuję sobie".

5

Kompetencje miękkie, kompetencje twarde... czy tylko mnie śmieszą te określenia? Założę się, że ich twórcą jest jakiś specjalista od kompetencji miękkich...

5

Tak się zastanawiam i dla mnie takie pytanie to jest w ogóle WTF... Albo znam dana technologię/język/framework w stopniu który podałem na CV i testy nie są mi straszne. Albo próbuję przedostać się przez testy fartem czy wykuwając odpowiedzi na pamięć... co z tego, że pracodawca wtedy straci, że ja stracę robotę jak się zorientują, że nie umiem..., że w oczach innych okażę się oszustem...

Może ja jestem jakimś dziwnym wyjątkiem(nie sądzę), że z pracodawcą traktujemy się po partnersku. Zgodziłem się na taką a nie inną płacę, zadeklarowałem, że potrafię to to i to i jeszcze do tego jestem w stanie zrobić to. To robię, zgodnie z umową, jakąś elementarna odpowiedzialnością za projekt - bo chcę, żeby to co zrobię było zrobione dobrze i dobrze funkcjonowało i co istotne - było wykonane w terminie.

P.S. Może zbyt emocjonalnie, ale to wydało mi się przykre...

0

Tak, rozumiem co masz na myśli. Ale o to co mam na swe usprawiedliwienie.

Na początku kariery ciężko wejść w branżę, gdyż wszędzie wymagane jest doświadczenie. Wychodzę z założenia, że chcę jakoś przedostać się przez sito rekruterskie i podjąć pracę, by na miejscu zdobywać doświadczenie i na prawdziwych problemach zdobywać umiejętności - a przecież żadna inna metoda nauki nie jest tak dobra.

Powiesz że powinienem aplikować na staże. Ale nawet tam często potrzebne jest doświadczenie.

0

W ogloszeniach jest napisane, ze potrzebne jest doswiadczenie, bo te ogleszenia ukladaja panie z HR. Natomiast w wiekszosci przypadkow na Junior Developera lub cos w ten desen, juz tak potrzebne ono nie jest. Jak juz sie dostaniesz na rozmowe, to beda sie liczyly umiejetnosci, ktore powinienes miec wypisane w CV. Natomiast wkuwanie pytan rekrutacyjnych na pamiec imo jest oszustwem.

[Ofc. Nie ujmujac roli doswiadczenia w tej pracy]

0

@okmanek bzdury. W ogłoszeniach wymagają doświadczenia, tak samo jak i wykształcenia żeby odsiać ludzi którym się wydaje że jak siedzą 8h dziennie na facebooku a przez kolejne 8 grają, to już są "informatykami" ;]
Tak, przychodzą nawet i tacy czasem na rozmowy na stanowisko programisty...
Ale próba "oszukiwania" na rozmowie żeby potem "nauczyć się w pracy" raczej nie zadziała bo jak się okaże że nic jednak nie umiesz to cię zwolnią ;]

0

@Shalom Hehe. Przypomniało mi się to: http://www.wykop.pl/ramka/997873/najlepsza-recenzja-ksiazki-o-programowaniu-w-c-ever/ . ;)
Co do samej rekrutacji, to niektóre firmy każą skodzić jakiś algorytm na żywo lub powiedzieć, jak można stworzyć algorytm do rozwiązania danego problemu lub dają kilka dni na napisanie konkretnego programu, a potem go oceniają.
W takich sytuacjach wykuwanie pytań nic nie da. Samo rozeznanie tematu pytań rekrutacyjnych nie jest złe, jeśli chcemy zorientować się w temacie, a nie je wkuwać.

0

@wiciu jeśli jakaś firma na rozmowie nie prosi cię o napisanie kawałka kodu / nie daje ci kodu do analizy / nie prosi o linka do githuba jakiegoś, to ja bym się bał w takiej firmie pracować ;) Bo przecież ty masz tam u nich kodzić, a oni nie chcą sprawdzić czy w ogóle potrafisz. Pomyśl jakich ludzi mogą czasem zatrudniać (i z którymi będziesz musiał pracowac) ;)

2
Shalom napisał(a):

@wiciu jeśli jakaś firma na rozmowie nie prosi cię o napisanie kawałka kodu / nie daje ci kodu do analizy / nie prosi o linka do githuba jakiegoś, to ja bym się bał w takiej firmie pracować ;) Bo przecież ty masz tam u nich kodzić, a oni nie chcą sprawdzić czy w ogóle potrafisz. Pomyśl jakich ludzi mogą czasem zatrudniać (i z którymi będziesz musiał pracowac) ;)

Myślisz, że można opowiedzieć o tym jak działa garbage collector, wymienić zastosowanie kilku wzorców projektowych, opowiedzieć o wadach i zaletach ORMów, wymienić poziomy izolacji transakcji i rodzaje indeksów, wiarygodnie opowiedzieć o dotychczasowych projektach w swojej karierze, i nie umieć pisać kodu?
Bo o ile zadanie "pracy domowej" w postaci małego programu jeszcze rozumiem, to programowania na kartkach podczas rozmowy raczej nie bardzo. To strasznie zajeżdża dziadowymi egzaminami z programowania na studiach, a niczego tak naprawdę nie sprawdza.

0

Pisanie kodu na kartce sprawdza jak dobrze piszesz kod na kartce. Nic więcej ;)

0
somekind napisał(a):
Shalom napisał(a):

@wiciu jeśli jakaś firma na rozmowie nie prosi cię o napisanie kawałka kodu / nie daje ci kodu do analizy / nie prosi o linka do githuba jakiegoś, to ja bym się bał w takiej firmie pracować ;) Bo przecież ty masz tam u nich kodzić, a oni nie chcą sprawdzić czy w ogóle potrafisz. Pomyśl jakich ludzi mogą czasem zatrudniać (i z którymi będziesz musiał pracowac) ;)

[...]
Bo o ile zadanie "pracy domowej" w postaci małego programu jeszcze rozumiem, to programowania na kartkach podczas rozmowy raczej nie bardzo. To strasznie zajeżdża dziadowymi egzaminami z programowania na studiach, a niczego tak naprawdę nie sprawdza.

A pisanie kodu "na żywo" np. w jakimś edytorze tekstu też będzie "dziadowe"? W zasadzie bez różnicy, czy piszesz na kartce, czy w edytorze tekstu. Na kartce może jedynie będzie wszystko pokreślone, ale filozofia ta sama, jeśli nie korzystasz w takim zadaniu z żadnego wspierającego IDE. Podczas rekrutacji do Google pisze się "na żywo" algorytm w edytorze on-line typu Google Docs, a nie sądzę, żeby zatrudniali tam byle kogo, więc nie wiem, czy ta metoda jest taka zła. Trudno powiedzieć.

1

Myślisz, że można opowiedzieć o tym jak działa garbage collector, wymienić zastosowanie kilku wzorców projektowych, opowiedzieć o wadach i zaletach ORMów, wymienić poziomy izolacji transakcji i rodzaje indeksów, wiarygodnie opowiedzieć o dotychczasowych projektach w swojej karierze, i nie umieć pisać kodu?

Oczywiście ze tak! Znam nawet całą masę ludzi którzy posiadają taką umiejętność. Bo to ze ja sobie przeczytałem jakieś 3 posty jakiegoś blogera, albo przeczytałem parę artykułów, wcale nie znaczy ze umiem tego używać w praktyce.
Ba, znam ludzi którzy potrafią ci wyłożyć zalety i wady jakiegoś wzorca, nawet diagramy namalować, ale nie potrafią go użyć w praktyce, nie widzą gdzie można go użyć i nie umieją zaimplementować...

Jasne ze nie chodzi tutaj o programowanie na kartce a raczej o sprawdzenie czy potrafisz. Jak umiesz bez bazgrania po tablicy powiedzieć jak być zrobił X czy Y to nie ma sensu tego pisać, to jasne. Jak powiesz ze uzyłbyś gdzieśtam hashmapy i cośtam byś z nia robił, to nie musisz pokazywać ze umiesz napisać new HashMap<> ;)

0
Shalom napisał(a):

Oczywiście ze tak! Znam nawet całą masę ludzi którzy posiadają taką umiejętność. Bo to ze ja sobie przeczytałem jakieś 3 posty jakiegoś blogera, albo przeczytałem parę artykułów, wcale nie znaczy ze umiem tego używać w praktyce.
Ba, znam ludzi którzy potrafią ci wyłożyć zalety i wady jakiegoś wzorca, nawet diagramy namalować, ale nie potrafią go użyć w praktyce, nie widzą gdzie można go użyć i nie umieją zaimplementować...

Bardzo łatwo można zweryfikować, czy ktoś wie o czymś, bo używał, czy tylko czytał o tym na blogu. Wystarczy spytać co sądzi na ten temat, albo widzi w tym zalety, wady, lub jakie zna alternatywy. Albo niech wymieni trzy najbardziej wkurzające rzeczy w danym języku/bibliotece/frameworku. W ogóle zadawanie pytań, na które nie ma prawidłowych odpowiedzi jest najlepszą metodą weryfikacji wiedzy.

Nie da się udawać wiedzy i doświadczenia przed kimś, kto wiedzę i doświadczenie ma. Jeśli rekruterzy się nabierają na takich ludzi, jak opisałeś, to znaczy, że sami nie potrafią programować. :P

1

IMHO w miare praktyczna zadanie do zakodowania w domu a potem dyskusja z kandydatem czemu użył takiego rozwiązania, sprawdza bardzo dobrze umiejętności koderskie. Jednak wciąż sporo firm (w tym te "topowe" jak google, facebook, amazon) na rozmowach woli rzucać kandydatom trudne zadania algorytmiczne do rozwiązania na kartce. Te bardziej przeciętne firmy małpują google i tak spirala bezsensu się nakręca. Autorowi wątku w ramach przygotowania do rozmów polecam poćwiczyć rozwiązywanie zadań algorytmicznych na kartce (nie na komputerze) bo niestety ma spore szanse, że właśnie coś takiego dostanie.

1

Ja tam zawsze się przygotowuję z jakichś top n pytań znalezionych w Internecie.

Czy to jest oszustwo?
Zdecydowanie nie, to jest logiczne następstwo tego, że sporo firm ciągle pyta o bzdury w stylu:

  1. Różnica pomiędzy ArrayListą a LinkedListą?
  2. Różnica pomiędzy Interfejsem a klasą abstrakcyjną?
  3. Jak w SQLu ograniczyć wynik zapytań do n pierwszych bez użycia słów LIMIT i TOP?
  4. Czym się różnią checked exceptions od unchecked exceptions?
  5. Pobawmy się w kompilator na kartce.
  6. Napisz quicksorta!

Poważna firma powinna zdawać sobie sprawę z tego, że zadając głupie pytania nic mądrego nie osiągnie, więc możliwości są dwie:
a) firma jest niepoważna, więc mi jej nie szkoda, że nie umie rekrutować
b) firma jest "poważna" i chce sprawdzić czy komuś się wystarczająco chciało żeby znaleźć schemat i czy umie go wykorzystać.

Rozmowa ma często znaczny wpływ na możliwe do wynegocjowania wynagrodzenie, więc IMO naturalnym jest chęć zostawienia po sobie na niej możliwie najlepszego wrażenia.

0

@Shalom, @somekind
Załóżmy, że przyszedł do Ciebie na rozmowę taki człowiek o jakim piszesz.
Zna wady i zalety 100 frameworków, zna dobre praktyki, i wie co można zrobić źle, co więcej powie też dla czego to jest źle a tamto jest dobrze.
Jak mu zadasz jakieś podchwytliwe pytanie, to odpowie tak, że odniesiesz wrażenie, że nie klepie z pamięci tylko faktycznie rozumie co mówi.
Nie umie programować i w praktyce nic z tego nie zrobi.

Czy spuścisz takiego człowieka na drzewo, czy uznasz, że jednak ma sporą wiedzę która może się jakoś w projektach przydać i zaproponujesz mu stanowisko nie programisty a myślącej bazy wiedzy?

0

@Maciej Cąderek
Może i jest odrealniony, ale załóż, że akurat taki ewenement Ci się trafił na rekrutacji.
Nie ma życia tylko analizuje przebiegi różnych projektów i czyta tony blogów tematycznych pisanych przez ludzi którzy bądź co bądź często programować umieją.
Może to tez być jakiś gość z lekkim asbergerem, ale tak, że komunikacji mu to nie zaburza.
Zasadniczo to chodzi mi o ustalenie takiego przypadku brzegowego.

0

Zdecydowanie nie, to jest logiczne następstwo tego, że sporo firm ciągle pyta o bzdury w stylu:

  1. Różnica pomiędzy ArrayListą a LinkedListą?
  2. Różnica pomiędzy Interfejsem a klasą abstrakcyjną?
  3. Czym się różnią checked exceptions od unchecked exceptions?

Ja wiem że odkopany temat ale żeby takie coś uważać za "bdzurę"....
Każda osoba która cokolwiek ogarnia w Javie więcej niż przysłowiowy hello world powinna to wiedzieć...

0
Złoty Samiec napisał(a):

Ja tam zawsze się przygotowuję z jakichś top n pytań znalezionych w Internecie.

Czy to jest oszustwo?
Zdecydowanie nie, to jest logiczne następstwo tego, że sporo firm ciągle pyta o bzdury w stylu:

  1. Różnica pomiędzy ArrayListą a LinkedListą?
  2. Różnica pomiędzy Interfejsem a klasą abstrakcyjną?
  3. Jak w SQLu ograniczyć wynik zapytań do n pierwszych bez użycia słów LIMIT i TOP?
  4. Czym się różnią checked exceptions od unchecked exceptions?
  5. Pobawmy się w kompilator na kartce.
  6. Napisz quicksorta!

Gdy mnie pytają o takie rzeczy to zwykle jest początek przygody. Np pierwsze pytanie pociąga za sobą konieczność przykładowej implementacji tych list, wskazania gdzie i jakiej lepiej użyć.

Drugie pytanie często wywołuje dyskusje na temat zasadności klas abstrakcyjnych w javie, oraz jak zmianiała się defnicja interfejsow w javie 7,8 i co przyniesie 9.

Czwarte pytanie to często sporo zadanek z tzw java puzzle oraz dyskusja na temat dobrych praktyk w obsłudze błędów.

Piąte pytanie to pewnie wyższa szkoła jazdy - nie wiem o co chodzi autorowi, ale może chodzi o wypisanie algorytmów JIT oraz generalnie zachowanie JVM. Duży temat.

Szóste pytanie również często dostaję. Najczęściej w kontekście obliczania złożoności oraz pisania testów jednostkowych.

Nie wiem dlaczego uważasz, że to głupie pytania. Moim zdaniem świetne.

2

@Ścibi92
@InterruptedException

  1. Jeżeli to byłoby pytanie kiedy czego użyć i dlaczego to jeszcze ok, ale jak ktoś pyta tylko o definicje do wydukania lub każe napisać swoją implementację listy to mam wrażenie, że to jest programista C przekwalifikowany na javę i już się boję o to, że zamiast używać gotowych przetestowanych rozwiązań będzie na siłę w projektach forsował swoje "lepsze".
    Wyważanie otwartych drzwi to jest antypatern i to się powinno tępić!

  2. Pogadać sobie można, ale co to daje?

  3. Rozmowa o dobrych praktykach jak najbardziej. Ten punkt wpisałem w sumie bardzo stronniczo po tym jak na pewnej rozmowie nie potrafiłem powiedzieć które są które(mea kulpa), ale już tłumaczenie jak się to powinno organizować i obsługiwać powiedziałem dobrze na przykładach exceptionów. Problem w tym, że akurat nazwa była najważniejsza i na to mam wieczny rage.

  4. Miałem na myśli zadania typu OCPJP, które zupełnie niczego nie sprawdzają, bo InteliJ podkreśla część od drazu, a pozostałe kompilator.
    Takie podejście: dobry kandydat, dobry, szukaj literówki, szukaj, szukaj !
    Pytań o Jit, G1, C64 i innych tego typu jeszcze nie uświadczyłem - a szkoda.

  5. Po co pisać coś co jest już gotowe, przetestowane, zoptymalizowane i dostępne?
    Czy znajomość algorytmu QS na pamięć ma jakikolwiek sens w pracy programisty?
    Ja rozumiem pytanie, o złożoność, albo o to kiedy faktycznie warto QS a kiedy jednak szybsze są inne(bo QS wcale nie jest najszybszy w wielu przypadkach).

Poza tym wszystkim co wyżej napisałem to jeszcze te zadania są tępego wkucia w pół dnia(na następne kilka dni, bo zzz), a dodatkowo są na każdej top liście zadań rekrutacyjnych, więc jak tylko ktoś będzie chciał to może taką listę przelecieć i niejako obejść system.
To znaczy tylko tyle, że algorytm rekrutacji jest dziurawy więc błędny.
Stosowanie błędnych alogorytmów jest głupie!

Piszę to już nty raz, ale będę pisał do pożygu, aż w końcu rekruterzy wezmą się do pracy zamiast ściągać z Internetu pierwszą wyszukaną toplistę(tak spotkałem się z takim przypadkiem, i nawet nie wiecie jak dobrze poszła mi tamta rekrutacja - SII power :D).
Poprawny proces(ale zajmuje czas) jest taki, że daje się kandydatowi projekcik do napisania, a rozmowa to już obrona wybranych frameworków, struktury kodu, wybranych wzorców projektowych, pytanie o to jak kandydat zmieniłby to i tamto w tym projekciku + jakiej inne pytania o konkrety które pozwalają ocenić jak sobie poradzi z codziennymi zadaniami w pracy.

1 użytkowników online, w tym zalogowanych: 0, gości: 1