Jaką płacę proponować na rozmowie

Wybieram się na kilka rozmów, mam około roku doświadczenia w .NET. Jaką stawkę proponować na rozmowie żeby nie zrazić ani nie wkopać się w głodową kwotę? Jestem na końcówce studiów zaocznych. Chodzi o stanowisko programisty C#.

1. Jakie miasto.
2. A o jakich kwotach myślisz?

Po roku doświadczenia w większym mieście (niekoniecznie wawa) 5-6k brutto to uczciwa kwota. Zapewne niektóre firmy będą w stanie zaoferować więcej a niektóre mniej.

0x200x20 napisał(a)

Zapewne niektóre firmy będą w stanie zaoferować więcej a niektóre mniej.

Nie wykluczone że będzie odwrotnie ; p

b

5k to mi się wydaje dużo za dużo, myślałem raczej poniżej 3k.

3k to bez doświadczenia.
Tylko co nazywasz doświadczeniem? Projekciki na studiach czy zajmowanie się tym na etacie w firmie? Masz jakieś portfolio? A certyfikaty?

3k w miastach typu Kraków czy Wrocław to, jak pisze @somekind, można spokojnie dostać bez doświadczenia. Kilka miesięcy doświadczenia to już 3,5-4k (mówię o doświadczeniu jako pracy zawodowej w jakiejś poważnej firmie). Napisz coś więcej o tym gdzie cię ta praca interesuje i jakie dokładnie masz doświadczenie.

Ta mam 4 certyfikaty i robię w holiłudzie.

Nie mam certyfikatów, doświadczenie w firmie na stanowisku programisty. Z tego co widzę po znajomych którzy pracują na pół lub na 3/4 etatu (studenci dzienni) to przeliczając na cały etat mają stawki 1600-2300 dlatego się dziwie jak mówicie że po 5k

Ustalmy czy mówimy o stawce brutto czy netto.

Powiedzmy, że posługujemy się netto (tyle ile dostajecie "na rękę!")

W takim razie, w dużych miastach 3-4k to jest .. sorry za wyrażenie - dymanie bez mydła.

@Deti - to ile Twoim zdaniem w Warszawie powinna na rękę dostać osoba:

1. Świeżo po studiach, znająca może język, biblioteki, coś tam z baz danych, IDE, ale nie mająca pojęcia o tworzeniu działającego softu w realnych firmach.
2. Z dwuletnim doświadczeniem na stanowisku.

Trochę się dziwię bo myślałem że stawki poniżej 3k to normalka dla takiego młodego gościa. A myślę tak dlatego że już na kilku rozmowach byłem i podając stawki o których mówię nie dostałem roboty więc myślę że gdybym krzyknął 4-5k to tym bardziej bym nie dostał. Jasne że pewnie tutaj wiedza i umiejętności przesądziły. Nie jestem jakimś wymiataczem ale na pewno powyżej średniej więc nie wiem co robię źle ;/

Kumpel pracuje w Alcatel-Lucent, zajmuje się stacjami bazowymi. Mówił że różnice płacy ludzi w jednym pokoju, siedzących "biurko w biurko", wykonujących tą samą pracę może wynosić 3k-5.5k. Także ile sobie wynegocjujesz tyle masz.

trza walić 20 k.. 9 razy dostaniesz po mordzie ale za 10 się uda;D

Nie wiem czemu w tym temacie najmniej dyskusji jest na temat najważniejszej rzeczy: umiejętności. To one najbardziej się liczą, a nie to, na którym jesteś roku studiów, czy w ogóle masz studia/byłeś na studiach, czy ile masz doświadczenia. Te parę rzeczy to tylko estymatory umiejętności. Sam fakt posiadania "roku doświadczenia" nic nie daje, podobnie jak sam fakt posiadania (iluś lat, lub w ogóle) studiów. Jeśli to masz, to pracodawca w większości przypadków może poczynić pewne założenia.

Nie muszą one być prawdziwe i działa to w obie strony. Bill Gates studiów nie ukończył, a za młody był przecież całkiem niezłym programistą, prawda? Kogo byś wolał zatrudnić w firmie: przeciętnego absolwenta informy na niby-dobrej polskiej uczelni, czy jakiegoś polskiego odpowiednika Billa?

W drugą stronę też to działa: możesz mieć rok doświadczenia profesjonalnego, możesz studiować na dobre uczelni i być totalną dupą wołową jeśli chodzi o programowanie.

Co wiesz na temat inżynierii oprogramowania? Jaką wagę przywiązujesz do jakości kodu? Jakie znasz techniki poprawienia jakości? W jaki sposób pracujesz nad swoimi umiejętnościami poza uczelnią -- bo na uczelni zbyt wiele praktyki to nie ma? Znasz wagę automatycznych testów i umiesz je pisać? Znasz problemy -- i ich rozwiązania -- dotyczące integracji? Refaktoryzujesz rutynowo swój kod?

Ktoś, kto na powyższe pytania odpowiada "tak" może szukać znacznie lepiej płatnej pracy niż ktoś, kto nie ma o tych sprawach bladego pojęcia. Nawet jeśli obaj mają rok doświadczenia zawodowego i studiują w jednej grupie.

U nas na studiach były takie różnice. Ja najlepiej orientuję się w branży webowej. Jedni z nas zarabiali na czwartym roku w okolicach 1600-1900 netto, inni 3000 netto. W tej samej branży. Ci drudzy nie byli geniuszami, tylko dbali o swe umiejętności. Niektórzy z nich wykonywali niby mało prestiżową robotę -- nie C#, .NET i enterprise'owe aplikacje, tylko "głupiutki" HTML i CSS z małą domieszką JS-u -- ale wykonywali ją dobrze.
(drobna uwaga: pracowało się wtedy często na umowę-zlecenia czy o dzieło, a dodatkowo było się studentem, więc płace netto lepiej wyglądały niż brutto ;-))

Istnieją pewne korelacje. Dobre firmy dobrze płacą. Dobre firmy wybierają pracowników głównie ze względu na umiejętności, a nie nic nie znaczące papierki. Dyplom uczelni naprawdę niewiele oznacza jeśli chodzi o programowanie, bo mnóstwo osób przechodzi dobre uczelnie po programistycznej linii najmniejszego oporu. Niektóre certyfikaty są już cenne, bo testują konkretne umiejętności programistyczne znacznie dokładniej niż głupiutkie uczelniane projekciki i egzaminy, które wystarczy zaliczyć na 3 (a zaliczenie na 5 też o niczym jeszcze nie świadczy). Dobre firmy to wiedzą i testują swoich pracowników.

Im jesteś lepszy, tym większa szansa, że dobra firma Cię zatrudni. Oni potrafią szanować nawet żółtodziobów. Czasem lepiej jest zatrudnić studenta, który się przykłada i który już na daną chwilę dużo umie (np. naprawdę się stara polepszyć jakość swojego kodu) niż kolesia, co ma parę lat doświadczenia i na daną chwilę może i jest lepszy, ogólnie rzecz biorąc, ale niemalże stoi w miejscu i prawie się nie polepsza.

Nie wiem jak to jest w przypadku programistów C#/.NET. Mi 5-6k brutto w dużym mieście, ale poza Wawą, dla przeciętnego studenta z rocznym doświadczeniem wydaje się dużą kwotą, choć przyzwyczajenia mam z branży webowej, która jest generalnie jedną ze słabiej płatnych. Z drugiej strony: i u nas można zarabiać wyraźnie więcej niż te 6k brutto bez ogromnego doświadczenia, ale to już trzeba być z danej dziedziny naprawdę dobrym.

W jakim mieście szukasz tej pracy? To też ma znaczenie. Wawa jest zwykle najlepsza. Wrocław też jest bardzo dobry. W Poznaniu przeważnie już nieco gorzej, choć też źle nie jest.

Generalnie myślę, że trzeba najpierw wybadać zarobki w branży i uzyskać szerokie widełki. Następnie trzeba umieścić się gdzieś tam na osi umiejętności, oceniając się obiektywnie. Bo dobre firmy i tak Cię sprawdzą. Tradycyjnie można podać oczekiwania finansowe nieco wyższe niż takie, które naprawdę (i rozsądnie) chciałoby się mieć. Wtedy jest z czego zejść przy negocjacjach. Gdy mówisz to słownie, możesz użyć zwrotu "mniej więcej", "około" czy "w granicach" (nawet jeśli to niezbyt poprawne, bo podajesz tylko jedną liczbę) co by było wiadomo, że kwota nie jest wyryta w kamieniu. Niestety, pracodawcy się bunkrują i nie chcą podawać widełek, więc jeśli potem człowiek ma podać jedną kwotę, to powinien użyć raczej górnej granicy swoich oczekiwań niż absolutnego minimum.

bswierczynski napisał(a)

Nie wiem czemu w tym temacie najmniej dyskusji jest na temat najważniejszej rzeczy: umiejętności.

Jeśli ktoś nie ma doświadczenia w branży, to nie ma umiejętności.
Jeśli ktoś od roku pisze w języku na uczelni, to zna składnię i biblioteki, coś potrafi napisać, ale od projektów studenckich do programowania jeszcze daleko.
Jeśli ktoś rok pracował w firmie, to już takie rzeczy jak praca zespołowa, korzystanie z kontroli wersji, bugtrackerów, pisanie testów, współpraca z analitykami, biznesem, testerami itd. powinny być mu znane, jest w tym już trochę obyty.

[quote]Nie wiem czemu w tym temacie najmniej dyskusji jest na temat najważniejszej rzeczy: umiejętności.[/quote]
Bo często firmy wychodzą z założenia, że nie są w stanie podczas godzinnej rozmowy przetestować obiektywanie Twoich umiejętności i opierają się tylko na ilości doświadczenia. Po okresie próbnym ewentualnie dostaniesz podwyżke jeżeli się wyróżniasz. W jednej norweskiej firmie meneger powiedział mi wprost, że nie mam co negocjować bo ma przez centralę narzuconą tabelkę z płacami x lat doświadczenia - x zł brutto i nie może tego zmienić.

.net i c# to banal, jak ktos kto cie zatrudnia sie na tym zna to nie dostaniesz wiecej niz 3k brutto. W tym pisze prawie kazdy programista, wiec podaz jest wysoka i co za tym idzie - ceny male. No i inni beda to robic za minimalna stawke, bo co to za problem uruchomic 10 gigabajtowi ide i klepac banalny kod. Jak trafisz na jakiegos losia, to moze dostaniesz te 5k i wiecej, ale ja nie wroze takiej firmie ze sie utrzyma. No chyba ze jestes geniuszem i bedziesz tworzyl projekty naprawde powazne, typu medycyna, samoloty, wojsko, przemysl, elektronika. Ale watpie bo takie rzeczy to raczej w bardziej powaznych technologiach niz jakis .net.

@up:
:O

.net i c# to banal, jak ktos kto cie zatrudnia sie na tym zna to nie dostaniesz wiecej niz 3k brutto. [...] Ale watpie bo takie rzeczy to raczej w bardziej powaznych technologiach niz jakis .net.

Duch cybera ciągle straszy ;P

somekind napisał(a)

Jeśli ktoś nie ma doświadczenia w branży, to nie ma umiejętności.

Na pewno można mieć tylko minimalne doświadczenie w pracy zarobkowej i mieć całkiem niezłe umiejętności. Na tyle niezłe, że różnica pomiędzy tobą a kolegą z roku na studiach może być ogromna, nawet jeśli obaj niby piszecie w tym samym języku.

somekind napisał(a)

Jeśli ktoś od roku pisze w języku na uczelni, to zna składnię i biblioteki, coś potrafi napisać, ale od projektów studenckich do programowania jeszcze daleko.

Różnice i tutaj są bardzo duże. Takie C# ma rozbudowaną, skomplikowaną składnię. Który student zna ją naprawdę dobrze, nie tylko na podstawowym poziomie?

W "projektach studenckich" też są różnice. Większość studentów pisze szkolne projekty na odpieprz, byleby mniej-więcej spełnić wymagania. Ich kod jest fatalny, kuloodporność projektu nie istnieje, bo prawie nie jest oceniana i w ogóle do niczego się te ich (nasze :P) programiki nie nadają. Niektórzy jednak chcą się uczyć i na zajęcia piszą całkiem praktyczne rzeczy. Nie na 500 zagmatwanych linijek, tylko nieraz na 5000.

To zależy głównie od chęci, nie tyle od "zdolności".

Parę moich własnych przykładów jeszcze z zajęć.

Programowanie niskopoziomowe. Jedno z zadań to napisanie konsolowego edytora tekstów w C. Ja sobie chciałem poćwiczyć operowanie strukturami danych/wskaźnikami i odgradzanie się od nich warstwą abstrakcji, więc tekst przechowywałem sobie w podwójnie wiązanej liście tablic z dziurami. Chciałem poćwiczyć parsowanie i operacje na ciągach, więc dorzuciłem kolorowanie składni języka C.

Z C# mieliśmy napisać jakiś kalkulator. Na wyższą ocenę było parsowanie wyrażeń arytmetycznych. O ile pamiętam, ludzie ułatwiali to sobie stosując ONP, ew. przeklejając z netu spore, pojedyncze funkcje parsujące i liczące. Mój kalkulator liczył normalnie, infiksowo. Podświetlał pary nawiasów czy błędy składni. Interpreter napisałem sam, obiektowo, dzieląc go na lekser i parser.

Olewanie projektów jest zrozumiałe, bo jest ich sporo. Ale jeśli ktoś chce być programistą, a nie wybierze sobie choćby jednego czy kilku projektów, do których się przyłoży i z których naprawdę COŚ wyniesie, a równolegle nie będzie pracował, to na studiach traci czas.

Z drugiej strony owszem, uczelniane jednoosobowe programiki na 5k linii kodu plus dosłownie kilka projektów zespołowych to nie jest jeszcze PRO-programowanie, ale wspomóż to choćby czytaniem SourceForge'a i tekstów/książek o IO, zarządzaniu projektami, istocie pracy programisty (np. o wadze komunikacji, o realiach) i...

somekind napisał(a)

Jeśli ktoś rok pracował w firmie, to już takie rzeczy jak praca zespołowa, korzystanie z kontroli wersji, bugtrackerów, pisanie testów, współpraca z analitykami, biznesem, testerami itd. powinny być mu znane, jest w tym już trochę obyty.

...i wcale nie musi być tak, że lepiej zatrudnić kolesia, który po prostu "rok pracował" i jest obyty niż przykładającego się, postępującego zgodnie z poprzednim punktem "żółtodzioba".

Przyznaję: rok w dobrej firmie to naprawdę bardzo, bardzo fajna rzecz.

Ale rok w kiepskiej, a do takich często się trafia bez umiejetności i doświadczenia... Wg mnie może być wręcz szkodliwy, czy też może wyjść na zero. Wiele firm wciąż nie pisze automatycznych testów. Wielu programistów nie przywiązuje wagi do komunikacji. Kod w kiepskich firmach bywa tak fatalny, tak okropny, że można się tylko zniechęcić i nauczyć złych nawyków. Przyswoić złe podejście. Uznać, że pewne rzeczy są normalne, gdy takie nie są.

Co do SVN-a, to sposobności do nauki jest sporo i bez pracy. Nawet swoje własne projekty warto wersjonować (zalecają to w "Pragmatycznym programiście"), a na uczelni czasami jest przymus. Testy jednostkowe też są w programie. Można je zacząć pisać samodzielnie. Pracowałeś w firmie ze słabszymi programistami? Widziałeś pewnie nie raz takie testy, że wystarczyłoby przeczytać książeczkę o JUnicie by napisać 5x lepsze. Jeśli Ty od razu po studiach stosowałeś bezproblemowo mockupy itp., to być może nie zdajesz sobie sprawy, na ile wyżej przeciętnej byłeś ;).

Bugtrackery stosuje się prywatnie rzadziej, choć jakąś kontrolę bugów można wprowadzić. Co do współpracy z analitykami i biznesem... Wiesz jak to potrafi wyglądać w takich firmach jak np. Comarch? ;) A to one zatrudniają hurtowo studentów i dają im ten pierwszy rok doświadczenia.

0x200x20 napisał(a)

Bo często firmy wychodzą z założenia, że nie są w stanie podczas godzinnej rozmowy przetestować obiektywanie Twoich umiejętności i opierają się tylko na ilości doświadczenia.

Coś w tym jest. Choć wg mnie znacznie lepiej poprosić kogoś o pokazanie swojego kodu niż o podanie liczby lat.

Poza tym, w dobrych firmach potrafią cię dość hardcorowo testować. Nie "godzinę".

W jednej dobrej firmie maglowali mnie praktycznie cały dzień -- oprócz rozmów, na miejscu robiłem projekcik testowy (nie było przymusu kończenia go w 100%, ale ja się uwziąłęm). W innej aplikacja przebiegła wieloetapowo. CV. Techniczna rozmowa telefoniczna z programistą (15-30 min). Projekt do zrobienia w domu (jak się chciało napisać i udokumentować porządnie, to zdecydowanie więcej niż dzień roboczy). Rozmowa techniczna w siedzibie firmy (3-4h). I dopiero niezależnie od tego standardowa rozmowa kwalifikacyjna z pytaniami typu "jaka jest Pana największa wada?" (no dobra, tego pytania akurat nie było ;). Na każdym etapie można odpaść, coby nie marnować czasu. Ale jak ktoś to przejdzie, to można chyba ocenić jego umiejętności istotnie lepiej niż po godzinnej rozmowie lub cyferce oznaczającej liczbę lat doświadczenia, prawda?

0x200x20 napisał(a)

W jednej norweskiej firmie meneger powiedział mi wprost, że nie mam co negocjować bo ma przez centralę narzuconą tabelkę z płacami x lat doświadczenia - x zł brutto i nie może tego zmienić.

Takie tabelki są faktycznie spotykane. Ale powinno się tam też znaleźć miejsce na ocenę umiejętności. Choćby na testach. Zupełne nie uwzględnianie tego może być wg mnie strzałem w stopę. Wiesz chyba, jak duże różnice produktywności mogą być pomiędzy programistami o tym samym stażu. Jeśli nie wiesz, to już mówię.

10:1.

Tak, mając tyle samo "lat doświadczenia", jeden programista może być dziesięciokrotnie bardziej produktywny od drugiego! Proponowanie im takiej samej wydaje się być... nieopłacalne.

somekind napisał(a)

Jeśli ktoś nie ma doświadczenia w branży, to nie ma umiejętności.

Przykład z życia. Bardzo dobry znajomy ode mnie z roku przepracował tylko miesiąc w pewnej firemce kodząc w C#. Potem długo szukał pracy, aż natknął się na firme, gdzie kodzi się w C. Na początek dostał 2,5 klocka - na okres próbny. Potem podnieśli mu do 3 z hakiem, a po pół roku pracy w firmie dostał nieco ponad 6k. Kwoty netto. Miasto Kraków.

@CyberKid:
Wow, a gościu jest naprawdę dobrym programistą niskopoziomowym? Czy te prace dostawał jeszcze na studiach, czy już po? To niezłe potwierdzenie tego, o czym tu piszę. 6k netto przy mniej niż roku doświadczenia, w Krakowie -- to dobre wynagrodzenie.

Ale jakby to policzyć, to nie musi być dziwne. Wszyscy znamy chyba maksymę: "dowolnego programistę da się zastąpić skończoną liczbą studentów" (tm). Tyle że wydaje mi się całkiem możliwe, by ten koleś, co dostaje 6k netto, był bardziej produktywny -- pisał w miesiącu więcej rzeczy, które naprawdę działają, o różnicy w jakości kodu nie wspominając -- niż dwóch czy trzech totalnych przeciętniaków robiących za 2.5k. Wtedy, z punktu widzenia firmy, zatrudnienie "drogiego" programisty po prostu się opłaca.

Swoją drogą, ciekawe przejście. Z C# na C :). Orientujesz się co on tam pisze w tym C?

@bswierczynski - jeżeli chodzi o tamtą norweską firmę to na rekrutację nawet dostałem kod do zrefaktoryzowania w domu i ogólnie rekrutacja miała 3 etapy ;) Ale dobrze wiedzieć, że jest więcej firm, które przykładają większą wagę do umiejętności a nie doświadczenia.

Swoją drogą, ciekawe przejście. Z C# na C

IMHO programista z backgroundem wysokopoziomowym będzie pisał lepszy kod w niskopoziomowym języku niż ludzie, którzy znają tylko C i assemblera. W drugą stronę to nie działa. Byłem w projekcie, który został napisany w Javie, przez ludzi, którzy się przesiadli z C. Kod był totalnie nieobiektowy (co w Javie jest sporym wyczynem) i napisany w fatalnym stylu.

@msm - zgadzam się z Tobą, szkoda, że większość pracodawców tego nie widzi i szuka specjalistów w jednej technologi/języku. Nie mówiąc już o ludziach z HR filtrujących napływające CV po słowach kluczowych.

bswierczynski napisał(a)

Programowanie niskopoziomowe. Jedno z zadań to napisanie konsolowego edytora tekstów w C. Ja sobie chciałem poćwiczyć operowanie strukturami danych/wskaźnikami i odgradzanie się od nich warstwą abstrakcji, więc tekst przechowywałem sobie w podwójnie wiązanej liście tablic z dziurami. Chciałem poćwiczyć parsowanie i operacje na ciągach, więc dorzuciłem kolorowanie składni języka C.

Z C# mieliśmy napisać jakiś kalkulator. Na wyższą ocenę było parsowanie wyrażeń arytmetycznych. O ile pamiętam, ludzie ułatwiali to sobie stosując ONP, ew. przeklejając z netu spore, pojedyncze funkcje parsujące i liczące. Mój kalkulator liczył normalnie, infiksowo. Podświetlał pary nawiasów czy błędy składni. Interpreter napisałem sam, obiektowo, dzieląc go na lekser i parser.

No fajnie, poćwiczyłeś programowanie takie i siakie, taki czy inny język, algorytmikę... Ale to nadal jest nikomu niepotrzebny kod, który jest wynalezieniem koła na nowo po raz tysięczny. Choćby nie wiem jak był piękny, to zbyt wiele to nie zmienia. :)
To nie są rzeczywiste problemy. Nie ma klienta, który mówi, że ten przycisk ma być 20 pikseli w lewo i w zasadzie to fajnie, jakby się pojawiał po mrugnięciu okiem, a w tego comboboxa trzeba wbudować treeview. No i oczywiście w oddzielnych zakładkach przeglądarki chce się móc logować na różne konta aplikacji, a poza tym jak wyłączą prąd na dzielnicy, to wyniki pracy mają się same zapisać. A poza tym w firmie część faktur jest generowana automatycznie a część ręcznie, ale numeracja musi być spójna, bo takie jest prawo. I tak dalej...
To ważna umiejętność umieć dogadać się z inną osobą, zrozumieć o co chodzi w jej często nietechnicznym języku, umieć wyperswadować rzeczy niemożliwe/nieopłacalne do zrobienia, zaproponować lepsze rozwiązanie danego zadania, znaleźć braki w rozumowaniu, umieć dopytać o szczegóły... Ważne jest też umiejętność takiego zorganizowania sobie pracy, aby najpierw wykonywać rzeczy bardziej potrzebne czy łatwiejsze w implementacji, tak aby już można było oddać je do testowania czy używania.
To wszystko siłą rzeczy jest nie do przećwiczenia na studiach, a też składa się na doświadczenie oraz produktywność.

Co do SVN-a, to sposobności do nauki jest sporo i bez pracy. Nawet swoje własne projekty warto wersjonować (zalecają to w "Pragmatycznym programiście"), a na uczelni czasami jest przymus. Testy jednostkowe też są w programie. Można je zacząć pisać samodzielnie. Pracowałeś w firmie ze słabszymi programistami? Widziałeś pewnie nie raz takie testy, że wystarczyłoby przeczytać książeczkę o JUnicie by napisać 5x lepsze. Jeśli Ty od razu po studiach stosowałeś bezproblemowo mockupy itp., to być może nie zdajesz sobie sprawy, na ile wyżej przeciętnej byłeś ;).

Jak już tak osobiście pytasz, to nie, nie stosowałem ich wcale, testy jednostkowe pisałem naprawdę podstawowe. Kontroli wersji w samodzielnych czy uczelnianych projektach też nie stosowałem, podobnie jak bugtrackerów, profilerów, itd. Może jestem pod tym względem złym przykładem, ale bezpośrednio po studiach (inżynierskich, magistra robię teraz) za słabego programistę się nie uważałem. Kumałem język, biblioteki, wiedziałem jak zrobić sporo rzeczy, co i jak trzeba obejść, bo jest niedopracowane, znałem trochę kruczków dotyczących wydajności. Nie miałem większych problemów z projektowaniem BD czy analizą obiektową. Nie byłem (i nie jestem) geniuszem, ale słaby też nie byłem wtedy. Tyle tylko, że byłem ograniczony do spraw związanych czysto z implementacją, bez tych wszystkich okołoprogramistycznych elementów pracy, których mogłem nauczyć się dopiero w pracy. Dlatego napisałem, że bez doświadczenia trudno o umiejętności.
Napisać pętlę for każdy potrafi, ale napisać ją tak, aby była bezpieczna, wydajna i ktoś był dzięki niej szczęśliwy, mimo tego, że chciał do...while, to zupełnie inna sprawa. :)

0x200x20 napisał(a)

Nie mówiąc już o ludziach z HR filtrujących napływające CV po słowach kluczowych.

Jakoś tak wątpię, żeby ludzie w HR filtrowali po słowach kluczowych.
Ja generalnie "siedzę" w C#, .NET i MSSQL, a dostawałem już oferty pracy jako programista Java albo Oracle. Ok, mogę się nauczyć tego czy coś, ale to były oferty dla ludzi ze stażem powyżej trzech lat. Ostatnio byłem na rozmowie kwalifikacyjnej, na której pani z HR pomyliła jQuery z Ext JS, który znam tylko z nazwy.
A już szczytem była pierwsza moja rozmowa kwalifikacyjna w życiu. Okazało się, że oni nie poszukują programisty C# jak w ogłoszeniu, tylko admina MSSQL. :D

Ten system kontroli wersji to chyba "ostateczny" argument wśród przeciwników akademickiego nauczania :D Tyle że opanowanie CVSa w stopniu pozwalającym na swobodną pracę to w porywach kilka dni. Opanowanie algorytmiki trwa znacznie dłużej.

somekind napisał(a)

No fajnie, poćwiczyłeś programowanie takie i siakie, taki czy inny język, algorytmikę... Ale to nadal jest nikomu niepotrzebny kod, który jest wynalezieniem koła na nowo po raz tysięczny. Choćby nie wiem jak był piękny, to zbyt wiele to nie zmienia. :)

A co z podszkoleniem się w zakresie czytelności i poprawności kodu? Wg mnie to są najważniejsze umiejętności przeciętnego programisty. Z tego można się całkiem nieźle szkolić samodzielnie. Fakt, uczestnictwo w dużych projektach zapewnia tutaj inne możliwości, ale jeśli miałbym wybrać: pracować rok w jakiejś firmie czy przez rok kupować sobie odpowiednie książki (ew. dłubiąc coś samodzielnie), to... wybrałbym pewnie to drugie. Zdaje się, że byłoby skuteczniejsze. Pewne rzeczy trzeba zrozumieć samodzielnie i zmuszanie kogoś do nich, np. poprzez standardy kodowania, samo w sobie kończy się przeważnie źle. Jeśli np. "każda procedura musi mieć co najmniej [X] testów" (gdzie [X] to jakiś wzór), niektórzy ludzie robią z tego perełki typu:

public void testMyProcedureDoingFooBar() {
  assertTrue(true);
}

Listingi na thedailywtf.com nie biorą się niestety znikąd.

Jak ktoś nauczy się tego, by dbać o swój kod, to szybko wdroży się w dobre standardy kodowania i będzie je próbował zrozumieć i wykorzystać.

somekind napisał(a)

To ważna umiejętność umieć dogadać się z inną osobą, zrozumieć o co chodzi w jej często nietechnicznym języku, umieć wyperswadować rzeczy niemożliwe/nieopłacalne do zrobienia, zaproponować lepsze rozwiązanie danego zadania, znaleźć braki w rozumowaniu, umieć dopytać o szczegóły...

To prawda, choć w większości firm programiści nie mają chyba jednak bezpośredniego kontaktu z klientami. Wtedy za to muszą rozmawiać z managerami itp.

Tylko że i do tego istnieją świetne źródła do samodzielnej nauki. Książki, blogi i witryny profesjonalistów. Zdarzyło mi się rozpoczynać współpracę z firmą i widzieć błędy, jakie popełniają w zakresie traktowania klientów nawet jeśli ja dla nich byłem żółtodziobem. Byli po prostu jedną z tysięcy firm, które robią pewne rzeczy źle (np. nie szanują się lub pozwalają klientom na micromanagement). Ja czytałem o innym podejściu i okazało się, że inne firmy takie podejście stosowały i faktycznie wychodziły na tym o wiele lepiej.

Można więc podłapać nie tylko złe, ale i dobre nawyki.

Przyznam natomiast, że wiedza teoretyczna to jedno, a rozmowy oko w oko z klientem czy managerem to drugie. Do tego drugiego trzeba się przyzwyczaić, trzeba się trochę doszlifować.

Ale wiesz co? Jakbyś miał zdobyte na sucho pojęcie, jak to ma wyglądać, to potem dość szybko wprowadzisz to w życie. Z drugiej strony, gdy masz rok doświadczenia w jednej firmie, a potem przechodzisz do drugiej i jesteś świeżakiem, to -- mimo doświadczenia -- też potrzebujesz troszkę czasu, żeby się wdrożyć w komunikację międzyludzką w tej nowej firmie. Raczej nikt Cię nie pośle na nie wiadomo jakie pertraktacje z ważnym klientem.

Ludzie mogą pracować w firmie nie rok, tylko pięć lat i nadal nie zdawać sobie sprawy z wagi tego, o czym piszesz: komunikacji.

somekind napisał(a)

nie stosowałem ich wcale, testy jednostkowe pisałem naprawdę podstawowe. Kontroli wersji w samodzielnych czy uczelnianych projektach też nie stosowałem, podobnie jak bugtrackerów, profilerów, itd. Może jestem pod tym względem złym przykładem

Jesteś absolutnie normalnym przykładem, niestety ;). Szkoda, że nawet na niby dobrych uczelniach niespecjalnie tego uczą.

Mogę Cię tylko prosić o uwierzenie na słowo, że niektórzy się takimi rzeczami interesowali i jakoś tam nieśmiało zaczynali stosować jeszcze na studiach.

somekind napisał(a)

Napisać pętlę for każdy potrafi, ale napisać ją tak, aby była bezpieczna, wydajna i ktoś był dzięki niej szczęśliwy, mimo tego, że chciał do...while, to zupełnie inna sprawa.

I jeszcze jedna sprawa: wypadałoby powiedzieć klientowi, żeby nie wtykał nosa w nasze pętle. Klient jest specjalistą ze swojej biznesowej dziedziny, my -- programiści -- ze swojej. Niech Klient zdefiniuje wymagania i ograniczenia, choćby i wydajnościowe, a już nasza głowa w wyborze odpowiedniego narzędzia.

Podobnie, trzeba "dorosnąć" do... ignorowania wydajności oprócz tych momentów, w których naprawdę trzeba się ją przejmować. Mnóstwo niedoświadczonych programistów optymalizuje jakieś totalnie nieistotne głupoty, co skutkuje wzrostem wydajności o 0.5% i pogorszeniem czytelności kodu o 500%. W rzeczywistości, programiści bardzo rzadko potrafią wydedukować, które miejsca (większego) programu mają największy wpływ na wydajność. Wąskie gardła wychodzą dopiero przy profilowaniu.

Wierz mi lub nie, ale takich rzeczy też można się dowiedzieć, czytając po prostu książki ;). Niby to tylko teoria, ale potem, gdy przyjdzie czas na praktykę i zwiększenie wydajności prawdziwego projektu, człowiek poszuka w necie profilera, odpali go, znajdzie wąskie gardła i zoptymalizuje te kilka krytycznych procent programu.

@somekind:
@kogucik:
Te wałki z rozmów kwalifikacyjnych to jakieś kpiny. Techniczne kwalifikacje programistów powinni sprawdzać techniczni ludzie, np. programiści. Nie HR-owcy i nawet nie managerowie. Oni robią dobrze swoje rzeczy, ale nie są zwykle najlepszymi ludźmi do sprawdzenia czyichś umiejętności technicznych.

somekind napisał(a)

Tylko, że w przeciętnej pracy kontroli wersji używa się codziennie, "algorytmów" prawie wcale.

To prawda. Złożonych algorytmów a często się nie używa w większości branż. Ale wiesz czego się używa non stop i co jest trudne do opanowania?

Zarządzanie złożonością. Po prostu: pisanie kodu czytelnego, zrozumiałego dla człowieka, z małą liczbą powiązań i dużą kohezją, spójnością. Doskonalenie tej sztuki to rzecz znacznie bardziej pracochłonna niż nauka jakiegoś tam języka. Umiejętność pisania kodu wysokiej jakości jest całkiem cross-platformowa ;).

Tylko, że w przeciętnej pracy kontroli wersji używa się codziennie, "algorytmów" prawie wcale.

Prawie wcale a wcale to duża różnica ;P Gdy w końcu przychodzi ten moment, że trzeba opracować algorytm dla jakiegoś problemu, ewentualnie zoptymalizować istniejący to wtedy wychodzi kto jest głupim klepaczem kodu a kto programistą.
Nawiasem mówiąc w obecnej pracy jestem w projekcie, który przypomina całkiem projekt z uczelni. Piszę go sam, 90% czasu implementuję oraz modyifukuje algorytmy opisywane przez doktórw w tzw. white papers. A najlepsze jest to że sporo mi płacą właśnie za znajomość algorytmyki. Na rekrutacji było zadanie wymgające stworzenia oraz zaimplementowania algorytmu przeszukiwania metaheurystycznego dla dosyć nietypowego problemu.

Jaką stawkę proponować na rozmowie żeby nie zrazić ani nie wkopać się w głodową kwotę?

1/3 ceny samochodu ;-)

Azarien napisał(a)

Jaką stawkę proponować na rozmowie żeby nie zrazić ani nie wkopać się w głodową kwotę?

1/3 ceny samochodu ;-)

Niestety kapitał zakładowy by nie pokrył Veyrona.
http://www.thesupercars.org/top-cars/most-expensive-cars-in-the-world-top-10-list-2007-2008/