Czy trzeba być dobrym z teorii żeby dostać pracę? Mam kilka lat doświadczenia, rozumiem co się dzieje w języku i frameworku którego używam, ale nie zawsze umiem to "ubrać" w słowa tak żeby wyrecytować to jak definicję. Dodatkowo jestem małomówny co utrudnia sprawę. Znacie książkowe definicje wszystkich zagadnień na pamięć? Do tej pory pokazywałem kod, robiłem zadania testowe i nie było takiego przepytywania z teorii.
Zależy od firmy.
Jedna firma zroi rekrutację sensownie, a inna oleje temat i użyje któregoś zgotowych zestawów pytań z Internetu.
Jak trafisz na tą drugą, to będziesz musiał pamiętać quicksorta, albo znać różne kruczki frameworków, a jako zadanie na kartce będziesz miał coś w stylu ocpjp.
Książkowych definicji wszystkich zagadnień natomiast chyba nikt nie zna, ale są pojęcia podstawowe, które wypada znać. Jeżeli nie umiesz powiedzieć na czym polega rekurencja to przepadłeś.
Zależy o jaką teorię chodzi. Jeżeli nie znasz podstawowych definicji z OOP albo wzorców projektowych to nikt Ci nie uwierzy, że to stosujesz. Co mnie obchodzi, że umiesz coś napisać, skoro przy najmniejszej zmianie trzeba będzie przepisać wszystko od początku?
tak, trzeba
pisze calkiem fajne rzeczy, na rozmowach pytalem zawsze czy zajrzeli na mojego githuba to jeszcze sie nie zdarzyło zeby odpowiedz byla twierdząca
po czym nastepuje napierdalanka pytan teoretycznych o bardzo wazne rzeczy w stylu czym rozni sie klasa abstrakcyjna od interfejsu, w koncu jest tylko jedna sluszna droga do rozwiazania problemu i nazywa sie to WZORCE PROJEKTOWE
banda pajacow po zarządzaniu woli wybrac kogos kto bedzie klepal puste frazesy na rozmowie, nie dajac nawet szansy takim jak ja i op
Wyczuwam ból czterech liter... - mariano901229 2 minuty temu
doprawdy? jak na to wpadles?
Mozna byc dobrym z teorii i praktyki. Miec doswiadczenie i byc dobrym algorytmikiem, a i tak byc bezrobotnym...
@Bogaty Szewc bo po co ktoś ma zatrudniać gościa który nie umie wyjaśnić nawet dlaczego A monad is just a monoid in the category of endofunctors
. Co taki człowiek może sobą reprezentować? Po co taki człowiek żyje jak ten chwast
? Czy taki ktoś ma w ogóle rozum i godność człowieka
?
#pdk
@mega_devs czasem nie trzeba, ale niektórzy nie do końca rozumieją co to jest teoria
. Różnica między interfejsem a klasą abstrakcyjną to nie jest teoria tylko praktyka w najczystszej postaci. Pytanie z teorii to by było na przykład wyjaśnij dlaczego funkcje hashujące nie nadają się do szyfrowania
.
Teoria jest jedną z najbardziej praktycznych rzeczy w życiu.
Kwestia tylko czego teoria dotyczy.
Pół biedy jak się jest programistą tworzącym kod(wiency, wiency kodu) bo taki przeważnie prowadzi rekrutacje więc wie o co pytać.
Dużo słabiej jak się jest na supporcie, gdzie specyfika jest taka, że zmienia się linijkę kodu raz na tydzień(jak w tym kawale 1$ za stuknięcie, 9999$ za wiedzę gzie stuknąć), ale za to dobrze się orientuje w nastoletnich projektach, zna jakieś turbokruczki frameworków czy optymalizuje jakieś operacje.
To jest zupełnie inna klasa problemów i wcale nie łatwiejsza czy mniej techniczna, ale rekrutację prawie na pewno przeprowadzać będzie typowy koder więc on o takich rzeczach pojęcia nie ma(czasem to jest jak taka trochę lepsza pani z hr w tej konkretnej działce) czyli będzie pytał o to co zna i tu prawie na pewno wypadniesz słabiej, bo zwyczajnie nie produkujesz setek linii kodu na codzień.
Tu nie byłoby nic złego gdyby taki człowiek trafiał później faktycznie na dev(czyli na to z czego go rekruterzy sprawdzali), ale z racji takiego a nie innego doświadczenia często trafi znowu na support.
Ja nie ogarniam wzorcy projektowych. Tzn. znam 1, czy 2. W teorii. Bo w praktyce to sam je wymyśliłem ;) Ale na tym bym poległ. Jednak uważam, że nie ma się co ich uczyć na siłę, póki nie masz konkretnego problemu do rozwiązania. Dobrą opcją jest przeczytanie jakiejś książki z wzorcami, żebyś wiedział, że np. do rozwiązania takiego problemu jest jakiś wzorzec. Jak będziesz miał ten problem do rozwiązania, to wtedy poszukaj wzorca. Takie jest moje zdanie.
@Juhas no tylko że jeśli nie miałeś konkretnego problemu do rozwiązania
kiedy warto byłoby użyć jakiegoś wzorca to chyba nic ponad hello world nie pisałeś ;) Albo wychodzi właśnie nieznajomość wzorców których należało użyć. Bo takie rzeczy jak Strategy, Template Method, Builder, Adapter (i przy jakims GUI jeszcze MVP) to wychodzą praktycznie od razu w dowolnym kodzie ;)
W tych czasach i tak szukają mistrzów frameworków, szczególnie w webdev ;)
Shalom napisał(a):
@Juhas no tylko że jeśli nie miałeś
konkretnego problemu do rozwiązania
kiedy warto byłoby użyć jakiegoś wzorca to chyba nic ponad hello world nie pisałeś ;) Albo wychodzi właśnie nieznajomość wzorców których należało użyć. Bo takie rzeczy jak Strategy, Template Method, Builder, Adapter (i przy jakims GUI jeszcze MVP) to wychodzą praktycznie od razu w dowolnym kodzie ;)
Ja nie mówię, że nie używałem wzorca, tylko że go nie znałem. Projektowałem i pisałem fragment systemu z myślą "powinno być dobrze", a potem się okazywało, że taki sposób już ktoś przede mną wymyślił i nawet jakoś to nazwał, tworząc wzorzec. Tak więc sam niejako tworzyłem i używałem wzorców, nie będąc tego świadomym.
@Juhas - wzorzec to nie jest sposób na rozwiązanie problemu algorytmicznego tylko projektowego, zatem możesz nigdy nie poczuć, że tego potrzebujesz. Napiszesz jakiś kod, a później będziesz się z nim użerać, bez świadomości, że gdybyś napisał go inaczej (przy użyciu wzorca) to byłby łatwiejszy do rozszerzania i modyfikowania.
Wiem, czym jest wzorzec. OK,
problem: zaimplementować system undo/redo.
problem: zaimplementować sortowanie tablicy intów
Widać chyba na pierwszy rzut oka różnicę pomiędzy tymi problemami, tak? Jeden jest typowo algorytmiczny, a drugi typowo projektowy. Jak umiesz projektować systemy (masz w tym kilkuletnie doświadczenie), to zazwyczaj wiesz, jak zaprojektować dobrze. I tu znajomość wzorców nie jest Ci potrzebna. Jest przydatna, bo gdy znasz te wzorce, to całość zaprojektujesz i napiszesz dużo szybciej i pewnie będziesz miał mniej problemów po drodze.
Bogaty Szewc napisał(a):
tak, trzeba
pisze calkiem fajne rzeczy, na rozmowach pytalem zawsze czy zajrzeli na mojego githuba to jeszcze sie nie zdarzyło zeby odpowiedz byla twierdząca
po czym nastepuje napierdalanka pytan teoretycznych o bardzo wazne rzeczy w stylu czym rozni sie klasa abstrakcyjna od interfejsu, w koncu jest tylko jedna sluszna droga do rozwiazania problemu i nazywa sie to WZORCE PROJEKTOWEbanda pajacow po zarządzaniu woli wybrac kogos kto bedzie klepal puste frazesy na rozmowie, nie dajac nawet szansy takim jak ja i op
Sorry, ale jak tego nie wiesz to nawet na staż się nie nadajesz.
Jeśli masz praktykę, co za problem? Wystarczy trochę się pouczyć, skoro znasz praktykę, wszystko powinno pójść łatwo i szybko. Przy okazji teoria da Ci szersze pojęcie nt. tego co stosujesz, i da Ci dodatkowe pomysły na zastosowania, tj. poszerzy świadomość programistycznych narzędzi i metodologii.
A co do wzorców, na początek chyba najlepsza to Head First Design Paterns (czy jakoś tak) - Java, ale w sumie jak znasz jakikolwiek język OOP, to nie ma problemu.
Musisz umieć podejmować decyzje i wybory oraz je uzasadniać. Decyzje i wybory to praktyka, uzasadnienie to teoria lub doświadczenie.
Czy trzeba być dobrym z teorii żeby dostać pracę? Mam kilka lat doświadczenia, rozumiem co się dzieje w języku i frameworku którego używam,
ale nie zawsze umiem to "ubrać" w słowa tak żeby wyrecytować to jak definicję. Dodatkowo jestem małomówny co utrudnia sprawę.
Twoim problemem wydaje się brak pewności siebie, a nie brak znajomości teorii.