Да се ​​отървете от страха от първата си работа

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

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

Чарлз Буковски

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

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

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

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

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

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

Изобщо няма да те наемат

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

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

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

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

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

Лудостта е точното повторение на едно и също действие. От време на време, надявайки се на промяна

Алберт Айнщайн

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

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

Глупав - уволни се

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

От новодошлия на работа се очаква:

• Познаване на обща техническа база
• Проучване на спецификата на предметната област на фирмата
• Овладяване на използваните инструменти и практики

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

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

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

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

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

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

Обикновено стъпките за стартиране на продукт в тестова среда са нещо подобно:

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

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

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

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

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

Регистрацията на вашето изследване под формата на документ ще ви позволи да:

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

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

От време на време колеги ще се интересуват от вашите успехи и ще споделят своите. Отделете малко време за това ежедневно или седмично.

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

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

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

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

Чувствайте се свободни да помолите за помощ

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

Добро място да започнете е да попитате „някой сблъсквал ли се е с този проблем преди?“ с кратко описание на проблема. Препоръчително е да прикачите част от съобщението за грешка или екранна снимка. По-добре е да изпратите това съобщение за първи път в някакъв общ работен чат. По този начин не разсейвате тези, които са наистина заети от работа. Безплатните колеги ще видят вашето съобщение и ще могат да помогнат.

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

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

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

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

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

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

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

Случва се на стажантите и новодошлите да бъде възложена ролята на пълноправни тестери. Обикновено, преди да направите това, трябва да разположите продукта локално и да прочетете изискванията. В резултат на това новият служител се очаква да:

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

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

Ако сбъркаш, ще те уволнят

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

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

Основното нещо е да се поучите от грешките и да не ги повтаряте отново.

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

По-добре е да избягвате инциденти

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

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

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

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

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

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

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

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

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

Пожелавам ви търпение и постоянство.

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

Какви бяха първите ви задачи в първата ви работа в ИТ?

• Комплекс

• Важно

• Спешно

• Нито едно от посочените

75 потребители гласуваха. 20 потребители се въздържаха.

Какво трябваше да направите в началото на първата си работа?

• Инсталирайте продукта локално

• Тествайте съществуващ продукт

• Извършете обучение, фалшива задача

• Направете експериментален, реален проект за клиент

63 потребители гласуваха. 25 потребители се въздържаха.

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

• 1 на 10

• 1 на 5

• Всяка секунда

• Всичко, с редки изключения

70 потребители гласуваха. 19 потребители се въздържаха.

Източник: www.habr.com