Jak dobrze rekrutować programistów?

2
Crowstorm napisał(a):

Chwalić się można czymś wyjątkowym a nie tym co robi miliony osób.

Typowe xd może jeszcze przepraszasz za to, że żyjesz?

jakbym chciał tracić resztki godności to pokazywałbym rowa na OF

Czyżby potrzebna maść na ból wiadomo czego?

Zgadzam się zupełnie z @bagietMajster .

3

Generalnie wymeldowuje sie z tego tematu, znowu następny przykład, że wam sie oczy otworza jak mi się zamkną.

Już 2 lata temu byłem zjechany za wyśmiewanie pajaców robiących 5 różnych zawodów naraz bo przeciez co za problem ogarnąć, a teraz wymagają tego od wszystkich i macie pełne gacie o końcu eldorado.

Teraz tak samo zaraz zaczniecie opowiadac, że zrobienie gały pracodawcy to nic wielkiego, 5 minut i masz robotę, to normalne przecież bro. Tak sie konczy gdy do branzy ma dostęp każdy z ulicy.

4

Nie lubię:

  • pytań z tezą, gdzie rekrutujący oczekuje czegoś od kandydata, a sam niczego od siebie nie powie, np. test driven development działa/nie działa
  • bezrefleksyjnych pytań o podstawy, gdzie wygląda to jak egzamin albo kolos na studiach
  • architecture design typu zaprojektuj nam nowego facebooka w 1-2h podczas rozmowy rekrutacyjnej
  • kiedy rekrutujący przykłada dużą wagę do zagadnień, które były wypisane w nice to have (najgorzej jak się okazuje, że to nie jest nice to have)
  • pytanie się kilka razy o to samo
  • jakichś gierek z przedszkola typu dobry i zły rekrutujący
  • jak jeden z rekrutujących siedzi przez prawie cały czas cicho i ma minę, jakby nienawidził swojej roboty (w sumie to może być znak, że jednak nie warto pracować w tej firmie)
  • jak feedback po kilkuetapowej rekrutacji jest dwuzdaniowy i generyczny
2

@korokczan Jeśli w pytaniach z tezą rekrutujący ma swoje zdanie i liczy na jedną konkretną odpowiedź to spoko zgadzam się. Ale ja zadając takie pytania liczyłbym po prostu na to, że odpowiadający opowie o plusach i minusach. Widać wtedy, że wie, że nie istnieją złote rozwiązania i wszystko ma swoje plusy/minusy itd.

0
Crowstorm napisał(a):

Już 2 lata temu byłem zjechany za wyśmiewanie pajaców robiących 5 różnych zawodów naraz bo przeciez co za problem ogarnąć, a teraz wymagają tego od wszystkich i macie pełne gacie o końcu eldorado.

Z tym się zgodzę. Oczekiwany jest ciągły rozwój, dostosowywanie się do nowych technologii, pisania FE, BE, devopsowania, a niekoniecznie idzie za tym wzrost zarobków (albo jest nieadekwatny do oczekiwań).

7

Niektórzy nie zrozumieli pytania. Nie pytałam jak chcielibyście być rekrutowani, pytałam jak rekrutować, żeby dobrze ocenić potencjał kandydata i skutecznie odsiać osoby, z którymi i tak nie będzie przyszłości (np. jak ten sfrustrowany kolega z komentarzy 😛 ).

Dzięki wszystkim, którzy wysilili się na konstruktywne uwagi :)

4
szarotka napisał(a):

Niektórzy nie zrozumieli pytania. Nie pytałam jak chcielibyście być rekrutowani, pytałam jak rekrutować, żeby dobrze ocenić potencjał kandydata i skutecznie odsiać osoby, z którymi i tak nie będzie przyszłości (np. jak ten sfrustrowany kolega z komentarzy 😛 ).

Dzięki wszystkim, którzy wysilili się na konstruktywne uwagi :)

odpowiedzielismy jak powinna wyglądać rekrutacja żebyśmy nie wyszli w trakcie tej rekrutacji

5

Na pewno proponowałbym opierać rekrutacje o tematy związane z codzienną pracą. W tym ew zadania podczas rozmowy. Tylko takie rozwiązanie ma sens, bo inaczej to wszystko jest na wyrost i sprawdzacie cos, czego nie koniecznie szukacie / potrzebujecie.

4
szarotka napisał(a):

Niektórzy nie zrozumieli pytania. Nie pytałam jak chcielibyście być rekrutowani, pytałam jak rekrutować, żeby dobrze ocenić potencjał kandydata i skutecznie odsiać osoby, z którymi i tak nie będzie przyszłości

Jedno z drugim się wiąże. Celem kandydata jest zwykle znalezienie pracy na dłużej, a celem firmy jest znalezienie pracownika na dłużej. Jak rekrutacja będzie źle przeprowadzona, to albo kandydat i firma nie nawiążą współpracy, albo nawiążą ją na chwilę (bo albo pracownik się zwolni, albo zostanie zwolniony). Czyli zarówno kandydatowi jak i firmie powinno zależeć na tym samym.

Z moich doświadczeń jako kandydata (i co uważam za dobrze prowadzone rekrutacje) bym powiedział tak:

  • jakieś testy techniczne, żeby sprawdzić, czy ktoś ogarnia, wiadomo, i żeby zobaczyć jak myśli. Tylko te testy techniczne powinny być z osobami z tego dokładnie zespołu, w którym będzie się pracować. Inaczej to trochę bez sensu.
  • zapytaj o oczekiwania, ambicje, sposób pracy, poglądy na agile, Scrum, podejście do pisania testów. Czy ktoś woli greenfieldy, czy większe projekty. Czy woli w piwnicy pracować, czy lubi spotkania i rozmowy z klientem. Czy lubi naprawiać bugi, czy woli klepać ficzery a może decydować o architekturze itp.
  • powiedz szczerze o projekcie, czy jest legacy kod. Jaki poziom otestowania. Czy jest Scrum i jak wygląda. Czy jest bardziej spaghetti czy przeinżynierowanie. Jak wyglądają praktyki CI/CD. Jeśli kod został pisany przez juniorów, to powiedz. Jeśli kod napisał kolega, który już tu nie pracuje, to też warto powiedzieć. Ogólnie nic nie ukrywać, a to, co "dobre", to powiedzieć z dobrodziejstwem inwentarza (czyli np. stosujemy TDD i mamy obowiązek 100% pokrycia testami, a code review nie przejdzie, jeśli zmienne nie będą się nazywać tak, jak senior powie i nie będzie 10 stron dokumentacji). Tak, żeby odstraszyć ludzi, którym się to nie spodoba i zatrzymać ludzi, którym się to podoba.

Czyli:

  • skille techniczne i to, jak się zespół dogaduje z kandydatem
  • co kandydat sądzi o różnych rzeczach (żeby odsiać niepasujących kandydatów).
  • jak wygląda projekt (żeby niepasujący kandydaci sami się odsiali).
3

Robienie teorii dookoła rekrutowania to jest wyższa szkoła problemów pierwszego świata.

Mniej wysiłku stracisz jak po prostu na podstawie 1h oceny online (idzie manago i ze dwóch technicznych którzy z nim będą robić - robią ocenę czy będzie pasował do stylu pracy) zatrudnisz typa na 1 miesięczny okres próbny i najwyżej go wywalasz później.

1

zatrudnisz typa na 1 miesięczny okres próbny i najwyżej go wywalasz później.

W wielu firmach jest UoP i planowane zatrudnienie na okres powyżej 6 miesięcy, więc musisz próbny na 3 miesiące to raz. Dwa - w ten sposób możesz latami szukać kandydata ;), bo w lepszym przypadku okaże się, że gość nie jest warty tych 20k co chciał, ale np 13k. Z tym, że on tego nie zaakceptuje i musisz szukać od nowa a ciepłe taski czekają, aż ktoś je weźmie. W gorszym wariancie to ten ktoś jest nieogarem i całkowicie straciliście 1-3 miesiące na próbę wdrażania. Jeżeli stosowałem ta metodę wcześniej to imo miałeś szczęście.

A jakbym dostał info, że najpierw 1 miesiąc próbny to bym się nawet nie zwalniał z poprzedniej firmy tylko robił OE.

4

Nie no pierwsze słyszę o wymogu umowy na czas określony z wymuszonym okresem minimalnym.

Ponadto jeśli firma stoi w sytuacji że gorące taski już czekają ... to firma się musi jednak lepiej ograniać i szukać ludzi nie mając noża na gardle. No to jest 101 rekrutacji. A jak ktoś tego nie wie to potem powstają takie tematy jak ten (rekrutacja na asapie).

2

@marian pazdzioch Wystarczy szybko wygooglac. https://www.pit.pl/umowa-o-prace/umowy-na-okres-probny-na-nowych-zasadach-1008273

Zgodnie bowiem z nowym art. 25 § 22 K.p. wchodzącym w życie 26 kwietnia br. umowę o pracę na okres próbny zawiera się na okres nieprzekraczający:

1 miesiąca - w przypadku zamiaru zawarcia umowy o pracę na czas określony krótszy niż 6 miesięcy,
2 miesięcy - w przypadku zamiaru zawarcia umowy o pracę na czas określony wynoszący co najmniej 6 miesięcy i krótszy niż 12 miesięcy.
Z przywołanej regulacji wynika, że w przypadku gdy strony planują zawrzeć po umowie na okres próbny umowę na czas określony wynoszący co najmniej 12 miesięcy lub umowę na czas nieokreślony, długość okresu próby powinna wynosić 3 miesiące (przykład 1).

Dziwi mnie jak wielu ludzi ciągle myśli, że żyjemy w kapitalistycznym kraju.

to firma się musi jednak lepiej ograniać

Gdyby ludzie mogli pracować gdzie chcą to by 90% firm na rynku nie miało pracowników, bo właśnie są nieogarnięte. W dodatku będąc menadżerem możesz po prostu dostać gówniany budżet na rekrutacje i baw się dobrze w próbie zatrudnienia seniora za 15-18k brutto.

4

Najlepsza rozmowa jaką wspominam to krótka rozmowa, może z 30min. Dwa trzy krótkie pytania teoretyczne, potem trochę bardziej złożone.
Można dorzucić jakieś krótkie zadanie na 20-30min max. Najlepiej coś z projektu, tak by wyczuć jak ktoś reaguje na uwagi, jak mówi o tym co robi.

Każdy projekt jest inny ma swoją specyfikę i swoje patologie i zaniedbania. Do tego trzeba przywyknąć. Niektóre braki techniczne można nadrobić inne nie. Jak ktoś jest oszołomem to i tak będą z nim problemy.

Rekrutacja to zawsze jest trochę ruletka. Można coś tam sprawdzić ale i tak wszystko wychodzi dopiero w praniu. Dlatego jestem zdania, że nie ma sensu sprawdzać za dużo.
Poza tym, wszystko zależy od budżetu firmy. Jak nie możesz dać więcej kasy to nie ma co szaleć z poziomem trudności w rekrutacji bo niekomu się nie będzie chciało męczyć.
Z drugiej strony duża kasa niekoniecznie przyciąga najlepszych programistów. Bo nie każdemu zawsze zależy na kasie. Spotkałem dobrych inżynierów którzy nie byli chytrzy na pieniądze i woleli siedzieć na UoP za 15k bo tak im było wygodnie. A miałem do czynienia z ściemniaczami co zmieniali wciąż pracę byle więcej zrobić. Never know.

1

Temat widać grzeje to dorzucę jeszcze (już widzę jak "entitled Karens" się odpalają). Dużo opinii na pytanie "jak dobrze rekrutować programistów" przyjmuje tylko pozycję zatrudnianego, pomijając drugą stronę.

Rekrutacja jest kosztowna 💸 ⏲️

  • headhunterzy biorą 3 miesięczne pensje
  • ogłoszenia w portalach kosztują
  • nowy pracownik potrzebuje czasu zanim staje się produktywny w nowym środowisku
  • czas jaki nowy "zabiera" HR, współpracownikom, onboarding itp.

Wiadomo, że jak firma inwestuje kasę w nowego pracownika to chce mieć pewność, że dobrze wybrała - krótka pogadanka o poprzednich projektach i szybkie zadanko może nie wystarczać.

TBH dla mnie to trochę red flag jak firma daje ofertę bez porządnego sprawdzenia kandydata/ki. Może to oznaczać, że będziesz pracował z niekompetentnym zespołem, że firma ma jakieś problemy i musi gasić pożar, albo że zatrudnia bez głowy i bez głowy będzie też zwalniać.

3
not Michal napisał(a):

Temat widać grzeje to dorzucę jeszcze (już widzę jak "entitled Karens" się odpalają). Dużo opinii na pytanie "jak dobrze rekrutować programistów" przyjmuje tylko pozycję zatrudnianego, pomijając drugą stronę.

Rekrutacja jest kosztowna 💸 ⏲️

  • headhunterzy biorą 3 miesięczne pensje
  • ogłoszenia w portalach kosztują
  • nowy pracownik potrzebuje czasu zanim staje się produktywny w nowym środowisku
  • czas jaki nowy "zabiera" HR, współpracownikom, onboarding itp.

Wiadomo, że jak firma inwestuje kasę w nowego pracownika to chce mieć pewność, że dobrze wybrała - krótka pogadanka o poprzednich projektach i szybkie zadanko może nie wystarczać.

TBH dla mnie to trochę red flag jak firma daje ofertę bez porządnego sprawdzenia kandydata/ki. Może to oznaczać, że będziesz pracował z niekompetentnym zespołem, że firma ma jakieś problemy i musi gasić pożar, albo że zatrudnia bez głowy i bez głowy będzie też zwalniać.

Ale nigdy nie masz pewności. Dlatego ja uważam podejście "Fail Fast" za lepsze.
Bo możesz sprawdzać mało i na okresie próbnym masz Fail bo kandydat nie spełnia oczekiwań.
Możesz sprawdzać dużo i na okresie próbnym mieć Fail bo kandydat nie spełnia oczekiwań.

Z tym, że przy pierwszym palisz mniej pieniędzy na rekrutację. W drugim palisz dużo pieniędzy na rekrutację a potem tyle samo na okres próbny co w pierwszym przypadku.
To, że przemielisz kandydata z zadań technicznych nie jest gwarantem, że spełni oczekiwania. Jeśli masz faktycznie dobry system rekrutacji w tym dobre zadania, które rzeczywiście weryfikują przydatność w projekcie to super. Ja jeszcze takich nie spotkałem. Istnieje ryzyko, że będziesz wydawać dużo na rekrutacje, stracisz sporo czasu na zadania i ich sprawdzanie a i tak nikogo nie zatrudnisz bo nikt nie spełni oczekiwań. Pytanie teraz czy projekt faktycznie wymaga takiej głębokiej wiedzy.

0

Ja jeszcze dodam że @szarotka nie podaje żadnych statystyk.

Jedynym wyznacznikiem dobroci rekrutacji jest procent osób które nie są złe/fatalne/zawodne/niezaradne w pracy.
Lub możemy to odwrócić i powiedzieć że słabość rekrutacji można mierzyć jako procent zatrudnionych osób które okazały się niezdolne do wykonywania im pracy.

Ale zakładam że skoro pojawiło się tutaj to pytanie to nie jest z tym współczynnikiem najlepiej (inaczej po co pytać?).

Naprawdę zachęcam na poważnie żeby podejść do tego w kategoriach testów A/B, gdzie jest obecny pipeline i alternatywny (zachęcam do podkręcenia poziomu na tym alternatywnym) a następnie porównać po roku rezultaty. Niestety badania dietetyczne i HRowe mają to do siebie że faktyczną produktywność można zbadać często jednynie po roku lub dwóch pracy. Niemiej doświadczenie życiowe nauczyło mnie że jak ktoś sobie nie radzi to ujawnia się to z reguły dużo wcześniej.


EDIT:

A teraz coś dla ludzi biznesu aka tych którzy cwaniakują i z niczego chcą zrobić coś! Zamiast inwestować w drogie testy A/B można też zrobić tak, umówić się na interview do kilku firm żeby wybadać (nie chcę tutaj użyć słowa ukraść, choć mentalnie o to chodzi, w końcu GUI to pomysł ukradziony BellLabs) jak tam wyglądają procesy. Następnie dostosować swój proces do średniej rynkowej. Dzięki temu nie zatrudnimy ludzi gorszych niż średnia z firm które obserwowaliśmy, a jeżeli wybierzemy firmy odpowiednio dobrze to możemy mieć proces rekrutacyjny top-notch czy jak mówimy po polsku z najwyższej półki.

Do odważnych świat należy! Koder robi, tester leży!

1
tefu napisał(a):

Ale nigdy nie masz pewności. Dlatego ja uważam podejście "Fail Fast" za lepsze.
Bo możesz sprawdzać mało i na okresie próbnym masz Fail bo kandydat nie spełnia oczekiwań.
Możesz sprawdzać dużo i na okresie próbnym mieć Fail bo kandydat nie spełnia oczekiwań.

Jasne, że nie masz pewności. Mówisz o tym jak o 0/1 wartości a to jest prawdopodobieństwo czy kandydat się sprawdzi (a nawet to nie jest zero-jedynkowe, bo może się sprawdzić w jakimś stopniu)

Lubię podejście "Fail fast" do projektów, ale tu mówimy o ludziach. Niektórzy mają rodziny, dzieci, kredyty, przeprowadzają się za pracą - trochę empatii ;)

0

@0xmarcin miałam jeden przypadek, gdzie zatrudniony kandydat okazał się kompletnym niewypałem.
Wówczas byłam osobą współtowarzyszącą w rekrutacji, ów kandydat był co prawda moim drugim wyborem (miałam lekkie wskazanie w kierunku innego kandydata), ale nie widziałam żadnych red flag, trochę mi brakowało, ale generalnie wydawał się ok i dałam okejkę. Nic nie zapowiadało katastrofy.

0

@szarotka

pytałam jak rekrutować, żeby dobrze ocenić potencjał kandydata i skutecznie odsiać osoby, z którymi i tak nie będzie przyszłości

Nie ma odpowiedzi na to pytanie. Gdyby istniała, to MAG7 (ex-faamg) ze swoim kapitałem już by ją stosowała.

Oni mają kapitał, skalę oraz dekady expa aby móc testować różne podejścia i z tego co czytam, to niby często jest to po prostu LC + System Design. Oczywiście nie twierdzę że każdy team w taki sposób tam rekrutuje.

I w sumie jakiś sens to ma - LC jako quasi-IQ test (IQ is the No. 1 predictor of work success) oraz jakichś tam umiejętności programowania

a sys design jako takie bardziej otwarte pytania dot. tego jak się składa klocki, gdzie raczej ciężej wyuczyć się regułek.

A, no i jeszcze musisz jakoś wyłapać cechy :D

LC medium/hard + zaprojektuj twittera? a może zamiast tysięcy CV masz tylko 10 i takie podejscie nie ma sensu?

1
szarotka napisał(a):

Wciąż mam niewielkie doświadczenie w byciu po tej drugiej stronie i rekrutowaniu.

Przede wszystkim zastanów się jak eliminować debili i cwaniaków których jest >95%.
5 lat temu miałem okazję być poproszony o ocenę kandydatów jako programistów mikrokontrolerów.
Umówiliśmy wszystkich (28 osób) na 1 dzień.
Większość rozmów trwała max 10 minut, z czego połowa do przywitanie itp. itp. i jedno proste pytanie.
Debil uciekał sam, nawet nie trzeba było dziękować za rozmowę. Ale i tak prawie cały dzień zszedł.

Zostały 2 osoby. Potrzebna była 1 osoba, skończyło się że obu zatrudnili.
Jeśli twój zleceniodawca zajmuje się jakimiś sensownymi rzeczami a nie bzdetami, chętnie posłuże pomocą.

0

@wojtekp112234 źle to świadczy jak się kogoś wyzywa. Inna sprawa, w tej branży raczej nie ma tego, że przychodzi ziomeczek z UP i tylko po pieczątkę aby dostać a nie aby chciał tam pracować. Ba do innych zawodów przychodzą takie ziomeczki co tylko chcą pieczątkę i mówią że nie chcą pracy bo pracują na czarno a do ubezpieczenia im potrzebna pieczątka, że byli na rozmowie. Nigdy nie daję a nawet w takich wypadkach dzwoniłem do UP aby ich może wzięli za d**y. Z takimi pasożytami społecznymi nie masz nawet pewnie do czynienia. Więc jak byś ich nazwał.

0
Cimron napisał(a):

@wojtekp112234 źle to świadczy jak się kogoś wyzywa. Inna sprawa, w tej branży raczej nie ma tego, że przychodzi ziomeczek z UP i tylko po pieczątkę aby dostać a nie aby chciał tam pracować. Ba do innych zawodów przychodzą takie ziomeczki co tylko chcą pieczątkę i mówią że nie chcą pracy bo pracują na czarno a do ubezpieczenia im potrzebna pieczątka, że byli na rozmowie. Nigdy nie daję a nawet w takich wypadkach dzwoniłem do UP aby ich może wzięli za d**y. Z takimi pasożytami społecznymi nie masz nawet pewnie do czynienia. Więc jak byś ich nazwał.

Czemu twierdzisz, że krogoś wyzywałem. Z mojej strony była absolutnie grzeczna rozmowa i jedno pytanie techniczne na przykładzie prawdziwego (nie zrobionego celowo pod test) programu.
Natomiast sam zostałem oskarżony o bycie złośliwym, ew. że sobie jaja robie. A nie byłem. Po prostu znalazłem prostą metodę jak stwierdzić, czy kandydat mówi prawdę twierdząc, że umie programować w C i zna mikrokontrolery z procesorem ARM.

Co istotne ŻADEN z tych co nie wiedział nie zachował się jak mężczyzna i nie powiedział coś w stylu:

"OK to mnie zagiąłeś i odpadłem, ale powiedz jaka była odpowiedź i dlaczego".
Gdyby tak powiedział to bym mu wytłumaczył.

Przysięgam - to pytanie było banalnie proste dla każdego kto ZNA MIKROKONTROLERY z procesorem ARM. A to nie w sensie każdej instrukcji asemblera, każdego rejestru itp. tylko podstawowej rzeczy.
Jakie było pytanie - nie zdradzę. Za pomysłowość się płaci.

A takich co opisujesz to w ogóle nie będzie na rozmowie na miejscu - to każdy normalny człowiek po przeczytaniu CV w ogóle nie zaprosi.
Co do skali nazewnictwa tych istot człekokształtnych o których mówisz - nie powiem więcej żeby nie mieć kłopotów z prawem.

1
szarotka napisał(a):

@0xmarcin miałam jeden przypadek, gdzie zatrudniony kandydat okazał się kompletnym niewypałem.

Raczej jeden przypadek gdy w porę to zauważyłeś.

0

I w sumie jakiś sens to ma - LC jako quasi-IQ test (IQ is the No. 1 predictor of work success) oraz jakichś tam umiejętności programowania

Testy IQ nic nie pokazują.

0

Z jednej strony IQ jest obiektywne, z drugiej jeśli ktoś ma nie pokładane w głowie, to będzie wyżądzał szkody szybciej. https://www.google.pl/url?sa=i&url=https%3A%2F%2Fwww.reddit.com%2Fr%2Fcomics%2Fcomments%2Fd1sm26%2Fbehold_the_ultimate_life_form%2F&psig=AOvVaw2_jKFVogY9Kj9QooHAoJgl&ust=1707861176586000&source=images&cd=vfe&opi=89978449&ved=0CBMQjRxqFwoTCPipuejkpoQDFQAAAAAdAAAAABAE — _flamingAccount 46 sekund temu

Test IQ mierzy szybkość kojarzenia. Nie myślenia.

Kojarzenie to to co robi np. chat GPT czy też struktury w mózgu. Kojarzenie+baza wiedzy jest niezbędnym narzędziem by móc myśleć. Ale nie jest myśleniem.

Natomiast żeby coś stworzyć potrzeba jest też zdolność myślenia i kreatywność. Tego IQ nie mierzy.
Osoba myśląca z niższym IQ po prostu wymyśli coś wolniej, ale wymyśli.
Natomiast jest całe mnóstwo kretynów z IQ nawet 160. Tak znam niejednego.

1

Nie mylcie wiedzy / doświadczenia z Inteligencją. To są różne zagadnienia - jakie często wiele osób splata w jedno.
Testy IQ - mają za zadanie przewidzieć rozwiązanie czy tok myślenia osoby co tworzyła testy. Osoby inteligentne nawet często mogą ich nie rozwiązać, bo zaczną dostrzegać inne wzorce w wielu przypadkach - niż te zamierzone przez twórcę testu.

IQ pozwala znajdywać nowe rozwiązania, a wiedza i doświadczenie wykonywać szybciej wymagane rozwiązania (już znane). Takie sprostowanie z mojej strony.

3

Następny złodupiec wszedl do tematu, wszystkie rozumy pozjadane a linka bez syfu wstawić nie potrafi xD

1
Cimron napisał(a):

Nie mylcie wiedzy / doświadczenia z Inteligencją. To są różne zagadnienia - jakie często wiele osób splata w jedno.
Testy IQ - mają za zadanie przewidzieć rozwiązanie czy tok myślenia osoby co tworzyła testy. Osoby inteligentne nawet często mogą ich nie rozwiązać, bo zaczną dostrzegać inne wzorce w wielu przypadkach - niż te zamierzone przez twórcę testu.

IQ pozwala znajdywać nowe rozwiązania, a wiedza i doświadczenie wykonywać szybciej wymagane rozwiązania (już znane). Takie sprostowanie z mojej strony.

Nie IQ tego nie pozwala. Co najwyżej - w połączeniu z kreatywnością - to ułatwia.

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