Są jakieś sposoby na to? Nie mam doświadczenia w komercyjnego w IT i kiedy przygotowuje się do rozmowy technicznej potrafię sobie poradzić (200+ rozwiązanych code warsów, ale nie jedno linijkowców), ale gdy jestem na technicznej to mam pustkę w głowię i niczego nie jestem pewny, do tego stopnia, ze nawet jak mam zrobić for loopa po liście to nie jestem pewny co to będzie i chcę printować (i). Są jakieś techniki na to, oprócz przechodzenia dziesiątki rekrutacji aż się przyzwyczaję do odmowy i przestane się przejmować?
0
0
Dokładnie tak jak piszesz. Przynajmniej ja nie znam innej metody.
2
Spróbuj zacząć od przykładów wejścia i wyjścia, wyjaśnij niejasności (np zakresy inputów, czy możesz założyć że input jest taki że rozwiązanie zawsze istnieje), później zrób sobie testy i dopiero wtedy pisz kod.
Dzięki przykładom powinieneś potwierdzisz czy dobrze rozumiesz problem, nie ma co tracić kilku minut na kod który rozwiązuje zły problem. Zyskujesz też chwilę czasu na przemyślenie problemu.
Pytanie się o edge casey daje ci dodatkowe punkty u rekrutera + unikasz przerywania i poprawek przy implementacji.
Testy powinny dać ci pewien sposób zabezpieczenia przed głupotami w implementacji i zapominaniu o edge caseach. To nie musi być automat, wystarczy sobie zapisać wejście/wyjście gdzieś z boku w komentarzu.
Zasugerowanie algorytmu rekruterowi może spowodować że naprowadzi cię bliżej tego co chce zobaczyć. Możesz też zrobić sobie sanity check przechodząc przez jakiegoś test casea (najlepiej nie skomplikowanego)
Napisanie kodu to powinna być formalność na zazielenienie test caseów. Kluczem jest dialog z rekruterem, tylko to też musi wyglądać trochę tak że ty prowadzisz ten dialog a rekruter ci tylko pomaga, nie na odwrót.
3
Na rozmowie kwalifikacyjnej nie chodzi o zadania. Bardziej liczy się to co widzisz, to jak dzielisz się swoją wiedzą i spostrzeżeniami.
Chcesz powiedzieć coś sensownego? To na początek daj sobie chwilę czasu, aby przetrawić problem, w między czasie wyluzuj, niech głowa sama włączy się do pracy, rozpisz zadanie na papierze, oceń wszystko co widzisz, określ na czym polega probem. Pomyśl chwilę dlaczego akurat takie zadanie dostałeś. Spróbuj określić plan (nie pisz wtedy jeszcze kodu), a potem zacznij o tym rozmawiać. Wciągnij w rozmowę rekrutera i zacznij zmieniać perspektywę, poświęć chwilę na ocenę alternatyw. Spróbuj podważyć sens całego dziania, przedstaw inne opcje, nawiąż do firmowych projektów (czy oni też takie głupie rzeczy piszą w swoich projektach), nie bój się modyfikować założeń.
W czasie całej rozmowy najcenniejsze informacje nie są w zadaniu, ale w osobie, która Cię rekrutuje. Zadanie to tylko pomost.
Z własnych doświadczeń słabe firmy to te:
- gdzie nie czujesz się sobą
- gdzie ludzie w trakcie rozmowy próbują być ciągle pewni, nieomylni. Wg mnie jak ktoś normalnie i po ludzku powie, że czegoś nie wie, nie jest pewny - to uwaga: masz przed sobą jedną z ciekawszych firm przed nosem, nie spie*rz tego!).
- gdzie rekrutacja była łatwa, nudna i bardzo sztywna
- gdzie w trakcie rozmowy zostawiają mnie z arkuszem zadań, testem psychoanalitycznym - rysuj wacka i nie marnuj swojego czasu
9
Domyślam się, że pustka pojawią się przez stres. Jak się nie ma pewności siebie a spotkanie uznajemy za ważne, to ciężko będzie się obronić przed stresem na samej rozmowie. Jak w postach wyżej: ćwiczyć.
Po drugie: podczas samej rozmowy przyznać się do stresu. Jak powiesz, że się denerwujesz, ktoś odpowie, że nie ma czym itp. To naprawdę działa. Wtedy widzisz, że po drugiej stronie też siedzi człowiek
2
Przećwicz sposób / proces rozwiązywania problemów. Przykładowy proces:
- Daj sobie chwilę na zrozumienie problemu, nie bój się zadawać pytań, dowiedz się, czy komuś zależy na tym, żebyś rozwiązał szaradę, czy żeby poznać sposób w jaki programujesz.
- Określ co jest wyjściem, zakoduj strukturę będącą rezultatem funkcji, napisz sygnaturę funkcji wraz z parametrami
- Jeżeli to możliwe, podziel problem na mniejsze części. Możesz to zrobić za pomocą pisania //TODO, możesz wykorzystać możliwości strukturalne języka (funkcje, klasy metody)
- Zobacz jakie masz edge case'y w każdej z jednostek kodu, im lepiej go podzieliłeś, tym ten krok jest prostszy
- Napisz test case'y (chyba, ze piszesz w google doc, wtedy napisz po prostu przykłady wejście -> wyjście
- Koduj...
1
Dziena, postaram sie po wprowadzac te rzeczy :)
8
Co do pustki - też ją czasem mam.
Przy zadaniach, które wielokrotnie robiłem, przy ludziach (np. miewam czasem zaćmienie podczas live codingu na warsztatach - mimo, że czasem robie kod któryś raz.
Bywa. W tej sytuacji - nawet mówię, ze mam zaćmienie i szkoda czasu - wyciągam gotowca (jak Adam Słodowy). Niestety, na interview tak prosto nie ma :-)
Trzeba ćwiczyć - znajdź sobie kogoś, kto Ci będzie patrzył na ekran i zrób dwa trzy proste zadania, patrzenie może być online, ten ktoś nie musi się nawet znać na kodowaniu. Po prostu rozwiązuj i tłumacz co robisz.
Zaakceptuj mentalnie, że czasem ta pustka trafi się w najgłupszym momencie na prostym zadaniu (bym wręcz powiedział, że to jest typowe). Trudno, bywa. Uwalenie interview to nie koniec świata, jak po drugiej stronie siedzi ktoś z doświadczeniem, to wie, że takie zaćmienia to norma i może będziesz miał kolejną szanse (może po prostu nie Twój dzień).
Niewyspanie ewidentnie źle wpływa - to widze. Tylko, że jak masz ważną rozmowę rano to trudno przekonać mózg, żeby szedł spać.
3
Też to przerabiałem. Ja po prostu już się tym nie przejmuję. Jak czegoś nie wiem to od razu mówię o tym ze nie wiem i tyle. A jak wiem to oprócz tego co wymagają dopowiadam swoje spostrzeżenia i rozwijam temat tak zeby było widac że kumam. W ten sposób wypda się wiarygodnie bo od razu widac ze z danymi rzeczami mialo sie do czynienia a jezeli sie z czyms nue mialo to żaden wstyd to powiedziec.