Позбавляємося страху перед першим працевлаштуванням

Кадр з к/ф «Гаррі Поттер та в'язень Азкабану»

Проблема цього світу в тому, що виховані люди сповнені сумнівів, а ідіоти сповнені впевненості

Чарльз Буковскі

Нещодавно я проводив чергове індивідуальне заняття з програмування. На відміну від звичайних занять, темою стала не конструкція мови та не проблема під час вирішення завдання. Студент поділився своєю турботою на тему майбутнього працевлаштування. Сам учень був досить кмітливим. Один із тих, хто приходить на курси, проходить всю програму найшвидше і з оригінальними рішеннями, але весь час щиро недооцінює себе. На мій погляд, такі сумніви виникають лише від нестачі інформації. Ця прогалина я постарався заповнити експромтом під час заняття.

Запитання були приблизно такі:

• Щороку з ВНЗ випускається безліч студентів, і вони всі йдуть шукати роботу. Адже це дуже багато людей. Напевно, візьмуть кращих, а мені місця не дістанеться.
• Що якщо я накосячу і мене звільнять?
• Що якщо в процесі роботи вони зрозуміють, що я тупий і виженуть?

Цей студент не був першою людиною, якій я відповідав на такі запитання. Вони виникають у багатьох і зазвичай доводиться розповідати без підготовки. Цього разу я вирішив записати свій монолог у блокнот. Думав, що вийде пара абзаців, а набралося на цілу статтю.

У статті описаний погляд на мій погляд і виходячи з мого досвіду. Однак наш світ дуже різноманітний і в ньому трапляються дивовижні речі. Якщо ви з чимось не згодні або ваш досвід якось відрізняється, то напишіть, будь ласка, коментар.

Стаття писалася від розробника розробників. Однак якщо ви плануєте займатися тестуванням, адмініструванням чи чимось іншим в IT, то частина порад вам теж знадобляться.

Взагалі не наймуть

Коли уявляєш собі, що щороку багато університетів випускають сотні студентів, то стає незатишно. Як конкурувати з таким величезним натовпом?

На жаль, далеко не всі випускники мають достатню технічну підготовку. Спробуйте запитати якогось знайомого студента з універу: як люди у його групі отримують допуск до іспитів з дисциплін на зразок «бази даних» чи «основи алгоритмізації та програмування»? У групі з 30 осіб у найкращому разі знайдеться 3-5 «просунутих» хлопців, які реально зробили самі. Інші просто списують у них, зубрять відповіді на запитання та здають.

Так було, коли я вчився сам. Однак мій досвід міг бути нерепрезентативним. Тому це питання я ставив кільком різним студентам. Відповідь була приблизно такою ж. Відповідачі були з різних ВНЗ та коледжів. Міркування про причини залишу за межами цієї статті. На повноцінне дослідження мене не вистачить, тому я зроблю висновок із фактів.

Серед сотень випускників, лише пара десятків становлять інтерес для роботодавців

Небагато випускників можуть скласти реальну конкуренцію для здібного студента з гарною підготовкою. Втім, навіть якщо ви сумлінно вчилися, то після першої співбесіди вас швидше за все не наймуть. Після другого, напевно, також. Все може скластися добре, проте краще настроїтись не на штурм, а на облогу. Невдала спроба влаштуватись це лише привід провести роботу над помилками та спробувати знову. Про підготовку до співбесід я не розповідатиму. В Інтернеті на цю тему вже написано чимало. Скажу тільки, що у проходженні співбесід є нюанси, для пояснення яких у програмі навчання навряд чи виділено час. Пошукайте цю інформацію самостійно, вона може скоротити кількість спроб.

Безумство — це точне повторення однієї й тієї ж дії. Щоразу, сподіваючись на зміну

Альберт Ейнштейн

Щоб проходження співбесід не перетворювалося на безумство, після кожної нової спроби потрібно ставати краще. Запам'ятовуйте або записуйте запитання, які ви ставили під час співбесіди. Після повернення додому переглядайте цей список і перевіряйте себе за допомогою інтернету. Так ви зрозумієте де помилилися ви, де інтерв'юер. Таке також буває. Повторіть або вивчіть теми, в яких ви погано відповіли, і спробуйте знову.

Крім того, існує яскраво виражена сезонність ринку праці. Грамотні компанії планують найм із урахуванням дат випуску з навчальних закладів. Навесні вакансій для новачків більше, ніж у решту часу. Однак і конкуренція в цей час вища.

Тупий - звільнять

Коли беруть на роботу людину без досвіду, до неї є відповідні очікування.

Від новачка на роботі очікують:

• Знання загальної технічної бази
• Вивчення особливостей предметної галузі компанії
• Освоєння використовуваних інструментів та практик

У деяких організаціях для новачків організують навчальні курси за технологіями, інструментами та місцевими порядками, що використовуються. Наприклад, правила хорошого тону при використанні корпоративної пошти, порядок зміни документів у вікі, місцеві особливості роботи з VCS та баг-трекером.

Ще бувають технічні вступні курси, але їхня корисність сумнівна. Якщо справа дійшла до працевлаштування, то наймачі переконалися, що ви маєте якийсь достатній рівень знань. Найкраще такі курси просто пройти сумлінно, як невелику формальність. Можливо в них справді буде щось корисне.

Коли ви приступите до роботи, пам'ятайте, що новачкові точно не доручать рішення термінового, складного та водночас важливого завдання. Швидше за все буде лише одна з цих властивостей. Або просте, але термінове: поправити верстку, переслати комусь якийсь файл, відтворити проблему. Або складне, але без будь-якої надії на завершення — заради того, щоб новачок зібрав більше граблів. Або важливе, але експериментальне. Наприклад, проект, який всі давно хочуть, але не можуть виділити час на реалізацію.

Завдання щодо освоєння інструментарію будуть «складними» та штучними. Швидше за все, це буде спрощений варіант основної системи. У подібних завданнях використовується той самий стек технологій і ті ж терміни з предметної галузі, що у всьому проекті. При цьому результат виконання не надаватиметься кінцевому користувачеві. Це може демотивувати, але цьому настрою краще чинити опір. Штучне завдання треба робити сумлінно, начебто від нього залежить доля проекту.

Результат вирішення вашого першого завдання складе перше враження про вас у колег, яких не було на співбесіді.

Інший варіант завдання на освоєння інструментарію це «запустити проект на локальній машині/тестовому середовищі». Іноді цей процес описано в інструкції. Але вони, як правило, старі та місцями неактуальні. Можна принести реальну користь проекту, якщо написати нову інструкцію з уточненнями з проблем, що виникли. Напевно, у ВНЗ доводилося писати РГР для звіту з якихось дисциплін. Тут майже те саме. У документі мають бути відображені дії, які слід виконати для запуску.

Зазвичай дії для запуску продукту на тестовому середовищі приблизно такі:

• клонувати репозиторій, перейти на якусь гілку або тег
• оформити якийсь конфігураційний файл
• підготувати структуру бази даних
• наповнити її тестовими даними
• виконати складання або компіляцію проекту,
• запустити набір консольних скриптів у певній послідовності

У процесі запуску системи локально неминуче виникатимуть непередбачені проблеми.

Знайдені рішення проблем потрібно дописувати до інструкції з розгортання. Тоді наступного разу при дотриманні інструкції ці проблеми вже не виникатимуть. При заповненні конфігураційних файлів та викликі скриптів, потрібно звертати увагу, яке значення де використовується, і з чим воно має співпадати. Наприклад, якщо проект збирається за допомогою CI-системи і потім запускається скриптом, то важливо зрозуміти куди писати ім'я гілки або номер комміта. Буває так, що скрипт передбачає передачу IP-адреси або DNS імені бази даних, її логіна та пароля. У цьому випадку потрібно знати яку саме адресу використовувати для тестового оточення, які там є логіни і які паролі для них потрібно вказати.

Деякі завдання можуть здаватися простими для досвідчених розробників і викликати складнощі у стажерів. Це нормальне явище.

Розробникам щодня доводиться вирішувати технічні проблеми. Досвідчені співробітники безліч проблем вже вирішували раніше, а новачкам ще тільки доведеться впоратися з ними. Найкращою тактикою буде запис усіх помилок, що зустрічаються, в документ «вирішення проблем з ${назва задачі}». Для кожної проблеми потрібно сформулювати гіпотезу про причину, знайти в Інтернеті варіанти вирішення та по черзі їх спробувати. Результати кожної спроби також потрібно фіксувати.

Оформлення ваших досліджень у вигляді документа дозволить:

• вивантажити із голови дрібні деталі. Наприклад, параметри конфігурації, DNS/IP-адреси, консольні команди та SQL запити.
• згадати «що я вчора робив» коли завдання розтягується кілька днів
• не блукати по колу. Ви завжди зможете прочитати, що робили раніше і зрозуміти, що повернулися до вихідної проблеми
• виразно відповісти на запитання: «що ти зробив за сьогодні?» навіть якщо готового рішення ще немає.

Вам потрібно вміти розповідати про статус своїх завдань колегам

Періодично, колеги будуть цікавитись вашими успіхами та ділитися своїми. На це щодня чи щотижня виділяють небагато часу.

Якщо ви не відстежуєте зустрічені та вирішені проблеми, то опис ваших успіхів виглядатиме як: «Я спробував зробити завдання, але у мене не виходить. Поки що шукаю рішення». З такого оповідання не ясно, чи робив стажер щось або просто сидів хабр читав. Чи потрібна йому допомога? Чи змінилася ситуація відучора?

Якщо вести документ із пошуком рішень, то можна буде сказати «я намагаюся зробити ось це завдання. У мене виникали такі помилки. Такі я вирішив ось так. Ось із цією ще не впорався. Є такі гіпотези і варіанти рішення. Наразі перевіряю їх».

Якщо завдання хоч якось може бути виміряне, то у статусі мають звучати цифри. Наприклад, для завдання «написати юніт тести для модуля» можна сказати «планую зробити 20 тестів, зараз написав 10».

Чим більше подробиць ви повідомите, тим краще ваші колеги будуть розуміти, що ви робили. Це сформує у колег позитивне ставлення до вас і дозволить їм зрозуміти, чи потрібна вам допомога чи ні.

Не соромтеся звертатися за допомогою

Вище я писав, що з появою проблеми, вам потрібно формулювати гіпотезу про її причини та варіанти вирішення. Однак, буває таке, що гіпотези не виправдовуються, а самостійно знайдені рішення проблеми не працюють. У такому разі краще попросити допомоги. Щоб не зловживати увагою колег над кожною проблемою треба посидіти самостійно. Якщо за пару годин не вдалося знайти рішення, настав час шукати поради у більш досвідчених товаришів.

Найкраще почати з питання: «Чи стикався хтось із проблемою раніше?». з коротким описом проблеми. Бажано докласти шматок повідомлення про помилку або скріншот. Це повідомлення вперше краще направити в якийсь спільний чат по роботі. Так ви не відриваєте від роботи тих, хто справді зайнятий. Вільні колеги при цьому побачать ваше повідомлення та зможуть допомогти.

Якщо після повідомлення в загальному чаті ніхто не допоміг, спробуйте спіймати досвідченого колегу під час перерви: обіду, походу за чаєм/кавою, партії у теніс або перекура. Якщо такого не вийшло, то повідомте про свої труднощі на летучці або стендапі.

При вирішенні відомих проблем на цьому все може закінчитися. Якщо ж проблема нова, то розпочнеться розслідування, де треба буде діяти за обставинами.

«Важливі» завдання новачків, які потрібні кінцевому користувачеві, будуть нудні та маленькі. Наприклад «додати додаткову колонку до звіту» або «поправити друкарську помилку» або «реалізувати метод моделі для завантаження атрибутів клієнта з СУБД». Мета таких завдань у тому, щоб новачок ознайомився з предметною областю та вбудувався у щоденну роботу.

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

В описі завдання, у чатах та розмовах зустрічатимуться терміни. Вони можуть виглядати як давно знайомі іменники. Однак у рамках інформаційної системи, вони з'являється особливий, більш точний сенс. Значення виявлених термінів найкраще записувати у спеціальний документ - словник термінів. При додаванні до словника достатньо написати своє розуміння слова, а за справжньою розшифровкою краще звертатися до аналітика. Якщо вона відсутня, то до старожилів проекту. Ведення словника термінів — один із найпростіших способів залучення до предметної галузі проекту.

Як тільки ви порозумієтеся з колегами, вони почнуть бачити у вас не новачка-стажера, а рівного собі фахівця.

Є особливі завдання, наприклад, «написати юніт-тести на модуль». На ній навряд чи можна надовго застрягти з пошуком рішень. При цьому вона є досить серйозною і дається не тільки для навчання стажера. Написані тести збільшують стабільність проекту шляхом зменшення багів у додатку та зменшення часу на тестування людьми. В ідеальному світі юніт-тести пишуться відразу в процесі розробки, але реальність як завжди інша. Буває, що розробник модуля повністю утримує його в голові і не бачить необхідності їх писати. "Все очевидно, що тут тестувати?" Іноді модулі пишуться в авральному режимі, і на юніт-тести не залишається часу. Тож у реальному світі юніт-тестів може не бути. Тому завдання щодо написання юніт-тестів доручають новачкові. Так стажер зможе швидше освоїтися у проекті, а проект зможе заощадити час високооплачуваних фахівців.

Буває, що стажистам та новачкам доручають роль повноцінних тестувальників. Зазвичай перед цим потрібно розгорнути продукт локально та почитати вимоги. Як результат від нового співробітника чекають:

• питання на кшталт «якщо зробити ось так, то вийде ось так. У вимогах цього немає. Як має бути?"
• завдання у баг-трекері «у вимогах написано ось так, а за фактом інакше».

Тестування — надмірна сфера діяльності цієї статті. Якщо вам видали подібне завдання, пошукайте в інтернеті, як найкраще його виконувати.

Накосячиш — звільнять

У нормальній організації, якщо раптом трапиться таке, що недосвідчений співробітник отримає доступ до чогось критичного і що-небудь зіпсує, то винний буде той, хто допустив таке. Тому що новачок за замовчуванням не має доступу до критичної інфраструктури. За адекватного керівництва, спускати всіх собак на недосвідченого стажера не будуть.

Якщо раптом щось трапиться, то звільняти через один інцидент не будуть. На помилках люди навчаються. Стажер, що накосячив, отримав цінний урок і цим сильно відрізняється від інших стажерів. Якщо звільнити того, хто накосив, то на його місце прийде інший і накосячить точно так само.

Головне — вчитися на помилках і більше не повторювати їх.

Якщо ж людина не робить висновків зі своїх помилок, тоді з нею намагатимуться попрощатися. Втім, світ різноманітний. У якійсь бандитській організації можуть одразу з вікна викинути за першу помилку. Але краще таких компаній уникати, навіщо попередньо навести довідки або дізнатися більше під час співбесіди.

Інциденти краще не допускати

Навіть якщо вас особисто не звільнять за одвірок, така подія завдасть небажаних проблем вашій команді та проекту загалом. Тому будьте особливо обережні з операціями видалення або створення таблиць у базі даних, файлів, інстансів сервісів та документів у базі знань з проекту. Якщо ви зустрічаєте адресу нового підключення, уточніть хоча б у двох різних людей, що там можна робити. Перевіряйте свої права на оточення не методом спроб і помилок, а відповідними командами. Наприклад, права на видалення файлів за допомогою команди `ls`, права на роботу з таблицями в mysql за допомогою команди `SHOW GRANTS FOR 'user'@'host';` тощо. Практично у будь-якому інструменті у вас буде подібна можливість.

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

Між стажером та кінцевим споживачем вибудовують кілька бар'єрів.

Якби ви могли відразу віддати свій продукт споживачеві, ви змогли б не влаштовуватися на роботу, а пуститися в «вільне плавання». Але поки у вас немає такої можливості (а заразом і відповідальності), вам потрібно пройти кілька стадій контролю на проекті.
Перша з них – перевірка наставником. Він оцінює рішення новачка з технічного погляду. Якщо наставника не було призначено, то потрібно його знайти. Для цього потрібно вибрати когось із старожилів проекту та на перерві попросити його подивитися рішення: чи правильно вирішене завдання? Якщо почне дивитися та відповідати, значить наставника знайдено. Якщо проігнорує — отже, варто запитати ще когось.

Наступна стадія – Quality Assurance. Російською - тестувальники. По-радянському — нормоконтроль і ВТК. Вони повинні переконатися, що результат роботи стажера відповідає поставленому йому завданню. Вони рідко вчитуватимуться в код. Найчастіше тестувальники перевірятимуть зібраний проект, який розробник зберігає у системі контролю версій.

Третя стадія – реліз менеджер. Окремої людини для цього завдання не може бути, але роль все одно хтось виконує. Він перевіряє, що тестувальники підтвердили, що проект можна випускати. Після цього він виконує дії з доставки продукту кінцевим користувачам.
У дрібних організаціях ці бар'єри з різних причин можуть бути відсутніми. Однак у них не поставлять новачкові завдання зміну чогось важливого. Тому що цей ризик нікому не потрібний.

Потрібно спочатку вплутатися в бій, а там видно буде.
Наполеон Бонапарт

Сподіваюся, що стаття допоможе вам перебороти свою невпевненість та надіслати своє перше резюме. Зрозуміло, що ви попередньо повинні підготуватися. Але не треба надмірно затягувати. Ви, швидше за все, і так уже кілька років провчилися у ВНЗ чи коледжі. Куди далі тягнути? Зрештою, краще один раз почути «ні» від фахівця та провести роботу над помилками, ніж щодня говорити «ні» самому собі та зупинитися у професійному зростанні.

Після працевлаштування потрібно сконцентруватися на тому, щоб вирости зі стажера до повноцінного члена команди. Подібне зростання зазвичай супроводжується збільшенням вашої оплати праці.

Бажаю терпіння та наполегливості.

Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.

Якими були ваші перші завдання на першій роботі в ІТ?

• Складними

• важливими

• терміновими

• Жодне з переліченого вище

Проголосували 75 користувачів. Утрималися 20 користувачів.

Що приблизно доводилося спочатку на першій роботі?

• Встановлювати продукт локально

• Тестувати існуючий продукт

• Виконувати навчальне, несправжнє завдання

• Займатися експериментальним проектом для клієнта

Проголосували 63 користувачів. Утрималися 25 користувачів.

Скільки студентів у вашій групі під час навчання могли самостійно виконати завдання з технічних предметів?

• 1 з 10

• 1 з 5

• Кожен другий

• Все, за рідкісним винятком

Проголосували 70 користувачів. Утрималися 19 користувачів.

Джерело: habr.com