Początki a portfolio

ktoś będzie chciał płacić komuś kto nadal będzie się uczył.

o.0 Uwaga - szoking mode on - programiści powinni się cały czas uczyć :)

Jeśli uważasz, że sklep internetowy i blog to coś prostego, to zauważ że na rynku od lat funkcjonują system przy których pracuje mnóstwo ludzi (WordPress, Magento, czy Shopify ostatnio), a wciąż nie są doskonałe i wciąż jest luka na rynku.

Przede wszystkim wykonuj projekty. Dzięki temu Twój kod powinien naturalnie ulegać poprawie. Po jakimś czasie sam uznasz co warto pokazać, a co nie.

Liczy się jakość kodu i praktyczność wykonanych projektów.

Nie do końca na temat, ale...

Kiedyś tam zrobiłem (wspólnie z czytelnikami mojego bloga) dość długą listę rzeczy, którą programiści (i ludzie od sec) mogą wrzucić w swoje CV:
http://gynvael.coldwind.pl/?id=338

Rzuć okiem, może znajdziesz coś ciekawego na tej liście - nie ma tam przykładów projektów, bardziej są rodzaje rzeczy które można wrzucić.

Z mojego punktu widzenia - nie jest istotne jakiego rodzaju projekt jest w CV na tym poziomie, ale czym lepiej pokazuje Twoją biegłość tym lepiej (tj. czym bardziej skomplikowany pod jakimś względem, tym lepiej).

Dziękuję wam za pomoc, i odnośnie waszych odpowiedzi - robiąc projekty bardziej skupić się na tym, żeby umieć jak najwięcej zrobić z pomocą internetu czy jednak zatrzymywać się na dłużej w trakcie tworzenia kodu i uczyć się tego co napisałem (oczywiście nie na pamięć) bo podczas takiej rozmowy kwalifikacyjnej będzie wymagane ode mnie np. napisanie jakiegoś fragmentu kodu z mojego projektu ale tylko z pomocą tego co ja umiem bez szukania w internecie?

Zdaję sobie sprawę, że obie kwestie są powiązane bo im więcej będę pisał tym więcej będę potrafił sam stworzyć i może po prostu teraz za bardzo kombinuję. :)

Odpowiem trochę na opak - firmu szukające dobrych programistów sprawdzają czy kandydat umie programować „by heart”. Tj. spodziewaj się, że podczas rozmowy będziesz poproszony o napisanie kodu na karte lub na tablicy*.
Zazwyczaj nie jest wymagana znajomość każdej funkcji czy biblioteki na pamięć (od tego ma się dokumentacje, nagłówki, internet, źródła) - jeśli nie będziesz mógł sobie przypomnieć nazwy danej funkcji, kolejności jej argumentów, etc, to możesz wymyślić własną na poczekaniu i powiedzieć, że zakładasz, że taka i taka funkcja istnieje w bibliotece, ale nie pamiętasz jej nazwy, więc założysz, że nazywa się tak i tak i przyjmuje takie i takie parametry, w takiej kolejności. Oczywiście taki skrót można stosować tylko w przypadku jeśli znajomość nazwy/parametrów danej funkcji jest ostatecznie nieistotna.

Co do normalnego pisania - szczerze, to ja mam cały czas jakieś man'y, MSDNy i inne specyfikacje otwarte. Nawet jeśli się zna nazwę funkcji, jej parametry, etc, to czasem są jakieś drobne detale, które są istotne przy kodzie jakości produkcyjnej i których się raczej nie pamięta (warto pamiętać/wiedzieć że istnieją i gdzie ich szukać ;>). Natomiast to dotyczy szczegółów ekosystemu - rzeczy związane z samym językiem (składnia, etc) oraz programowaniem (tj. tlumaczeniem myśli na kod) w zasadzie powinno się znać „by heart” (co sprowadza się do „na pamięć”) - ale jak napisałeś, to przyjdzie z czasem.

• • Kojarzę, że niektórzy studenci/kandydaci często się irytują, jak ćwiczeniowiec/wykładowca/rekruter/interviewer każe im napisać kod na kartce, ale szczerze, to trudno mi sobie wyobrazić by dobry programista miał z tym problem ;) Sry ;)

bo podczas takiej rozmowy kwalifikacyjnej będzie wymagane ode mnie np. napisanie jakiegoś fragmentu kodu z mojego projektu ale tylko z pomocą tego co ja umiem bez szukania w internecie?

na jakim jesteś etapie? Jeśli umiesz już coś, to ja bym wysyłał CV i poszedł na jakąś rozmowę. Może się nie dostaniesz, ale przynajmniej zobaczysz jak to wygląda (nie wiem jak ty, ale dla mnie pierwsze rozmowy to był straszny stres - a widzę, że teraz spekulujesz jakieś dziwne rzeczy, zamiast sprawdzić w praktyce jak wygląda rozmowa o pracę dla programisty).

Rozumiem, że wypadałoby mieć jakieś portfolio, własne projekty itd. Co by to mogło być? Myślę o czymś w stylu sklep internetowy, jakiś blog ale to wydają się niezbyt skomplikowane rzeczy.

Wiele rzeczy zwykle się wydaje proste, dopóki ich nie spróbujemy sami zrobić.

Rozumiem, że wypadałoby mieć jakieś portfolio, własne projekty itd. Co by to mogło być?

Nie rozumiem jak można się interesować programowaniem i nie mieć inwencji na zrobienie czegoś własnego.

Jakiego typu aplikacje możnaby stworzyć aby nie wyglądały źle w takim portfolio?

Jakiekolwiek. Kiedyś zrobiłem dobre wrażenie na rekruterze grą platformową 2D ze skaczącym kotem, którą zrobiłem.

catkot napisał(a):

Rozumiem, że wypadałoby mieć jakieś portfolio, własne projekty itd. Co by to mogło być? Myślę o czymś w stylu sklep internetowy, jakiś blog ale to wydają się niezbyt skomplikowane rzeczy. Jakiego typu aplikacje możnaby stworzyć aby nie wyglądały źle w takim portfolio?

Żeby taki projekt miał sens musisz w niego wierzyć, mieć osobiste zaangażowanie, musi wypływać z Twoich potrzeb.
Myślę tu o projekcie nie do pokazania a do uczenia się.
Gdy będzie to projekt wypływający z rzeczywistych porzeb to będziesz w nim dorabiał realne rzeczy więc się szybciej nauczysz.
Książkowe projekty są pod tym względem bardzo ograniczone.

Jeśli chodzi o blog to powinien on prezentować Twoją wiedzę ekspercką a nie kroki w nauce (czyli nie "dziś nauczyłem się zapisywać wskaźnik na funkcję" tylko raczej "właśnie skończyłem implementację kolejnego sklepu, efekt pod adresem: x".

Skoro dużo pracujesz to musisz wybrać konkretną technologię i konkretne dla niej frameworki.
Inaczej będziesz za bardzo się rozpraszał.

Przejrzyj oferty pracy i zbierz statystyki czego warto się uczyć w rejonie w którym chcesz pracować.