🥇Избавяме се от страха пред първото трудоустройство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глупав - ще те уволнят

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

От новака на работа се очаква:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

След като намерите общ език с колегите, те ще започнат да ви виждат не като новак-стажант, а като равен на себе си специалист.

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

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

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

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

Накосячиш — уволнят

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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