🥇Преодоляйте страха от първото назначение

Кадър от филмa „Хари Потър и затворникът от Азкабан“

Проблемът на този свят е, че възпитаните хора са пълни с несигурност, а глупаците са пълни с увереност
Чарлз Буковски

Напоследък провеждах индивидуално занятие по програмиране. За разлика от обикновените занятия, темата не беше конструкцията на езика или проблемът при решаване на задача. Студентът сподели своите притеснения относно бъдещото си трудоустройство. Самият ученик беше доста прозорлив. Един от онези, които идват на курсове, завършват програмата по-бързо от всички и с оригинални решения, но постоянно искрено подценява себе си. Според мен, такива съмнения възникват само от недостатък на информация. Този пропуск се опитах да запълня импровизирано по време на занятието.

Въпросите бяха приблизително такива:

Всеки година от университетите завършват множество студенти и всички те тръгват да търсят работа. Това е много хора. Сигурно ще вземат най-добрите, а на мен няма да ми остане място.
Какво стане ако сгреша и ме уволнят на часа?
Какво, ако по време на работата разберат, че съм глупав и ме изгонят?

Този студент не беше първият човек, на когото отговарях на подобни въпроси. Тези въпроси се появяват у много хора, и обикновено се налага да говоря без подготовка. Този път реших да запиша монолога си в тетрадка. Мислех, че ще се получат две-три абзаца, а се събра цяла статия.

В статията е описан погледът ми от моята перспектива и въз основа на моя опит. Въпреки това, нашият свят е много разнообразен и в него се случват удивителни неща. Ако не сте съгласни с нещо или вашият опит е различен, моля, напишете коментар.

Статията беше написана от разработчик за разработчици. Въпреки това, ако планирате да се занимавате с тестване, администриране или нещо друго в ИТ, част от съветите също ще ви бъдат полезни.

Вообще не ще наемат

Когато си представиш, че всяка година множество университети дипломират стотици студенти, става неудобно. Как да се конкурираш с такава огромна тълпа?

За съжаление, далеко не всички завършили имат достатъчна техническа подготовка. Опитайте се да попитате някой познат студент от университета: как хората в неговата група получават достъп до изпити по дисциплини като „бази данни“ или „основи на алгоритмизацията и програмирането“? В група от 30 души в най-добрия случай ще има 3-5 „напреднали“ младежи, които всичко наистина са направили сами. Останалите просто им преписват, зубрят отговори на въпросите и успешно полагат изпити.

Така беше и когато учех сам. Въпреки това, моят опит можеше да не е представителен. Затова зададох този въпрос на няколко различни студенти. Отговорът беше приблизително същият. Отговарящите бяха от различни вузове и колежи. Разсъжденията за причините оставям извън пределите на тази статия. За пълноценно изследване не ми стига времето, затова ще направя извод от наличните факти.

Сред стотиците завършили, едва няколко десетки представляват интерес за работодателите.

Несетни завършили могат да съставят реална конкуренция за способен студент с добра подготовка. Въпреки това, дори ако сте учили усърдно, след първото интервю вероятно няма да бъдете наети. След второто, вероятно също. Всичко може да се подреди добре, но по-добре е да се настроите не на щурм, а на обсадна тактика. Неуспешната опитност за работа е просто повод да се направи анализ на грешките и да се опита отново. Няма да говоря за подготовката за интервюта. В интернет вече е написано много по тази тема. Ще кажа само, че в преминаването на интервюта има нюанси, за обяснението на които в програмата на обучението ви едва ли остава време. Потърсете тази информация сами, може да намали броя на опитите.

Безумието е точно повторение на едно и също действие. Отново и отново, в надежда за промяна.
Алберт Айнщайн

За да не превърнете преминаването на интервюта в безумие, след всяка нова опитност трябва да ставате по-добри. Запомнете или запишете въпросите, които ви задаваха по време на интервюто. Когато се върнете у дома, прегледайте този списък и проверявайте себе си с помощта на интернет. Така ще разберете къде сте сгрешили вие, а къде — интервюиращият. Такова нещо също може да се случи. Повторете или изучете темите, по които отговорихте слабо и опитайте отново.

Освен това, на пазара на труда има ясно изразена сезонност. Умелите компании планират наемането на персонал с оглед на датите на завършване от учебните заведения. През пролетта има повече обяви за работа за начинаещи, отколкото в останалото време. Въпреки това, конкуренцията в този период е по-висока.

Тъп — ще го уволнят

Когато наемат човек без опит, имат съответните очаквания към него.

Очакванията към начинаещия на работа са:

Знания за общата техническа база
Изучаване на особеностите на предметната област на компанията
Освояване на използваните инструменти и практики

В някои организации за начинаещите се организират обучителни курсове по използваните технологии, инструменти и местни правила. Например, правила за добър тон при използването на корпоративната поща, реда за промяна на документи в уики, местни особености при работа с VCS и системата за управление на грешки.

Има и технически въводни курсове, но тяхната полезност е съмнителна. Ако сте стигнали до наемане, означава, че наемателите са се убедили, че имате някакво достатъчно ниво на знания. Най-добре е да преминете тези курсове добросъвестно, като малка формалност. Може би наистина ще има нещо полезно в тях.

Когато започнете работа, помнете, че на начинаещия със сигурност няма да му бъде възложено решаването на спешна, сложна и едновременно важна задача. По-скоро ще бъде само едно от тези свойства. Либо просто, но спешно: поправка на верстка, изпращане на файл на някого, възпроизвеждане на проблем. Либо сложно, но без никаква надежда за завършване — за да може начинаещият да натрупа опит. Либо важно, но експериментално. Например проект, който всички отдавна искат, но не могат да отделят време за реализиране.

Задачите за усвояване на инструментариума ще бъдат "сложни" и изкуствени. По-вероятно е да бъде опростен вариант на основната система. В подобни задачи се използва същият стек технологии и същите термини от предметната област, както и в целия проект. При това, резултатът от изпълнението няма да бъде предоставен на крайния потребител. Това може да демотивира, но на това настроение е по-добре да се противостои. Изкуствената задача трябва да се изпълнява добросъвестно, сякаш съдбата на проекта зависи от нея.

Резултатът от решението на вашата първа задача ще остави първо впечатление у колегите, които не са били на интервюто.

Друг вариант на задачата за усвояване на инструментариума е „да стартирате проект на локалната машина/тестовата среда“. Понякога този процес е описан в инструкциите. Но те обикновено са стари и на места неактуални. Можете да внесете реална полза в проекта, ако напишете нова инструкция с уточнения относно възникналите проблеми. Сигурно в университета е трябвало да напишете РГР за отчет по различни дисциплини. Тук е почти същото. В документа трябва да бъдат отразени действията, които трябва да се изпълнят за стартиране.

Обикновено действията за стартиране на продукта на тестовата среда са приблизително следните:

клонирайте репозитория, превключете се на някакъв клон или таг
оформете някакъв конфигурационен файл
подгответе структурата на базата данни
попълнете я с тестови данни
извършете сборка или компилация на проекта,
стартирайте набор от конзолни скриптове в определена последователност

В процеса на стартиране на системата локално неизбежно ще възникнат непредвидени проблеми.

Намерени решения на проблемите трябва да бъдат дописвани в инструкцията за разгръщане. Тогава при следващото следване на инструкцията, тези проблеми вече няма да възникват. При попълване на конфигурационни файлове и извикване на скриптове, трябва да се обърне внимание каква стойност къде се използва и с какво трябва да съвпада. Например, ако проектът се компилира с помощта на CI-система и след това се стартира със скрипт, важно е да се разбере къде да се напише името на клона или номера на комита. Понякога скриптът предполага предаване IP адреси или DNS име на базата данни, нейния логин и парола. В този случай трябва да се знае кой точно адрес да се използва за тестовата среда, какви логини там съществуват и какви пароли трябва да бъдат посочени.

Някои задачи могат да изглеждат прости за опитни разработчици и да предизвикат затруднения у стажантите. Това е нормално явление.

Разработчиците ежедневно трябва да решават технически проблеми. Опитните служители вече са се справяли с много проблеми, а на новаците им предстои да се справят с тях. Най-добрата тактика е записването на всички срещнати грешки в документа „решаване на проблеми с ${название задачи}“. За всеки проблем трябва да се формулира хипотеза за причината, да се намерят в интернет варианти за решение и последователно да се опитат. Резултатът от всяко опитване също трябва да се фиксира.

Формализирането на вашите проучвания под формата на документ ще позволи:

да изнесете от главата си малките детайли. Например параметри на конфигурацията, DNS/IP адреси, конзолни команди и SQL заявки.
да си спомните „какво правех вчера“, когато задачата се разтегли на няколко дни.
да не блуждаете в кръг. Вие винаги ще можете да прочетете какво сте правили преди и да разберете, че сте се върнали към първоначалния проблем.
ясно да отговорите на въпроса: „какво направи днес“, дори ако готово решение все още няма.

Трябва да можете да разказвате статуса на задачите си на колегите.

Периодично колегите ще се интересуват от вашите успехи и ще споделят своите. За това се отделя малко време всеки ден или седмица.

Ако не проследявате срещнатите и решените проблеми, описанието на вашите успехи ще изглежда така: „Опитах се да направя задачата, но не успях. Все още търся решение“. От такъв разказ не е ясно дали стажантът е правел нещо или просто е седял и читал. Нужна ли му е помощ? Променена ли е ситуацията от вчера?

Ако водите документ с проучвания за решения, то ще можете да кажете: „Опитвам се да направя тази задача. Имам следните грешки. Някои от тях реших по този начин. Сега тепърва ще се справя с тази. Имам такива хипотези и варианти за решение. В момента ги проверявам.“

Ако задачата може да бъде измерена, статусът трябва да съдържа цифри. Например, за задачата „да напиша юнит тестове за модула“ можете да кажете „планирам да направя 20 теста, а сега съм написал 10“.

Колкото повече детайли предоставите, толкова по-добре вашите колеги ще разбират какво сте правили. Това ще създаде положително отношение към вас и ще им помогне да разберат дали имате нужда от помощ или не.

Не се колебайте да поискате помощ.

По-горе казах, че когато възникне проблем, е необходимо да формулирате хипотеза за причините и варианти за решение. Въпреки това понякога хипотезите не се оправдават и самостоятелно намерените решения не работят. В такъв случай е по-добре да поискаме помощ. За да не прекъсвате вниманието на колегите, трябва да се опитате сами да решите всеки проблем. Ако в рамките на няколко часа не успеете да намерите решение, е време да потърсите съвет от по-опитни колеги.

Най-добре е да започнете с въпроса: „Столква ли се някой преди с проблема?“ с кратко описание на проблема. Желателно е да приложите част от съобщението за грешка или екранна снимка. Това съобщение е най-добре да се изпрати първо в някакъв общ чат за работа. Така няма да пречите на тези, които наистина са заети. Свободните колеги ще видят вашето съобщение и могат да помогнат.

Ако след съобщението в общия чат никой не е помогнал, опитайте да хванете опитен колега по време на пауза: обяд, разходка за чай/кафе, партия тенис или цигара. Ако не успеете, съобщете за затрудненията си на летучка или стендап.

При решаване на известни проблеми това може да е всичко. Ако обаче проблемът е нов, ще започне разследване, при което трябва да действате според обстоятелствата.

„Важните“ задачи на начинаещите, които са нужни на крайните потребители, ще бъдат скучни и малки. Например „да добавите допълнителна колона в отчета“ или „да поправите печатна грешка във формата“ или „да реализирате метод на модела за зареждане на атрибутите на клиента от СУБД“. Целта на тези задачи е начинаещият да се запознае с предметната област и да се впише в ежедневната работа.

Важно е не само технически да решите задачата, но и да разширите знанията по предметната област.

В описанието на задачата, в чатове и разговори ще срещнете термини. Те може да изглеждат като добре известни съществителни. Въпреки това, в контекста на информационна система, те придобиват особен, по-точен смисъл. Значението на откритите термини е най-добре да се запише в специален документ — речник на термините. При добавяне в речника е достатъчно да запишете разбирането си на думата, а за истинското й значение е по-добре да се обърнете към аналитика. Ако такъв липсва, тогава към опитните членове на проекта. Воденето на речник на термините е един от най-простите начини за приобщаване към предметната област на проекта.

Когда ведете диалог с колегами, те вскоре начнут воспринимать вас не как новичка-стажера, а как равного себе специалиста.

Има специални задачи, например „да напишете юнит тестове за модула“. На тях е малко вероятно да се задържите дълго с търсене на решения. Въпреки това, те са достатъчно сериозни и не се дават само за обучение на стажера. Написаните тестове увеличават стабилността на проекта, като намаляват бъговете в приложението и времето за тестване от хората. В идеалния свят юнит тестовете се пишат веднага в хода на разработката, но реалността е различна. Понякога разработчикът на модула напълно го задържа в главата си и не вижда необходимост да ги пише. „Всичко е очевидно, какво да се тества тук?“ Понякога модулите се пишат в спешен режим и времето за юнит тестове не остава. Затова задачата за написването на юнит тестове се възлага на новичка. Така стажерът може да се адаптира по-бързо в проекта, а проектът може да спести време на по-високоплатените специалисти.

Има случаи, когато стажерите и новичките получават ролята на пълноценни тестери. Обикновено преди това трябва да разгръщат продукта локално и да прочетат изискванията. От новия служител се очаква:

въпроси като „ако направя така, какво ще стане? В изискванията това не е посочено. Как трябва да бъде?“
задачи в баг трекера „в изискванията е написано така, а на практика е иначе“.

Тестированието е прекалено обширна област за тази статия. Ако ви е възложена такава задача, потърсете в интернет как най-добре да я изпълните.

Ако сгрешите — ще ви уволнят

В нормалната организация, ако се случи така, че неопитен служител получи достъп до нещо критично и провали нещо, вината ще бъде на този, който е допуснал това. Защото новакът по подразбиране няма достъп до критичната инфраструктура. При адекватно управление няма да са склонни да опрекват неопитния стажант.

Ако се случи нещо, няма да уволнят за един инцидент. Хората учат на грешките си. Стажантът, който е допуснал грешка, е получил ценен урок и това го прави значително различен от другите стажанти. Ако уволнят стажанта, на негово място ще дойде друг, който също ще допусне подобни грешки.

Най-важното е да учим от грешките и да не ги повтаряме.

Ако човек не извлече поуки от грешките си, с него ще се опитат да се разделят. Въпреки това, светът е разнообразен. В някоя бандитска организация могат да го изхвърлят през прозореца за първата грешка. Но е по-добре да избягвате такива компании, като предварително направите справка или разберете повече по време на интервюто.

По-добре е да не допускаме инциденти.

Дори ако вас лично не уволнят за грешка, такова произшествие ще създаде нежелателни проблеми за вашия екип и проекта като цяло. Затова бъдете особено внимателни с операции по изтриване или създаване на таблици в базата данни, файлове, инстанции на услуги и документи в базата знания на проекта. Ако срещнете адрес на ново свързване, уточнете поне с двама различни хора какво може да се прави там. Проверявайте правата си в средите не чрез метода на опити и грешки, а с подходящи команди. Например правата за изтриване на файлове с помощта на командата `ls`, правата за работа с таблици в mysql с помощта на командата `SHOW GRANTS FOR ‘user’@’host’;` и подобни. В практически всеки инструмент ще имате подобна възможност.

При редактиране на файлове, за всеки случай, запазвайте копие на оригинала.

Между стажанта и крайния потребител са изградени няколко бариера.

Ако бихте могли да предоставите продукта си директно на потребителя, вие бихте могли да не се назначавате на работа, а да тръгнете по "свободно плаване". Но тъй като все още нямате такава възможност (а и отговорност), трябва да преминете през няколко етапа на контрол в проекта.
Първата стъпка е проверката от ментор. Той оценява решението на начинаещия от техническа гледна точка. Ако ментор не е назначен, е необходимо да се намери такъв. За целта трябва да се избере някой от старейшините на проекта и по време на почивката да помолите да погледне решението: правилно ли е решена задачата? Ако започне да преглежда и отговаря, значи менторът е намерен. Ако игнорира, е добре да питате някой друг.

Следващата стъпка е Quality Assurance. На български – тестери. По съветски – нормоконтрол и ОТК. Те трябва да се уверят, че резултатът от работата на стажанта съответства на зададената задача. Те рядко ще се вглеждат в кода. Най-често тестерите ще проверяват събрания проект, който разработчикът запазва в системата за контрол на версиите.

Третата стъпка е мениджер на релиза. Може да няма отделен човек за тази задача, но все пак някой изпълнява тази роля. Той проверява, че тестерите са потвърдили, че проектът може да бъде пуснат. След това той извършва действията по доставката на продукта на крайните потребители.
В малките организации тези бариери по различни причини могат да липсват. Въпреки това, там няма да наградят начинаещия с важна задача за промяна на нещо. Защото този риск не е нужен на никого.

Трябва първо да се включиш в битката, а после ще видиш.
Наполеон Бонапарт

Надявам се, че статията ще ви помогне да преодолеете несигурността си и да изпратите първото си резюме. Разбира се, предварително трябва да се подготвите. Но не трябва да се бавите прекалено. Вероятно вече сте прекарали няколко години в университет или колеж. Къде още да отлагате? В края на краищата, по-добре е веднъж да чуете "не" от специалист и да направите корекции, отколкото всеки ден да си казвате "не" и да спирате професионалното си развитие.

След наемането трябва да се концентрирате върху това да израснете от стажант в пълноправен член на екипа. Такъв растеж обикновено е съпроводен с повишаване на заплатата ви.

Желая ви търпение и упоритост.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.