Moj pomysl na cv.

Czesc, niedlugo mam zamiar szukac drugiej pracy, troche umiejetnosci nabylem w swojej pierwszej firmie, dlatego moje stare cv idzie do smieci, kompletna masakra :D

A wiec do rzeczy, chcialem sie zapytac, czy rzeczy ktore chce dodac w cv i sposob w jaki to podziele bedzie ok. Nie mam jeszcze zadnego wzorca, bo najpierw chce w glowie sobie to ulozyc potem poszukac template ktory by dobrze to odwzorowal.

• W moim cv chcialbym nie dosc, ze podzielic na sekcje typu: dev ops, languages etc. to dodac tez do tego poziom, zeby pracodawca nie pomyslal, ze np jestem wymiataczem w gicie, np.
• Dodac sekcje, w jakim temacie aktualnie teraz sie ucze / czytam. np (DDD Eric Evans)

To sa chyba takie moje glowne rzeczy, ktorych zbytnio nie widzialem w cv, reszta bez zmian.

Wpisanie tego o czym się uczysz ale jeszcze nie umiesz nie ma wiele sensu, chyba że chcesz żebym cię z tego pytał na rozmowie. O czymś takim można pogadać jak wyjdzie na rozmowie, w CV szkoda miejsca.

to dodac tez do tego poziom, zeby pracodawca nie pomyslal, ze np jestem wymiataczem w gicie, np.

Nikt tak nie pomyśli.

Dodac sekcje, w jakim temacie aktualnie teraz sie ucze / czytam. np (DDD Eric Evans)

Takie rzeczy lepiej na blogu pisz i daj linka co najwyżej. Informacje w CV o tym, że czytasz o DDD czy innym zagadnieniu z programowania będą głupio wyglądać.

A ja mam teraz ileś artykułów o programowaniu otwartych w przeglądarce, czytałem też dzisiaj Reddita. Jednak nie napiszę o tym w CV, bo to jakoś mi nie pasuje, by to wyglądało dość głupio, wyobraź sobie np. w rubryce testowanie: "czytam artykuły w necie na temat TDD", w rubryce frameworki "czytałem dokumentację Angulara 2" czy w rubryce programowanie: "czytam Reddita" xD (w zasadzie Reddita czytam głównie, żeby się pośmiać z głupoty innych programistów, bo poziom tam jest dość niski).

A to by było w tym stylu jak pisanie o tym, że czytasz o DDD w CV (prędzej na rozmowie możesz o tym wspomnieć i podyskutować na ten temat, jeśli będzie na to czas i miejsce albo odpowiedni kontekst - np. jeśli będziesz aplikował tam, gdzie się korzysta z DDD).

A i tak teorię warto zamieniać w praktykę i robić jakieś konkretne projekty, bo sama nauka to cóż... każdy programista się uczy, a tylko nie wiele z nich coś faktycznie umie.

Niestety nie pisze bloga i watpie, ze sie za niego zabiore. Wiec moze uda mi sie zrobic jakis mini-mini projekt w DDD, zeby pokazac,ze chociaz wiem co to jest. Dzieki za odp. Czyli zostanie tradycyjnie ;)

Dodac sekcje, w jakim temacie aktualnie teraz sie ucze / czytam. np (DDD Eric Evans)

Swoją drogą ciekawa ta książka, teraz przeglądam. Sam zacznę ją czytać (w zasadzie już wcześniej tak myślałem, żeby to kiedyś przeczytać, podobnie jak np. "Code Complete" Steve McConnella)

zeby pokazac,ze chociaz wiem co to jest.

Wiedza jest ważna, ale ważniejszy jest zdrowy rozsądek. Nie chodzi przecież, żeby na pokaz stosować repozytoria, encje, bounded contexty i inne cuda, ale żeby wiedzieć kiedy to stosować, jak stosować i czy w ogóle stosować, czy może nie.

Wydaje mi się, że Eric Evans właśnie rozsądnie pisze, te urywki z ksiązki Domain-Driven Design: Tackling Complexity in the Heart of Software pozytywne wrażenie na mnie robią, widać, że pisał to ktoś, kto się na programowaniu zna a nie jakiś młodziak z Medium.com, który zjadł wszystkie rozumy.