Trochę o wynagradzaniu w IT 2

Home

W tym poście będę kontynuował tematykę wynagradzaniu programistów i napiszę o tzw. bonusach na wejście oraz pakietach akcji (znanych też pod nazwą RSU - Restricted Stock Unit). W Polsce są to rzeczy, powiedziałbym, egzotyczne. O pakietach akcji to pewnie jeszcze sporo osób słyszało, ale o bonusie na wejście to pewnie mało kto.

Tak jak napisałem w poprzednim poście, obie te rzeczy są dodatkiem do systemu poziomów. Sprawiają, że jest bardziej elastyczny i dają pole do negocjacji, czego w systemie poziomów nie ma. Bonus na wejście, po pierwsze, pozwala przyciągnąć pracownika, jeśli goła pensja wynikająca z poziomu jest za niska, a jednak chcemy go zatrudnić. Bonus na wejście wypłacany jest w całości z pierwszą pensją albo proporcjonalne co miesiąc przez 1 lub 2 lata. Czasami jest tak, że w pierwszy roku bonus wynosi X, a w drugim mniej. Bonus potrafi stanowić bardzo ważną część pensji, nawet 30%!

Ktoś zapyta, a po co taki bonus skoro od razu można dać więcej? No właśnie nie można, bo system poziomów jest po to, aby się go trzymać. Jeśli robimy wyjątki to nie ma on sensu. Sensu nie ma też sztuczne zawyżanie poziomu, to byłoby jeszcze gorsze. W tym momencie dochodzimy do drugiej funkcji bonusu. Tak jak napisałem jest on czasowy i stanowi ważną część pensji. Po upływie 2 lat potencjalnie możemy więc ''stracić'' kawał grosza, o ile się nie wykażemy i nie awansujemy na kolejny poziom. Czyli ten bonus w założeniu działa dodatkowo jako motywator.

Teraz trochę o akcje. Ten element wynagrodzenia ma za zadanie związać pracownika z firmą. Chodzi o to, że na wejściu dostajesz na przykład pakiet 50 akcji, ale nie możesz ich od razu sprzedać. Dopiero po upływie 1 roku uzyskujesz dostęp na przykład do 10% z nich, po upływie 2 roku kolejne 15%, a w każdym kolejnym roku kolejne 25%. Systemy różnią się w zależności od firmy. Co więcej, co roku możemy dostać kolejny pakiet akcji. Załóżmy, że na wejściu dostaliśmy 50 akcji, a potem co roku po 50. Pracujemy już 5 i do tej pory nie sprzedawaliśmy niczego, a więc na koniec 5 roku mamy przypisanych 250 akcji i według moich obliczeń możemy sprzedać 170 z nich. A, jeśli pracujemy dla takiego Google, będzie to stanowić na dzisiaj około 90 tysięcy $, a akcje warte kolejne 42 tysiące $ będą na nas czekać i wciąż możemy dostawać kolejne porcje.

Z tego co wiem, zdarza się tak, że niektórzy pracownicy dostają co roku w akcjach nawet więcej niż ich pensja. Zauważcie, że celowo w pierwszych latach dostaje się mało akcji, aby ich nie marnować na pracowników, którzy się nie sprawdzą lub szybko odejdą. Równocześnie odchodząc z pracy po kilku latach mamy świadomość, że tyle, a tyle akcji na nas jeszcze czeka i jak tu zmienić pracę w takiej sytuacji ;)

Co o tym myślicie? Ja mam mieszane uczucia, szczególnie jeśli chodzi o bonus na wejście. Z drugiej strony to pewnie dlatego, że jestem przyzwyczajony do konkretnej kwoty w umowie, którą staram się maksymalizować. Przy systemie z bonusem na wejście i dodatkowymi akcjami bazowa pensja może być niższa, niż gdyby tych bonusów nie było i dochodzi też element niepewności. Jak zawsze jest coś za coś.

Trochę o wynagradzaniu w IT

Home

W Polsce system wynagrodzeń w IT przeważnie wygląda tak. Przychodzi się do firmy i na wejściu dostaje się tyle, ile wynegocjowało się na początku. W niektórych firmach co roku można też liczyć na wyrównanie inflacyjne (z reguły kilka procent), a jeśli się posiedzi w firmie dłużej lub awansuje to jest szansa na większą podwyżkę. Czasami jest też tak, że pensje są zamrożone nawet prze kilka lat. Według mojego i ludzi z jakim rozmawiałem doświadczenia o dużą podwyżkę najłatwiej zmieniając pracę. Dodatkowe benefity to przeważnie opieka medyczna i karta Multisport lub podobna. Bywają też inne, ale, moim zdaniem, jeśli już są, to pełnią rolę wisienki na torcie niż czegoś co mogłoby rzeczywiście kogoś skusić. Oczywiście szczegóły zależą od firmy, ale moim zdaniem ten system jest mocno nieokreślony i bardzo dużo zależy od umiejętności negocjowania i momentu, kiedy przyszło się do firmy.

Mi do gustu przypadł system stosowany w niektórych, bo w cale nie wszystkich, firmach na zachodzie. Zacznę od tego, że opiera się na systemie poziomów, a od zdobytego poziomu bezpośrednio zależy nasza pensja. Nie jest to regułą, ale ja akurat spotkałem się ze skalą zaczynającą się w okolicach 8 oraz kończącą się w okolicach 20 i zawsze się zastanawiam z czego to wynika. Nawet o to pytałem, ale odpowiedzi były, jak dla mnie, mgliste. Na przykład spotkałem się z stwierdzeniem, że z powodów psychologicznych po poziom 1 to brzmi źle.

Ostatnio, całkiem przez przypadek, natknąłem się na kilka artykułów na ten temat napisanych, między innymi, przez Joel'a Spolsky'ego jednego z założycieli portalu stackoverflow.com. W firmie Joel'a algorytm liczenia poziomu jest funkcją 3 zmiennych tj. doświadczenia (liczonego w latach), umiejętności (ocenianych w zakresie 0-6) oraz zakresu obowiązków (również ocenianego w zakresie 0-6). A możliwe kombinacje zostały ujęte w taką tabelkę:



Ważne jest to, że pracowniczy na danym poziomie zarabiają tyle samo względem kwoty bazowej, która aktualizowana jest co jakiś czas. Czyli na przykład na poziomie dziewiątym zarabiasz X, na dziesiątym X+10%, a na jedenastym X+20% itd. Kwota X nie podlega dyskusji. Jeśli chce się zarabiać więcej to najłatwiej osiągnąć to przez zwiększenie swoich umiejętności. Zauważcie, że według powyższej tabelki wraz z kolejnymi latami doświadczenia poziom rośnie powoli w porównaniu do wzrostu umiejętności i zakresu obowiązków.

Istotne jest to, że osiągniecie maksymalnego poziomu nie oznacza, że programista przestaje być programistą i staje się menadżerem. Wprost odwrotnie, to oznacza, że jest wyjebistym programistą i będzie nadal robił to w czym jest najlepszy. Natomiast jak zaczynasz bez żadnego doświadczenia to dostajesz co prawda najniższy poziom, ale po pierwszym roku możesz skoczyć o 5 oczek do przodu, czyli tyle co ma ktoś z 15 latami doświadczenia, ale nie jest tak dobry jak ty.

Jak dla mnie takie postawienie sprawy to super rzecz. Każdy wie, na co może liczyć i mniej więcej przewidzieć, jak będzie wyglądała jego pensja w przyszłości. Można się pewnie czepiać, że ocena umiejętności jest subiektywna, że ktoś może nas nam zaniżyć ocenę... Ja na taki zarzut odpowiem tak: nie ma systemu idealnego i uważam, że ten jest dużo lepszy od tego co opisałem na początki postu. Natomiast jeśli uważasz, że ktoś może Ci celowo zaniżyć ocenę to lepiej bierz nogi za pas i zmień pracę.

Co o tym myślicie? Czy taki system mógłby przyjąć się w Polsce?

Na koniec trochę linków:

• Fog Creek Professional Ladder
• How do You Compensate Programmers?
• Fog Creek Compensation
• Why I Never Let Employees Negotiate a Raise
• Professional Development Ladder
• Transparent Salaries

W kolejnym poście napiszę o systemie bonusów na wejście oraz opcji na akcje, które stanowią ważne uzupełnienie czystego systemu poziomów, a są bardzo mało znane w Polsce.

Jako programista przyzwyczaiłem się do...

Home

Jakiś czas temu rozmawiałem z kolegą z branży i w pewnym momencie powiedział on zdanie, które utkwiło mi w pamięci. Parafrazując stwierdził, że:

"Jako programista przyzwyczaiłem się do tego, że się ze mną rozmawia."

Powiedział to w kontekście pracy w firmie, dla kogoś. Chodziło o to, że nawet jeśli coś mu się nie podobało, ale musiał to zrobić bo ktoś podjął taką decyzję, to nie bolało tak bardzo jeśli ktoś z nim wcześniej o tym porozmawiał. Mam tutaj na myśli zarówno sprawy techniczne co nasuwa się samo, ale również te "miękkie" na przykład związane z organizacją pracy.

Jak się nad tym chwilę zastanowiłem to stwierdziłem, że z pewnymi wyjątkami mam podobne doświadczenie i w sumie takie podejście wydało mi się oczywiste. Pytanie czy tak jest wszędzie? Może po prostu mieliśmy szczęście. Czy macie podobne wrażenia, a może wprost przeciwnie?

Co wyróżnia bardzo dobrego programistę (2)?

Home

Pewnie słyszeliście o strumieniach (ang. stream) w .NET. O tym, że się je otwiera, a po użyciu zamyka. Zresztą w innych technologiach jest podobnie. Sprawa stara jak świat i wydawałoby się, że każdy o tym wie. Ja w każdym razie z definicji tak robię.

Dziwi mnie więc, że po tylu latach istnienia .NET ciągle pojawiają się pytanie z tym związane, jak na przykład to na stackoverflow.com. Dziwi mnie również, że przy okazji tego rodzaju pytań często pojawiają się najróżniejsze koncepcje / pomysły / odpowiedzi i to od użytkowników, którzy wcale nie są początkujący. Tymczasem wystarczy wrócić do podstaw, aby rozwiązać problem.

A może jest tak, że kiedy na co dzień pracujemy z skomplikowanymi algorytmami / trudnymi problemami biznesowymi / strukturami danych (niepotrzebne skreślić) to w pewnym momencie tracimy perspektywę i każdy napotkany problem od razu wydaje się nam skomplikowany.

Kolejny czynnik powodujący tą utratę perspektywy to chyba również mnogość różnych technologii i bibliotek, jakie są u obecnie używane. Ta biblioteka do tego, tamta ułatwia to, ta automatyzuje tamto itd. W ten sposób przyzwyczajamy się do tego, że wiele rzeczy coś robi za nas i my nie wnikamy w szczegóły i równocześnie zapominamy również o podstawach.

Nie mówię, że nie należy używać bibliotek, framework'ów czyli ułatwiać sobie pracy, ale bardzo dobry programista powinien również wiedzieć co, się za tym wszystkim kryje i nie zapominać o podstawach.

Z rozmów o pracę

Home

Nie wiem dlaczego, ale ostatnio wzięło mnie na refleksje. Siedzę, popijam sobie herbatę i tak ni z gruszki ni z pietruszki przypomniała mi się dawna rozmowa o pracę. Rozmawiałem z dwoma menadżerami, ale takimi z wiedzą techniczną, co to nie zmieniają szybko tematu, jak przechodzisz na tematy techniczne.

Rozmawialiśmy dość długo i w głowie utknęła mi jedna rzecz, jaką powiedzieli. Parafrazując, zgodnie stwierdzili, że ciężko znaleźć programistę, który nie byłby code monkey. Przy czym przez code monkey rozumieli trochę coś innego niż ja w tamtym momencie. Ja pod tym terminem rozumiałem osobę słabo radząca sobie z programowaniem, umiejąca napisać coś pod dyktando, ale nie dużo więcej. Dla nich jednak code monkey mógł być nawet bardzo dobry technicznie programista, doskonale radzący sobie z zadaniami, samodzielny... lecz z jednym bardzo istotnym z ich menadżerskiego punktu widzenia "ale". To jest nie umiejący lub słabo radzący sobie z komunikacją, w szczególności z biznesem, ludźmi nietechnicznymi, taki nieumiejący postawić się w roli użytkownika końcowego.

Z pewnością my programiści nie jesteśmy mistrzami komunikacji i Ci, którzy posiadają obok wiedzy technicznej umiejętności miękkie mogą się łatwo wyróżnić. Zastanawiam się jednak czy rzeczywiście większość z nas to geeki, którzy nie widzą nic poza kodem. Co myślicie?

Co wyróżnia bardzo dobrego programistę?

Home

Sądzę, że dla każdego bycie bardzo dobrym programistą oznacz trochę coś innego, na przykład do wyboru: znajomość nowych technologii, minimalizowanie używania myszki na rzecz posługiwania się głównie klawiaturą, samodzielne doszkalanie się, blogowanie, udział w konferencjach, komunikatywność, umiejętność pracy pod presją czasu... Ja jednak chciałbym zwrócić uwagę na inną rzecz.

Czasami jest tak, że dostajemy do naprawienie jakiś "wredny" błąd. Niekoniecznie wymaga on wielu zmian w kodzie, ale jest trudny do odtworzenia. Być może brakuje nam też danych, aby go powtórzyć lub opis jest niedokładny. A może jest tak, że błąd dotyczy nieznanego nam obszaru, kod jest brzydki albo to kolejny błąd dotyczący podobnej rzeczy i zaczyna nas to irytować.

W każdym razie mamy dosyć i, jak tylko znajdziemy przyczynę i wyk-minimy rozwiązanie (być może nietrywialne i wymagające dużo technicznej wiedzy), to szybko robimy commit i zapominamy o sprawie. To jest moim zdaniem ten moment, kiedy można zobaczyć na czym polega bycie bardzo dobrym programistą. Moim zdaniem w takiej sytuacji bardzo dobry programista, nawet mimo zniechęcenia, zada sobie dodatkowe pytania:

• Czy ten błąd nie występuje jeszcze gdzieś indziej, nawet jeśli zgłoszenie tego nie dotyczy?
• Jak jego poprawka wpłynie na resztę systemu? Powiązania pomiędzy różnymi modułami systemu mogą być nieoczywiste i często uzyskanie odpowiedzi na takie pytanie wymaga dużo wysiłku.
• Jaka jest pra-przyczyna błędu? Na przykład NullReferenceException można "naprawić" bardzo łatwo przy pomocy jednego if'ka. Często będzie to dobre rozwiązanie, ale może być też tak, że null nigdy nie powinien się pojawić w danym miejscu i jest on wynikiem zmiany gdzieś indziej.

To mogą być bardzo niewygodne pytania, szczególnie, jeśli się nam nie chce, ręce bolą i jest coś ciekawszego do zrobienia, ale równocześnie bardzo potrzebne, szczególnie, jeśli pracujemy z starszymi systemami czy nawet tymi młodszymi, ale bez testów automatycznych.

Nie wiem jak Wy, ale ja na początku swojej kariery uważałem, że w zawodzie programisty właściwie liczy się tylko strona techniczna, znajomość nowych technologii, bibliotek itd. W obecnej chwili rzeczy te uważam za niezwykle ważne, ale nie najważniejsze i coraz większą wagę przywiązuje do umiejętności i predyspozycji, nazwijmy je około-technicznych i miękkich. A co wy o tym myślicie? Też tak macie, a może to tylko moje "zboczenie"?

Konferencja wewnątrz-firmowa - edycja 2

Home

Rok temu tutaj oraz tutaj opisałem zorganizowaną przez siebie konferencję wewnątrz-firmową. W tym roku odbyła się jej druga edycja. O szczegółach organizacyjnych nie będę pisał, aby się nie powtarzać. Z drobnymi szczegółami wyglądało to podobnie. Tematy prezentacji były przynajmniej tak ciekawe, jak przed rokiem i można było posłuchać następujących wystąpień:

Janusz Prusaczyk - Introduction to PowerShell scripting

Paweł Kupis - C# 5.0 Async Feature (async/await) and Synchronization Context – the old new friends

Marcin Wierzbicki - Praktyczny pomiar i atrybucja efektywności portfela inwestycji finansowych

Kamil Langowski - Wolfram Alpha: Computational Knowledge Engine

Adam Juszkiewicz - Mobile game development in Unity

Albert Skłodowski - Design Patterns in Functional Programming

Daniel Celeda - Kręgosłup programisty

Jaroslaw Trafidlo - Czy możemy czuć się bezpiecznie podłączając komputer do sieci?

Damian Orzechowski - Silniki gier komputerowych

Paweł Kaczan - Claims based itentity

Mikołaj Barwicki - Science of Motivation

Michał Komorowski - Debuggery historyczne, co to takiego?

Konferencja ponownie udała się i nie jest to tylko moja opinia. Znowu można było posłuchać o najróżniejszych rzeczach, typowo technicznych, wymagających więcej i mniej uwagi, luźnych... i właśnie to mi się w tym wszystkim najbardziej podoba. Być może się powtórzę, ale pozwala to dowiedzieć się o rzeczach, którymi na co dzień zupełnie się nie interesujemy i nawet do głowy nam nie przyjdzie, że jednak warto. Zdecydowanie polecam.

Mam też trochę wniosków na przyszłość. Było bardzo fajnie, ale zawsze może być lepiej. Jednym z pomysłów na poprawę jest wprowadzenie szablonu prezentacji z przykładami oraz ostrego limitu na poziom slajdów. Szablon powinien zapewnić, że wszystkie prezentacje będą równie czytelne oraz, że nikogo nie porwie zbytnia fantazja przy tworzeniu slajdów ;) Limit na liczbę slajdów powinien natomiast ułatwić zmieszczenie się w czasie. Po głowie chodzi mi również zaproszenie na konferencję ludzi z poza firmy. Może to być trudne do zrealizowania, ale może się uda. Co o tym myślicie, bylibyście chętni do wzięcia udziału w takim wydarzeniu?

Z nowości względem poprzedniej edycji, w tym roku wystąpienia były nagrywane. A wszystko dzięki uprzejmości Jarka Trafidło, który udostępnił kamerkę z serii GoPro, był operatorem, a także poddał zgromadzony materiał obróbce. Jeśli ktoś nie był na jakiejś prezentacji, to będzie mógł ją teraz obejrzeć na spokojnie w domu.

Z mojej perspektywy ogromnym dodatkowym plusem tych nagrań jest to, że w końcu mogłem sporzeć na siebie od tej drugiej strony. Przyznam, że to trochę dziwne uczucie, bo głos brzmi jakoś tak inaczej i w ogóle percepcja siebie się zmienia. Na przykład, wiedziałem, że dużo gestykuluję, ale nagranie pokazało, że chyba zbyt dużo. Po drugie, występując wydawało mi się, że ogólnie stoję w miejscu i tylko od czasu do czasu zrobię krok w jedną albo w drugą stronę. Nagranie znowu uświadomiło mi, że poruszam się więcej niż mi się wydaje, a to kroczek w tą, a to kroczek w drugą. Nie mówię, że trzeba stać w miejscu, ale zbytnia ruchliowść również przeszkadza. Bardzo cenne wskazówki na przyszłość.

Konferencja wewnątrz-firmowa 2

Home

Ostatnio napisałem o zorganizowanej przez siebie konferencji wewnątrz-firmowej. Teraz należy napisać o czym można było posłuchać. Oto lista 12 przygotowanych prezentacji, wszystkie moim zdaniem stały na wysokim poziomie. O jakości prezentacji niech świadczą bardzo dobre wyniki ankiet. Średnia ocena to 8.3 w skali od 1 do 10!

Albert Skłodowski - F# as a functional language for the .NET platform

An introduction to functional programming in .NET using F# language. Write simple code to solve complex problems!

Damiarz Orzechowski - Is C++ dead? What was added into C++ x11 standard in comparison to C# and .NET features

Summary of history behind latest C++ standard. Presentation of highlights of latest standard and comparison of features between C++ and C#/.NET.

Daniel Celeda - Software Project Survival Guide

Quick induction to the main factors of a successful software project.“Software projects succeed or fail based on how carefully they are planned and how deliberately they are executed. The vast majority of software projects can be run in a deterministic way that virtually assures success. If a project’s stakeholders understand the major issues that determine project success, they can ensure that their project reaches a successful conclusion.”

Kamil Langowski - Paradoxes and idiosyncrasies of probability

Simple math problems that are outstandingly controversial, but are nonetheless facts.

Marcin Wierzbicki - Financial instruments for dummies

The talk covers basic subjects from financial engineering field, starting with present value, fixed income securities, bond pricing, immunization and arbitrage, and finishing... after 1 hour :)

Marek Ryński - An introduction to the basics of Web Application Security - theoretical lecture

A review of available mechanisms used to ensure confidentiality, integrity and availability of information in Web Applications. The talk will cover different approaches to authentication, highlighting strong and weak solutions. A few words will be said about smart cards and biometrics. Hacking, injection attacks and social engineering are only buzz words to attract your attention on this abstract, but none of these things will be discussed.

Michał Komorowski - RavenDB as an example of document oriented databases. A history of application in my pet project.

NoSQL databases are a relatively new idea which is becoming more and more popular. In this presentation, I’ll focus on document oriented databases. I’ll discuss the topic on the example of RavenDB and my pet project LanguageTrainer which supports learning foreign languages.

Michał Rzeszutko - Dependency Injection patterns and best practices

An introduction to the subject of DI. The talk covers basic subjects - what it is DI and what are the benefits of using it, as well as the more advanced ones – how to use it properly (patterns) and what to avoid (anti-patterns).

Mikołaj Barwicki - Do IT the Toyota Way?

Toyota is an enterprise built on unique philosophy focused on manufacturing and process quality that is summarized in a set of statements referred to as “Toyota Way”. Is this what made Toyota the world’s largest car manufacturer? Are these statements applicable to software development organizations?

Paweł Kupis - Aspect-oriented programming on the example of PostSharp.

Short introduction to aspect-oriented programming concept, fast review of .NET aspect frameworks and PostSharp in action.

Przemek Wasylko - Command-query responsibility segregation: can we successfully separate read from write parts of the system?

Exploration of design pattern where different (often in a radical way) model and approach is used to update information than model used to read information. I will try to show how this affects system architecture and user interface experience. But does it really make engineer’s life easier? And software less prone to errors?

Tomasz Moska - Configuring SQL Server Instance for optimal performance

The talk will cover some good practices regarding configuration of SQL Server instance.

Konferencja wewnątrz-firmowa

Home

W jednym z ostatnich postów pisałem o zorganizowanym przez siebie Quiz'ie. Dzisiaj napiszę o innym pomyśle na powiew świeżości w pracy, czyli o konferencji wewnątrz-firmowej. Konferencję taką zorganizowałem pod koniec czerwca (jej pierwotnym pomysłodawcą był mój przełożony Mikołaj).

Trochę uprzedzając, był to strzał w dziesiątkę pod każdym względem, a więc czym prędzej biegnijcie do swoich przełożonych z propozycją zorganizowania takiego wydarzenia ;) Zacznijmy od spraw organziacyjnych, czyli jak się do tego zabrałem.

• Na początek ustaliłem szczegóły z przełożonymi, czyli kiedy taka konferencja może się odbyć i ile czasu można na nią poświęcić. My wybraliśmy ostatni tydzień czerwca i na każdą prezentację przeznaczyliśmy godzinę. W konferencji mógł wsiąść udział każdy i mógł zobaczyć dowolną ilość prezentacji, przy czym było jasno powiedziane, że praca ma priorytet, czyli jeśli jest pilne zgłoszenie to trzeba je obsłużyć.
• 4 miesiące przed konferencją rozesłałem prośbę o zgłaszanie tematów wraz z krótkim opisem. Na zastanowienie się dałem 1 miesiąc.
• Co bardzo ważne, tematyka prezentacji mogła być dowolna, również nietechniczna. Jedynym warunkiem było, że prelegent:
• Ma interesować się tematem.
• Musi mieć przynajmniej trochę przekonania :), że dla innych temat również będzie interesujący.
• W regularnych odstępach (to bardzo ważne) rozsyłałem przypomnienie, że zostało tyle, a tyle czasu na  zgłoszenia.
• Po zebraniu propozycji (około 30 prezentacji, ale każdy mógł zgłosić więcej niż 1) zorganizowałem głosowanie. Na oddanie głosu były 2 tygodnie i znowu należy o tym przypominać.
• Na konferencję wybrałem 12 najlepszych prezentacji, ale każdy prelegent miał przygotować tylko 1.
• Poinformowałem kolegów o wyniku głosowania.
• Aby prelegenci nie czekali do ostatniej chwili z przygotowaniami poprosiłem ich aby przesłali mi agendę miesiąc przed konferencją.
• Zarezerwowałem salę, rzutnik, laptop itp.
• Poprosiłem prelegentów o preferencje kiedy chcą wygłosić swoje prezentacje i przygotowałem harmonogram.
• Dwa tygodnie przed konferencją rozesłałem do wszystkich w firmie zaproszenie na poszczególne prezentacje.
• Tuż przed samą konferencją przygotowałem ankiety, wydrukowałem je i pociąłem.
• Sprawdziłem również czy laptop działa, czy współpracuje z rzutnikiem i co jest na nim zainstalowane. Oczywiście poinformowałem również prelegentów czego mogą się spodziewać po sprzęcie. Pomimo to, zgodnie z prawem Murphy'ego, nie obyło się bez niewielkich problemów technicznych.
• Na każdej prezentacji na stołach czekały długopisy i anonimowe ankiety. Ich wypełnienie było obowiązkowe.
• Po konferencji zebrałem od prelegentów materiały i umieściłem je na Wiki.
• Podliczyłem ankiety i rozesłałem je do prelegentów. Przy okazji zapytałem czy zgadzają się na publikację wyników. Wszyscy się zgodzili więc udostępniłem również wyniki ankiet.

Przed godziną zero wszystko było więc zapięte na ostatni guzik. Konferencja spodobała się chyba wszystkim. Ja jestem z niej bardzo zadowolony, zarówno jako organizator jak i prelegent. To wspaniała okazja do integracji zespołu, nauki nowych rzeczy i potrenowania swoich umiejętności prelegenta w sprzyjającym środowisku.

Za jakiś czas napiszę o czym można było posłuchać na konferencji.

Quiz - rozruszaj towarzystwo

Home

Czy Wasza praca jest zawsze ciekawa i pełna wyznań, a może czasami Was nuży i zastanawiacie się jak ją urozmaicić?

Byłoby super gdyby każdy z nas mógł odpowiedzieć na to pytanie "Tak moja praca jest bardzo ciekawa i nigdy mnie nie nuży", ale w rzeczywistości bywa różnie. Zawsze można zmienić pracę, ale można również próbować zmienić coś w obecnej. Sceptycy pewnie powiedzą, a co ja mały trybik w wielkiej machinie mogę zrobić. Dużo zależy od firmy i bywają przypadki beznadziejne. Ja na rozruszanie zespołu proponuję zorganizować Quiz.

Ja postanowiłem coś takiego zrobić już po raz drugi w swojej karierze i jestem bardzo zadowolony z efektów. Odgórnym celem Quiz'u była zabawa i nauka. Zasady były proste:

• 10 tur po 3 pytania (łatwe, średnie i trudne) dotyczące szeroko pojętego programowania.
• Pytania przygotowałem za wczasu, tak aby nie musieć ich wymyślać co tydzień.
• Starałem się, aby odpowiedzi można było udzielić w jednym zdaniu, czasem wręcz jednym słowem, ewentualnie napisać kilka linijek kodu.
• Pytania rozsyłałem w poniedziałek rano i czekałem na odpowiedzi do końca dnia. Następnego dnia oceniałem wyniki, rozsyłałem odpowiedzi z komentarzami i aktualną statystykę (anonimowa lista).
• Udział był dobrowolny.
• Udział był anonimowy, każdy uczestnik miał przypisany identyfikator i tylko ja znałem mapowanie.
• Zwycięzca mógł wybrać sobie nagrodę ufundowaną przez firmę (wybrał przenośny dysk).

Do Quiz'u zgłosiło się 20 osób. Łącznie zadałem 9 łatwych pytań, 12 średnich oraz 9 trudnych za łącznie 60 punktów. Zwycięzca zdobył 52.5 punkty i walka trwała do ostatniej tury ponieważ druga osoba w rankingu miała 52 punkty, a trzecia i czwarta 51. Zebrane w całości pytania i odpowiedzi utworzyły 22 stronicowy dokument!

Quiz spodobał się i spotkał się z bardzo dobrym odbiorem również ze strony przełożonego, który dał pieniądze na nagrodę. Najbardziej cieszy mnie jednak to, że już kilkukrotnie słyszałem od kolegów, że w trakcie Quiz'u nauczyli się czegoś nowego.

Organizacja Quiz'u to również nauka dla mnie. Aby przygotować pytania i nie zaliczyć wpadki wiele zagadnień musiałem przestudiować dużo dokładniej. Nauczyłem się również jak, wbrew pozorom, trudne jest układanie pytań w taki sposób, aby były zrozumiałe dla wszystkich. Pomimo, że każde zadanie czytałem wielokrotnie zdarzało się, że musiałem odpowiadać na pytania i rozsyłać dodatkowe informacje.

Na koniec kilka przykładów pytań:

Łatwe

We have to measure an execution time with the maximum possible resolution/precision. It was implemented in the following way. Does this code meet this requirement? If yes, why? If not, propose a better solution.

var start = DateTime.Now;
//...
var end = DateTime.Now;

Średnie

.NET 4.5 introduces a new, easy and elegant way to retrieve a name of a method (caller) which executed/called a given method (calle).

public void Fun()
{
//Here, I want to get a name of a method that executed/called Fun method
}

Trudne

We want to use a class called  Fun, that  is defined in an external library. Unfortunately, a constructor of this class contains a bug which causes an exception. In other words, we can't create a new instance of Fun class, but we have to. You have to find a workaround. You mustn't modify Fun class.

Codility

Home

Jestem wielkim zwolennikiem sprawdzania kandydatów na programistów przy pomocy zadań wymagających napisania kodu. Sam również byłem egzaminowany w ten sposób nie raz i nie dwa. W pamięci zapadły mi jednak rekrutacje z udziałem portalu Codility, który weryfikuje nie tylko poprawność kodu ale również jego wydajność, za każdym razem było to dla mnie ciekawe wyzwanie.

Postanowiłem więc skontaktować się z Codility i zapytać czy w ofercie mają produkt pozwalający programistom ćwiczyć ich umiejętności. Odpowiedź na zapytanie dostałem bardzo szybko i niestety okazała się negatywna, ale zostałem zaproszony do ich biura w Warszawie aby porozmawiać o tym pomyśle.

Trochę to trwało zanim udało się nam ustalić termin spotkania, ale w końcu pewnego popołudnia wsiadłem w tramwaj i pojechałem na Plac Bankowy. Na miejscu przywitała mnie przemiła Czeszka Zuzana, miałem okazję poznać zespół pracujący nad rozwojem Codility oraz porozmawiać o ich pracy. Ponieważ nie miałem wcześniej okazji korzystać z portalu od strony rekrutera pokazano mi jak to wygląda.

Na koniec wręczono mi upominek w postaci książki Looking For a Challenge? z opisem kilkudziesięciu ciekawych zadań programistycznych, przygotowanych przez zwycięzców międzynarodowych konkursów programistycznych.

À propos problemów algorytmicznych, dowiedziałem się również, że część zadań Codility dostępna jest w Internecie dla każdego programisty, ale nie wszystkie łatwo znaleźć. Poniżej, dzięki uprzejmości Codility, macie ich pełną listę. Lista ta z czasem będzie z czasem rozszerzana o tzw. zadania well known czyli takie, które są dobrze znane i nie ma sensu przy ich pomocy testować kandydatów ale idealnie nadają się do ćwiczeń.

• psi2012
• phi2012
• chi2012
• upsilon2012
• tau2012
• sigma2012
• rho2012
• pi2012
• omicron2012
• xi2012
• nu2011
• mu2011
• lambda2011
• kappa2011
• iota2011
• theta2011
• eta2011
• zeta2011
• epsilon2011
• delta2011
• gamma2011
• beta2010
• alpha2010

Wizytę wspominam bardzo miło. Tym bardziej, że Codility odwiedziłem nie jako klient, ale jako "człowiek z ulicy". Cieszy również, że to polski start-up odnoszący sukcesy na świecie.

See[Mike]Code

Home

Dzisiaj rozmawiając z kolegami zeszliśmy na temat rekrutacji programistów. Między innymi rozmawialiśmy o narzędziach wspomagających ten proces takich jak Codility. Rozmowa ta przypomniała mi, że swego czasu natknąłem się ba bardzo proste ale pomysłowe narzędzie pozwalające na żywo, zdalnie sprawdzić jak potencjalny kandydat radzi sobie z programowaniem. Miałem trudności z przypomnieniem sobie adresu strony dlatego ku pamięci publikuję ten post. Przy okazji sądzę, że narzędzie to może przydać się innym. Mianowicie chodzi o See[Mike]Code.

Zasada działania jest bardzo prosta. Wchodzimy na stronę See[Mike]Code, klikamy przycisk New Interview Site i otrzymujemy dwa adresy. Jeden wysyłamy do kandydata, a drugi zachowujemy dla siebie. O wyznaczonej porze prosimy aby kandydat uruchomił przeglądarkę i wszedł na podany adres. Jego oczom ukarze się taki widok:



Kiedy wejdziemy pod drugi adres wyświetlona zostanie dość podobna strona. Teraz prosimy kandydata aby wykonał jakieś proste zadanie programistyczne np.: słynne FizzBuzz, a jego poczynania możemy obserwować na ekranie naszego komputera. See[Mike]Code nie udostępnia takich dobrodziejstw jak IntelliSense ale w przypadku prostych zadań, takich jak wspomniane FizzBuzz, nie jest to konieczne.

Jestem przekonany, że na polskim rynku nie mamy sytuacji, w której jak to napisał Jeff Atwood na swoim blogu:

Like me, the author is having trouble with the fact that 199 out of 200 applicants for every programming job can't write code at all. I repeat: they can't write any code whatsoever.

Sądzę jednak, że dobrze mieć w swoim repertuarze takie narzędzie.

Bardzo wymagająca rekrutacja 2

Home

W ostatnim poście opisałem przebieg pewnej rekrutacji, w której uczestniczyłem, aż do rozmowy z kierownikiem projektu. Post ten stanowi dokończenie tego tematu, a w szczególności zawiera odpowiedź na pytania jakie pojawiły się w komentarzach.

Po jakimś czasie po rozmowie z kierownikiem projektu, w tej chwili już nie pamiętam szczegółów, zostałem zaproszony do kolejnego etapu rekrutacji. Tym razem musiałem pofatygować się do innego miasta na serię rozmów z przedstawicielami firmy z zagranicy. O takiej konieczności zostałem zresztą poinformowany dużo wcześniej i dlatego również na każdym z wcześniejszych etapów rekrutacji była sprawdzana moja znajomość angielskiego. Nie ukrywam, że taka podróż nie do końca mi się podobała ale ponieważ praca wyglądała bardzo obiecująca to zdecydowałem się na wyjazd.

Na rozmowę pojechałem samochodem ze względu na elastyczność, jadę kiedy chcę, nie przejmuję się godziną odjazdu pociągu... Decyzja była dobra i zła. Zła ponieważ 6 godzin jazdy to męcząca sprawa, a dobra bo pociągiem nie byłoby wiele krócej, a musiałbym jeszcze płacić za taksówkę itd. Na rozmowę pojechałem dzień wcześniej aby się porządnie wyspać. Nocleg miałem prawie za darmowo, a za benzynę zwrócono mi pieniądze. Tutaj dodam, że z perspektywy uważam, że po tak długiej jeździe samochodem, a chyba nawet pociągiem porządny odpoczynek to konieczność. Innymi słowy nie ma sensu umawiać się na rozmowę o pracę tuż po długiej podróży. Zapewne można wypaść dobrze ale jestem przekonany, że zawsze będzie to gorzej niż kiedy będziemy wypoczęci.

Rozmowy z przedstawicielami z zagranicy trwały 3 godziny. W sumie odbyłem trzy rozmowy. Każda z nich była mocno techniczna ale dotyczyła trochę innych rzeczy. Rozmawiałem o algorytmach np.: programowanie dynamiczne, implementacji funkcji wirtulanych w C++, złożoności obliczeniowej, a także o rzeczach bardziej biznesowych. Muszę przyznać, że po tych rozmowach nabyłem większej pewności co do mojego mówionego języka angielskiego. To jednak co innego rozmawiać po angielsku na wczasach czy prowadzić luźną rozmowę, a co innego mieć kilkugodzinną rozmowę o pracę w tym języku z ludźmi, z którymi w inny sposób sie nie dogadasz.

Z przebiegu tych rozmów byłem zadowolony, a moje wrażenie zostało wkrótce potwierdzone bo zaproponowano mi pracę. Tutaj dodam, bo zapomniałem o tym wcześniej napisać, że rekrutacja dotyczyła stanowiska programisty czy jak to się nazywało w nomenklaturze tejże firmy. Z tą istotną różnicą, że było to stanowisku tzw. programisty algorytmicznego czyli takiego, który zajmuje się na co dzień przede wszystkim implementacją i analizą algorytmów np.: data miningowych, sortowania itp., a nie realizacją typowo biznesowych wymagań.

Dalszy etap rekrutacji to oczywiście negocjacje, które trwały dość długo (dwa spotkania, rozmowy telefoniczne). Jak się skończyły? Finalnie odrzuciłem ofertę pracy. Czemu? Wbrew pozorom nie chodziło o kwestie finansowe, a na pewno nie miały one decydującej roli. Głównym argumentem przeciw były powody natury rodzinno osobistej. Co tu dużo mówić, przeprowadzka do innego miasta kiedy całe życie spędziło się w Warszawie, ma się tutaj rodzinę, przyjaciół, pracę, mieszkanie i jest się zadowolony z życia to bardzo ciężka decyzja. Pozostaje mi tylko żałować, że oferta nie dotyczyła pracy w Warszawie.

Jako podsumowanie chciałbym wymienić te cechy/zalety tego procesu rekrutacyjnego, które spowodowały, że go zapamiętałem:

• Bardzo kompetentne osoby sprawdzające wiedzę techniczną.
• Dyskusja, a nie tylko ocena przedstawionych przeze mnie rozwiązań.
• Praca domowa do zrobienia.
• Sprawdzenie znajomości algorytmów i rozwiązywania zadań algorytmicznych.
• Prowadzenie części rozmowy w języku angielskim.
• Szczerość w odpowiedziach na moje pytania nawet jeśli odpowiadający wiedział, że taka odpowiedź może mnie zniechęcić.
• Jeśli firma wkłada tyle wysiłku w znalezienie pracowników to znaczy, że planuje dłuższą współpracę.
• Jeśli firma wkłada tyle wysiłku w znalezienie pracowników to znaczy, że potencjalni współpracownicy są bardzo kompetentni.

Opisana rekrutacja jest dla mnie wzorem rekrutacji dobrze sprawdzającej umiejętności i wiedzę technologiczną kandydata i porównuję do niej inne. Nie twierdzę jednak, że zawsze powinno to wyglądać w taki sposób. Nie każdej firmy na to stać, a po drugie nie zawsze potrzebne jest tak gruntowne sprawdzenie potencjalnego pracownika. Każdy proces rekrutacyjny na stanowisko programistyczne powinien jednak charakteryzować się kilkoma rzeczami (łatwymi do osiągnięcia):

• Pisanie jakiegoś kodu przez kandydata.
• Test z wiedzy technicznej.
• Rozmowa z osobą techniczną i biznesową.
• Sprawdzenie znajomość języka angielskiego przynajmniej w stopniu pozwalającym czytać dokumentację.

Bardzo wymagająca rekrutacja

Home

W swojej dotychczasowej karierze wziąłem udział w wielu rekrutacjach. W przeważającej liczbie przypadków zostałem zaproszony na rozmowę ale czasami skończyło się na wysłaniu CV. Bardzo często zaproszenie na rozmowę poprzedzone było wywiadem telefonicznym. Wielokrotnie rozwiązywałem różnego rodzaju testy, dużo rzadziej byłem proszony o wykonanie pracy domowej. Część rekrutacji organizowana była przez firmy HR'owe inne bezpośrednio przez zatrudniającą firmę. Spośród tych wszystkich rekrutacji kilka zapadło mi w pamięci, a szczególnie jedna niezwykle wymagająca. Aby nie budzić wątpliwości napiszę, że rekrutacja ta odbyła się już sporo czasu temu i finalnie nie podjąłem współpracy z tą firmą. Chciałbym jednak opisać jak wyglądała ponieważ dużo się dzięki niej nauczyłem i jest dla mnie dzisiaj wzorem, do którego porównuję inne rekrutacje. Post ze względu na jego długość postanowiłem rozbić na dwie części, tutaj prezentuję pierwszą.

Wszystko rozpoczęło się w sposób standardowy od zapytania na portalu internetowym czy jestem zainteresowany taką, a taką ofertą pracy. Propozycja była na tyle interesująca, że odpowiedziałem na nią pozytywnie. Po jakimś czasie zadzwoniła do mnie Pani z HR'ów aby potwierdzić moje zainteresowanie i umówić się na dłuższą rozmowę telefoniczną.

O ile mnie pamięć nie myli rozmowa odbyła się w ciągu kolejnego tygodnia i trwała około półgodziny. W tym czasie zostałem poproszony o opisanie swojego dotychczasowego doświadczenia, w jakich projektach brałem udział, jakich technologii używałem... jednym słowem standard. Padło również pytanie o oczekiwania finansowe, na które to mimo starań i prób aby to druga strona wyszła najpierw z propozycją w końcu udzieliłem odpowiedzi. Rozmowę wyróżnia trochę to, że już na tym etapie została zweryfikowana moja znajomość języka angielskiego. Z drugiej strony taka praktyka jest chyba coraz powszechniejsza. Na koniec dowiedziałem się, że dalszy etap rekrutacji będzie polegał na rozwiązaniu dwóch zadań algorytmicznych i jednego biznesowego. Przy czym większą uwagę miałem zwrócić na zadania algorytmiczne.

Następnego dnia otrzymałem drogą mailową treść zadań. Niestety ze względu na klauzulę poufności nie przytoczę ich tutaj, chociaż chciałbym ponieważ były bardzo ciekawe. Pierwsze zadanie algorytmiczne rozwiązałem następnego wieczoru. Moje pierwsza implementacja bazowała na przeszukiwaniu przestrzeni stanów i dawało poprawne wyniki ale kiedy już miałem je wysłać zauważyłem, że do problemu można podejść w zupełnie innych sposób. Finalne rozwiązanie zajmowało kilka linii kodu zamiast kilkuset! Za drugie zadanie zabrałem się następnego dnia i doszedłem do wniosku, że to pytanie z hakiem ponieważ przedstawiony problem należy do klasy NP, co też napisałem w odpowiedzi.

Rozwiązanie pierwszego zadania została zaakceptowane. Co do drugiego to zostałem poproszony żebym się jeszcze mu przyjrzał ponieważ postawiony problem można rozwiązać w czasie wielomianowym. Początkowo byłem przekonany, że to układający/oceniający zadanie pomylił się. Błąd tkwił jednak po mojej stronie. Na czym polegał? Przedstawiony problem można było sprowadzić do znalezienie ścieżki Hamiltona w grafie i to rzeczywiście jest problem NP. Ja zapomniałem jednak o tym, że wśród wszystkich możliwych grafów są takie ich odmiany dla, których problem znalezienia ścieżki Hamiltona można sprowadzić do znalezienia ścieżki Eulera, a to można zrobić w czasie wielomianowym. Co do zadania biznesowego to w końcu z braku czasu go nie rozwiązałem ale tak jak pisałem nie było ono bardzo istotne.

Co dalej? Zostałem zaproszony na rozmowę, połączoną z testem. Test składał się z 20 otwartych pytań i na jego rozwiązanie było około 30 minut. Pytania były tak ułożone, że można na nie było odpowiedzieć w jednym/dwóch zadaniach. Czy były trudne? Dla mnie raczej nie, chociaż nad niektórymi musiałem się dłużej zastanowić. Pomimo, że pytań było tylko 20 sądzę, że dobrze weryfikowały ogólną znajomość platformy .NET. Było coś o zwalnianiu zasobów, użyciu słowa kluczowego using, synchronizacji, LINQ'u itd. Te 30 minut starczyło dokładnie na tyle aby napisać odpowiedzi, ktoś nie orientujący się w temacie miałby z tym problem.

Po rozwiązaniu testu przyszła kolej na rozmowę z dwoma "technicznymi" osobami. Rozmowa odbyła się za pośrednictwem Skype. Początkowo zapraszano mnie na wizytę do innego miasta ale kiedy powiedziałem, że będzie z tym ciężko zorganizowano mi video konferencję. Rozmowa miała być połączona z omówieniem testu ale widać wypadłem dobrze ponieważ zadano mi raptem 1 albo 2 pytania na ten temat. Całą rozmowę zapamiętałem z 2 powodów. Po pierwsze trwała bite 3 godziny, a po drugie zadawano mi naprawdę trudne pytania. Pytania nad którymi musiałem się dogłębnie zastanowić przed podaniem odpowiedzi. W gruncie rzeczy nie były to po prostu pytania ale spore problemy do rozwiązania. Fajne było to, że nawet po podaniu prawidłowej odpowiedzi mówiono mi żebym się zastanowił bo można to zrobić jeszcze lepiej, bardziej optymalnie. W czasie tej rozmowy powtórnie zweryfikowano moją znajomość języka angielskiego tyle, że tym razem rozmawialiśmy o zagadnieniach technicznych. Po tych 3 godzinach byłem równie zmęczony jak po całym dniu pracy.

W czasie tej rozmowy miałem też okazję zadać kilka pytań, na które w miarę możliwości udzielono mi odpowiedzi. Jak zwykle w takich przypadkach poprosiłem również o feedback. Powiedziano mi, że pełnego raportu raczej nie otrzymam ale na pewno dostanę informację zwrotna czy było coś nie tak, a jeśli tak to co. Dwa dni później dostałem zaproszenie na następną rozmowę, tym razem z kierownikiem projektu. Rozmowa ta również odbyła się za pośrednictwem video konferencji i trwała około półgodziny. I tym razem sprawdzono moją znajomość języka angielskiego i zadano kilka "biznesowych" pytań. Miałem też okazję dopytać o interesujące rzeczy. Na koniec kierownik projektu powiedział, że w razie jakichś wątpliwości zaprasza do kontaktu. Z możliwości tej skorzystałem kilkukrotnie i za każdym razem otrzymałem wyczerpującą odpowiedź...