Jak uczymy się pod technical interview?

Witam,

Często aplikując, zauważam ciągły wzrost oczekiwań technicznych. Tyle, ile wymagano rok-dwa temu na stanowisko juniorskie, obecnie z trudem wystarcza na stanowisko testerskie. Ostatnio zaskakujące okazały się pytanie - które algorytmy sortujące mają daną złożoność oraz impleentacja od zera kilku wzorców projektowych bardziej zaawansowanych, z czego wiedzę poszerzyłem i ciągle poszerzam. Jednak nie poddaję się i wciąż aplikuję gdzie racjonalnie mniej więcej spełniam wymagania-w Krakowie wychodzi z 20-30 aplikacji dziennie z samych portali: pracuj.pl, justjoin.it, nofluffjobs.com oraz glassdoor.
O ile nigdy nie otrzymałem feedbacku, iż część "umiejętności miękkie" w którymś etapie przebiegła niezadowalająco, o tyle zazwyczaj dostaję informację, iż część techniczna poszła niewystarczająco. W danym momencie pierwszą rzeczą po wyjściu z budynku, w któym była rozmowa, jest zapisanie w telefonie wszystkich zagadnień, z których nie umiałem lub też odpowiedziałem niewystarczająco, by później z nich się douczać.
Z tych rzeczy powstał dłuższy plik tekstowy, liczący już ponad 20 stron, ciągle o nowe zagadnienie aktualizowany, który staram się choć raz dziennie przeczytać
Natomiast jako codzienna anuka, dokszałcam się z wykonywania zadań na następujących portalach:
-codewars
-hackerrank
-ostatnio także na leetcode(część darmowa)

• w wolnych chwilach także czyywanie "Top interview questions", choć bardzo pobieżnie opisane

Często uczę się wielu nowych zagadnień, jednak zauważam, że wiele z nich na marne i tylko marnuję czas, bo nigdy o nie nie zostanę zapytany podczas interview a do czasu pracy zawodowej i tak będę musiał się nauczyć ich od nowa.

Stąd moje pytanie - jak zorganizować naukę na rzecz przejśćia interview technicznego? Czego najbardziej się uczyć a co byłoby stratą czasu?
Wiem, że po zatrudnieniu jako developer będzie i tak nauka nieustanna, jednak chciałbym zapytać - na czym skupiać się w nauce w danym etapie?

Trzeba się nauczyć podstaw i je rozumieć.
20 stron tekstu z zagadnieniami da radę objąć tematykę dwóch kierunków, matematyki i informatyki co masz chyba w Krakowie na UJ (podwójny dyplom).
Powinieneś z tym wymiatać, ale same porażki pokazują, że tą metodą dojdziesz do 80 stron tekstu z zagadnieniami a na interview i tak trafisz na inaczej sformułowane problemy.

Z nauką analizy czy dyskretnej jest podobnie. Umiesz podstawy i rozumiesz zagadnienia to z połowę zadań ze zbioru robisz z marszu. Skupiasz się na samych zadaniach to się zastanawiasz dlaczego uwaliłeś ostatni termin zaliczenia.

Zagadnienia które cię rozłożyły to podstawowe tematy z początku nauki na studiach. Żeby dostać zaliczenia trzeba było je przerobić, nie powinieneś się zatem dziwić, że w formach pytają o "powtórkę ze szkoły".
Ciężko to by było gdyby wymagali więcej niż naprawdę połowa podstawowych tematów z pierwszego stopnia infy.

Mogliby przecież, zamiast o sortowania, to zapytać co to jest i jak (opisowo) działa router, co lata w sieci lokalnej przed routerem, co gdy na drodze jest do przejścia router, a na dobicie kandydata zapytać o porty.

Można dyskutować, czy w Warszawie wymagają papier i wiedza za studiów, czy wystarczy sama wiedza na bazowym poziomie studiów. Czy Kraków ma takie same wymagania jak Warszawa? Ale jak sam piszesz, bez solidnie ugruntowanej wiedzy obecnie nie da rady "wbić w branżę".

Jakie tam pytanka wjechaly?

wciąż aplikuję gdzie racjonalnie mniej więcej spełniam wymagania-w Krakowie wychodzi z 20-30 aplikacji dziennie

Następny xD już był to niedawno taki geniusz co się żalił, ze brakło mu firm i co teraz?, bo też tak idiotycznie wszędzie aplikował. Aplikujesz do kilku, jak się nie uda, to dostajesz feedback czego ci brakuje. Następnie pracujesz nad tym i za pół roku czy rok znowu aplikujesz.

racjonalnie mniej więcej spełniam wymagania

No chyba nie spełniasz skoro wysyłasz po 20-30 aplikacji dziennie i nie masz nadal pracy.

Jak uczymy się pod technical interview?

W ogóle tego nie robimy. Interview sprwadza czy posiadasz wiedzę potrzebną do pracy w danym miejscu i na danym stanowisku. Uczenie się pod interview po prostu nie działa. Raz, bo zwykle na kilometr widać, że ktoś tylko wykuł formułki, albo w życiu nie widział czegoś w praktyce. A dwa, że nawet jakby jakimś cudem się "udało na interview", to potem:

• albo nie poradzisz sobie w pracy
• albo w ogóle się rozczarujesz, bo okaże się, że praca w ogóle cię nie interesuje, skoro musiałeś skillować pod interview

Ucz się programowania, a nie "pod interview". Lepiej na tym wyjdziesz.

Hydraulik Kerynieśpi napisał(a):

Stąd moje pytanie - jak zorganizować naukę na rzecz przejśćia interview technicznego? Czego najbardziej się uczyć a co byłoby stratą czasu?
Wiem, że po zatrudnieniu jako developer będzie i tak nauka nieustanna, jednak chciałbym zapytać - na czym skupiać się w nauce w danym etapie?

Nie wiem jak wygladaja realia rynku teraz, ale "za moich czasow" pytano o podobne rzeczy. Nawet kolegom opylalem listy pytan na rozmowy w danej korpo bo chodzilem z ciekawosci na rozmowy. Ale kandydat na juniora z wiedza o:

1. zlozonosci obliczeniowej podstawowych algorytmow , obslugi struktur danych, ich plusow ujemnych i dodatnich,
2. jednym jezyku programowania na ktory kandyduje i w ktorym porusza sie swobodnie i jakis tam jego niuasnach,
3. wiedzy o podstawowych wzorcach projektowych (10-15 typu singleton, fabric, mvc i umie wytlumaczyc po co to jest, co by z tym zrobil, oraz narysowac badz wypisac w pseudokodzie )
4. ogolnych wlasciwosciach i definicjach programowania objektowego
5. podstawowej obsludze linii komend (linux/windows whatever)
6. wiedzy o wersjonowaniu kodu (np umiejetnosc dzialania w svn, teraz to bardziej git)
7. Umiejetnosc czytania i pisania diagramow klas (UML)

Mial duza szanse na przyjecie na staz / juniora. Ale tak bylo kiedys. Taka lista zagadnien miescila sie na wlasnie mniej-wiecej 20 stronach .

Co radze?

1. brac listy pytan od znajomych (nawet z rozmowy w tej samej firmie - inny "egzaminator" i juz zmiania sie zestaw)
2. wbijac na jana na kazda dostepna rekrutacje
3. wzorcow projektowych nie kuc, bo tego nikt nie zrozumie bez obycia z kodem, a przerobic z dobra ksiazka i napisac sobie jakies wydmuszki do kazdego, do tego dojdzie zrozumienie obiektowki

No i uczenie pod konkretna rozmowe nie ma sensu jak tu ktos wspomnial, ale... majac pytania z np. 10 firm zauwazysz, ze wiele rzeczy w rekrutacjach sie powtarza i bedziesz wiedzail czego sie uczyc. Moze twoja probka jest po prostu jeszcze za mala?

Shalom napisał(a):

wciąż aplikuję gdzie racjonalnie mniej więcej spełniam wymagania-w Krakowie wychodzi z 20-30 aplikacji dziennie

Następny xD już był to niedawno taki geniusz co się żalił, ze brakło mu firm i co teraz?, bo też tak idiotycznie wszędzie aplikował. Aplikujesz do kilku, jak się nie uda, to dostajesz feedback czego ci brakuje. Następnie pracujesz nad tym i za pół roku czy rok znowu aplikujesz.

Nie chciałem dobijać, poczekałem aż ktoś inny to zrobi. tx @Shalom

30 aplikacji dziennie nie oznacza 30 różnych firm, tak dobrze nie ma nawet w Krakowskiej Smogowej Dolinie.

Oficjalnie nikt tego nie potwierdzi, ale w dużej firmie z sensowną rekrutacją aplikujący na juniora po uwaleniu (nie pośliźnięciu na jakimś temacie ale uwaleniu po całości) ma bana na powiedzmy rok, bo firma, rekrutacja nie będą tracić czasu na ponowne sprawdzanie co gość wstawił na githuba albo jaki nowy zestaw TOP & HOT 25 interview questions nauczył się na pamięć.

Firma zatrudnia pracownika żeby zarabiał dla firmy więcej niż mu firma płaci. Rekrutacja pracuje nad tym żeby takich pracowników firmie zapewnić.

Hydraulik Kerynieśpi napisał(a):

Tyle, ile wymagano rok-dwa temu na stanowisko juniorskie, obecnie z trudem wystarcza na stanowisko testerskie.

A to jakieś stanowisko niższe od juniora wg. ciebie? :D

Nie wiem jak wygladaja realia rynku teraz, ale "za moich czasow" pytano o podobne rzeczy. Nawet kolegom opylalem listy pytan na rozmowy w danej korpo bo chodzilem z ciekawosci na rozmowy. Ale kandydat na juniora z wiedza o:

1. zlozonosci obliczeniowej podstawowych algorytmow , obslugi struktur danych, ich plusow ujemnych i dodatnich,
2. jednym jezyku programowania na ktory kandyduje i w ktorym porusza sie swobodnie i jakis tam jego niuasnach,
3. wiedzy o podstawowych wzorcach projektowych (10-15 typu singleton, fabric, mvc i umie wytlumaczyc po co to jest, co by z tym zrobil, oraz narysowac badz wypisac w pseudokodzie )
4. ogolnych wlasciwosciach i definicjach programowania objektowego
5. podstawowej obsludze linii komend (linux/windows whatever)
6. wiedzy o wersjonowaniu kodu (np umiejetnosc dzialania w svn, teraz to bardziej git)
7. Umiejetnosc czytania i pisania diagramow klas (UML)

Mial duza szanse na przyjecie na staz / juniora. Ale tak bylo kiedys. Taka lista zagadnien miescila sie na wlasnie mniej-wiecej 20 stronach .

To wybacz, ale to są wygórowane wymagania na staż. Jeżeli ktoś się przyjmuje na staż z wiedzą na temat algorytmów, złożoności obliczeniowej, znajomością wzorców projektowych, czytania diagramów UML i jeszcze znajomością technologii to imo daje się wyzyskiwać i to mocno. Jeszcze pewnie za minimalną przez rok bo przecież najpierw staż xD.
Ktoś na staż/juniora powinien imo dobrze znać język w którym pisze, IDE, umieć oszacować złożoność, żeby nie wypalił pętli potrójnie zagnieżdżonej oraz struktury danych. Thats all, bo co to za wiedza np na temat wzorców projektowych kiedy nie widział tego w komercyjnym zastosowaniu? Wszystkiego bez problemu się nauczy.
Imo o wiele bardziej jakościowe dla takiego stażysty są umiejętności miękkie oraz po prostu umiejętność organizacji oraz nauki.

Czitels napisał(a):

To wybacz, ale to są wygórowane wymagania na staż. Jeżeli ktoś się przyjmuje na staż z wiedzą na temat algorytmów, złożoności obliczeniowej, znajomością wzorców projektowych, czytania diagramów UML i jeszcze znajomością technologii to imo daje się wyzyskiwać i to mocno.

Przyjmowanie się na staż (1 do 2, rzadko 3 miesięcy) w Warszawie w korpo to w 2019 roku było od 3200 do 4200 brutto ze statusem studenta.
Minimalna na 2019 r to było 2250 zł.

Disclaimer ;)
Nie piszę o "wbiciu w branżę", js i agencje reklamowe itp.

Dwa, przyjmowanie się na staż i przyjmowanie po stażu propozycji pracy (za więcej niż 3200) to nie jest branie kablówki z internetem i HBO, rozważanie drogo, tanio, a ja wolałbym Netflix.

To firma stawia takie a nie inne wymagania (łagodnie traktowane nie więcej jak połowa kierunkowych studiów). Firma z takimi a nie innymi wymaganiami (i wynagrodzeniem) albo znajduje programistów - albo nie - wtedy musiałaby obniżyć wymagania.

Wymagania na start są jakie są, ludzie do pracy się znajdują. Wniosek: do korpo na wymarzone dobrze płatne technologie próg jest jaki jest i nic nie wskazuje na to, żeby miał się obniżać. Mało tego, "głos ludu" w internecie niesie, że wymagania już urosły i dalej rosną.

Wzrastają wymagania, rośnie kasa. To znaczy, Pan Pareto jak zawsze miał rację, 80% odpada, 20% wchodzi do gry i zgarnia 80% z puli kasy.

https://en.wikipedia.org/wiki/Pareto_principle

Czitels napisał(a):

To wybacz, ale to są wygórowane wymagania na staż. Jeżeli ktoś się przyjmuje na staż z wiedzą na temat algorytmów, złożoności obliczeniowej, znajomością wzorców projektowych, czytania diagramów UML i jeszcze znajomością technologii to imo daje się wyzyskiwać i to mocno. Jeszcze pewnie za minimalną przez rok bo przecież najpierw staż xD.

Była mowa o podstawowych algorytmach i raczej niczym niezbyt skomplikowanym. Nikt nie każe stażyście pisać AES.

Ktoś na staż/juniora powinien imo dobrze znać język w którym pisze

Znać język czy standardowe biblioteki i możliwości chociażby .NET (przykładowo)? Sam język o zdecydowanie za mało, ważna jest znajomość platformy jako całości.

@Czitels

To wybacz, ale to są wygórowane wymagania na staż. Jeżeli ktoś się przyjmuje na staż z wiedzą na temat algorytmów, złożoności obliczeniowej, znajomością wzorców projektowych, czytania diagramów UML i jeszcze znajomością technologii to imo daje się wyzyskiwać i to mocno. Jeszcze pewnie za minimalną przez rok bo przecież najpierw staż xD.

po pierwsze wspomnialem, ze opisuje sytuacje z kiedys (10y++), nie wiem jak jest dokladnie na rynku juniorow teraz, bo bardzo dlugo juz juniorem nie jestem. Ale wiem czego wymagano na rekrutacjach. Napisalem te liste, poniewaz z tego co opisuje autor watku i z tego czego byl odpytywany, tematyka rozmow z juniorami/stazystami mocno sie nie zmienila. (no bo w sumie czego pytac juniora?)
Nie wiem skad bierzesz te dane o stazach, pameitam ze stazysci byli ~3msc na stazu.

Ktoś na staż/juniora powinien imo dobrze znać język w którym pisze, IDE, umieć oszacować złożoność, żeby nie wypalił pętli potrójnie zagnieżdżonej oraz struktury danych. Thats all, bo co to za wiedza np na temat wzorców projektowych kiedy nie widział tego w komercyjnym zastosowaniu? Wszystkiego bez problemu się nauczy.

Rowne dobrze mozna zapytac po co mu znajomosc niekomercyjna np. system kontroli wersji. W rzeczywistosci pracy w sumie po nic, nauczy sie. Ale rekrutacja ma na celu odsiac ziarna od plew, i zostawic ludzi, ktorzy cos na studiach robili albo sami sie dobrze nauczyli i jakies pojecie o temacie maja, i ta nauka do "komercyjnych" standardow zajmie krocej. Szczegolnie ma to znaczenie, gdy zmienia sie nieco relacja popyt/podaz na rynku juniorskim.

Imo o wiele bardziej jakościowe dla takiego stażysty są umiejętności miękkie oraz po prostu umiejętność organizacji oraz nauki.

Jedno nie wyklucza drugiego.

Shalom napisał(a):

Ucz się programowania, a nie "pod interview". Lepiej na tym wyjdziesz.

Ech, nie do końca się zgadzam. To jest troche sytuacja jak z próbą jak najlepszego zdania matury/SAT'ów albo innych tego typu egzaminów. Fakt, na dłuższą metę najlepiej się uczyć materiału, który jest sprawdzany. Ale jeśli chcemy otrzymać jak najlepszy wynik na tle innych kandydatów, powinniśmy się uczyć jak najlepiej zdać maturę albo jak najlepiej wypaść na interview. Nauka tego typu też da ci wiedzę ogólną, ale nie wiedza ogólna jest sprawdzana.

Niestety, rekrutacje nie weryfikują kto będzie najlepszym kandydatem na dane stanowisko, tylko kto jest najlepszy w radzeniu sobie na rozmowie.

Wracając do przykładu matury, nie jest to koniecznie złe - bo przygotowanie pod egzamin to też jest weryfikacja tego, kto potrafi robić to najlepiej. Jest na pewno duża korelacja pomiędzy osobami, które mogą się przygotować do matury na 90+% a osobami, które są w stanie opanować cały materiał ze zrozumieniem. Tylko trzeba sobie zdać sprawę, że ucząc się materiału a nie zdawania egzaminu, strzelasz sobie w stopę jeśli chodzi o efektywność.

No i wracając do rozmów: jak chcesz dostać pracę, uczysz się pod rozmowy, bo to jest najbardziej efektywne. Kandydat który tego nie robi, będzie sobie szkodził na tle innych kandydatów, którzy tak robią.

Jasne, uczenie się ogólnej wiedzy też sprawi że będzie Ci szło lepiej na rozmowach. Ale za każde (uwaga! liczby z d**y) 4h które ty spędzisz na nauce, ktoś inny tak samo dobrze wypadnie na inteview ucząc się 1h. A niestety, czas wszyscy mamy ograniczony :(

ItsFine napisał(a):

Ech, nie do końca się zgadzam. To jest troche sytuacja jak z próbą jak najlepszego zdania matury/SAT'ów albo innych tego typu egzaminów. Fakt, na dłuższą metę najlepiej się uczyć materiału, który jest sprawdzany. Ale jeśli chcemy otrzymać jak najlepszy wynik na tle innych kandydatów, powinniśmy się uczyć jak najlepiej zdać maturę albo jak najlepiej wypaść na interview. Nauka tego typu też da ci wiedzę ogólną, ale nie wiedza ogólna jest sprawdzana.

Trochę złe porównanie. Jak chcemy otrzymać najlepszy wynik to powinnismy trzaskać zadania z matmy, a jeśli chodzi programowanie to pisać programy. Jak ktoś, będzie dużo kodował to poradzi sobie na interview.

Trochę głupoty opowiadacie, ale uczenie się pod rozmowy jest jak najbardziej okej. W Ameryce są już nawet bootcampy tzw. Interview Camp, na których tylko się uczysz charakterystycznych zagadnień na rozmowy rekrutacyjne. Są tam tematy poruszane w stylu algorytmów, struktur danych, architektury (tematyka generyczna).
Ja np, z perspektywy Java Developera musiałem w domu po pracy parę miesięcy siedzieć i uczyć się "pod rozmowy" (gdy zmieniałem pracę), bo jak masz w wymaganiach np wpisane Hibernate/Spring to często rekruterzy techniczni pytają ze znajomości frameworków co dla mnie jest nieporozumieniem, no ale taki tutaj mamy klimat.

ItsFine napisał(a):

No i wracając do rozmów: jak chcesz dostać pracę, uczysz się pod rozmowy, bo to jest najbardziej efektywne. Kandydat który tego nie robi, będzie sobie szkodził na tle innych kandydatów, którzy tak robią.

No nie wiem, może na poziomie juniorskim to działa, bo ktoś kto będzie umiał np. odczytać plik z dysku będzie lepszy od kandydata, który nie będzie tego potrafił. No, ale ile razy w karierze to przejdzie?

Ja jakoś nigdy nie uczyłem się "pod rozmowy" ani "przed rozmowami". No bo czego miałbym się uczyć? Jakiejś konkretnej biblioteki albo API? A co jak mnie spytają z jakiejś innej? Coś tam w życiu zrobiłem, czegoś używałem, coś poskładałem do kupy i jakoś działało, opowiedzenie o tym wystarczy do poradzenia sobie na rozmowach. Jakieś podstawowe mechanizmy albo typowe błędy danych technologii się pamięta, a jeśli na jakiejś rekrutacji chcą pytać o kolejność parametrów metody jakiejś biblioteki, to ja nie chcę tam pracować.

Można powiedzieć w sumie, że raz się uczyłem przy okazji rekrutacji, bo dostałem zadanie napisać aplikację częściowo w technologii, której nie znałem, więc musiałem się douczyć jakichś podstaw i dobrych praktyk. No i jakoś mnie przyjęli na programistę tej technologii, więc jak widać niekoniecznie coś bym zyskał kując wcześniej kontrolki GUI na pamięć.

Ostatnio też na rekrutacji na pytania o to, czy pracowałem w technologiach, które stosują odpowiadałem głównie, że nie, a mimo tego mnie przyjęli. Widocznie obecnie w cenie jest głównie asertywność.

@somekind:

nie żebym to popierał, lecz jest to jakoś zrozumiałe

jest firma X która oferuje twoja_wypłata * 2 i akurat tak się składa, że wiesz, że pytają tam z zagadnień A oraz B z którymi nie masz doświadczenia i są czasochłonne, to czy aby zwiększyć swoje szanse uczyłbyś się tego przed rozmową?

No nie ma takich firm. A nawet jeśli, to co bym w ten sposób osiągnął? Cudem prześlizgnę się przez rekrutację, a potem odkryją że ściemniałem? Jakoś nie widzę w tym sensu.

@somekind:

No dla ciebie może nie ma, ale spójrz szerzej.

Cudem prześlizgnę się przez rekrutację, a potem odkryją że ściemniałem? Jakoś nie widzę w tym sensu.

A jak nie odkryją? A jak "tak wyjdzie", że te w/w zagadnienia pojawiające się na rekrutacji nie są aż tak częste w pracy i będziesz dawał radę? Przecież wiemy, że procesy rekrutacyjne nie są idealne.

To jest po prostu jakieś tam ryzyko - jeżeli się uda, to ktoś może mieć fajną / dobrze płatną / prestiżową / x / pracę, a jak nie to się ośmieszy i wyleci :P

Pamiętasz jak ściągałeś na studiach? to podobnie jest z tym

zagadnienia pojawiające się na rekrutacji nie są aż tak częste w pracy

znaczy ze rekrutacja jest z d**y i nie chce tam pracować ;) bo współpracownicy pewnie też z łapanki, co przyskillowali jakieś 100 interview questions xD

@Shalom:

widzę, że ktoś tu ma strong opinion na temat pytań na rekrutacji :D

bierzesz w ogóle pod uwagę że ludzie zmieniają teamy / projekty? ;)

BraVolt napisał(a):

30 aplikacji dziennie nie oznacza 30 różnych firm, tak dobrze nie ma nawet w Krakowskiej Smogowej Dolinie.

Pijesz do podziału jednej firmy na kilkanaście mniejszych celem kiwania skarbówki? Wystawianiu faktur samemu sobie i temu podobne życie na krawędzi? To w Krakowie dość popularny sport. xD

@WeiXiao: No może właśnie problem polega na tym, że nie mam czego pamiętać, więc w dorosłym życiu też nie widzę sensu w takim podejściu. Ostatecznie oszukuje się tylko siebie i traci się głównie swój czas. Nie wyobrażam sobie też żeby fajna i prestiżowa była praca, w miejscu, w którym rekrutacja całkowicie nie ma sensu. Z doświadczenia wiem, że jakieś popieprzone rekrutacje to domena słabych firm. A fajną i dobrze płatną pracę można zdobyć tam, gdzie rekrutacja ma sens.

Ale ok, rozumiem, że niektórzy mają taki fetysz, tylko niech potem na forum nie płacze, że dostał się do pracy, ale w niej cierpi.

@somekind:

teoryjka fajna, niemniej jednak chyba słabo się to ma do tego, że serwisy do nawalania zadanek i wymieniania się pytaniami z rekrutacji powstały w celu (uwaga)

dostania się do facebooka, googla, ms, amazona, ubera, netflixa itd?

Tacy ludzie istnieją i uczą się pod rekrutacje

Nawet powstała książka na ten temat i jest relatywnie popularna

Cracking the Coding Interview: 189 Programming Questions and Solutions is a book by Gayle Laakmann McDowell about coding interviews.[1][2] It describes typical problems in computer science that are often asked during coding interviews, typically on a whiteboard during job interviews at big technology companies such as Google, Apple, Microsoft, Amazon.com, Facebook and Palantir Technologies.

@WeiXiao nie, one powstały bo jest popyt. Tak samo jak bootcampy i książki 100 interview questions. Są ludzie którzy w to wierzą i płacą $ więc są też ludzie którzy taki content produkują. Nijak się to ma do jakiejkolwiek użyteczności tychże.

WeiXiao napisał(a):

teoryjka fajna, niemniej jednak chyba słabo się to ma do tego, że serwisy do nawalania zadanek i wymieniania się pytaniami z rekrutacji powstały w celu (uwaga)

dostania się do facebooka, googla, ms, amazona, ubera, netflixa itd?

Wiesz, ja nie wiedziałem, że my tu rozmawiamy o dostawaniu się do firm z tej listy. Autor wątku też nie sprawiał wrażenia, że się do którejś z nich wybiera.
Ja w każdym razie pisałem o rekrutacjach do zwykłych firm będących w zasięgu większości ludzi z tego forum.

@tdudzik: nie mówie że są bezużyteczne, bo to zawsze jakaś nauka. Wiadomo, że jak zrobisz X zadań z algorytmiki to siłą rzeczy będziesz lepszym algorytmikiem, praktyka czyni mistrza. Ale to ma sens, tylko jeśli właśnie w ten sposób to traktujesz - jako sposób na naukę nowych rzeczy, a nie ZZZ pod interview.

Podepnę się pod temat.

Jak często zdarzało Wam się nie dostać pracy po rozmowie z powodu umiejętności miękkich? Lub uwalić kogoś na rozmowie z tego powodu?

Właśnie dziś się dowiedziałem, że mój plan zdobycia posadki nie wypali, bo poległem z powodu średniego angielskiego. A czekałem przez 2 miechy na tą rekrutację... Ogólnie ponad połowę uwalonych rozmów, to uwaliłem przez umiejętności miękkie^^.

serek napisał(a):

poległem z powodu średniego angielskiego

Znajomość języka (angielski + jeden z wybranych: PHP, JS, C, Java) to zawodowa umiejętność programisty, a nie miękka.
Sorry, 21 wiek i globalizacja.

BraVolt napisał(a):

Znajomość języka (angielski + jeden z wybranych: PHP, JS, C, Java) to zawodowa umiejętność programisty, a nie miękka.
Sorry, 21 wiek i globalizacja.

Tylko nie każdy ma predyspozycje, by umieć to w bardzo dobrym stopniu. Niestety... Ciężko u mnie z tym, bo jeszcze dochodzi problem ze zwykłym rozmawianiem (bez względu czy po polsku, czy angielsku) - zacinam się, jąkam, itp.^^ A to już ciężko się tego pozbyć...

Ale za n-tym razem pewnie coś znajdę^^

serek napisał(a):

Niestety^^ Ciężko u mnie z tym, bo jeszcze dochodzi problem ze zwykłym rozmawianiem (bez względu czy po polsku, czy angielsku) - zacinam się, jąkam, itp.^^ A to już ciężko się tego pozbyć...

Masz dziecko albo rodzinę, znajomych, z małym dzieckiem?
Przypatrz się jak niemowlak zaczyna mówić. Kurde, kumaty nie jest, 2+2 nie policzy a uczy się języka. Jak? Najpierw słucha mamy, taty, "osłuchuje się" z mową.
Ucząc się angielskiego najpierw osłuchaj się z nim. Nie czytaj książek, słynnej dokumentacji technicznej.
Zaczynaj poznawanie nowych rzeczy (w końcu cały czas coś poznajesz) od YouTube i krótkich filmów, sięgaj po konferencje. Może będziesz słabo mówić ale będziesz prawie wszystko rozumiał, w związku z tym odpadnie ci stres "bo nie rozumiem!!". Zaczniesz mówić jak małe dziecko, najpierw słuchasz, rozumiesz mamę, później słowa, zdania. Trzy, czterolatek rozumie całkiem rozbudowany język ale mówi w sposób bardzo ograniczony (te audycje ze śmiesznymi wypowiedziami czterolatków na różne tematy).

Zanurz się w język, to samo przyjdzie.

Porównanie z niemowlakiem rozpoczynającym mówienie i sposób w jaki on uczy to nie są moje przemyślenia, to psychologia dziecka.
Większość dorosłych na takie porównania reaguje źle "co to ja dziecko jestem?!". Programiści "książki, tylko książki, żadnych video, konferencji, wykładów" i później mamy programistów "inglisz - jes, siur, czytam dokumentację".