Nie pisz demo na rozmowę, jeśli możesz tego uniknąć; prześlij istniejący kod lub projekty, jeśli możesz.
Dema i próbki kodu są ważne z wielu powodów (które różnią się w zależności od recenzenta), ale przede wszystkim dotyczą pokazania potencjalnym pracodawcom rodzaju kodu, który piszesz na wolności i problemów, które chcesz rozwiązać. Pomagają również wykazać poziom zainteresowania tworzeniem oprogramowania.
O wiele lepiej jest przesłać kod, który już napisałeś dla poprzedniego projektu lub gry, z której jesteś dumny lub który pokazuje sprytne rozwiązanie problemu - wszystko, co jest interesujące lub trudne lub które może służyć jako podstawa dobrej dyskusji.
Pisanie kodu jawnie do przesłania jako przykładowego kodu wydaje się być wymyślone i fałszywe; zaskakująco łatwo jest powiedzieć na przykład, że programista pomyślał, że potencjalny pracodawca chciałby zobaczyć „dobrze udokumentowany” kod, a tym samym umieścił bardzo szczegółowe komentarze na temat wszystkiego, dążąc do tego, co uważają za doskonałość. Prawdziwy kod nie jest idealny, ma brodawki i ostre krawędzie, a kiedy piszesz kod wprost w celu przesłania wersji demonstracyjnej, masz tendencję do polerowania go tak bardzo, że staje się oczywiste, że go nie napisałeś, ponieważ lubiłeś go pisać. Po prostu chciałeś pracy.
To powiedziawszy, jeśli nie masz żadnej pracy, którą możesz przesłać - albo dlatego, że jeszcze jej nie napisałeś, albo dlatego, że twoja poprzednia praca uniemożliwia przesłanie jakiegokolwiek kodu (w ramach NDA) - nie masz wiele opcji, ale napisać coś nowego. W tym scenariuszu zachęcam do skoncentrowania się na pisaniu rzeczy dla samej siebie i zapomnienia o tym, czego „chcą” pracodawcy. Napisz grę, ponieważ chcesz napisać grę. Napisz fajne demo techniczne, ponieważ chcesz poznać tę technologię, ponieważ to właśnie Cię interesuje.
- Jak ważna jest modułowość kodu?
- Jak ważne jest zaprezentowanie typowej implementacji algorytmu?
- Jak ważne jest uwzględnienie nowatorskich funkcji?
- Jak ważna jest grywalność?
- Czy powinienem uprzywilejować czytelność lub optymalizację kodu?
- Jak ważna jest dokumentacja kodu?
Odpowiedzi na wszystkie te mniejsze pytania brzmią niestety „to zależy” (z wyjątkiem kwestii czytelności - myślę, że powinieneś sprzyjać ogólnie czytelności, szczególnie w przypadku „kodu demonstracyjnego”). Niektórzy pracodawcy mogą chcieć zobaczyć, jak reimplementujesz Quicksort. Inni mogą się tym nie przejmować. Inni poproszą cię o ponowne zaimplementowanie Quicksort na tablicy podczas rozmowy.
Nie skupiaj się na tym, co Twoim zdaniem chcą pracodawcy , ponieważ różni pracodawcy, a nawet różni ludzie, którzy mogą przejrzeć Twój kod, będą chcieli różnych rzeczy. Zamiast tego skup się na tym, co chcesz pokazać o sobie , ponieważ masz o wiele większą kontrolę nad tym, a na dłuższą metę przyniesie ci to więcej korzyści.
