Pytania na poziomie seniora na rekrutacji na mida

korokczan napisał(a):

Wiele pytań na rekrutacji jest głupia i wygląda jak kolos na studiach. Nie widzę sensu w pytaniu np. o modyfikatory dostępu, albo o język sam w sobie. Miałem już taką rekrutację, gdzie ziomek mnie wypytał o podstawy JSa i pytał o różnicę między Javą a JavaScriptem, a to była niby oferta na mida/seniora xD Podobno są "seniorzy", którzy nie ogarniają takich rzeczy, ale imo już lepiej pytać o projekty, w których dev pracował, o zastosowane tam rozwiązania i dopiero wtedy dopytanie o jakieś szczegóły danej technologii. Nie wiem, może pytania o optymalizację, np. jak można zoptymalizować zapytania w SQLu, ogólny flow aplikacji, albo wielowątkowość. Na takim odpytywaniu regułek sam często zawalam, bo wylatują mi takie rzeczy z głowy. Od tego jest dokumentacja, żeby z niej korzystać, a nie wkuwać wszystko na pamięć.

nie wiem czym mogę pochwalić się na rozmowie. Powiem że optymalizowałem SQL, ale nie przypomnę sobie jakie to było dokładnie zapytanie i w jaki sposób zoptymalizowałem. Kto takie rzeczy pamięta. Robiłem taska na optymalizacje pół roku temu i co mam na pamięć się uczyć, żeby na rozmowie dobrze wypaść? Takich rzeczy nie da się zapamiętać żeby dobrze o tym opowiedzieć, bo raz jest to ściśle powiązane z domeną projektu i w jaki sposób masz w 2 min. opowiedzieć o twoim zadaniu żeby zrozumiał, musiałbym tłumaczyć mu domenę. To by brzmiało mniej więcej tak:

Z tabeli customersDataOrders wybrełem productWithOrderAndPayment i zoptymalizowałem zapytanie w taki sposób że zamiast zwracać z tabeli kolumny Customer i Amount zwróciłem kolumny PricePerProduct, Order i Amout z tabeli CustomerOrders co poprawiło szybkość zwracania danych z tabeli o 1s.

Jak w ogóle o takich rzeczach opowiadać zielonemu rekruterowi który nie zna domeny, tego nie da się wytłumaczyć.

kamyk77 napisał(a):

nie wiem czym mogę pochwalić się na rozmowie. Powiem że optymalizowałem SQL, ale nie przypomnę sobie jakie to było dokładnie zapytanie i w jaki sposób zoptymalizowałem. Kto takie rzeczy pamięta. Robiłem taska na optymalizacje pół roku temu i co mam na pamięć się uczyć, żeby na rozmowie dobrze wypaść?

Przecież to jest standardowe miękkie pytanie, które często pada - opowiedzieć o jakimś problemie z pracy i jak go rozwiązałeś. Nigdy się z czymś takim nie spotkałeś, że taki zdziwiony?
Ciezko sobie wyobrazić, żeby kandydat był ogarnięty, ale miał problem z opowiedzeniem o swojej pracy w taki sposób, żeby laik zrozumiał i żeby nie naruszyć NDA. Taki nerd jest śmieszny tylko w filmach, w normalnym życiu nie dałoby się pracować z nim w jednym zespole

kamyk77 napisał(a):

na rekrutacji miałem pytanie co to jest CQRS,

Przedszkole...

Event drven development

Nauczanie początkowe...

, mam 3 lata expa, czy to nie jest poziom seniora?

Nie, to jest poziom początkujacego.

Co sądzicie o rozmowie prowadzone w formie teleturnieju i pytaniach typu:
Jaka jest różnica między Dispose vs Finalize?
Transient vs Scoped vs Singleton,
List vs IEnumerable
wymień wszystkie modifikatory dostępu i czym się różnią,
wzorce projektowe

Ziew.
Podstawy.

Tego nie da się wszystkiego spamiętać, po to jest IDE żeby podejrzeć dokumentację.

Jprdl.

kamyk77 napisał(a):

Robiłem taska na optymalizacje pół roku temu i co mam na pamięć się uczyć, żeby na rozmowie dobrze wypaść?

To zależy. Jeśli miałeś ileś takich rozmów sfailowanych, to może to sugerować problemy z autoprezencją. Wtedy faktycznie należałoby pomyśleć, co odpowiesz na takie pytania.

Ogólnie zmieniłbym postawę, bo:

1. narzekasz, że cię pytają o coś, czego nie wiedziałeś, zamiast się z tego cieszyć i potraktować jako okazję do pogłębienia wiedzy z tych tematów
2. zasłaniasz się tym, że czegoś nie wiesz, bo pracowałeś w legacy w gównianej architekturze: problem w tym, że rekrutera to nie będzie obchodzić, a nawet może to być na minus, jeśli będziesz deprecjonował własne doświadczenie, zamiast pomyśleć o doświadczeniach jakie stamtąd wyniosłeś
3. masz faktycznie przydatne doświadczenie (optymalizowanie SQLa) i zamiast pomyśleć, jak o tym powiedzieć na rekrutacji, to piszesz, że nie pamiętasz, że nie będziesz się uczyć mówienia pod rozmowę
4. szufladkujesz się jako mid i bronisz się przed wiedzą, którą uważasz za "seniorską"

Ogólnie masz roszczeniowe podejście, pytanie czy powinieneś. Problem z branżą IT jest to, że roszczeniowe podejście i bycie szlachtą stało się czymś, czym wiele ludzi się chwaliło i wręcz prześcigało w tym, kto będzie najbardziej roszczeniowy. I przez lata to funkcjonowało, ale obecnie być może roszczeniowe podejście nie musi być już tym najlepszym, ponieważ rynek stał się trudniejszy dla programistów i jak ktoś ma zbyt roszczeniowe podejście niż jego siła przebicia, to rekrutacji nie przechodzi.

Ty mnie pouczasz że narzekam ale nie podałeś rozwiązania, nadal nie wiem co mam odpowiedzieć na te pytania z rekrutacji.

Na przykład:

• zrefaktoryzowałem kod, który robi (wstaw co chcesz) i ten kod wykonuje się szybciej, łatwiej też się w nim połapać
• dużym problemem był brak dokumentacji w projekcie, więc analizując kod i pytając innych jak działa program, przygotowałem prostą dokumentację, aby innym było łatwiej wejść w projekt
• przejrzałem wymagania i zauważyłem, że aplikacja nie uwzględniała wymagania odnośnie (wstaw co chcesz), więc je zaproponowałem
• nie było review, więc namówiłem kolegę byśmy razem przeglądali kod
• zaproponowałem, by zacząć gita, a nie przerzucać się archiwami
• przejrzałem otwarte taski, zaproponowałem ich priorytety zgodnie z roadmapą
• napisałem testy, np. obciążające, by sprawdzić wydajność
• rozbiłem zbyt duże taski na mniejsze

@kamyk77: ja pierdl gościu - TO TY PRACOWAŁEŚ I WIESZ CO ROBIŁEŚ!!! Skoro uważasz, że nic nie robiłeś to taka jest prawda i pretensje tylko do siebie możesz mieć. Ale ty nie jesteś midem!!! TY JESTEŚ JUNIOREM i na takie stanowisko powinieneś startować.
Juniora od mida i od seniora NIE ODRÓŻNIA TYLKO STAŻ!! Odróżnia go przede wszystkim DOŚWIADCZENIE (którego tobie ewidentnie brakuje) i podejście do problemów.

Taka analogia - jakbyś pracował na budowie i przez 3 laty jedynie przerzucał piach i mieszał zaprawę to nikt w nowej pracy, z powodu tego, że pracowałeś 3 lata na budowie, nie da ci do łapy kielni i nie każe stawiać ścian.

Tutaj przykładowa „checklista na seniora”: https://littleblah.com/post/2019-09-01-senior-engineer-checklist/

Zwykle od mida oczekuje się bardzo dobrej znajomości narzędzi, umiejętności pracy w zespole i samodzielności.

Poziom seniorski to albo głęboka specjalizacja w konkretnej technologii (np. optymalizacja JVM, znajomość architektury rozproszonej poparta realnymi wdrożeniami, itd), albo/i wpływ na rozwój innych inżynierów (np. delegowanie, mentoring, leadership, tzw. „10x”). Jak widzisz, nie chodzi tutaj o znajomość SDK czy architektury na poziomie teoretycznym - to jest poziom mid.

Powyższe tyczy się firm, z którymi miałem ostatnio najwiecej styczności, tj. firma produktowa i big tech.

kamyk77 napisał(a):

podaj przykład jak ty byś odpowiedział. Pisałem wyżej że w pracy nie mam imponujących zadań którymi mogę się pochwalić. Na codzień poprawiam drobne bugi. Byłem odpowiedzialny za wykrycie błedu, krzystając z debuggera odkryłem, że błąd okazał się literówką. Robiłem endpointa do api, napisałem zapytanie do bazy, serwis, a później przetestowałem wszystko end to end korzystając z TDD. Czy to jest imponująca rzecz którą można się pochwalić? Nie sądze

To odpowiedź na mój post, ale na drugiej stronie dodałeś więcej podobnych.

Jak czytam te twoje komentarze, to mi się wydaje, że tutaj niekoniecznie problem jest tylko z twoim poziomem wiedzy. Może warto być mniej bucowatym i trochę pokazać pokory, jak rozmowa z tobą na rekrutacji wygląda tak, jak tutaj na forum, to nic dziwnego, że nikt nie chce z tobą pracować ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

Ale Ci javowcy niewychowani ( ͡° ͜ʖ ͡°)

abrakadaber napisał(a):

@kamyk77: ja pierdl gościu - TO TY PRACOWAŁEŚ I WIESZ CO ROBIŁEŚ!!! Skoro uważasz, że nic nie robiłeś to taka jest prawda i pretensje tylko do siebie możesz mieć. Ale ty nie jesteś midem!!! TY JESTEŚ JUNIOREM i na takie stanowisko powinieneś startować.

Też takie mam wrażenie. Masz postawę jak typowy junior. Coś jak:

• tego się nie nauczę, bo to jeszcze nie mój poziom
• coś tam robiłem przez te 3 lata, ale nawet nie pamiętam co dokładnie
• praca w zespole? Pff, to nieważne, tylko klikanie w komputer się liczy
• po co się komunikować? Niech rekruter sam się domyśli, co robiłem

Plus postawa kogoś, kto się zasiedział w jednej firmie i zaczyna zazdrościć innym doświadczenia, bo uważa, że doświadczenie innych jest lepsze (czyli ja biedny legacy dostałem, a inni dostali mikroserwisy).

nie potrzebuję rad o mojej postawie, bo nie o to pytam.

Tylko że postawę możesz zmienić.

Powiem że optymalizowałem SQL, ale nie przypomnę sobie jakie to było dokładnie zapytanie i w jaki sposób zoptymalizowałem. Kto takie rzeczy pamięta.

No np. osoby, które podchodzą aktywnie i starają się z każdego doświadczenia coś wyciągnąć.

Na stanowisku programisty w większości rozwiązuje się zadania PROGRAMISTYCZNYCZNE związane z kodowaniem, technologiami

Nie rozumiesz zawodu programisty. Nie ty jeden i nie ostatni. W rzeczywistości programista rozwiązuje problemy biznesowe, a kod to po prostu output i narzędzie.

Natomiast czyste programowanie jest ciekawe, tylko rzadko ktoś za nie płaci (bo tak to można swoje projekty dla funu czy własnej nauki robić i myśleć tylko o kodowaniu i technologiach). Tylko, że nawet w hobbystycznych projektach już na jakimś etapie rozwoju widać, że jednak to nie tylko kodowanie, ale i design i komunikacja z użytkownikami (np. jak ktoś bibliotekę open source wypuszcza, z której ktoś korzysta. Wtedy ważniejsze już jest przemyślenie, co dodać, co usunąć, czego oczekują użytkownicy itp. Skupienie się tylko na technologii to nie jest dobre podejście).

@LukeJL:
Przypominam o co pytam:

Pytam o wasze przykłady rozwiązanych zadań w pracy na stanoswisku mida którymi można się pochwalić na rozmowie rekrutacyjnej. Nieoczywistych, które wyróżnią z tłumu kandydatów. Zadania programistyczne związane z pisaniem kodu, nie zadania PMa, nie Scrum mastera, nie Lider Zespołu.
I bardziej rozbudowane niż optymalizacja kodu, optymalizacja zapytania, napisanie testów. Takie zadania, które junior nie potrafiłby zrobić, a mid tak.

Chcę mieć porównanie co podobni kandydaci którzy rekrutują na mida odpowiedzieliby na takie pytanie ponieważ uważam że moje zadania z pracy są powtarzalne i nie ma mam czy się chwalić właściwie

kamyk77 napisał(a):

Chcę mieć porównanie co podobni kandydaci którzy rekrutują na mida odpowiedzieliby na takie pytanie ponieważ uważam że moje zadania z pracy są powtarzalne i nie ma mam czy się chwalić właściwie

Każdy odpowiedziałby na podstawie własnego doświadczenia.

Będę szczery, masz pecha. "Przespałeś" ostatnie 3 lata robiąc proste, powtarzalne i nierozwijające taski i teraz jest tak jak piszesz - nie masz się czym pochwalić na rozmowie.

Każdy jest kowalem własnego losu. O byciu midem nie decyduje ilość przepracowanych lat, tylko konkretne umiejętności, których widocznie ci brak. Dlaczego ci brak? Tylko ty możesz odpowiedź na to pytanie. Może było ci wygodnie w robocie, może byłeś zwyczajnie leniwy. Nie wiem dlaczego tkwiłeś w nierozwijającej pracy tak długo. Teraz możesz mieć pretensje tylko do siebie.

Sytuacja na rynku też nie pomaga, bo jest mega duża konkurencja na poziomach junior/mid i na jedno takie stanowisko potrafi spłynąć kilkaset CV więc rywalizacja jest ostra i faktycznie trzeba się czymś wyróżnić a nawet powiem więcej - mieć zwyczajnie szczęście.

Takie czasy, że wraz z boomem na programowanie i setkami chętnych po bootcampach i kursikach od hindusa, od kandydatów wymaga się więcej niż 3, 4 lata temu.

Na stanowisku programisty w większości rozwiązuje się zadania PROGRAMISTYCZNYCZNE związane z kodowaniem, technologiami

Fajnie by było xD spotkania, zbieranie wymagań biznesowych, inwestygacje, pisanie dokumentacji, szukanie czegoś w bazach danych, testowanie, infrastruktura. Ogólnie dużo jest roboty innej niż programowanie. Od razu dodam, że u mnie to tak wygląda, żeby ktoś nie napisał, że sobie wymyślam.

korokczan napisał(a):

Na stanowisku programisty w większości rozwiązuje się zadania PROGRAMISTYCZNYCZNE związane z kodowaniem, technologiami

Fajnie by było xD spotkania, zbieranie wymagań biznesowych, inwestygacje, pisanie dokumentacji, szukanie czegoś w bazach danych, testowanie, infrastruktura. Ogólnie dużo jest roboty innej niż programowanie. Od razu dodam, że u mnie to tak wygląda, żeby ktoś nie napisał, że sobie wymyślam.

W dużej mierze zależy od organizacji. W słabych organizacjach niestety tak to wygląda jak napisałeś. I broń boże nie piję do Ciebie, bo sam w takiej pracowałem tzw "one-man-army" :) O dziwo można normalnie pracować tzn skupiać się GŁÓWNIE na programowaniu (z minimalną dozą innych rzeczy). Obecnie jestem w takim projekcie, gdzie faktycznie do zbierania wymogów są dedykowani analitycy, od infry dedykowani devopsi a od testów dedykowani testerzy.

mam duzo do czynienia z tego typu pytaniami i najepszy pomysl to chyba pobrac pare naprawde specjalistycznych deep dive ksiazek (Java Complete Reference 12th edition, Pivotal Certified Professional Spring Developer Exam, Spring Microservices in Action) i przejsc pare razy w wolnej chwili po spisie tresci, poczytac na spokojnie rozdzial jak po nazwie wydaje sie byc relevant i moga o tym spytac. Bo sprawdzac pytania na google jedno, ale jak nie ma sie glebszego zrozumienia, typu czlowiek przeczytal na spokojnie od eksperta i pozwolil temu na chwile zamarynowac w glowie, to jednak wyleci z pamieci