Idealny proces rekrutacji

2

Ostatnio byłem na rozmowie kwalifikacyjnej, po której jeden z team leader'ów (a było ich dwóch) stwierdził, iż po tej rozmowie jest w stanie jednoznacznie stwierdzić - jaki jest mój potencjał i jak wiele mogę wnieść do zespołu. Zaintrygowało mnie to do rozważań, jak człowiek może po półgodzinnej rozmowie określić precyzyjnie jakim będę pracownikiem ?

Generalnie przeszedłem kilka rozmów i mam niezłą statystykę tylko raz nie dostałem oferty pracy i była to moja pierwsza rozmowa. Nigdy nie kłamie na rozmowach i zawsze mówię czego nie wiem, liznąłem naprawdę sporo technologii, ale mówię pracodawcą, że czasem robię błędy, które nie powinny się zdarzyć. Z reguły zawsze na rozmowie jest jeden programista, który chce mi dowalić, jest poniekąd agresywny, to znaczy zadaje podchwytliwe pytania (na które ja się daje złapać czasem, za co mi jest wstyd, choć wiem, że coś jest nie tak). Jest i drugi programista, który ma charakter raczej spokojny i ułożony, jest miły, sympatyczny, za wiele nie mówi. Czasem jest ktoś trzeci do tego grona. Pytanie jak można po 30 czy 60 minutowej rozmowie określić precyzyjnie z kim mamy do czynienia ? Dla mnie jest to niemożliwe.

Padają na takich rozmowach głupie pytania w stylu:

  • Dlaczego chcesz u nas pracować ? - Odpowiedź - Bo chce od was kasy. Nie mam pojęcia kto u was pracuje ? Jak wygląda zespół ? Mam tylko informacje o waszych klientach i produktach ze strony internetowej. Mam zgadywać czy jakiś projekt jest rozwijany ? Gdzie mnie rzucicie też nie wiem. Oczywistym jest, że wysłałem kilka CV do różnych firm i ta rozmowa też jest dla mnie, żebym wiedział z kim będę współpracował.
  • Czy planujesz u nas dłużej zostać ? - Odpowiedź - Jak do cholery mam to planować, skoro ja nawet was nie znam ani wy mnie ? Może za rok żona stwierdzi, że chce wyjechać do Burkina Faso i co wtedy? Takie pytanie powinno się zadawać po okresie próbnym.

Moim zdaniem idealna rozmowa powinna raczej skupiać się na poznaniu obu stron, nie skupiajmy się na aspektach technicznych póki co. By pracodawca mógł stwierdzić na ile gościu kłamie w CV, kto to jest, czy to nie jest jakiś losowy koleś etc. Jeżeli będziemy mieli już jakieś grono ludzi co się nadają to dajmy im coś to rozwiązania i zapłaćmy za to. Tak by nikt nie robił nam za darmo. Zadanie lub zadania powinny być dobrane tak by w miarę stwierdzić czy nasz przyszły pracownik odnajdzie się w pracy, sprawdzić w czym ma braki. Do zadań dołóżmy serię pytań w stylu: a co by było gdyby ? Dlaczego rozwiązałeś to tak ? Dopiero na tej podstawie już możemy mieć jakiś obraz naszego przyszłego pracownika.

A jak waszym zdaniem powinien wyglądać idealny proces rekrutacji.

2

Jako ciekawostkę podam pewien eksperyment opisany w książce "Pułapki myślenia" Kahnemana (ogólnie polecam całą książkę, bardzo ciekawa).

Kahneman został poproszony przez izraelską armię o ocenę ich procesu rekrutacji oficerów. Cały proces składa się z pewnych ćwiczeń grupowych, które symulują sytuacje bojowe. Rekruci nie dostali żadnych wytycznych co do swojej roli, więc sami musieli dojść do tego jak współpracować ze sobą. No i w trakcie tych symulacji zwykle wyłaniają się liderzy, posłuszni szeregowi, maruderzy itd. Na podstawie tych obserwacji oceniano i wybierano ludzi do dalszych szkoleń oficerskich.
Po jakimś czasie Kahneman porównał wyniki tych rekrutacji z wynikami pracy oficerów i okazało się, że ci z najlepszymi ocenami wcale nie poradzili sobie najlepiej później. Co więcej, nie ma żadnej korelacji między dobrymi ocenami podczas symulacji a byciem dobrym oficerem później. Równie dobrze mogli wybrać losowo.

Oczywiście wyniki tych badań są bardzo nieintuicyjne, trudno powiedzieć czy to się odnosi tylko do specyficznych ról (praca przy ogromnym stresie i odpowiedzialności), ale dobrze o nich wiedzieć, by ślepo nie wierzyć takim testom.

0

Czasem spotyka się wypowiedzi kolesi, że nigdy nie pomylili się w rekrutacji. No nie wiem, może rzeczywiście, bo to zwykle bywa w artykułach z wielkiego kraju USA - może tam do każdego odrzuconego kandydata wynajmują prywatnego detektywa na rok, żeby wyczaił, co to był za jeden. ;) A na serio, to ci rekrutujący wskoczyli niedawno na jakiś stołeczek w pracy i odwala im sodówka. Też tak miałem, samo przeszło.

2

mysle ze twoje negatywne doswiadczenie wynika z tego ze imo malo ktora firma robi selekcje kto tak naprawde ma byc rekrutatorem, po prostu brany jest pierwszy lepszy koder ktory akurat nie jest zawalony robota i/lub zechce przeprowadzic ta rozmowe.
ludzie sa rozni, niestety ale duza czesc, zwlaszcza tych mniej doswiadczonych rekruterow zamiast sprawdzic wiedze kandydata chce pokazac jaka to nie jest madra (czytaj oczekuje bardzo konkretnej odpowiedzi na niezbyt jednoznaczne pytanie, bo takie akurat mial z danym zagadnieniem doswiadczenie). w takiej sytuacji glownie decyduje nie twoja wiedza ale to jak bardzo 'masz gadane'.

30-60 minut w zupelnosci wytarcza aby stwierdzic czy kandydat jest technicznie dobry czy do d**y (chyba ze bardzo wolno mowi i/lub jaka sie), co do przydatnosci w zespole to w sumie zalezy czego oczekujemy, ale jesli zada sie dobre pytania to jest to dosc latwe do stwierdzenia.
pytania typu 'czemu u nas' albo 'jak sie widzisz w przyszlosci' maja sens, to ze kandydata interesuje tylko kasa (i wiecej kasy w przyszlosci) nie jest dobrym sygnalem dla wiekszosci firm.

idealny proces wg mnie to:

  1. 10-15 minut gadki technicznej przez telefon
  2. jesli obie strony sa ok to spotkanie:
    10 min: o firmie, projekcie, zespole, narzedziach, wynagrodzeniu i stanowisku
    10 min: o doswiadczeniu kandydata z ogolnym zarysem projektu do ktorego ostatnio sie przylozyl
    15-30 min: pytania techniczne (bardziej zamkniete)
    1-2h: rozwiazywanie problemow/kodowanie/praca z projektem
  3. werdykt
5
katelx napisał(a):

pytania typu 'czemu u nas' albo 'jak sie widzisz w przyszlosci' maja sens, to ze kandydata interesuje tylko kasa (i wiecej kasy w przyszlosci) nie jest dobrym sygnalem dla wiekszosci firm.

to jest dla mnie przegiecie - oczekiwac ze kandydat bedzie przywiazany do firmy i bedzie mu zalezec na niej a nie tylko na kasie to takie sztuczne ze masakra. mowimy tu o pozycji kodera a nie CTO. Ciekawe ze kandydat dla firmy jest do zastapienia, dlaczego firma dla niego ma nie byc? :v

2
lazur napisał(a):
katelx napisał(a):

pytania typu 'czemu u nas' albo 'jak sie widzisz w przyszlosci' maja sens, to ze kandydata interesuje tylko kasa (i wiecej kasy w przyszlosci) nie jest dobrym sygnalem dla wiekszosci firm.

to jest dla mnie przegiecie - oczekiwac ze kandydat bedzie przywiazany do firmy i bedzie mu zalezec na niej a nie tylko na kasie to takie sztuczne ze masakra. mowimy tu o pozycji kodera a nie CTO. Ciekawe ze kandydat dla firmy jest do zastapienia, dlaczego firma dla niego ma nie byc? :v

Dlatego mówię takie pytania powinny się pojawić, ale po okresie próbnym na przykład. Być może faktycznie przywiąże do firmy i powiem, że darzę ją uczuciem. Nie jestem w stanie tego stwierdzić będąc pierwsze 20 minut w nowym otoczeniu.

0

powiedzmy sobie szczerze że (prócz kwestii technicznej) rekrutacji można sie nauczyć
pytania zwykle są wszędzie podobne, wystarczy być przygotowanym i odpowiednio mówić
oczywiście na logikę są to bzdury, których w żadne sposób nie można zweryfikować, no ale co zrobić, taki system ...

1

Imo dla Javy idealnie to 4. etapowo:

  1. CV po angielsku
  2. Rozmowa z pania z HR o tym dlaczego odszedl z ostatniej, w czym sie czuje silny, w czym slaby, co by chcial robic, ile zarabiac, test z angielskiego, jakies 30 na:
  • prostego selekta
  • n-ty element fibbonaciego
  • prostego regexa
    Na te 3 pytania dziewczyna z HR powinna miec przygotowane rozwiazania.
  1. Jezeli ktos przeszedl etap 2. to daje sie mu zadanie i np 2 tygodnie na zrobienie.
    W zadaniu ma miec pelna dowolnosc doboru bibliotek czy projektowania klas, tylko ma byc swiadomy tego, ze wymagania sie moga zmienic.
    Zadanko jakies proste ala wygenerowac z danego wsdla webclienta zapisujacego cos w bazie. Kod wstawic na githuba.

4.Omowienie rozwiazania(czytelnosc, testy, wydajnosc, architektura), obrona wybranych bibliotek i struktury kodu.
Pytanie o to jak dodac do tego kodu cos, lub zmienic cos.

W zadnym wypadku nie powinno sie kazac pisac quicksorta, wlasnej implementacji drzewa czy innych podobnych.
Takie polecenia sa oderwane od tego co faktycznie programista bedzie robil i utrwalaja antypatern pisania gotowych, przetestowanych i zoptymalizowanych rzeczy po swojemu zamiast znalexc w 5 minut gotowa biblioteke na googlach.

1

ale kto mowi o przywiazaniu do firmy juz na rozmowie? pytanie 'dlaczego chcesz u nas pracowac?' nie oznacza 'udawaj ze to twoje marzenie zeby do nas dolaczyc'. jesli rzeczywiscie jedyna motywacja do pracy sa dla ciebie pieniadze to moze rzeczywiscie warto zebys o tym wspomnial, ale zadna powazna firma takiej osoby przyjmowac by raczej nie chciala. poza tym 'chce u was pracowac bo dobrze placicie' to nie jest szczyt elokwencji, nie jest tajemnica ze kazdy chce zarabiac jak najwiecej.
to samo z pytaniem o to 'ile planujesz u nas zostac', firma nie oczekuje od kandydata ze ten zadeklaruje swoje plany zyciowe na najblizsze 10 lat, ale odpowiedz 'nie wiem, nie powiem' jest najzwyczajniej w swiecie arogancka.
rozumiem ze ktos woli rozmawiac wylacznie o aspektach technicznych ale imo to nie tak dziala i trzeba sie z tym pogodzic. stawiajac sie w roli firmy poszukujacej pracownikow - wiadomo ze poszukiwani sa specjalisci, licza sie umiejetnosci techniczne etc ale jesli specjalista ma nastawienie 'a co wy w ogole ode mnie chcecie, ja tu mam kodowac a nie gadac o bzdurach, co was to obchodzi co bede robil za 2 lata, dajcie pieniadze to wszyscy bedziemy zadowoleni poki ktos nie da wiecej' to nie jest to doskonaly wstep do dlugoletniej i owocnej wspolpracy.

co do nie zadawania pytan ktore mozna wygoglowac w 5 minut to nie do konca sie zgodze, jak najbardziej sa na miejscu, tylko powinny byc dostosowane do profilu kandydata.

1
mariano901229 napisał(a):

Padają na takich rozmowach głupie pytania w stylu:

  • Dlaczego chcesz u nas pracować ?
    To może nie być takie głupie. Przykładowo firma robi jakiś specjalizowany CAD do instalacji hydraulicznych (tak tylko zmyślam) i przychodzi do nich jako kandydat na programistę koleś, którego "aspergerowym" hobby od dziecka było kolekcjonowanie katalogów części hydrauliki. Dla niego to będzie praca życia, a oni będą przez lata współpracować z gościem z bananem na twarzy przy rozmowach o kolankach od kanalizacji ;) - wielka szkoda to zmarnować, o ile poza tym się z grubsza nadaje.
0

@katelx
Poważnie pamiętasz te wszystkie algorytmy?
Ja wiem kiedy quicksort ma sens, a kiedy dużo lepsze są inne sortowania, ale żebym po co mam pamiętać sam algorytm.
Ja wiem, że dużo firm ze specjalistami nauczonych na studiach turbokartki uskutecznia to teraz w pracy i każe wyważać otwarte drzwi(antypatern) kandydatom na jakichś codility czy innych hackerczymś, ale to nijak się ma do tego co pracownik będzie w firmie robił(a chyba umiejętność tego powinno się sprawdzać?).

BTW:
Jak na rozmowie raz ktoś chciał żebym napisał quicksorta to odpowiedziałem, że nie pamiętam jak to działało, i na szybko mogę najwyżej bombelkowe napisać.
Człowiek się oburzył i powiedział, że jak to tak nie pamiętać "jedynego poważnego sortowania"(zdanie miało wydźwięk w stylu czego ty tu szukasz dziecko jak nawet tego nie umiesz), a jak powiedziałem, że wcale nie jedynego, wspomniałem kiedy insertsort jest szybszy, oraz to, że wyważanie otwartych drzwi nie ma sensu(tylko nie dokońca wprost) to się chyba zawstydził sądząc po minie.
W każdym razie rozmowy nie przeszedłem :) (tak, to co piszę to tylko trauma :D)

1

bo to, że ktoś ma wykute jakieś zagadnienia nie znaczy że je rozumie i potrafi zastosować\zmodyfikować
to jak z angielskim, to że umiesz słowa nie znaczy że sklecisz poprawne zdania

1
Czarny Lew napisał(a):

@katelx
Poważnie pamiętasz te wszystkie algorytmy?
chyba nie przeczytales uwaznie mojej wypowiedzi, napisalam wyraznie ze pytania powinny byc dostosowane do profilu kandydata. jesli stanowisko wymaga bardzo dobrej znajomosci algorytmiki to tlumaczenie 'ale to w googlu w minute znajde' jest srednio na miejscu, nie?
na wiele pozycji developerskich algorytmy sa rzeczywiscie malo potrzebne a testy typu codility praktycznie bezuzyteczne (no chyba ze naprawde banalne problemy sa do rozwiazania, tak zeby zrobic odsiew totalnych baranow). osobiscie bardzo nie lubie naduzywania 'googlowego' wytlumaczenia niewiedzy, bo jesli kandydat aplikuje na senior java deva w systemie sieciowym to powinien wiedziec jaka jest roznica miedzy tcp a udp a nie sciemniac ze to w 10 sekund sie dowie jak bedzie trzeba.

3
Krwawy Terrorysta napisał(a):

Imo dla Javy idealnie to 4. etapowo:
3. Jezeli ktos przeszedl etap 2. to daje sie mu zadanie i np 2 tygodnie na zrobienie.
W zadaniu ma miec pelna dowolnosc doboru bibliotek czy projektowania klas, tylko ma byc swiadomy tego, ze wymagania sie moga zmienic.
Zadanko jakies proste ala wygenerowac z danego wsdla webclienta zapisujacego cos w bazie. Kod wstawic na githuba.

Ja bym w tym momencie rezygnowal z firmy. Zadanie co zajmuje 2 tygodnie??? Co najwyzej na wieczor cos do zrobienia.

0

To musiałoby być jakieś super stanowisko, żeby pisać tak wymagające zadanie. W 2 tygodnie można znaleźć inne miejsce pracy.

0

Dobre rozmowy z firmami, w których się zatrudniłem, to było CV, później krótka rozmowa przez telefon, by umówić się, później jakiś prosty test sprawdzający, a w zasadzie wykluczający tych, co kłamali w CV (proste - podstawowe pytania z języka, którym twierdzą,ze potrafią), jakieś proste zadanie na myslenie (do napisania jakiś algorytm cos robiacy, lub cos podobnego - nie chodzi nawet o napisanie gotowego działającego kodu, ale o sposób myslenia i czy mysli), dalej już ustalenie szczegółów przy zatrudnieniu. Ponieważ w każdej z firm wychodzono z zalożenia (slusznego zresztą), że od tego jest okres próbny, aby sprawdzić, czy będziemy dobrze współpracować z zespołem. I jest to moim zdaniem jedynie słuszne podejście. Nie sprawdzisz człowieka w pół godziny, czy godzinę. To co najwyzej może pomóc odrzucic tych, co ewidentnie się nie nadają. Reszta juz będzie loterią.

0

@krzywy Pomidor
@adhed
Zadanko o którym napisałem jest właśnie do zrobienia w jeden wieczór bez problemów.
2 tygodnie powinno się dać po to, żeby osoby zajęte(np pracujące, z dziećmi czy budujące się) miały możliwość znalezienia tych kilku godzin na rozwiązanie.
Nie ma najmniejszego problemu żeby ktoś pusha zrobił dużo wcześniej.

0
Krwawy Terrorysta napisał(a):
  1. Jezeli ktos przeszedl etap 2. to daje sie mu zadanie i np 2 tygodnie na zrobienie.

taka firma nikogo dobrego niestety nie zatrudni... bo nie zdąży.
Programistę przejmie firma która ma krótszy proces rekutacji
chyba że programiście zależy na tej konkretnej firmie ale to już trzeba być firmą pokroju google (albo już na starcie dać znać że widełki są znacznie wyższe)

Akurat o dobrego programistę to działy rekrutacyjne muszą się ścigać a nie na odwrót - żaden dobry programista nie pozostaje bez pracy dłużej niż 2 tygodnie

0

Nie czytałem całego wątku ale team leader, czy nawet gość, który był na rozmowie rekrutacyjnej nie musi być ekspertem w dziedzinie do której rekrutują nowego człowieka. Taki gość ma raczej za zadanie sprawdzić, czy w ogóle coś ogarniasz temat i czy jesteś odpowiednią osobą na stanowisko, o które się ubiegasz. Pytania w stylu "dlaczego nasza firma" itd to inna bajka.
Ze swojej strony powiem (nie przeprowadzam rekrutacji), że ogarniętych ludzi jest bardzo mało, stąd nie dziwi mnie bardzo powściągliwe podejście rekruterów.

0
Wybitny Młot napisał(a):

Akurat o dobrego programistę to działy rekrutacyjne muszą się ścigać a nie na odwrót - żaden dobry programista nie pozostaje bez pracy dłużej niż 2 tygodnie
No chyba że nie jest naprawdę dobry.
https://en.wikipedia.org/wiki/No_true_Scotsman
;)

3
lazur napisał(a):

to jest dla mnie przegiecie - oczekiwac ze kandydat bedzie przywiazany do firmy i bedzie mu zalezec na niej a nie tylko na kasie to takie sztuczne ze masakra. mowimy tu o pozycji kodera a nie CTO. Ciekawe ze kandydat dla firmy jest do zastapienia, dlaczego firma dla niego ma nie byc? :v

Ludzie, którym zależy tylko na kasie są słabi technicznie, więc po co ich zatrudniać?
Kasa to ważny aspekt, ale jest też wiele innych: rozwój, ciekawe projekty, możliwość rozwoju w ulubionym języku/technologii/frameworku, kontakt z klientem (albo jego brak), dziedzina dla której pisze się soft, itd., itp. Jeśli ktoś nie potrafi powiedzieć choćby tyle, że interesuje go zdobywanie doświadczenia w SQL i JS, żeby za 10 lat zostać seniorem, to chyba znaczy, że jest aż tak niedojrzały, że nie ma nawet żadnych planów życiowych. (Czym się różni od przeciętnego pięciolatka, który już wie, że chce być strażakiem/kosmonautą. ;))

Wybitny Młot napisał(a):

taka firma nikogo dobrego niestety nie zatrudni... bo nie zdąży.
Programistę przejmie firma która ma krótszy proces rekutacji
chyba że programiście zależy na tej konkretnej firmie ale to już trzeba być firmą pokroju google (albo już na starcie dać znać że widełki są znacznie wyższe)

Akurat o dobrego programistę to działy rekrutacyjne muszą się ścigać a nie na odwrót - żaden dobry programista nie pozostaje bez pracy dłużej niż 2 tygodnie

No tak, bo każdy dobry programista wie, że aby szukać nowej pracy, trzeba najpierw rzucić starą i stać się bezrobotnym.

Idealny proces?

  • Żadnych paniusi z HR;
  • Panów z HR też nie;
  • Rozmowa o pracy, nie o pracę;
  • Rozmowa o programowaniu;
  • Jeśli rozmawiamy po angielsku (bez względu na to, czy całość, czy część rozmowy), to też o programowaniu, nie pogodzie, podróżach i planach na przyszłość;
  • Firma przedstawia się mi, a nie pyta mnie, co sam o nich wiem;
  • Pytania praktycznie, np. nie o to, "do czego służy sealed", ale "kiedy należy oznaczać klasy jako sealed"; nie o definicję jakiegoś wzorca, ale np. "jakiego wzorca użyłbyś do generowania danych do testów jednostkowych"; albo dostajesz projekt w technologii X, cały kod w jednym pliku, jak go zrefaktoryzujesz (proces, wzorce, itd.);
  • Zadania na kartce - nie lubię ich, ale niech też będą praktyczne. Np. zamiast "napisz funkcję sortującą co trzeci wyraz ciągu" może to być kawałek kodu do oceny przez kandydata i wymienienie miejsc, w których kod ma wady, należy go zrefaktoryzować. Zamiast kodu może być też np. diagram bazy danych.
  • Jeśli pisanie kodu, to tylko na komputerze, z dostępem do internetu, itd. Dobrze przemyślanym zadaniem na godzinę-dwie kodowania można sprawdzić, czy człowiek ma pojęcie o programowaniu, czy nie.
0

Pierwszy etap - Kilka testowych zadań (na godzinę mniej więcej roboty każde) w technologiach w których firma robi, a zamieszczonych na stronie rekrutacji. Aplikujący na ich podstawie wie czy ma sens w ogóle startować, a z drugiej strony nadesłane rozwiązania pozwalają rekrutującym ocenić jakość kodu etc.
Drugi etap - to samo w skrócie na żywo, w celu sprawdzenia samodzielności rozwiązań.
Trzeci etap - dogadanie warunków pracy.
Czwarty etap - okres próbny.

Wszystko co ponad to ode złego pochodzi.

Taka metoda w minimalnym stopniu obciąża aplikującego i personel techniczny, a rola panienki z HR ogranicza się do podania papierów oraz herbaty.

0

@somekind

Ludzie, którym zależy tylko na kasie są słabi technicznie, więc po co ich zatrudniać?

Każde korpo ma projekty do których nie trzeba być super ekspertem, bo np jest tam tylko przepakowywanie danych pomiędzy 2. webserwisami i logowanie do bazy.
Do takich zadań wcale nie trzeba pasjonata artysty, rzemieślnik wystarczy w zupełności, a może nawet będzie lepiej pasował, bo nie będzie się frustrował(i siał defetyzmu) tym, że przez ciągle zmiany wymagań i brak czasu w kodzie jest syf, tylko odbębni swoje, weźmie kasę i wszyscy będą szczęśliwi.

To trochę tak jakby ktoś kto wierci 5 dziurek raz na kilka lat mówił, że potrzebuje profesjonalnej wiertarki dewalta.

2

Tak w skrócie to dla mnie:

  • idealna rozmowa powinna być dialogiem a nie monologiem kandydata (a czasami rekruterzy wymuszają te monologi, co uważam za błąd rekrutera)

  • rekruterzy powinni jakoś zachęcić do pracy w tej firmy. Czyli nie tylko sprawdzanie wiedzy kandydata, ale powinni powiedzieć dlaczego warto akurat w tej firmie pracować

  • rekruterzy powinni przeczytać CV kandydata, oraz spróbować się dowiedzieć czegokolwiek o kandydacie. Niestety często rekruter czyta dopiero w trakcie(!) rozmowy i widać po jego zachowaniu, że dopiero się z nim zapoznaje. A o takich luksusach jak to, że wejdzie na podane w CV konto na Githubie nie ma już nawet co marzyć... (dziwi mnie to, bo jak ja idę gdzieś na rozmowę to zaglądam chociaż na oficjalną stronę firmy i spróbuję się dowiedzieć, czym się zajmują)

Napisałem zresztą artykuł o tym u siebie na blogu, w którym opisałem szerzej co o tym sądzę.
http://13zmiennych.blogspot.com/2015/07/jak-powinna-wygladac-rozmowa.html

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